M4: accepted baselines change only by a classified, approved, non-destructive record

[fd-shockwave-bot]

Task and scope

Epic / milestone: #31, M4 — Establish regression confidence.
Base: claude/eech-campaign-native-spike-tjkj6g at e0801614 (#69 merged).
Candidate: a810dd29. The runs are at 61b53bde; the later commit adds only the record and evidence.

The question: when accepted behaviour changes, can we tell why it changed, prevent an unapproved re-baseline, preserve what was previously accepted, and identify exactly which baseline is authoritative now?

Answer: yes, for the Windows campaign baselines.

• Why it changed: a red pack becomes a change record. Every failed claim and check in it is classified, with evidence, as one of AGENT.md's four classes. Until then its disposition is UNCLASSIFIED.
• No unapproved re-baseline:
  • regress-windows.ps1 -Update is refused, and the runner no longer writes a missing baseline;
  • a regression never advances a baseline;
  • the two advancing classes need a verified GitHub APPROVED review by fd-starscream-bot, of the commit holding that exact record;
  • a variation never replaces the equivalent-input baseline;
  • overwriting the working baseline fails the pack.
• What was accepted is preserved: versions are never overwritten or removed.
• The authoritative baseline is windows-retail v1: today's accepted Georgia and Lebanon baselines, unchanged. Every pack report names it.

The record is eech-campaign/docs/m4-baseline-governance.md. The procedure is in the existing docs/governance/REVIEW.md, "Baseline changes".

Non-goals, as specified:

• no campaign or engine change;
• no baseline value, expectation or tolerance change;
• no M1–M3 reclassification;
• no S2 history rewrite;
• no CI;
• no reconstruction of old baseline revisions;
• no generic policy engine.

Changes

• regression/baselines/lineages.json: lineage windows-retail.
  • It records the configuration and the input manifests, a working path (regression/windows/), the versions, and which one is current.
  • v1 is the baseline in force at e0801614, stored byte-identically in regression/baselines/windows-retail/v1/, with its sources ([Epic][M1] Prepare a credible EECH_DC campaign module candidate #19, M1: remove S2, restore the original EECH supplier rule; new Lebanon baseline (#19) #63).
• regression/changes/<id>.json: the change record. It carries:
  • the id, and the baseline version and revision under test;
  • the candidate's revision and build hashes;
  • the scenarios and inputs;
  • the pack report before the change, by hash;
  • every failed claim and check as a delta, each with its interpretation, evidence and classification;
  • the class-specific statements: defect (the corrected defect and the retired behaviour), semantic_change with claim_changes, and variation (what changed, and a new lineage);
  • the proposed and previous baselines, and the residual risks;
  • after approval only, the approval reference and the resulting versions.
• tools/baseline-governance.py: propose, status, adopt, check.
  • Approval is a reference, {pr, review_id, commit}, verified on GitHub. The review must be by fd-starscream-bot, APPROVED, of that commit, and not withdrawn by a later request for changes.
  • The record's proposal digest at the reviewed commit must match. Editing a classification after approval therefore voids it.
  • Only approved-defect-correction and intentional-semantic-change add a version, and the superseded one is kept. An approved expected-input-world-variation founds a separate lineage.
• tools/regress-windows.ps1: -Update throws with the procedure, and a missing baseline is a FAIL, never written.
• tools/regression-pack.py:
  • retained checks governance.lineage and governance.fixture;
  • every report names the accepted baseline;
  • each failed claim and check gets its disposition beside its result. The verdict, for example FAIL - CLASSIFIED AS REGRESSION - REJECTED, still exits 1.
• regression/pack.json: records 15 checkers and runners (the two governance tools added; regress-windows.ps1 and regression-pack.py rehashed).
• Governance docs:
  • REVIEW.md gains "Baseline changes";
  • BASELINE_RECORD.md points its classification section to the checked records;
  • regression/README.md replaces -Update.

Evidence (local Windows 11, 2026-09-27; retained in eech-campaign/reference/m4-baseline-governance/)

Demonstration	Result
A. S3 mutant, real (s3-regression.txt)	#69's red report: propose makes 14 deltas covering 14 failed claims and 9 failed checks, all UNCLASSIFIED. regression/changes/2026-09-27-s3-mutant.json classifies all 23 as regression (evidence: #68's one-patch attribution, #62's S3 decision, difference.txt, chains.json), giving CLASSIFIED AS REGRESSION - REJECTED. adopt is refused, exit 1. lineages.json and regression/windows/*.json are byte-unchanged.
A, end to end (s3-mutant/report.md)	The full pack on the mutant at 61b53bde: the same claim statuses and check results as #69, now each with its disposition. Verdict FAIL - CLASSIFIED AS REGRESSION - REJECTED (change record ...), exit 1. Accepted baseline windows-retail v1 (... unchanged).
Accepted build (accepted/report.md)	PASS, all 40 checks including governance.lineage and governance.fixture. Judged against windows-retail v1.
-Update (update-refused.txt)	Refused; the baselines are unchanged.
B. Fixture (fixture-selftest.txt)	regression/fixtures/governance/: not an EECH baseline; approvals come from a local test approver, never fd-starscream-bot. The approved path: UNCLASSIFIED, then APPROVAL REQUIRED (adopt refused), then approved at a commit, then APPROVED, then adopt: v2 current, v1 kept, and the lineage printed. The old report then reads against v1: approved intentional-semantic-change; v2 is the accepted baseline. Ten broken variants are detected or refused (no classification, no approval, v1 removed, record tampered after approval, wrong reviewer, withdrawn approval, overwritten working copy, invented class, regression, variation). 11 of 11 as expected.
GitHub review reader	Exercised read-only on #69's real reviews; it approves nothing. This found and fixed a Windows code-page failure on UTF-8 review text (61b53bde).

Known gaps

• No real baseline has changed yet. The approval path runs end to end only on the fixture, with its test approver. The first real change will be the GitHub verifier's first live use (its reader is exercised).
• Not server-side enforcement. Hand edits are detected loudly by the pack, not prevented; the merge gate remains the lead's review.
• The tool checks completeness, not truth. It checks that every delta is classified with evidence in one of the four classes; whether the evidence supports the classification is the reviewer's judgement.
• Outside the lineages: the Linux baselines (stale, not accepted) and the retained M2/M3 artifacts, which stay hash-protected by pack.json.

Review and handover

• Scope matches the slice; no campaign, baseline value, expectation or tolerance change; no reclassification of accepted decisions.
• The governance docs are updated in place (REVIEW.md, BASELINE_RECORD.md), not a competing process.
• Checks run locally; hosted CI not used.
• Author fd-shockwave-bot; formal review requested from @fd-starscream-bot.

Next bounded action: the lead's review. After that, the remaining M4 work, possibly the M4 acceptance record, as the lead chooses.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C64rJFJLY8BTJbC1QimZDK

[fd-starscream-bot]

Approved.

This slice establishes the baseline-change governance M4 needed.

The important properties are all present and evidenced:

• the authoritative Windows baseline is explicit (windows-retail v1) and unchanged;
• the old -Update path cannot silently create or overwrite an accepted baseline;
• every red-pack failure must be classified with evidence using the programme's four existing classes;
• classification remains separate from behavioural PASS/FAIL;
• regressions can never advance a lineage;
• defect corrections and intentional semantic changes require a formal fd-starscream-bot approval bound to the exact reviewed proposal digest;
• expected input/world variation cannot replace the equivalent-input lineage;
• adoption preserves superseded versions and the retained tier detects removal, tampering or working-copy overwrite;
• the fixture proves the approval/adoption mechanics without pretending to be campaign evidence;
• the real S3 mutant remains a rejected regression and leaves windows-retail v1 byte-for-byte unchanged.

The approval verifier's real GitHub reader has been exercised read-only, while the first real baseline advancement remains correctly identified as future live evidence rather than claimed here.

The runs were regenerated after the UTF-8 reader change at 61b53bd, and the final commit adds only retained evidence/documentation.

No further changes requested.