Refuse an ambiguous bare-name read in the v1 evaluator: the wall, its fixture-authored RED, and the variant-arm tier

[briansrls]

Makes an ambiguous bare-name read a refusal in the v1 evaluator, rather than something the shared name slot silently settles.

The refusal

claim_scope_for now returns a typed AmbiguousBareNameRead refusal when a bare value reference reaches the shared name slot with two transitively-reached declarations spelling it and nothing the author wrote ranking them. Previously scope precedence picked one — a resolution no source authorizes.

It carries its remedy, naming declaring modules. A site authored next week reds someone who never heard of this campaign, in a module they may not own, over a name they did not know was contested. So each row prints the bare name, the referring module, each claimant with the module that declares it and the kind, and a pasteable import <declaring module> { <name> } — plus a warning that an import naming a re-exporter binds nothing. That warning is measured, not hypothetical: copying an adjacent file's import line is how import std.types { String } came to appear in ~1951 modules while binding nothing.

The evidence: a fixture that authors the ambiguity

dag/test/claim/bare_name_ambiguity_wall_witness_test.dag builds a synthetic multi-module source set in which shared_thing is genuinely declared twice and read bare — so the RED is authored rather than waited for. Eight rows:

• subject — a genuine bare value read refuses, pinned to the AmbiguousBareNameRead cause rather than satisfied by any refusal
• two negative controls — a record field label and a function's own parameter sharing the name must not refuse; these separate the value-position projection from the raw free-reference set, which unions field labels
• two arm rows — a singly-declared variant arm, and an arm of the site's own coproduct, must not refuse
• two-coproduct row — asserts the VariantCollision the compile raises, because no scope is ever built there; a control asserting a scope refusal it never observes would be satisfied by a cause it never saw
• two remedy rows — the refusal names a declaring module and carries a pasteable import line

Two geometry facts were measured, not assumed, and are recorded at the rows: the reader must be a containment descendant of one claimant (otherwise v1 refuses the compile with AmbiguousReference and no scope exists — the class this wall covers is the one the compile silently settles by ancestry), and each claimant needs a uniquely-named puller, or only one claimant enters the scope and the arm passes for an unrelated reason.

The discriminating RED has fired

Beyond the authored fixture, the guard itself was shown to be the cause: the seed was built twice with only !ambiguous_reads.is_empty() disabled between them. The two refusal rows flip with it and back; the field-label control holds in both directions. Flipping one way proves a red exists — flipping back, with a neighbour held fixed, proves the guard causes it. The witness names that instrument and states the predicate it decides rather than transcribing readings.

The variant-arm tier

fn_entries walks top-level items only, so an arm of type TestClass = Unit | Hermetic | Integration was invisible to both resolution tiers — five corpus sites read as defects while being correctly written. The tier derives arm owners by walking every top-level coproduct and resolves a site from its own module or its authored import binding, keyed on (module, coproduct): two visible coproducts declaring one arm stay ambiguous, which is the fail-closed direction.

It does not read item.inferred — that branch was removed after the fixture caught it registering every coproduct-returning function as a declarer of its return type's arms. An item's inferred node is its type, not its declaration.

What the climb deletes

The [floor-bare-name-ambiguity-read] census lines, the ambiguous_bare_reads field that fed them, and the memo-equivalence assert over it. Once the wall returns Err before a scope exists, all three could only ever report zero — §4b's "permanently green by construction … worse than absent because it will be cited as coverage." §4b(4) dissolves the production machinery and keeps the evidence: the eight fixture rows stay enrolled. The declaration-grain and qualified-read censuses survive, because they are populated on scopes the wall accepts.

resolution_fingerprint now includes the new tier, so the memo-equivalence witness covers it.

Corpus state

Zero ambiguous bare-name reads remain for the wall to refuse: the sixteen Filesystem/Clock sites were qualified by #11156, and the five variant-arm sites are resolved by the tier rather than excused by a list.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT

[gunbai-bot]

Merge hazard on this branch, recorded before it bites.

This branch (…-wall2) was cut from …-wall (#11143) and therefore inherited the third resolution tier. #11143 has since removed the tier, in response to review 64472 — correctly, because it was landed production behaviour with no discriminating control there, and its controls (the singly-declared-arm row and the two-visible-coproducts row) live here.

So the two branches now disagree about the tier on purpose:

…-wall   (#11143)  tier absent   — instrument only, controls proven
…-wall2  (#11166)  tier present  — tier + wall, controls not yet firing

Merging …-wall into …-wall2 will propagate the removal and silently delete the tier from this PR. Git will do it cleanly — there is no textual conflict, because one side deleted lines the other never touched — so nothing will flag it. The wall would then ship without the tier that stops it refusing five correctly-written variant-arm sites, which is the precise failure the tier exists to prevent.

If this branch needs anything from …-wall (the compile-diagnostics repair is already here), take it as a targeted cherry-pick rather than a branch merge, and verify afterwards with:

git show <this-branch>:src/v1/stage0/src/v1_interpreter.rs | grep -c 'variant_arm_owners\|site_resolved_variant_arm_module'

That should be non-zero. Zero means the tier was merged away.

This is a semantic conflict with no textual signature, which is why it is written down rather than left to be noticed.

— sent from witty-moth-510

[gunbai-bot]

The wall's controlled RED is now authorable, and enrolling it found a defect in the tier.

Pushed 013f1ba5c4. Eight rows, all green by execution against a locally built binary.

Why every arm was a non-verdict before. Once ClaimScopeCompileRefused started carrying its diagnostic rows, the cause was readable instead of inferable: AmbiguousReference: shared_thing. The manifest never compiled, so no scope was built and no control observed anything. v1 already refuses a bare read whose claimants it cannot rank — global_bare_policy_candidate picks the nearest containment ancestor, and where no candidate is an ancestor the compile emits a blocking AmbiguousReference. The old fixtures put claimants and reader in unrelated trees, which is precisely the shape the compile refuses. The class this wall covers is the other one: the read the compile settles silently by ancestry. The geometry now reproduces that settlement (reader amb.user under claimant amb, elsewhere.y unranked), plus a second measured requirement — each claimant needs a uniquely-named puller, because a user that reads only the contested name pulls in one claimant and the arm goes accepted for a reason unrelated to the wall.

What the fixture caught. Both variant-arm rows were red, and not because of the fixture. fragment_coproduct_disj_node read item.inferred, which is an item's TYPE, not its declaration — for fn probe() -> Pick that is the Disj of Pick, so every function returning a coproduct registered as a second declarer of that coproduct's arms. The tier saw two visible owners where the source has one and refused a read the author had named. Branch deleted; both arm rows green in the site's own module and through an explicit import. Nothing in the corpus could have shown this: the phantom owner needs a coproduct-returning function and a contested arm name in one scope.

Row 5 now asserts what actually happens. Two visible coproducts is refused at compile grain as VariantCollision, so the tier's strict arm is unreachable through any manifest the compile accepts. A row claiming a scope refusal there would be a control satisfied by a cause it never observed, so it asserts the compile class instead. The strict arm keeps its honest standing — fail-closed direction, evidence named as the compile wall below it, not a control of its own.

This PR stays in draft and is inside the fleet landing freeze; it also still depends on #11156 / #11138 / #11143 landing before the corpus census reaches zero on the population the wall governs.

— sent from witty-moth-510

[gunbai-bot]

Both failures are one cause, and it is this wall doing its job against a corpus whose repair is held by the freeze.

required-witnesses-floor and witnesses both fail on the same refusal:

CLAIM-SCOPE REFUSAL cause=AmbiguousBareNameRead
scope=v2.test.execution.emit_on_demand_match_loop_fold_family_witness sites=16

The 16 sites are 14 Filesystem reads and 2 Clock reads. I checked the population against the fix rather than assuming it: the referring modules named in the refusal are exactly the set of dag/ files #11156 edits — gunbc.clock_read, gunbc.fabric_event_log_host, extdeps.provisioning.ubuntu_seeded_install_media_remaster, extdeps.realization.materialization_store_local, gunbc.auth.netrc_binding, gunbc.devboot.produce, gunbc.fabric_event_log, the three gunbc.host_effect_*, gunbc.package_delivery, the two gunbc.roadmap*, gunbc.srv3_boot_once_cd, gunbc.tools.bmc_onboard and tools.self_host_curated_seed_linked_harness. #11156 is green and CLEAN; it is held only by the fleet landing freeze on dag/, src/v1/, src/v2/.

So this red is not a defect in this diff — it is the ordering the campaign was designed around: the wall goes green when the qualifications land, and until then it correctly refuses the residue. The refusal text is also the remedy #11156 applies, site by site.

I am not stacking #11156 onto this branch to go green. A merge of it conflicts on src/v1/stage0/src/v1_interpreter_dispatch_generated.rs with GeneratedArtifactConcurrentDivergence — a generated projection both sides changed, whose declared repair route is a full regenerate-and-fixed-point cycle, not a hand resolution. Spending that on a draft PR to manufacture a green that the merge order produces for free is the wrong trade, and hand-resolving those bytes is exactly what the driver refuses.

This PR stays in draft until the freeze lifts and #11156 / #11138 / #11143 land. Its own eight controls are green by execution (013f1ba5c4).

— sent from witty-moth-510

[gunbai-bot]

Merged main (d7b7ab96c) — the population this wall refused is now qualified on main. Head b6cb886a51ce.

#11156 landed, so the sixteen Filesystem/Clock sites this wall was refusing are bound to their declaring services. That refusal was the whole of this PR's floor red: the wall was firing correctly on a corpus whose repair was still in flight.

One conflict, v1_interpreter_dispatch_generated.rs — the generated projection both sides changed (GeneratedArtifactConcurrentDivergence). Main's file taken whole, this branch's three generated rows re-added: 3 insertions, 0 deletions against origin/main. Verified by the gate rather than by that reasoning — claim_executor --required-regen reports first_generation_equal=true, 155/155 planned/executed/adjudicated. That conflict disappears once #11143 lands, since main then already carries these rows.

Staying in draft for one more step, deliberately. I attempted to merge #11143's branch in directly so this PR would carry the two things already adjudicated there — the narrowed slot-competition commentary and the seed-growth receipt — and hit exactly the hazard recorded on this PR earlier: that merge strips the variant-arm tier (variant_arm_owners 5 → 0, site_resolved_variant_arm_module 5 → 0), because #11143's branch is where the tier was removed and this branch is where it lives. Git conflicted rather than silently taking it this time, but the resolved tree had the deletion in it.

So I aborted it. Those two repairs arrive cleanly via main once #11143 lands: main will carry no tier, this branch adds it, and there is nothing to collide. Hand-resolving a deletion into this wall's own detector to save one merge is not a trade worth making.

Verified after the abort: all four tier symbols intact.

— sent from witty-moth-510

[gunbai-bot]

Review 65430's REQUEST_CHANGES is correct on both halves, and I verified each in the code rather than accepting them. Pushed a9285c4f69dc.

1. The read census was permanently zero by construction. The wall returns Err when ambiguous_reads is non-empty, before PreparedClaimScope exists; required_floor_runner reaches built only through claim_scope_for(..)?. So a non-empty population propagates the ? and never arrives at the census — [floor-bare-name-ambiguity-read] and [floor-bare-name-ambiguity-reads] could print zero and nothing else. That is DESIGN §4b's decoration: "permanently green by construction, carrying no information, and worse than absent because it will be cited as coverage."

Deleted under §4b(4), which is what distinguishes this from weakening the floor — a climb deletes the redundant lower-rung production machinery it obsoletes, while the discriminating RED and positive control remain enrolled. The evidence is separate and stays: bare_name_ambiguity_wall_witness_test.dag keeps all eight rows, including the subject that must refuse and the field-label and local-parameter controls that must not. Removed the per-site loop, the summary line, the ambiguous_read_sites map and its population; clippy is clean, so nothing else read them.

2. The annotation falsified itself, and that is the sharper half. It claimed "the census lines in required_floor_runner read this same vector, so the refusal and the count cannot drift apart." After this climb they cannot agree either — the count is structurally silent. Withdrawn and replaced with what is true, including the scope the review drew and I had not: ambiguous_bare_names and qualified_bare_reads are populated on scopes the wall accepts, so they keep carrying information. Only the read half dies, because only it reads the population the wall refuses on.

The review's framing is the part worth keeping past this PR: a climb that leaves its own census standing produces a line that can only ever agree with itself, and the fact that it was my annotation asserting the opposite is what made it findable.

— sent from witty-moth-510

[gunbai-bot]

Review 65520's three findings are all verified and all mine. Pushed 572da555e82c.

1. A merge-blocking clippy red I introduced. ambiguous_claimants_len was bound solely for the [floor-bare-name-ambiguity-reads] line the census dissolution deleted. Removed; cargo clippy --all-targets -p v1-compiler -- -D warnings is clean.

Worth stating why I missed it: I ran --release -p v1-compiler --lib. CLAUDE.md names --all-targets as "the only command that compiles the integration-test and example targets, so a red there is invisible to every other step" — I used the invisible one and reported it as clippy-clean.

2 & 3. Two doc blocks deleted as collateral, not as dissolution. The annotations on compile_dag_multi_module_fixture (27 lines) and multi_module_compile_fixture_value (5 lines) were gone from the tree. §4b(4) authorizes deleting obsoleted production machinery on a climb; these are the scope statement and next-rung-trigger bookkeeping of an instrument that still runs, and §4b(2) requires a class below its ceiling to keep naming its trigger. Restored verbatim from origin/main — git diff origin/main on both files now deletes zero doc lines.

How they went, because the mechanism matters more than the restoration: the duplicate-definition dedup two heads ago walked upward from the function it was deleting while lines started with ///, and swallowed the doc block belonging to the next function. That is the same slice-swallow that took the string_eq doc on #11138 earlier today — second instance, same mechanism.

And the check that would have caught both is one I ran on that PR and not on this one: after any deletion, diff against the tree the deletion was made from and count the doc lines it removes. On #11138 I ran it and it found nothing, because the lost block was my own branch's addition; here it would have worked, because these were main's lines. Two failures, one instrument, and I applied it to the case it couldn't see and skipped the case it could.

— sent from witty-moth-510

[gunbai-bot]

Review 65757's three findings are all correct and all the same class: the climb deleted the census's consumer and left everything that fed it. Pushed 32e7fb76929d.

1. The field was retained write-only. The wall returns Err whenever ambiguous_reads is non-empty and both entry points reach it, so on every Ok path PreparedClaimScope.ambiguous_bare_reads was the empty vector by construction. §4b(4) names the collection into the returned struct as exactly the production machinery a climb dissolves. Field and push deleted.

2. The memo-equivalence assert was vec![] == vec![]. A non-empty population propagates Err through the .expect("memoized scope") above it, so the assertion could not fail. That is the same §4b sentence this diff already quotes to justify deleting the census lines — and I applied it to the printed lines while leaving an assert in the identical state two thousand lines away. Deleted.

The sibling asserts on ambiguous_bare_names and qualified_bare_reads stay: those populations are non-empty on accepted scopes, so those comparisons can still fail.

3. The last citation of the deleted census. The fixture doc still said the wall reads "the same ambiguous_reads vector the census prints from" while this diff deletes that census — §6 rot in the direction the rule warns about, a named instrument that no longer exists.

I also retired two dangling symbol citations the review did not raise. Two historical sentences still named ambiguous_bare_reads after the field was gone, so a reader following them would grep for a symbol that does not exist. Both now say what was deleted without naming a dead symbol; zero mentions remain in src.

The generalizable part, since this is the second time today one of my climbs was half-finished: deleting a consumer is not dissolving a class. The consumer is the visible end; the producer, the field it fills, the asserts that compare it and the prose that cites it all outlive it silently, and each one reads as coverage afterward. The check is to grep the symbol and account for every hit before calling the climb done — which is what I did here only after being told.

cargo clippy --all-targets -p v1-compiler -- -D warnings clean.

— sent from witty-moth-510

[gunbai-bot]

Review 65775's three findings are all correct. Pushed 8798f05be126, and the PR is retitled because the condition its old title named is now satisfied.

1. The discriminating RED has fired. The review is right that I had been treating "the rows are green" as the evidence, and §4b(1) asks for the rung established by executed evidence — a discriminating RED refused on the real acceptance path plus an accepted positive control. Executed by building the seed twice against the same manifest, with only the wall's own if !ambiguous_reads.is_empty() guard disabled between them:

WALL REMOVED    bare_value_read_of_an_ambiguous_name_refuses              false
                the_refusal_names_a_declaring_module                      false
                a_field_label_sharing_an_ambiguous_name_does_not_refuse   TRUE
WALL RESTORED   all three                                                 true

The two rows asserting the refusal flip with the wall and back. The negative control holding in both directions is the load-bearing half: it shows those rows moved because the refusal moved, not because anything about the manifest or the fixture changed. Receipt recorded at the rows with its re-derivation route; the disabling edit is not in this branch and nothing re-derives it.

2. The new tier was invisible to the memo-equivalence fingerprint. resolution_fingerprint claims to cover "every resolution this index set can answer" and did not enumerate variant_arm_owners — so the new memoized fragment field travelled the memo path with zero equivalence coverage, and a divergence there flows straight into whether the wall fires. The fail-open direction is §5's absorbing fallback, which is the one direction a silent divergence must not take. One loop added.

The pairing is the part worth naming: deleting the obsolete ambiguous_bare_reads assert was right, and leaving the new tier uncovered was the regression — both in the same diff. I removed equivalence coverage and added an uncovered field in one change and checked neither against the other.

3. The fixture's acceptance annotation said the opposite of its Rust twin. All three clauses of the old block are false after this change, and the five claim_scope_was_accepted rows are precisely the "rows cited as coverage" it forbids. One fact, two annotations, opposite obligations. Compounding it, my replacement was inserted below the stale block, so the orphan became the leading // block of a function it does not describe — the third time in this branch that the same slice/dedup mechanism has moved prose onto the wrong declaration.

— sent from witty-moth-510

[gunbai-bot]

Review 65808's two findings are correct. Pushed 0b8761cba055.

1. The row projection was hand-copied three times — in compile_diagnostic_census_value, in claim_scope_fixture_value, and in multi_module_compile_fixture_value forty lines apart in one file. §2's test is that "net concepts must not grow by re-invention", and the cost here isn't style: the day CompileDiagnosticCensusRow gains a field, two of the three keep emitting the old shape and the new field arrives NULL at its first reader.

This instrument has already paid that exact price once. The diagnostics field this branch added was declared and never set, and a control died with type error: filter expects a list, got Null. I fixed that instance and then left three producers standing to do it again. One compile_diagnostic_census_row_value, three callers.

2. My §4b(1) receipt was a transcribed table in a comment — and it said in its own words that "nothing re-derives it", which is the confession. §6: "a transcribed number is unreachable from the thing that owns it, so it rots." §4c: "an annotation is never evidence that a machine claim holds, because no Accepted program can read one." A rung resting on prose is what this wall exists to refuse, one level up, and I wrote one into the wall's own witness while correcting other people's transcriptions all day.

Replaced with the two things that are legitimately annotation content:

• The instrument, named so anyone can re-derive it: negate the wall's own !ambiguous_reads.is_empty() guard, rebuild, run these three rows against both binaries.
• The predicate the run decides, stated as what it must show rather than what a run showed: the two refusal rows must flip with the wall, and the field-label control must hold in both directions — because a run where all three move together would mean the rows are keyed on the manifest rather than on the wall, and the pair would establish nothing.

And the next rung is named rather than claimed: the mutation is a hand edit of the seed, not a mode of it, so making it a flag is what would turn this receipt into an instrument.

— sent from witty-moth-510