Repair main: the interpreter roster's hand-written denominators are stale

[gunbai-bot]

main is RED and has been since 12:55. Two roster witnesses fail on every PR, so this blocks all lanes, not one. Found while investigating a failure on #7607, which turned out not to be its cause.

What happened

#7562 added the interpreter free-call arm parse_stage0_cargo_manifest_bins and merged with its witness constants still reading the pre-arm values — that is why its own ci was red at merge. #7575 then bumped two of them by one, which looked like the repair but was one short in both, and left the derived-arm constant untouched entirely.

Measured with a binary built from current main:

assertion	asserts	actual
v1_interpreter_derived_arm_count()	182	183
distinct_arm_identity_count()	173	174
authored_spelling_count()	160	161
v1_interpreter_declared_arm_count()	2	2 ✓

Why this was not caught locally — the reusable part

These denominators are derived from Rust macro token lists, so they are a property of the binary, not of the checkout. A target/ built before #7562 reports the pre-arm counts and therefore agrees with the stale constants — the witnesses pass locally and fail in CI, which builds fresh.

I hit exactly this: the two witnesses passed on my machine at the precise failing SHA, which sent me looking for a cause in the diff that was never there. Any local green on these two rows is meaningless unless the binary postdates the last interpreter change.

So the numbers here were measured after an explicit rebuild, not reasoned forward from "one arm was added, so add one". That reasoning would have produced 174/161 and still missed the derived-arm constant at 183 — which is presumably how #7575 arrived one short.

The class, which this repair does not remove

R0 made the roster rows derive from the dispatch, and that half worked — the roster picked up the new arm by itself, with no edit. What went stale is the witness’s hand-typed constant, which nothing derives. So every interpreter arm re-reds a number somebody has to chase, and two PRs touching it the same afternoon raced.

The R1 inversion (v1-interpreter-primitive-dispatch-authority, added to the roadmap in #7598) dissolves this by making the denominator itself derived. Until then these constants stay writable and stale-able, and this will recur.

Verification

24/24 witnesses in the file green by execution, with a binary rebuilt from this branch.

🤖 Generated with Claude Code

[gunbai-bot]

Closing as superseded by #7614, which landed the same repair on main and did it more completely.

We diagnosed the same red independently (#7562 added an interpreter arm and merged with pre-arm constants; #7575 bumped two of them one short and left the derived-arm constant untouched) and measured the same values — 183 derived arms, 174 distinct identities, 161 authored spellings.

#7614 is strictly better and this PR would have regressed main. It updated the assertions and exact_count_witness_note, whose prose cites the same three numbers plus the row count. I changed only the assertions, so merging this on top of #7614 would have reverted that note to 172/159/183 — stale figures sitting in the carrier that explains why the numbers are exact. That is the §3 citation-rot class, and it would have been invisible: every assertion would still pass while the prose beside them lied.

Recording one finding that stands independently of who landed the fix, because it will recur. These denominators derive from Rust macro token lists, so they are a property of the binary, not the checkout. A target/ predating the arm reports pre-arm counts and agrees with the stale constants — both witnesses passed locally at the exact failing SHA, which sent me looking for a cause inside my own diff that was never there. Any local green on these rows is meaningless unless the binary postdates the last interpreter change.

Also worth stating: repair-by-reasoning ("one arm was added, so add one") yields 174/161 — right for two of three, and it misses the derived-arm constant entirely. That is almost certainly how #7575 landed one short and left main red for roughly five hours. Both #7614 and this PR measured after a rebuild instead.

The underlying class survives the repair: R0 made the roster rows derive from the dispatch and that half worked — the roster picked up the new arm with no edit. What went stale is the hand-typed constant beside it, which nothing derives, so every interpreter arm re-reds a number someone must chase. The R1 inversion (v1-interpreter-primitive-dispatch-authority, added to the roadmap in #7598) makes that constant underivable rather than merely correct today.

— sent from clever-crab-111