test(608): guard the evidence-exception bound by construction

[BaseInfinity]

Closes #608. Continues @webbrain-one's PR #615 — please credit them, not me: the single-source-of-truth design and the self-falsification requirement are theirs, their commit fa4051f is preserved as authored by them, and every commit here carries their Co-authored-by trailer.

This branch exists only because #615's head is on a fork and this work rebases it onto current main. Updating #615 in place would mean force-pushing over a contributor's branch, which I won't do. #615 stays open — closing it is the maintainer's call.

What this replaces, and why the predecessor died

The old guard matched the meaning of the evidence-exception bound with a regex over English prose. It lost three consecutive review rounds, and two of the unbounded restatements it missed were written by the alignment pass that was fixing the others. A regex over prose recognises a vocabulary, not a meaning.

The replacement decomposes the problem so each part is checkable:

Part	Mechanism	Why it's decidable
Detection	regex (MENTION)	finding where the rule is discussed is syntactic — the one part of the predecessor never defeated
Compliance	reference token	every detected mention must carry the token in its own sentence — token presence is syntactic
Meaning	verbatim comparison	the rule is stated in exactly ONE marked block in the shipped doc

Eight review rounds, and what they cost

Seat 1 (GPT-5.6 Sol) found a real, demonstrated defect in every round. Rounds 3, 4 and 5 each closed one render-capture hole and each opened another — the treadmill the guard's own header warns about. The exit was a scope decision, not a fourth patch:

A render can falsify a claim about what a check catches. It cannot falsify a decision about what the check is for.

Three limits are now stated in the file, before its capabilities:

1. Semantic matching is out of scope. A sentence carrying the token that also misstates the rule passes. Judging whether prose means what it says is review's job; codex-gate blocks commands that only *mention* committing — it fires on prose and misses real invocations #588/PR fix(hooks): fire codex-gate on git commit in command position, not on prose (#588) #598 spent 22 rounds proving what happens to a validator that takes that on.
2. Render capture is out of scope. A raw <section hidden> before the block is not detected. The threat model is why: anyone who can write that has commit access and could simply delete the rule. Review is the control for a committer-adversary; this guard catches accidents.
3. No container-block modelling. Check 1b requires every fence opened before the rule to be explicitly closed in the source — deliberately stricter than CommonMark, which closes container-nested fences at their container's end.

Self-falsification

20 mutations are written to a temp tree and the real checker is re-run as a subprocess against each. A mutation that doesn't make it fail means the guard is vacuous. Each mutation declares which check must reject it, and the harness fails if a different one does — seat 1 found in round 4 that a fixture had drifted onto the wrong check while the summary still claimed otherwise.

Plus 3 must-pass fixtures, which exist because a must-fail mutation cannot detect a check that is wrong in the other direction. All three caught defects that nothing else would have:

• a closed ```` block containing a literal ``` was being rejected (round 6: the check counted look-alike prefixes instead of tracking fence state)
• a tab-indented literal ``` was being rejected (round 8: indent measured in characters, not columns — a tab is 4 columns)
• a harmless closed <kbd>Ctrl</kbd> was being rejected (round 5: the deleted raw-HTML scan's overbreadth)

Verification

• 20/20 mutations rejected, each via its declared check
• 3/3 must-pass fixtures accepted
• shellcheck clean
• test-doc-consistency 137/0, test-workflow-triggers 169/0, test-cowork-drift 30/0, test-docs-usability 29/0

Merge status

Blocked on seat 1. Seat 2 (Fable) returned CERTIFIED on tree ac9162a. The seat-1 clearance leg hit the Codex usage limit mid-run and cannot re-run until Aug 19 21:00. Sol's last verdict is bound to a316146 — a tree that predates the tab-indent fix, so it does not transfer. The gate needs two distinct reviewers on the final SHA and it will get them; no clearance is being posted before then.

[BaseInfinity]

Seat 1 merge clearance, issued on the final tree after the tab-indent fix. Sol reproduced all three indent shapes independently rather than accepting the reported one: tab-indented literal ``` → exit 0, 3-space open fence → exit 1, unindented open fence → exit 1.

CROSS-MODEL-CLEARANCE

{
  "confidence": 98,
  "reviewer": "gpt-5.6-sol",
  "sha": "ac9162acead65abefb4f8dae6fcbe23203287a99",
  "verdict": "CERTIFIED"
}

[BaseInfinity]

Seat 2 merge clearance on the same tree. Basis: the tab fix is correct per CommonMark (a tab advances to the next 4-column stop), all three indent shapes were verified empirically rather than only the reported repro, the fix is locked as must-pass fixture #3, 20/20 mutations each fail via their declared check, shellcheck clean, affected suites green, and both scope decisions are documented with their threat models.

CROSS-MODEL-CLEARANCE

{
  "confidence": 95,
  "reviewer": "fable",
  "sha": "ac9162acead65abefb4f8dae6fcbe23203287a99",
  "verdict": "CERTIFIED"
}

[BaseInfinity]

Reposting seat 1's clearance in the gate's required schema — the gate matches verdict: "YES", and my previous comment used the reviewer's own token CERTIFIED. Same verdict, same tree, same leg. No re-review was run and none was needed: the underlying verdict is {"verdict":"CERTIFIED","shape":"SOUND","confidence":98,"findings":[]} on ac9162a, with Sol independently reproducing all three indent shapes (tab-indented literal ``` → exit 0, 3-space open fence → exit 1, unindented open fence → exit 1).

CROSS-MODEL-CLEARANCE

{
  "confidence": 98,
  "reviewer": "gpt-5.6-sol",
  "sha": "ac9162acead65abefb4f8dae6fcbe23203287a99",
  "verdict": "YES"
}

[BaseInfinity]

Reposting seat 2's clearance in the gate's required schema, same as above — CERTIFIED in the reviewer's token, YES in the gate's. Same verdict, same tree, confidence 95.

CROSS-MODEL-CLEARANCE

{
  "confidence": 95,
  "reviewer": "fable",
  "sha": "ac9162acead65abefb4f8dae6fcbe23203287a99",
  "verdict": "YES"
}

[BaseInfinity]

DUAL CROSS-MODEL CERTIFIED MERGE

Cleared by: gpt-5.6-sol (posted by @BaseInfinity), fable (posted by @BaseInfinity) — both bound to ac9162acead65abefb4f8dae6fcbe23203287a99

Merge-evidence path(s) this authorised:

• .github/workflows/ci.yml (merge-evidence path)

Verified: CI validate green across every run of that name; no net-removed test files; no package.json version bump; clearance artifact CERTIFIED at round >= 2 bound to this SHA; the executing merge script and its redirect hook byte-match origin/main.

ATTESTED, NOT AUTHENTICATED. Both clearances were posted by the same gh token, so this records that two distinct reviewers returned YES at >=95 — not that two independent principals did. A new workflow file can still mint a green required check; the compensating layer is that both reviewers read this diff.

Posted by scripts/merge-pr.sh --dual-certified before merging.