Re-promote the 35-claim parse-reaching cohort: the residue's release trigger fired at #8565

[gunbai-bot]

Re-promotes the 35-claim parse-reaching cohort that gunbc#8505 declared as residue. The dissolution condition this cohort was waiting on has fired.

The residue, and why it existed

gunbc#8505 promoted 322 claims from inert TestClaim data rows into executing witnesses. Eight of them budget-refused at 1553–1568ms against a 1552ms ceiling — over by 1 to 11ms. The fold reported failed=0: no wrong answer anywhere in 9421 rows. What it reported was eight claims that produced no verdict at all.

An enrolled row that budget-refuses is worse than an unplanned one. Enrollment asserts an expected verdict; a refusal preempts the verdict, so a content defect in those rows would be indistinguishable from the enrolled failure. That is the same coverage-shaped-but-not-coverage state #8505 exists to remove, one step further along — so the rows were unpromoted rather than quarantined, leaving them visibly uncovered instead of falsely covered.

The cut was scoped by reachability, not by the observed eight: every claim in these three files reaches grammar preparation through a shared zero-arg helper (body_lowering_normalized_module, body_lowering_parsed_fn_decl, body_lowering_parsed_tree), so the cheap rows were cheap only because a prior claim had already paid and they hit the call memo. A non-payer's measured cost is not evidence of what it costs as a payer. Dropping the observed eight would have promoted their replacements into the identical refusal.

The trigger fired

floor_expected_red chunk_14's note named the condition exactly:

RELEASE TRIGGER: the interner-independent hashing fix (dashboard adhoc-e78c4260-d3a). Once the key is a function of the grammar, the preparation amortises across claims and this cohort is promotable in one motion.

That fix is gunbc#8565, merged 2026-08-19: the cross-claim prepare_grammar memo now keys on hashes of resolved symbol text rather than interner-local ordinals. The measured defect it closes was that reversing only the order in which the same claims are named produced a different digest for the same grammar — so a first payer's stored result was unreachable to anyone who interned differently.

What this PR does

Restores the three files to their exact pre-cut promoted form, taken verbatim from e397169649^ rather than re-derived. Re-deriving a promotion set by predicate is precisely how the byte-offset overflow defect was introduced in this lane (demotion by enumeration where a property was available), so the authoritative prior state is used instead.

Verified by reading back after writing: 7 + 25 + 3 = 35 test fn, zero residual TestClaim rows, three unpromoted files removed. Main's unpromoted copies are byte-identical to the cut's output and nothing has touched them since, so there is no drift to reconcile.

What it deliberately does not do yet

chunk_14's note still describes these rows as unpromoted. That note is rewritten from the measured outcome, not before it. The floor run answers two distinct questions and only the second licenses dissolving the residue:

question	answers
do the 33 rows pass	the prediction gunbc#8540 recorded in main
do they now cost ~200ms rather than ~1550ms	whether the shared first-payer preparation actually amortises

Rows could pass for reasons unrelated to amortisation — a budget policy change, host speed, evaluation order — and a bare pass would dissolve the residue on a premise that never held. Both numbers get posted here, pass or fail.

Standing obligation this discharges

gunbc#8540's merged body states that the 33-row prediction is confirmed or falsified after the cohort is re-run on top of the fix, and that the numbers will be posted. That commitment was recorded against a session that has since closed; this PR carries it.

🤖 Generated with Claude Code

https://claude.ai/code/session_015P8uZha7JWXtQDb6wNhyfU

[gunbai-bot]

Both measurements, posted pass or fail as promised — and they disagree

Floor run 32305275924 on the re-promoted cohort:

required-floor: planned=9721 executed=9721 terminal=9721 passed=9415
  known_red_held=306 failed=0 stale_quarantine=0
  interrupted_before_verdict=0 completed_over_cost_requirement=0
  host_tool_unresolved=0 over_cost_line_diagnostic=34

1. Do the 33 rows pass — CONFIRMED

All 35 claims execute and reach a verdict. failed=0, interrupted_before_verdict=0. This discharges the commitment gunbc#8540 recorded in main.

2. Do they now cost ~200ms rather than ~1550ms — FALSIFIED

All 35 cohort costs, sorted:

136  178  1806 1865 1865 1876 1879 1879 1888 1894 1895 1896 1899 1960
1970 1974 1985 1986 1988 1992 1992 1994 1995 1995 1998 2006 2015 2025
2027 2037 2046 2100 2118 2138 2210

Median 1986ms. 33 of 35 rows pay full price. Nothing amortised.

The rows pass because gunbc#8533 moved the ceiling from 1552ms to 10000ms — not because the cost went away. This is precisely the confound the PR description named: "rows could pass for reasons unrelated to amortisation, and a bare pass would dissolve the residue on a premise that never held." It did, and it would have.

The cold cost was never what the old numbers said

The eight rows that budget-refused reported 1553–1568ms. That is the old ceiling plus a scheduler quantum — where the interruption landed, not what the row cost. Their true cost, visible for the first time now that the ceiling accommodates them:

row	old (interruption point)	now (actual)
arrow_token_holds	≥1559ms	1865ms
has_plus_token	≥1554ms	1879ms
match_arms_found	≥1553ms	2037ms
match_first_arm_wires	≥1556ms	2015ms
match_swapped_arms_normalize_accepts	≥1558ms	2138ms
normalize_accepts_match_module	≥1553ms	2118ms
normalized_module_has_match	≥1553ms	2100ms

This closes a gap that made the 1552ms ceiling's own derivation unassessable: it was computed as a measured-max over rows that complete, and an interrupted row contributes its interruption point rather than its cost — so the calibration sample systematically excluded exactly the rows being refused.

What this leaves open

gunbc#8565 made the memo key content-addressed and demonstrably fixed the order-dependent digest. No amortisation followed. Either the memo still misses for a reason the key change did not address, or the ~2000ms was never grammar preparation and the residue note's cost model was wrong from the start. Both are live; neither is asserted here. Recorded against the memo class (adhoc-e78c4260-d3a) rather than in this PR.

chunk_14's note is deleted rather than amended — its subject is gone, and its stated premise for re-promotion turned out to be false, so leaving it edited would preserve a wrong cost model in the roster authority.

— sent from wise-bat-141

[gunbai-bot]

Correction: #8533 split the cost concept, it did not move the ceiling

My previous comment said the rows pass because "#8533 moved the ceiling from 1552ms to 10000ms." That is wrong about the mechanism, and the correct version is more interesting.

#8533 split one number into three. On main now:

knob	value
required_floor_claim_cost_line_ms	1552 — unchanged
required_floor_claim_cpu_safety_limit_ms	5000
required_floor_claim_wall_safety_limit_ms	10000
required_floor_claim_warn_ms	100

The cost line is still 1552. The 10000ms figure is a wall safety limit — a different concept doing a different job. So these rows do not pass because a ceiling rose to meet them; they pass because exceeding the cost line stopped being a verdict and became a counted diagnostic, while the thing that still fails is a safety deadline 3–6× higher. That is #8533's stated cut — cost policy separated from safety deadline.

The falsification is unaffected. The rows still cost 1806–2210ms against an unchanged 1552ms cost line; nothing amortised. Only my explanation of why that is now survivable was wrong.

And the cost line is demonstrably not inert for this population

Worth stating because the natural next worry is that the 1552 policy simply isn't evaluated for these rows. It is. Counting every row in the run whose measured cost exceeds 1552ms, independently of what the fold reports:

34 rows measured over 1552ms
over_cost_line_diagnostic = 34   (reported by the fold)

Exact agreement, including composition — 33 are this cohort, and the 34th is test.claim.occurrence_identity_witness_test.occurrence_identity_typed_ordinal_boundary_refuses_raw_scalar_holds at 1621ms, an unrelated row I neither knew about nor constructed the count from. The two cost counters measure different things and both are honest: over_cost_line_diagnostic counts policy-line excess (34, non-blocking by design), completed_over_cost_requirement counts rows violating a declared per-row cost requirement (0, because nothing here declares one).

So the ~2000ms is a real measured cost, tested against a real policy, counted when it exceeds it.

What that leaves for someone to decide

33 rows now sit 16–42% over a policy line, counted and non-blocking, with no owner named. #8533 made that visible rather than fatal, which is defensible — but visible-and-unowned is a state worth an explicit decision rather than a diagnostic nobody reads. That is a policy question for whoever owns the cost line, not something this PR should answer.

— sent from wise-bat-141

[gunbai-bot]

The honest cost of this PR, stated as a number

Checked against main rather than assumed. Main's most recent green run (32305520689):

planned=9686 executed=9686 passed=9380 known_red_held=306 failed=0
  ... over_cost_line_diagnostic=1

Main carries exactly one row over the 1552ms cost line — occurrence_identity_typed_ordinal_boundary_refuses_raw_scalar_holds at 1621ms. Not zero.

This PR takes that population from 1 to 34. The delta is exactly this cohort: 33 rows, each 16–42% over the line.

That is the price of the promotion and it belongs in front of a reviewer rather than inside a diagnostic nobody reads. Stated plainly:

• What it buys: 35 claims move from inert data rows — planned by nothing, executing nowhere — to executing witnesses that reach real verdicts. failed=0, interrupted_before_verdict=0.
• What it costs: the over-cost-line population grows 1 → 34, non-blocking under Split required-floor cost policy from safety deadline (BUDGET POLICY CUT) #8533's split but real.
• What it does not buy: any amortisation. The premise under which this cohort was promised re-promotion did not hold.

The two counters agreeing across two different trees — 1 on main, 34 here, delta exactly the cohort I added — is also the strongest available evidence that the cost line is evaluated for these rows rather than skipped for them.

I am not arguing that trade is obviously correct. It is a policy decision about whether 33 rows over a cost line is an acceptable price for 35 claims that execute, and it belongs to whoever owns the cost line. If the answer is no, the right response is not to re-shelve these rows — it is to find why every claim reaching grammar preparation pays ~2000ms when the memo was supposed to make that a once-per-subject cost.

— sent from wise-bat-141

[gunbai-bot]

Correction to my own "1 → 34": the baseline is not stable, my contribution is

The second CI run on this branch (32307706966, the commit that deletes a comment block and nothing else) is green — planned=9721 executed=9721 passed=9415 failed=0 — identical population to the first run. But:

run	change vs previous	over_cost_line_diagnostic
32305275924	re-promotion	34
32307706966	deleted a comment	45

Deleting a comment cannot change execution cost. So I decomposed both:

	cohort rows over 1552ms	non-cohort rows over 1552ms
run 1	33	1
run 2	33	12

My cohort's contribution is stable at 33 across both runs. The baseline is not — it moved 1 → 12 with no code change.

What the varying population actually is

Every one of the 11 newly-crossing rows is a live_deploy witness sitting just over the line — 1560, 1566, 1581, 1595, 1611, 1612, 1620, 1623, 1629, 1784ms. And occurrence_identity_typed_ordinal_boundary_refuses_raw_scalar_holds went 1621ms → 2024ms, a 25% swing on one row between two runs of the same tree.

That is a marginal population crossing a fixed threshold under host variance — real, and confined to rows that are not mine. My 33 sit at 1806–2210ms, 16–42% over, and cross in every run because they are nowhere near marginal.

Why this matters beyond bookkeeping

over_cost_line_diagnostic is not a stable metric. It is a fixed threshold applied to a distribution with a marginal band, so its value is a joint function of the tree and the host. Anyone using it as a policy number — to decide whether a violating population is growing, or whether a change made things worse — will read host noise as signal. Comparing two runs on different hosts can show an 11-row "regression" from a comment deletion.

For this PR the honest statement is therefore:

• stable and attributable: +33 rows over the cost line, this cohort, every run
• not attributable to this PR: a baseline that has been observed anywhere from 1 to 12

I stated "1 → 34" earlier as though both halves were facts. The first half was one observation of a variable quantity, and I should have measured it twice before quoting it — which is what the second run did for free.

— sent from wise-bat-141