grammar_relation_row_for_emitted's serve BEATS its recompute over its own consumers — measured, two pairs, and the control everyone was using is biased

[gunbai-bot]

Verdict: the row stays, and it now stands on all three conjuncts rather than two

v2.compiler.translate.grammar_relation_row_for_emitted was enrolled on measured recompute AND
measured sharing before this file's serve-below-recompute criterion existed. gunbc#10141's
carrier-overlap wall then refused it on a neighbour's null result — it serves
v2.test.manual.rust_add_emit_translate, a carrier of the refused rust_target_model_core_edges,
whose refusal was NoMeasuredEffectOverItsConsumers. A null about a different producer is evidence
neither of a cost here nor of its absence, so the honest state was UNMEASURED, not fine.

This PR measures it. The diff is comment-only — annotations are erased from the semantic
projection, so no roster row, no emitted byte, and no resolution result changes.

The arms, and the proof that the arm actually varied

pair	PRESENT	ABSENT
1	33701546412	33701544509
2	33705546522	33705544280

workflow_dispatch on branches, not PRs: CI builds refs/pull/N/MERGE, so a PR pair measures two
different trees the moment main moves. Each pair is one main commit differing in one line.

The independent variable is verified to have varied, not assumed: the key carries 148 fills over
60 consumer modules in both present arms and is wholly absent from both absent ledgers, while the
other five enrolled keys carry identical fill counts in all four runs.

Conditioned on (stated because rust_target_model_staging measured clean beside a wider row and
inherited its regression the moment that row was withdrawn): both bash warm rows plus
bash_fold_serialize_node, formal_productions_from_catalog_node, bash_fold_relation_row_witness
enrolled in every arm; no rust row enrolled in any.

The control everyone was using is biased, and that is the transferable finding

Normalising against rows in no consumer module of any enrolled key reports a ~12% win. That number
is mostly composition. eval_steps is already in required_floor_claim_cost.tsv and is
host-independent, so the subject's own rows split by mechanism: 150 rows whose steps fell (the
serve reached them) against 171 whose steps are byte-identical across arms (same claims, same
runs, serve never reached them). The second group is a control the change provably cannot have
touched — and it moves almost as much as the first.

Rows elsewhere are an assumption about the corpus. Rows doing byte-identical work are an
observation about the row.

Against that control, in both pairs, the serve beats the recompute by roughly a tenth on the rows it
reaches, ~12.7% of their eval_steps avoided, and neither bootstrap interval admits 1. The estimate is
biased toward the null: a row the serve reached whose step count happened not to move lands in the
control group.

The refusal that opened this question is already gone — and observed gone

gunbc#10141's overlap join is now narrowed to refused rows whose verdict records a measured cost:
refused_row_carriers_transfer answers false for NoMeasuredEffectOverItsConsumers, so
core_edges' carriers never transfer and the wall never reaches this key. That is not only designed
away but observed not to fire: floor run 33703215821 is FloorClean with this key enrolled and
core_edges in the refused roster — same roster, same carriers, no refusal.

So this PR asks nothing of #10141. My change is annotation-only in the header above the claim-forced
list, and its author is not editing that header, so there is nothing to rebase around.

One observation left unexplained on purpose

12 claims carry exactly +1044 more eval_steps with this row enrolled — a constant, not a
distribution, across claims of very different sizes. Pre-registered from pair 1 and reproduced
12 of 12 at exactly 1044 in pair 2, so it is structural and deterministic. Two mechanisms are
eliminated in the note: it is not roster resolution (install_pure_producer_share decodes both lists
once per prepared subject) and it is not admission diverting calls from the cheaper per-frame memo
(eval_pure_named_call is reached only when pure_call_memo_key returns None). Cause unknown, and
the file says so rather than carrying a plausible story — an unsupported cause in a carrier is read as
a lead and spends the next reader's time before it spends their doubt.

🤖 Generated with Claude Code

https://claude.ai/code/session_014T3j1sSKhCsKjuiAfpYQeG

[gunbai-bot]

The floor refusal on 2f45189 is not attributable to this diff, and eval_steps proves it rather than argues it

required-witnesses-floor refused run 33701938720 at cost=501ms EXACT — one millisecond over the
per-claim line — carried entirely by
v2.test.execution.rust_emit_host_call_equals_eval.rust_emit_host_call_equals_eval_holds.

That claim is not a consumer of the removed row, and this is measured, not assumed. Its consumer
set comes from the present arm's own [floor-shared-fill] modules= field: the key serves 94 modules
and v2.test.execution.rust_emit_host_call_equals_eval is not among them.

The decisive fact is that its eval_steps are byte-identical across all three runs:

run	arm	cpu_ms	eval_steps
33701546412	PRESENT (row enrolled)	395	173208
33701544509	ABSENT (this diff)	355	173208
33701938720	ABSENT (this diff, PR merge ref)	501	173208

Identical eval_steps means the interpreter did the same work, instruction for instruction, in all
three. The claim cannot have been touched by a roster edit; a 355 → 501 swing on constant work is the
ambient envelope, which is ~41% here. And note the direction: with the row enrolled this claim cost
more (395) than with it removed (355), so the refusal cannot be read as a cost this diff introduced.

So there is no fix to push, and pushing one would be the wrong move. The line-stop is real — a claim
1ms over a 500ms ceiling on work that did not change is a genuine finding about that claim's position
against the line, and it belongs to the near-ceiling subject jolly-ferret-412's lane owns. What it is
not is a defect in this diff. Editing anything here to get green would be tuning the corpus to a runner,
which is what this roster's own header refuses when it says the repair is "stop recomputing", never
"raise the line".

This head remains the ABSENT measurement arm and stays draft. If the verdict is that the row stays, the
PR closes with --delete-branch rather than landing; if the row goes, it is re-authored on top of
gunbc#10141 with a floor_cross_claim_refused_candidates row, never as a bare deletion.

🤖 Generated with Claude Code

https://claude.ai/code/session_014T3j1sSKhCsKjuiAfpYQeG