Give the fixture instrument a claim scope, with the third resolution tier

[briansrls]

Prerequisite for the bare-name-ambiguity wall, landing ahead of it. Census instrument: #11078. Qualification batches: #11137, #11145, #11146.

Still a draft until the qualification batches merge, because the wall it enables must not land before the corpus is ready for it — but the instrument and the tier below are complete and their controls are run.

Why the wall is NOT in this PR

An earlier revision of this branch carried it, and the required floor refused with the wall's own words:

scope `v2.test.execution.emit_on_demand_match_loop_fold_family_witness`:
16 ambiguous bare-name read(s) refused

That is the refusal working. The corpus still carries 82 measured ambiguous reads because the qualification batches have not merged, so a wall landed now refuses the tree it exists to protect. Weakening it to green the lane would invert the point, so the wall was removed and lands on top of the qualifications instead.

The third resolution tier

site_resolved_fn answered over fn_nodes, which is built from module.items — top-level declarations only. A variant arm is not a top-level item, so a bare read of one matched neither tier and was reported as falling through to the shared slot even when the arm's coproduct is declared in the reading module or imported by name. Measured: five such sites in the corpus census (property: Unit meaning systemd's Unit=; spelling: Int meaning a C++ surface spelling).

variant_arm_owners indexes arm name → (declaring module, coproduct) and resolves only when exactly one visible coproduct declares the arm. Keyed on the coproduct rather than the module because a module-only key cannot tell one coproduct from two in the same module, and would resolve a genuinely ambiguous arm read to whichever matched first — silencing the class the wall exists to catch.

The tier is deliberately stricter than the two above it, which let the site's own module win unconditionally. They can: a top-level declaration in one's own module is the authored answer by construction. Arms carry no such precedence rule — an arm of one's own coproduct and an arm of an imported one are named with equal standing — so two visible coproducts refuse.

Not a new error class: an instance of gunbc.recurring_failure_mode.binding_chosen_by_pool_membership_rather_than_by_the_declared_rule, whose root sentence is this same asymmetry.

The fixture claim scope, and why it was needed

tools.multi_module_compile_fixture routes through compile_to_resolved and never builds a claim scope, so nothing CI executes could reach a refusal living in claim_scope_for. The corpus cannot host the red either — a module authored to carry one would refuse the whole floor rather than sit in it as a probe — and src/v1/stage0/tests/ is compiled by clippy and run by nobody. DESIGN §4b names exactly this remedy: a state unrepresentable in the accepted corpus may still be representable as source handed to the compiler by a fixture.

One detector, not two. The host function calls claim_scope_for_with_memos itself rather than re-deriving anything, so a refusal a control observes is the refusal the corpus floor raises. PreparedRepository is built entirely from the manifest; no corpus root is read.

The controls are run, not described

a_well_formed_manifest_builds_a_claim_scope                        -> true
an_entry_outside_the_subject_reaches_the_caller_as_a_scope_refusal -> true

The two manifests are identical and differ by exactly one string — the entry module path — so the only variable is the scope builder's verdict.

The red is pinned to its cause, and that was falsified rather than assumed. claim_scope_was_refused says only that something refused; such a probe goes green the day an unrelated refusal fires first and is then cited as coverage for a cause it never observed. claim_scope_refusal_names matches the arm and requires the cause to name EntryModuleOutsidePreparedSubject. Pointing the marker at a string the refusal does not contain turns that row false — so the predicate reads the cause, not merely the arm.

ClaimScopeInstrumentRefused and ClaimScopeCompileRefused read false on both polarities, so a ragged manifest fails the positive and negative rows together rather than satisfying whichever was phrased as an absence.

Ordering

Merge after #11137, #11145, #11146. The wall follows this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT

---

v1 seed admission (added for review 64495)

This adds ~170 lines of hand-written Rust to the v1 seed — the host builtin, its projection, the dispatch rows and the registry row. That is growth, and the review is right that the diff did not say why it is admitted. gunbc.v1_maintenance_standing v1_seed_standing sets a strict test: admitted when it serves the v2 self-host program, full stop.

It is growth of an existing, already-reasoned class rather than a new one. The corpus has two nested-compile instruments — gunbc.compile_diagnostic_census and tools.multi_module_compile_fixture — and both route through a host builtin for a stated reason recorded at v1.tests.claim.reference_derived_disposition_census_witness: a nested compile is not evaluable in the interpreter, so the pipeline cannot be called from .dag at all. This is a third instrument of that same kind, for that same reason, one stage further along the same pipeline (scope construction rather than compile).

Why it serves the self-host program, stated so it can be disputed rather than assumed: v2 is emitted by v1, so the v1 resolver's answers are the substrate v2 is built on. A resolution defect in the seed — a bare read settled by scope precedence rather than by anything the author wrote — propagates into everything v1 emits. This instrument is what lets a refusal for that class carry an executable red. Without it the wall is a check whose red cannot fire, which §4b calls worse than absent.

The honest qualification: that argument is about the seed's correctness, not about shrinking the seed, and this change makes the seed larger. I am not claiming it reduces v1. It is admitted on the ground that the class it protects is one v2 inherits, and it is worth a reviewer disputing that rather than my asserting it.

Dissolution trigger — the same one the precedent carries: a nested-execution capability in the interpreter, at which point these instruments stop needing a host builtin and become ordinary .dag. That is the trigger already recorded for the two existing nested-compile instruments; this one does not mint a new one, because it is the same deferral grown rather than a second.

[gunbai-bot]

Review 64472 is right on both findings. Fixed in e445a81, by removing the tier rather than defending it.

The tier had no discriminating control, and that is disqualifying on its own terms. It changes what claim_scope_for reports — five corpus sites leave the ambiguous_bare_reads population the census consumes — and nothing in this diff executed it. The three enrolled rows exercise ClaimScopeAccepted, EntryModuleOutsidePreparedSubject and the memo bound; none authors a variant-arm read, so none goes red if the tier resolves the wrong coproduct or over-resolves.

My earlier defence does not reach it. I argued a control for a wall belongs with the wall. That is true and irrelevant here: the tier is not the deferred wall, it is landed production behaviour shrinking a census population in this diff, and it has to carry its own red.

So the fix is packaging, not new machinery. The tier's controls already exist — the singly-declared-arm row and the two-visible-coproducts row — in #11166's set. The tier goes where they are. That is also the coherent story: the tier exists for the wall, because without it the wall would refuse five correctly-written sites. Landing them together means neither arrives unexercised.

You also correctly identified that the instrument this PR builds is the harness that can author that red. Worth flagging for whoever picks up #11166: I have since measured that authoring an ambiguous read in a fixture manifest does not work yet — the declaring modules are not pulled into the compiled closure, so the read is undefined variable rather than ambiguous. The harness is right; the manifest geometry is unsolved. That is #11166's problem now, and its title says so.

Second finding — transcribed instrument output. Both sites fixed. One left with the tier. The other now names the producer (the required floor job whose control rows re-derive it) rather than copying the observation, keeping the irreducible rationale §4c protects without the transcription §6 forbids. Same point review 64326 made about the admission roster, so the same treatment.

Evidence the removal is clean — all three instrument controls still pass, so they never depended on the tier:

a_well_formed_manifest_builds_a_claim_scope                        -> true
an_entry_outside_the_subject_reaches_the_caller_as_a_scope_refusal -> true
several_distinct_fixture_subjects_all_resolve                      -> true

— sent from witty-moth-510

[gunbai-bot]

Review 64487 — all three findings verified against the code, all three correct, fixed in 4421cdaf.

Two rationale receipts had been silently relocated. Both new functions were inserted by anchoring on an existing fn line, which put them between that function and its doc comment. Rustdoc then attached the older rationale to the newer function and left the original bare:

• compile_dag_multi_module_fixture's block — including "Unlike the census it does NOT arm with_type_ref_hit_ne_bind_measure" — came to document claim_scope_dag_multi_module_fixture, which does not touch that knob at all.
• multi_module_compile_fixture_value's block — including "a compile that never ran must never arrive as FixtureCompileCompleted with an empty diagnostic list" — came to document claim_scope_fixture_value, which has no such arm.

Your §4c citation is the right one. These are §5 rationale receipts, and a receipt filed against the wrong declaration is worse than a missing one, because it reads as authority — a later reader would have taken "does not arm with_type_ref_hit_ne_bind_measure" as a fact about the claim-scope instrument. Both moved back; claim_scope_fixture_value now has its own doc stating what its four arms keep distinct.

Worth naming: this is the same mistake as the import insertion earlier in this campaign, in a different channel. There the anchor was "the last line starting with import" and the insertion landed inside a multi-line import block; here the anchor was the fn line and it landed inside the doc block. Both silent — the code compiles, rustdoc renders — and both visible only by reading what the neighbouring text now claims. I had already learned the lesson once and did not generalise it past imports.

Third finding — a false fact used as a reason. The memo-free path was justified by "whose PreparedRepository is synthesized here and carries an empty subject digest". That was true of the first revision and stopped being true when the digest was made real in e6b56b7; the sentence survived as the stated reason for the design. The reason is the bounded per-subject population, not the digest, so it now says that. This is the sharper half of the finding — a stale comment is noise, but a stale comment load-bearing as a justification invites someone to "simplify" the design by removing a guard whose stated basis no longer holds.

— sent from witty-moth-510

[gunbai-bot]

Review 64493 — both findings verified, both correct, fixed in 17f03f65.

A doc asserting a call the code cannot make. Two blocks said the instrument "runs claim_scope_for_without_memos itself". It calls claim_scope_for_with_memos(…, None, …, Some(reference_index)). And the named function is cfg(any(test, feature = "interp_test_witness")) — so the sentence asserted a call a release build has no function for, while the code's own comment three files away says exactly that. Both now name what is actually called, plus what differs from the floor's call (memo arguments — a caching decision, not a semantic one) and why the obvious spelling is unavailable.

This is the third instance of one pattern in this PR, and I'd rather name it as a pattern than as three defects: prose written against one state of the code and not re-read when the code moved. The others were the stale "empty subject digest" justification and the two relocated rationale receipts. All three compile, all three read as authority, and none is visible except by reading what the text claims against what the code does. The fix for the class is re-reading the prose whenever the call it describes changes — which is what the reviews have been doing for me.

A declaration with no consumer. claim_scope_was_refused was used by nothing: its one caller became claim_scope_refusal_names when that reader was tightened to pin the cause, and I left the weaker one standing. §3c is the right citation. Deleted.

I kept the reason in the surrounding comment rather than just removing the symbol, because that is the part with value: a reader answering "did it refuse" goes green the day an unrelated refusal fires first, and shipping two readers where one is strictly weaker is an invitation to reach for the weaker — re-creating exactly the failure the stronger one exists to prevent. Your note that the file's own comment already argued for its deletion is the sharpest part of the finding: the case against it was written down and then not acted on.

Evidence the removal is clean — both controls still pass after taking a symbol off the instrument's surface:

a_well_formed_manifest_builds_a_claim_scope                        -> true
an_entry_outside_the_subject_reaches_the_caller_as_a_scope_refusal -> true

— sent from witty-moth-510

[gunbai-bot]

Review 64495 — the seed-growth point is fair and the diff did not say what it should have. Added to the PR body rather than pushed, since it is a statement of admission and not a code change.

The finding is right: ~170 lines of hand-Rust into the v1 seed with no stated admission, under an authority whose test is strict — gunbc.v1_maintenance_standing v1_seed_standing: admitted when it serves the v2 self-host program, full stop.

What I found when I looked rather than argued: this is growth of an existing, already-reasoned class. gunbc.compile_diagnostic_census and tools.multi_module_compile_fixture both route through a host builtin for a reason recorded at v1.tests.claim.reference_derived_disposition_census_witness — a nested compile is not evaluable in the interpreter, so the pipeline cannot be called from .dag at all. This is a third instrument of that kind, for that reason, one stage further along the same pipeline. It does not mint a new deferral; it is the same one grown, and it carries the same dissolution trigger (a nested-execution capability in the interpreter).

Where I have qualified rather than asserted: the argument is that v2 is emitted by v1, so a resolution defect in the seed propagates into everything v1 emits, and this is what lets a refusal for that class carry an executable red. That is about the seed's correctness, not about shrinking it — and this change makes the seed larger. I have said so in the body rather than let "serves the self-host program" do silent work. It is worth disputing; I would rather it be disputed than assumed.

Your framing that this is ctrl review policy rather than a DESIGN.md rule, and that §7's declared-row obligation is the repo-side test, is the part that made the answer findable — I went looking for the existing row rather than writing a new justification, and the precedent was already written down.

Noting also that your clean-checks list independently confirmed the two things I most wanted a second pair of eyes on: that every pre-existing claim_scope_for_with_memos caller passes None so production behaviour is unchanged, and that the five-subject row is a real discriminating probe for the bounded-slot property.

— sent from witty-moth-510

[gunbai-bot]

Review 64511 — verified and fixed in 2b751a90. This is the fourth instance of one pattern in this PR, and your framing of why this one is worse than stale is the part that matters.

The claim was false. ScopeAccepted's doc said "and the scope holds no ambiguous bare-name read." The wall was deliberately removed from this branch, and claim_scope_for_with_memos does not refuse on ambiguity — it collects ambiguous_reads and returns them on the accepted scope. grep -c AmbiguousBareNameRead over this branch's cli_run.rs is 0.

Why it was worse than stale. Both positive controls assert through claim_scope_was_accepted. A doc promising "no ambiguous bare-name read" on that arm turns two rows that establish nothing about ambiguity into what reads as coverage for a wall that is not in this diff — §4b rung inflation with a citation already attached, and it would have been cited by someone with no way to know the wall had left. Both the Rust arm and the .dag reader now state what acceptance means and what it is silent about, and point a reader needing the stronger claim at ambiguous_bare_reads.

On the pattern, since four is enough to call it one rather than a run of accidents. Every instance was prose that was true when written and became false when the code under it moved: the without_memos call, the "empty subject digest" justification, the two relocated rationale receipts, and now this. None was caught by compiling. None was caught by me. The habit that would have caught them is re-reading the prose attached to every symbol a change touches — not just the lines the change edits — and that is what these reviews have been doing on my behalf, four times.

I'll note the asymmetry plainly: the code in this PR has held up under review; the prose about the code has not. That is a real quality signal about how I work, not a run of bad luck, and it is worth more to me than the individual fixes.

— sent from witty-moth-510

[gunbai-bot]

Review 64522 — verified and fixed in 971a2efb. This is the worst of the prose defects on this branch, because it cost a real receipt to buy a false one.

The paragraph claimed work this PR does not do. It said "the gunbc#11137 … row is deleted, leaving the roster EMPTY". This PR deletes no row — the roster is already empty at the base, main carries = &[]; and its own RETIRED (2026-09-12): #11137 merged as 34d2a8db32d, and this branch's own merge commit says exactly that. So it was a receipt for work performed elsewhere, written in the first person of a change that did not perform it. §4b(1) and §4c, both as you cite them.

And it was not free. The same hunk deleted the surviving THE gunbc#10671 ROWS DISSOLVED HERE (2026-09-06) record — a real adjudication carrying the three-direction join that established CONSUMED for those four rows rather than asserting it. Net loss of evidence: one genuine receipt removed, one fabricated receipt added, in a file whose entire value is that its history can be read back. You were right to weigh those together rather than treat the addition alone.

The file is restored to main's version byte for byte. This branch has no roster obligation and should touch it not at all, which is now what it does.

The mechanism, since it is the reusable part: my conflict resolution replaced a region of the doc chain instead of taking one side of it, and the replacement swallowed a paragraph neither side was in conflict about. Git flagged the conflict correctly; my resolution is what lost the text. Resolving by region is how you delete text no one edited — resolving by side is not. I had already been bitten once this session by reconstructing a change by hand instead of using git's own recorded hunks, and this is the same lesson in the conflict-resolution direction.

Noting your clean-checks list confirms the parts I most wanted independently verified: one detector via claim_scope_for_with_memos, None on every production caller, and both builders registering nothing.

— sent from witty-moth-510

[gunbai-bot]

Review 64528 — the NonEmptyStr point is right and is applied in be9ae741, but it was not a bare type swap, and the reason is worth recording.

Branding the field broke the instrument:

function 'split' not found in scope
method 'count' cannot be resolved: receiver type 'Primitive()' establishes no method surface

split is declared over String, and the NonEmptyStr brand establishes no method surface of its own — so claim_scope_refusal_names, the reader that pins the discriminating red to its cause, stopped resolving. The Rust built clean; the .dag resolve failed. Committing on a green build would have shipped a PR whose controls silently stop running.

The brand is kept where it earns its keep — on the field, where it makes an empty cause unwritable rather than merely unwritten — and coerced at the one site that reads it (c as String). One ascription, located where it is visible. So your suggestion holds; it just costs a line at the use site rather than nothing.

Falsified rather than assumed, because the coercion sits inside the exact comparison the discriminating arm exists to probe. Three green rows are equally consistent with "the coercion restored the reader" and "the coercion made the reader permissive" — only the wrong-marker arm separates them:

a_well_formed_manifest_builds_a_claim_scope                        -> true
an_entry_outside_the_subject_reaches_the_caller_as_a_scope_refusal -> true
several_distinct_fixture_subjects_all_resolve                      -> true
same row, marker the refusal does not contain                      -> false

On the advisory receipt point: the v1 admission is already in the PR body from review 64495 — it names the existing reasoned class (compile_diagnostic_census and multi_module_compile_fixture both route through host builtins because a nested compile is not evaluable in the interpreter), carries that class's dissolution trigger rather than minting a new one, and states plainly the part that does not fit: this makes the seed larger, and is admitted on the correctness of a class v2 inherits rather than on shrinking v1. Happy to sharpen it if that reads as insufficient.

— sent from witty-moth-510

[gunbai-bot]

Review 64545 — both findings verified and fixed in cf67459a.

Re-invention, with a comment defending it. Containment was hand-rolled as (split(…) |> count) > 1 while the corpus carries string_contains — declared at std.methods, 4,095 call sites, and called by a sibling instrument in the same directory (dag_compile_clean_seam). §2 as you cite it.

The comment made it harder to catch, not easier. It defended the hand-rolled form as "the idiom the corpus already uses for this" — true of the weaker idiom only. I copied a pattern from one neighbouring file and asserted corpus-wide practice from a sample of one, then wrote that assertion down where it would pre-answer the question a reader should have asked. Your phrasing — "true of the weaker idiom only" — is precisely the gap.

The frontier was gestured at, not declared. §3c admits an unconsumed declaration in exactly one form: a named consumer in a named later change with the trigger beside it. "Lands separately and brings its own controls" names neither, and I had thought that sentence discharged the obligation. It now names the consumer (the AmbiguousBareNameRead refusal on session/witty-moth-510-wall2, #11166) and the trigger (the census population reaching zero, which needs the qualification batches and the variant-arm tier).

I added one sentence you didn't ask for: if that refusal is abandoned, this instrument has no remaining consumer and should be deleted rather than retained. A frontier without that clause quietly becomes a permanent resting state, which is how dangling declarations survive.

Evidence — falsification re-run rather than carried over, because string_contains is a different comparison than the one that arm last falsified:

a_well_formed_manifest_builds_a_claim_scope                        -> true
an_entry_outside_the_subject_reaches_the_caller_as_a_scope_refusal -> true
several_distinct_fixture_subjects_all_resolve                      -> true
same row, marker the refusal does not contain                      -> false

Noted your credit on the rung-honesty points; those were the parts I was least sure I'd got right, so it is useful to know they read correctly from outside.

— sent from witty-moth-510

[gunbai-bot]

Review 64893's seed-side receipt is now paid, in the repo's own authority rather than in this PR body — pushed 58a47bc98e.

The review is right that the §3c frontier and the seed receipt are different questions, and that the first says nothing about the second. The repo does resolve the second: gunbc.seed_growth_admission seed_growth_forward_freeze_policy_note makes unenumerated hand growth in src/v1 a stop-line and states exactly what a receipt must carry (item identity, why Rust, owning lane, deletion trigger, current boundary). A PR-body paragraph would not be reachable from the code, so dag/gunbc/claim_scope_fixture_seed_growth.dag carries it as a SeedGrowthJustification row.

What it records:

• The four hand declarations by identity — ClaimScopeFixtureOutcome, build_reference_closure_index, claim_scope_dag_multi_module_fixture, claim_scope_fixture_value.
• Why Rust. The subject is a seed function: claim_scope_for and the PreparedRepository it reads have no substrate representation, and a .dag-side re-derivation of the ambiguity population would be a second detector beside the census — free to drift from the one the floor prints and the wall refuses on. The instrument calls the same claim_scope_for_with_memos the floor's own entry point calls; it is one detector observed from a fixture, not a copy of one.
• The §4b argument, measured rather than asserted. Authoring this fixture found a real defect in the resolution tier it controls (a coproduct-returning function registering as a declarer of its return type's arms) — a shape that needs a coproduct-returning function and a contested arm name in one scope, so it could not have surfaced from the corpus.
• What is not netted, named rather than counted against the additions because seed_growth_deletions_offset_nothing executes that rule: the new parameter and the lifted body are ExistingSeedItemModified, and the three generated dispatch rows are exempt by generation authority, not by my say-so.
• Deltas deliberately not restated. gunbc.rust_item_host_observation derives hand-item and hand-LOC deltas from the diff; an authored copy is the second representation that policy note measured going wrong on gunbc#9095.

Consumed rather than dangling: imported by gunbc.seed_growth_admission and added to seed_growth_justification_roster(), the live population G1 joins against. gunbc compile on that module reports 0 blocking errors.

Thanks for separating the two questions — the frontier answer had been standing in for a receipt it cannot give.

— sent from witty-moth-510

[gunbai-bot]

Item 3 from my side-chat review request is now answered by execution, not by argument.

I asked whether several_distinct_fixture_subjects_all_resolve can actually go red, or whether it is a decoration — the row exists because the per-subject memo is a thread_local bounded at two and the floor already holds both slots, so a fixture that registers would refuse the next real subject. I had measured the failure mode before the fix, but had never watched this row red.

So I ran the falsification: re-armed registration in the fixture path (pass None instead of the scope-private index, so the instrument goes back through the bounded cache), rebuilt, and ran two controls against the same binary.

several_distinct_fixture_subjects_all_resolve   ->  false   (RED)
a_well_formed_manifest_builds_a_claim_scope     ->  true    (unchanged)

The RED is authorable and discriminating: it fires exactly when the fixture occupies a bounded slot, and the neighbouring positive control does not move — which is the difference between a control and a row that reds whenever anything at all is wrong. The arm is reverted and is not in this branch.

That closes the one place where this PR's evidence was weaker than its claim. The other two items I raised — that the builtin calls the same claim_scope_for_with_memos the floor calls with both production callers passing None, and that the seed-growth receipt's trigger names a capability with a complete four-item population — are still with the reviewer.

— sent from witty-moth-510