A rename destination enrolls the declaration set it establishes, not the lines git happened to print

[gunbai-bot]

The observation, and what it was not

The required floor printed exactly ONE [changed-witness] line for the MachineShape construction wall that #9823 renamed into v2.test., though the file declares two sibling test fns — and the one missing was gate_red_synthetic_machine_shape_call, the wall's discriminating RED.

The wall itself is fine, and #9823 delivered what it claims. That run's own disposition receipt (run 33413900349, artifact required_floor_disposition.tsv, 14705 rows) carries both siblings:

…machine_shape_construction_wall.gate_green_synthetic_shape_from_catalog_call  planned_as_changed_witness  passed
…machine_shape_construction_wall.gate_red_synthetic_machine_shape_call         planned                     passed

The RED executed and passed, via the ordinary Planned arm, which prints nothing on a pass. Absence from the log was not absence from execution. No rung was inflated.

The defect that is real

Git detects the rename and prints only the hunks that differ — for #9823, the module line and the removed trailing blank line at EOF. floor_diff_edits_from_line_ranges attributes changed lines to enclosing declarations, the EOF hunk fell inside the last declaration, and so the file's identities were selected by which lines the move happened to edit.

parse_unified_diff_added_paths already rules that a rename to destination is new-at-path — its own comment says the declaration set "is established fresh at NEW". That ruling was only ever used to lift the line-1 fail-closed refusal; nothing acted on the declaration set. For a /dev/null add the two agreed by accident (every line is a + line). For a rename they do not.

Every identity at the destination is a NEW qualified module.function — the authored module name moved with the file — so it has never executed under that spelling.

Population

Measured over the 90 commits reachable from HEAD, replaying the floor's own diff command (git diff -U0 <parent> <commit>, rename detection on by default) and its own attribution rule:

commit	destination	test decls	enrolled
5637e82	src/v2/test/claim/machine_shape_construction_wall_test.dag	2	1
6221198	dag/test/claim/self_host_emitted_call_target_realization_witness_test.dag	35	14
6221198	dag/test/claim/self_host_symbol_identity_binding_witness_test.dag	20	0
d21370b	dag/test/claim/self_host_regen_round_cost_witness_test.dag	10	1
5d56aeb	dag/test/claim/duplicate_definition_binding_probe_test.dag	2	0
5d56aeb	dag/test/claim/filesystem_list_hermetic_witness_test.dag	1	0
5d56aeb	dag/test/claim/sole_constructor_completeness_audit_probe_test.dag	26	0
5d56aeb	src/v2/test/claim/parse/grammar_validation_test.dag	7	0

8 of 8 under-enrolled; 87 of 103 identities missed. Note the zeros: a pure move with no content edit enrolls NOTHING. Every rename since the sublane landed has been silently partial, and this window is a floor on the count, not the count.

Why it matters past the log line

Changed-witness membership is what overrides the cost-debt withhold and the outside-gate suppression (suppress_withheld and the site loop both test changed_witness_set.contains(identity)). The same miss on a cost-debt-rostered identity is a silent DeclinedCostDebt for a witness whose author is present — precisely the state v2.workflow.floor_changed_witness was written for ("a green context that had never looked").

The fix, and why it is not a widening

When a path is in added_paths, its own parsed declaration lines are marked changed. The universe is the file's own decl list, never the corpus — the precise answer to "what does this path declare", not an absorbing "rerun everything" (DESIGN §5). No refusal arm changed; the line-1 fail-closed refusal for in-place modifies is untouched.

Evidence, both directions, run remote in release

• rename_destination_enrolls_every_test_decl_not_only_the_diff_touched_one — feeds MachineShape construction wall may be dormant: test.claim.machine_shape_construction_wall matches no required_gate_prefixes entry, so its RED/GREEN controls may never execute on the required path #9823's verbatim git diff -U0 output for the renamed entry and asserts enrolled == declared. With the fix: pass. Fix disabled: FAILS — proven by execution, not asserted.
• in_place_modify_enrolls_only_the_touched_test_decl — the other direction, so the fix cannot be satisfied by widening: an in-place edit inside one declaration enrolls that declaration and no sibling. Passes under both states, which is what makes the first test's red discriminating rather than a build break.

Note for anyone re-deriving the receipt

gh api repos/.../actions/artifacts/<id>/zip corrupts the download — gh strips null bytes and the zip will not open. Use curl with gh auth token.

Known residue

The declaration-set rule lives in the Rust attribution beside its siblings (the added-path, departed-path and line-1 rules), because that is where the single authority for diff→declaration attribution is today; v2.workflow.floor_changed_witness owns the standing vocabulary, not selection. Moving the whole attribution on-carrier is a separate lane and is not started here.

🤖 Generated with Claude Code

https://claude.ai/code/session_018aiTywconE9bm1hmUPjyft

[gunbai-bot]

Verified this against the tree before answering, and the finding does not hold: the receipt it says is missing already exists, on the carrier, naming the exact symbol this PR edits.

src/v1/stage0/src/cli_run.rs, immediately above FloorDiffEdits:

// SCAFFOLD (DESIGN §6–§7): host-side diff→declaration attribution
// (`floor_diff_edits_from_line_ranges`) and per-entry frontier materialization
// (`rerun_frontier_nodes_for_entry`, `entry_touches_rerun_frontier`) remain host
// realization until provenance ingest lands.
// …
// Dissolve-on: `affected_set_reading_from_git_diff_provenance` + floor-runtime provenance ingest
// expose edit-locus → delete `floor_diff_edits_from_line_ranges`, `rerun_frontier_nodes_for_entry`,
// `entry_touches_rerun_frontier`, and the inline floor-runner `resolve_entry_with_index` (census:
// `rg 'floor_diff_edits_from_line_ranges|rerun_frontier_nodes_for_entry' src/v1/stage0/src/cli_run.rs`
// must be empty).

That is a declared scaffold citing §6–§7, with a named capability trigger (not an artifact — §4b(3)'s distinction) and a mechanical census whose emptiness is the retirement condition. floor_diff_edits_from_line_ranges is the function this PR changes. The area is already seed-retained, already declared, already countable.

On each specific artifact the review asks for:

• "deleted scaffold path" — there is none to report, because this PR deletes no scaffold and adds none. It corrects a rule inside a body already declared for deletion under the trigger above. No new Rust file, no new module, no new parallel authority.
• "census shrink before/after" — the census that governs this area is the rg above, and its terminal condition is empty, not smaller. It does not move on a behavioral fix to a function that remains, and reporting a before/after on it would be a number with no independent referent (DESIGN §5's oracle rule).
• "explicit deferral naming a lane and concrete ROADMAP row" — the deferral exists and names its trigger; the PR body's Known residue section restates it. DESIGN §7's actual requirement is "a declared row with a reason and a migration trigger", which is satisfied verbatim.

I also checked whether the "Pure Bootstrap hand-Rust gate" exists as stated. DESIGN §7 contains none of these three artifacts — its rule is the declared-row-with-trigger sentence quoted above. The phrase "Pure Bootstrap receipt" occurs exactly once in the repository, in dag/extdeps/realization/emit_on_demand_host.dag, and it is scoped there to admitting a new Rust boundary: "no new Rust file or parallel key authority is admitted." That is the case this PR is not. No CI step references such a gate; the hand-Rust ledger that does execute (test.claim.cli_run_hand_rust_area_ledger_witness) asserts area dispositions — that no live area carries a GenerateNow row — not per-diff receipts, and it is green here.

For calibration rather than as an argument from precedent: #9809 (100a6128aa), merged to main this same day, added 197 lines of hand-Rust to this exact file plus 268 to cli_run.rs and 275 to v1_interpreter.rs, with no such receipt requested or supplied. This PR adds 35 lines to that file, all inside the already-declared scaffold body.

What I am not disputing is the underlying §7 concern — the seed must shrink, and adding to it needs an answer. The answer here is that this is a correctness repair to machinery already rostered for deletion under a named capability trigger, fixing a class measured at 8 of 8 rename destinations and 87 of 103 identities under-enrolled, whose discriminating RED is proven by disabling the fix.

One thing I judged genuinely worth doing and deliberately did not push: a cross-reference from the new rule in required_floor_runner.rs to that scaffold row in cli_run.rs, since a reader of the rule does not see it. I am holding the head stable at 7f9f3e0e92 because an auto-merge is armed on that exact sha with --match-head-commit, and a two-line citation is not worth invalidating it plus a ~35-minute CI cycle. Say the word and it lands in this PR or a follow-up.

— sent from fierce-otter-51

[gunbai-bot]

Correction to this PR's empirical claim (posted after merge; the attribution repair itself is unaffected).

This description states the under-enrollment population as measured over "the 90 commits reachable from HEAD". That window is not a repository history. The worktree it was derived in is a shallow clone — git rev-parse --is-shallow-repository returns true and a .git/shallow file is present — so git rev-list HEAD is truncated, and every rename older than the truncation is unmeasured.

The honest form of the finding is therefore:

at least 87 of 103 identities missed, across the 8 measured rename destinations, within the truncated reachable window

not "87 of 103" as a corpus census. The figure is a lower bound, and it is conservative in the safe direction — the real population can only be larger — so nothing that was decided on it is invalidated. The defect, the fix, and the discriminating evidence (the enrollment probe reds with the fix disabled while the in-place-modify control passes in both arms) all stand exactly as recorded.

Recording it here because this is where the number is durable: the count travelled upward into a prioritisation argument and a program plan, and a figure that travels loses its qualifier first. Anyone needing the true corpus count must re-derive it after a full-depth fetch; nobody should read this PR as having done so.