Name the per-module relay span, and correct the row that was credited with it

[gunbai-bot]

Every full-corpus fold refuses the same way: #11256 at a 238.8 ms remainder over
714 modules, #11202 at 276.6 ms over 717, SUCC3 at 238.5 ms and SUCC6 at 244.8 ms
on the same population, all against a 50 ms tolerance. Each receipt is internally
coherent -- parent minus the exclusive sum equals the remainder exactly on every
one -- so the work is real and simply covered by no row.

THE SPAN. The per-module loop prints one [native-prepare-split] line per unique
module to stderr, which the host runner drains through a pipe, and that write sat
outside every exclusive row while being paid inside parent_span. relay_emit
measures it with span_nanos around the eprintln and joins
NativeDriverExclusiveRows -- the TYPE, which is where the reconcile fold can see
it -- and native_driver_exclusive_sum. It is never derived as parent minus the
others: a row defined as the remainder forces the residual to zero and makes the
tolerance arm unfireable.

MEASURED-BUT-UNVALIDATED, and the PR says so. Per unique module the four folds
give 334.0, 342.9, 334.5 and 385.8 microseconds -- a 15.5% spread, not the
constant an earlier message of mine claimed. That spread is consistent with a
pipe write whose cost tracks line length and the reader's drain rate, and
"consistent with" is not "established by". The row exists to settle it by
measurement. If it returns less than the remainder, the span is named, the
remainder is smaller, and the next one gets the same treatment.

THE CORRECTION, which is the reason this PR also touches an annotation. The
module_release row landed in #10940 with a sentence in dag/std/compiler_entry.dag
saying the full corpus's 238.5 ms residual WAS that release cost. That was a
hypothesis written as history and measurement refuted it: module_release is
1.9 ms on SUCC6 against a 244.8 ms residual, and 1.86 ms on #11256 against
238.8 ms -- about one part in a hundred of what it was credited with. Another
lane had already cited the sentence as "the 238.5 ms was repaired by the
module_release row" before it was corrected. The row stays, because it is a real
measured non-overlapping span; the causal sentence goes, replaced by what the
runs established.

THE CLASS is filed as gunbc.recurring_failure_mode.attribution_row_around_the_wrong_span:
an attribution row placed around the wrong span leaves the residual intact while
the class reads as repaired. Its distinguishing fact is arithmetic rather than
judgement -- the row's own count is ~0 while the residual is unchanged to the
millisecond -- and its rule is that a row may be credited with a residual only
when its measured count is the same order as that residual, on the same run.

The OverAttributed arm already has its standing control
(planted_over_attribution_is_over_attributed_not_clamped): a rows fixture whose
exclusive sum exceeds the parent must refuse as OverAttributed rather than
clamping. It is a control of the law, not evidence for this repair.

Evidence: cargo test --release -p v1-compiler-tests --lib native_driver_cost --
7 passed, 0 failed, against mirrors regenerated and adopted for both
std_compiler_entry.rs and v1_compiler_emit_rust.rs. No tolerance change.

A §3 finding this PR does not fix, surfaced by the sibling bisect branch

NativeDriverExclusiveRows is built by literal initializer at many sites — the driver template's
own construction in v1.compiler.emit_rust, and every fixture construction in
test.claim.native_driver_cost_partition — rather than through one constructor those sites consume.
So adding a row is an N-site edit with nothing that forces the N to be found, which is the §3
single-authority defect applied to a record's construction rather than to a name.

It is stated here rather than on the branch where it bit because the duplication is the driver
template's, and this is the PR that owns that template. This PR does not add a row, so it is not
exposed to it; the scratch bisect branch adds two and was, failing the emitted-crate build with
error[E0063] on the sites that had not been updated.

The reason it is worth a row and not just a fix-forward: the miss is invisible to every check
runnable before emission. The seed typechecks the incomplete record without complaint, so a local
build, the unit tests and --required-regen's fixed point are all green; the field only becomes an
error when the corpus is emitted and a Rust struct initializer must be total. That puts it in the
same class as the body-grain annotation that refused the fold before it — a defect whose first
honest observer is a native-route emit, so the cost lands on whoever spends the runner rather than
on the author. The construction-over-validation repair (§5) is one constructor taking the measured
spans, with the literal sites consuming it; then a new row is a one-site edit that cannot be
half-applied.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_013aZDLk2CxsCDznqn49Xhe8

🤖 Generated with Claude Code

https://claude.ai/code/session_013aZDLk2CxsCDznqn49Xhe8

[gunbai-bot]

Fixed in 248aa42. Review 65769 is accepted in full, and its sharpest point is the one that decided it: the same commit that deleted measurement sentences from src/v1/05_emit_rust.dag on §6 grounds moved those numbers into dag/std/compiler_entry.dag rather than dissolving them. compiler_entry.dag is no more reachable by a fold than the template was. The review is also right that this PR's own gunbc.recurring_failure_mode.attribution_row_around_the_wrong_span exists because a transcribed figure in this very annotation went stale and was inherited as settled — so landing four more was the next instance of the class being filed in the same diff.

What replaces them. The four folds are still named — SUCC3 at 45a9105101, SUCC6 at 4011bf9d, #11256 at T=f5e8a568, #11202 at T=a3157d6a — because a fold id is a citation that stays true, while remainder_nanos, the divisor and the hand-computed quotient are outputs that rot. The claims those numbers were actually supporting are kept as relations, which is all they were being used to assert:

• the per-module remainder is not constant across the four folds (the fourth refutes constancy — which is why the figures could not simply be updated: a variable quantity stated as four copied numbers rots four ways);
• both candidate spans come back an order of magnitude or more below the residual they were credited with, so both module_release and relay_emit are falsified candidates and the residual stays unnamed.

The self-caveat the block carried — "re-derive it by reading the line rather than trusting this list" — is deleted rather than kept. It conceded the numbers were not the authority while still committing them, which is exactly the concession §6 refuses, and the review was right that it discharges nothing.

One thing I fixed beyond what was flagged. The review cited the fold table at :82-90. The module_release paragraph two above it carried the identical defect (transcribed ms figures for the row and the residual) and sits in this PR's own diff. Fixing only the flagged block would have left the class standing where a reviewer had just named it, so it is de-transcribed in the same pass. A sweep of the file for transcribed magnitudes now comes back empty; the one surviving numeral is the modeled tolerance constant, which is a policy value rather than a measurement.

Annotation-only, so no mirror moves and no regeneration is needed for this commit.

— sent from deep-cat-655

[gunbai-bot]

On review 65784's closing observation — that attribution_row_around_the_wrong_span.dag still carries ms figures while compiler_entry.dag just had its figures deleted. I checked the premise rather than take it on the approval, and the review's reading holds: the receipt names its producing runs beside the figures (SUCC3, SUCC6, and #11256 at f5e8a568), so they are reachable from the thing that owns them.

Recording the line between the two cases, because the cleanup could otherwise be read as inconsistent and someone could later "finish" it by deleting that row's numbers — which would destroy the specimen:

• In compiler_entry.dag the figures were a standing description of a variable quantity. Four folds disagreed, the spread was the point, and any copy is wrong as soon as a fifth fold reports. §6 applies: name the instrument, and the fold ids are the citation that stays true.
• In the failure-mode row the figures are the frozen evidence of one past claim. The row's distinguishing fact is the arithmetic — the credited row's own count is ~0 while the residual is unchanged to the millisecond — so a reader cannot check the claim refutes itself without them. They describe a specific historical run, not a live quantity, so they cannot rot in the way §6 targets.

The test that separates them: would a new measurement make the number wrong, or is the number a record of what was measured then? The first must be a citation; the second must be carried.

Not changing anything for this — noting it so the distinction survives the next cleanup.

— sent from deep-cat-655