Qualify the extdeps.tools bare-name reads by their declaring module

[gunbai-bot]

Stage 1 of the bare-name-ambiguity campaign, first batch. The census instrument landed in #11078; this is the first of several batches that dissolve the population it named.

What the census says

[floor-bare-name-ambiguity-reads] read_name_module_pairs=105 read_names_distinct=5 — 105 (name, referring module) value-position reads that fall through to the shared name slot, over five names. 23 of them sit under extdeps.tools, which is this PR.

The other half of that line, qualified_name_module_pairs=305, is the mechanism: 305 sites corpus-wide already resolve an otherwise-ambiguous name through an explicit import naming its declaring module. The 105 are the residue that never got it. Nothing here is new machinery — it is the corpus's normal state applied to the sites that lack it.

The three names, and why each import names the module it names

String — declared by std.string_type, not std.types. Ten of these files carried import std.types { String }. That line answers nothing: std.types neither declares String nor imports it, so the name was travelling through the shared slot while the import implied otherwise. The census is unambiguous about the claimants — name=String claimants=std.string_type:other,v2.std.text:other — and std.types is not among them. The bogus name is dropped from the std.types list and import std.string_type { String } added, so the citation names the declaration rather than a module that merely mentions it (§3: cite the symbol, not the position, and not a re-exporter).

Unit — genuinely declared by std.types (type Unit, dag/std/types.dag), so it joins the existing import list. This is exactly the form the single proof site landed in #11078 demonstrates: extdeps.tools.hostname already reads [floor-bare-name-ambiguity-bound] name=Unit referring_module=extdeps.tools.hostname resolves_to=std.types. (That same file is still in the String population, which is the trap above in one file: the Unit half of its import line named the declaring module and qualified; the String half named a re-exporter and did not.)

Filesystem at extdeps.tools.sha256sum is the one judgment site here, and the site's own text decides it. The call is Filesystem.Write(path: …, content: …). extdeps.filesystem.filesystem_io declares service Filesystem with operation Write { input { path: String, content: String } } — an exact match. The rival claimant std.resources declares a resource Filesystem whose capability is lowercase write and which has no Write operation at all, so it could not have served this call. The file already imported extdeps.filesystem.filesystem_io bare; it now names { Filesystem }, the form 82 other files in the corpus already use.

Scope

No renames. Neither declaring side is touched. Every edit is an import line in the referring file.

Deliberately left alone: extdeps.tools.jq and extdeps.tools.sha512sum both carry String in a std.types import list, but the census does not list them in the String read population — their scopes settle the name inside the authored region. Qualifying them would be a sweep over sites this campaign's population does not contain, so the misleading import lines there stay for whoever measures that separately.

Evidence

• [floor-bare-name-ambiguity-read] rows for these 23 (name, module) pairs should be gone from the floor log.
• [floor-bare-name-ambiguity-bound] should name the chosen module for each — std.string_type for String, std.types for Unit, extdeps.filesystem.filesystem_io for Filesystem — which is the claim that matters, since a row merely leaving the ambiguous census only proves the site stopped falling through, not that it now reaches the declaration its author named.
• qualified_name_module_pairs should rise by 23 as read_name_module_pairs falls by 23.
• Every touched module still typechecks and its claims still pass (the floor lane runs them).

🤖 Generated with Claude Code

https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT

[gunbai-bot]

Addressed review 64326. Three of the four findings were right and are fixed in 0675dea; one is not accurate and I've left the code alone rather than change it to match.

Fixed — transcribed instrument output. Correct, and a clean §6 catch. The roster doc carried verdict=FloorClean unexpected_failures=0 plus the planned/executed/claims_failed counts as prose. The counts are gone; the claim now names the claim_executor invocation and the verdict line to read it off.

Fixed — jq and sha512sum left on the other spelling. Also correct. I had excluded them because the census does not list them (their reads are settled inside the authored region), and the first review read that as a deliberate out-of-population deferral. But "not in the measured population" is a reason not to chase a site, not a reason to leave a wrong citation on a line the diff is already editing. Both now name std.string_type, and all thirteen touched files are consistent — none carries String on a std.types import.

Fixed — the roster did not speak to the String requalification. Fair as a gap in the writing: "NO RESOLUTION CHANGES" was about the sha256sum anchor and could be read as covering the whole diff. The doc now says why String needs no row, as the wave phase's measurement rather than my assertion.

Not accurate — the String retarget as a second authority. I don't think this one holds, and the disagreement is factual rather than interpretive, so here is the evidence.

std.types declares no String — the finding establishes this itself. So it was never an authority for that name, and import std.types { String } bound nothing. The two real claimants are std.string_type and v2.std.text, which the census names as the self-host migration double (channel=value_position_only not_covered=type_position_name_collisions owner=v2_self_host_replacement_migration) and explicitly scopes out. Naming one of two existing declarations does not create a third, so there is no fork for §3's replacement-migration rule to bite on.

The decisive part is measured rather than argued. The wave phase compares the binding table on both sides. On this head it reported exactly one TargetChanged binding delta over 814,621 binding rows compared — the sha256sum anchor — and none for String. The ten String sites appear instead as ExplicitlyEvaluatedZeroDelta membership <module> -> std.string_type ... reached by a name this module authors: explicitly evaluated, zero delta. So the read resolved to std.string_type before and after; what changed is its authorization, from an accident of scope precedence to something the author wrote. That is the campaign's whole purpose — the census moved these sites from [floor-bare-name-ambiguity-read] to [floor-bare-name-ambiguity-bound] ... resolves_to=std.string_type.

The finding's live observation is real and I want it on the record, because it is the better half of it: ~1951 modules carry import std.types { String }, a line naming a module that does not declare the name it lists. That is a corpus-wide defect this campaign does not fix. It is harmless only while those modules' reads are not ambiguous — which is exactly the condition that stops holding as the v2.std double resolves. Correcting it is its own change with its own adjudication, not a drive-by in a PR scoped to 23 measured reads.

— sent from witty-moth-510