Repository navigation
Qualify the remaining extdeps bare-name reads by their declaring module - #11145
Merged
Merged
Conversation
Second batch of the bare-name-ambiguity campaign (census instrument: #11078, first batch: #11137). 57 of the 105 value-position reads the census names, across 29 extdeps modules outside `extdeps.tools`. Same two names and the same two authorities as the first batch: - `String` is declared by `std.string_type`. Twenty-six of these files carried `import std.types { String }`, which binds nothing: `std.types` neither declares `String` nor imports it, so the read was travelling through the shared slot while the import line implied it had been settled. The name is dropped from the `std.types` list and `import std.string_type { String }` added. Two files -- `extdeps.clock` and `extdeps.entropy` -- read `String` bare without importing it under any spelling at all, and simply gain the `std.string_type` line. - `Unit` is declared by `std.types` (`type Unit`), so it joins the existing list, which is the form the #11078 proof site already shows binding to `resolves_to=std.types`. `extdeps.github.pulls` reads only `String` and so takes only that half. No renames, and neither declaring side is touched. Both this batch and the first are the mechanism 305 sites corpus-wide already resolve through, applied to the residue that never got it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
This was referenced Sep 12, 2026
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 12, 2026
…asured THE CENSUS POPULATION IS NOT STATIC, and that is the finding here rather than the two lines. Main's own floor at 0c93af0 -- with #11137, #11145 and #11146 merged -- reports `read_name_module_pairs=25`, and two of the seventeen `Filesystem` sites in it are NEW: they arrived from another lane in `extdeps.realization.materialization_store_local` and its wet witness, after this batch's population was measured. So sites are being ADDED while the campaign removes them. That matters for the refusal this campaign is building toward: a wall cannot wait for a permanent zero it will never see, because a wall is precisely the thing that KEEPS the count at zero once reached. The landing window is narrow and follows immediately after this batch. Both are the same decision every other site in this batch took -- `Filesystem.Read` / `.Write` are operations of `service Filesystem` in `extdeps.filesystem.filesystem_io`, and no rival claimant declares them. `materialization_store_local` already imported that module with a braced list and simply lacked `Filesystem`; its wet witness had the bare form. QUALIFIED PREDICTIVELY THIS TIME, not reactively, because the mechanism behind review 64402's finding and the six stranded names is now known exactly: A BARE IMPORT RE-EXPORTS THE IMPORTED MODULE'S OWN BINDINGS. `extdeps.clock` imports `v2.std.optional { Present }` and `extdeps.filesystem.filesystem_io` imports `std.types { ... List ... }`, which is why narrowing those stranded `Present` and `List` in files that never mention either module. That makes the risk computable before the edit rather than discoverable after it. For the wet witness the set of names reachable ONLY through its bare import is exactly `{Filesystem}`, so narrowing strands nothing; `materialization_store_local` gains a name and can strand nothing by construction. It compiles at 0 blocking errors. A note on the pre-check, so it is not trusted further than it earns: it OVER-APPROXIMATES. Run over this batch it flags fourteen files where the floor found six, because it unions both narrowed modules' re-exports regardless of which module a given file imports, and counts a name as at risk even when another import already supplies it. It is a candidate list worth inspecting before a push, not a verdict, and the floor's `NewUnresolvedness` deltas remain the authority. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second qualification batch of the bare-name-ambiguity campaign. Census instrument: #11078. First batch: #11137.
57 of the 105 value-position reads, across 29
extdepsmodules outsideextdeps.tools.The technique is proven, not proposed
#11137's floor executed it on 23 sites and reported:
verdict=FloorClean unexpected_failures=0, planned=3757 executed=3757 claims_failed=0read_name_module_pairs105 → 82,qualified_name_module_pairs305 → 334[floor-bare-name-ambiguity-bound]rows naming the authority chosen —String→std.string_type,Unit→std.types,Filesystem→extdeps.filesystem.filesystem_ioThat last line is the claim that matters. A row leaving the ambiguous census only proves the site stopped falling through; the
boundrow proves it now reaches the declaration its author named.The two names, and the trap
Stringis declared bystd.string_type, notstd.types. Twenty-six of these files carriedimport std.types { String }, which binds nothing —std.typesneither declaresStringnor imports it, so the read was travelling through the shared slot while the import line implied it had been settled. The census agrees:name=String claimants=std.string_type:other,v2.std.text:other, andstd.typesis not among them. The name is dropped from thestd.typeslist andimport std.string_type { String }added, so the citation names the declaration rather than a module that merely mentions it (§3).Two files —
extdeps.clockandextdeps.entropy— readStringbare without importing it under any spelling, and simply gain thestd.string_typeline.Unitis genuinely declared bystd.types(type Unit), so it joins the existing list.extdeps.github.pullsreads onlyStringand takes only that half.Why no admission rows are expected here
#11137 produced one
namespace-wave-admissiondelta, and it came from converting a bareimport extdeps.filesystem.filesystem_iointo a named one — a bare module import drags the whole module into the candidate set for every name it declares, so narrowing it also narrowed an unrelated spelling's candidate set.This batch converts no bare import. It only adds named imports and removes a name that never bound. In #11137 the ten analogous
-> std.string_typemembership additions were each classifiedExplicitlyEvaluatedZeroDelta ... reached by a name this module authors, and removingStringfrom astd.typeslist left that module's membership edge intact because the module is still imported for other names.If a delta does appear, it gets an adjudicated row like #11137's, not a widened check.
Scope
No renames. Neither declaring side is touched. This is the mechanism 334 sites corpus-wide already resolve through, applied to the residue that never got it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT