Qualify the last two genuine bare-name reads, and stop at the five that are not

[gunbai-bot]

Final qualification batch of the bare-name-ambiguity campaign. Census: #11078. Earlier batches: #11137, #11145.

It is two lines, because auditing the last seven sites the census names found that only two of them are defects.

The two that are

gunbc.cli_services reads Unit and String in the shell-exit fold (0 => Unit / nonzero => String "..."), the same shape the extdeps tool modules carry. Unit joins the std.types import that declares it; String moves to std.string_type, which is the module that actually declares it.

The five that are not, and why they must not be swept

Each is a bare read of a variant arm, not of either claimant type:

site	name	what it actually means
std.fidelity	Unit	arm of its OWN type TestClass = Unit | Hermetic | Integration
gunbc.live_deploy.unit_standing	Unit	arm of SystemdUnitProperty in extdeps.systemd, already imported by name — the site is property: Unit, the systemd Unit= property
v2.test.lens_cost.valuation	Unit	arm of TestgenLayer in v2.std.verification, already imported by name — the site is layer: Unit
v2.test.manual.infer_ground_add	Unit	same
v2.extdeps.languages.cpp	Int	arm of its OWN type CppSignedIntegerSurfaceSpelling — the site is spelling: Int

None means std.types.Unit, v2.std.cardinality.Unit, or v2.std.integer.Int. Adding an import naming one of those would not qualify a read — it would point a correctly-written site at a declaration whose meaning is different, while the census reported the corpus getting cleaner. That is the worst available outcome, so these are left alone.

Why the census counts them

Its resolver is PreparedScopeIndexes::site_resolved_fn, two tiers over fn_nodes: the site's own module, then the file's import binding. fn_nodes is populated from fragment.fn_entries, and fn_entries is built by walking module.items — top-level items only. A variant arm is not a top-level item, so no arm is reachable under either tier, and a bare read of one is reported as falling through to the shared slot even when it is locally declared or explicitly imported.

Confirmed from the other side too: the census's claimant lists for these rows name only the two type claimants — neither cpp nor v2.std.verification appears — so arms are invisible to the declaration census as well.

This is not a new error class. It is an instance of gunbc.recurring_failure_mode.binding_chosen_by_pool_membership_rather_than_by_the_declared_rule, whose root sentence is exactly this asymmetry: a coproduct arm is pool-visible corpus-wide while not being a local binding under its own spelling.

What this means for the wall

The refusal this campaign is building toward is specified to key on the same value-position population this census reports, and these five are sites that must NOT refuse. The instrument needs a third resolution tier — variant arms of a coproduct the site's module declares or explicitly imports — before a refusal over this population is safe. That tier is not in this PR; it belongs with the wall, and it needs its own discriminating controls.

Where that leaves the campaign

100 of the 105 reported reads are bound to the authority their own module means. The residual five are not qualification targets but the instrument's own next correction.

Worth stating plainly, because it is the campaign's real result: this was funded as a rename campaign and produced zero renames. What it found instead is that the corpus's bare-name ambiguity is qualification residue and mid-self-host migration doubles, plus an instrument that could not see variant arms.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT