Eight extdeps modules carried no mandatory external-authority anchor

[gunbai-bot]

What was red

v2.lens.mandatory_tag.corpus_scan_witness_test:corpus_live_clean_tree_wall_holds asserts the live extdeps corpus carries no mandatory-tag violation. It started executing on main when #9106 deleted the floor's stale live-tree decline, and immediately found the corpus dirty.

The population

Eight extdeps.* modules carry no extdeps_external_authority_anchor. All eight landed while the witness was declined, in #9509, #9468, #9491 and #9436:

module	anchor now cites
extdeps.git.enumeration	git-scm.com/docs/git-for-each-ref
extdeps.git.worktree_enumeration	git-scm.com/docs/git-worktree
extdeps.bmc.pid_control_decode	phosphor-pid-control README
extdeps.bmc.pid_control_semantic_identity	phosphor-pid-control README
extdeps.bmc.pid_control_representability	phosphor-pid-control README
extdeps.languages.json.number	RFC 8259 §6
extdeps.languages.json.member_conservation	RFC 8259 §4
extdeps.standards.rfc_8118	(already cited — see below)

Each of the first seven gets an inline ExternalAuthority { uri: Uri { scheme: Https, locator: ... } } literal naming the upstream document that module actually reads. The literal form is deliberate: the host scanner does not resolve an anchor declared as a reference to a same-file declaration, and such a module reads as ABSENT.

The eighth is a binding, and the first attempt at it was wrong

extdeps.standards.rfc_8118 already carried the literal — under the name rfc_8118_external_authority_anchor, which the wall cannot see. I first RENAMED it to the conventional symbol, and CI's namespace-wave-admission phase refused that with a NewAmbiguity: test.claim.citation_cit1_consumer_witness cites TWO modules' authorities, and after the rename extdeps_external_authority_anchor resolved to both extdeps.runtime.abi.sysv_amd64 and extdeps.standards.rfc_8118 in one module — the silent last-import-wins hazard, and exactly why the document-specific name exists.

So the two names are not a nickname; they answer different questions. The conventional name is what the corpus wall reads and is per-module, so it collides the moment one reader cites two authorities. The document-specific name is what a consumer imports and is unique tree-wide. The corpus already settles this — extdeps.cpu_attachment.ilm4926 and lotes_azifa072 bind the conventional name to the specific one rather than forking the locator.

The four renamed files are back to main's bytes and rfc_8118 gains that binding instead. It resolves only because of the projection fix below; before it, a same-file alias read as ABSENT, which is what made the rename look like the only option.

One note corrected

member_conservation's header said it "carries no citation of its own". It now names the single upstream fact the anchor rests on — an object is a sequence of members — while keeping the distinction the old sentence was drawing: the reading discipline is ours, the thing it partitions is RFC 8259's.

Verification

The wall's oracle is the host projection behind extdeps_external_authority_live_clean_tree_holds(); cargo test -p v1-compiler --lib extdeps_external_authority_anchor_projection_tests runs it over the live tree, and CI's floor runs the witness itself.

Second commit: the wall was also misreporting one module

Running the wall's own oracle (cargo test -p v1-compiler --lib extdeps_external_authority_anchor_projection_tests) after the eight anchors showed it still red, with one violation left: missing:extdeps.cpu_attachment.lotes_azifa072.

That module is not missing anything. It declares the mandatory anchor as a reference to azifa072_drawing_authority, declared four lines above it in the same file and imported from nowhere — and the host projection followed an alias only through the module's IMPORTS, answering Absent when the symbol named none. Two states with opposite remedies collapsed onto one answer: no anchor declared is an authoring defect, an anchor I did not follow is a defect in the reader.

Reshaping that module to satisfy the reader would have been the workaround, so the reader is fixed instead: the alias's remaining home is the module itself, resolved there, with a per-(module, symbol) cycle key so a self-referential alias refuses rather than recursing.

Two tests hold it from both directions — the local-alias case now projects present/Https/www.lotes.cc/en/contact.php (it read absent before this commit), and the missing-anchor fixture still projects absent, so resolution widened without fabricating presence.

Measured on this tree: 6 passed, 0 failed, including corpus_live_clean_tree_wall_holds_with_aliased_setup_token_cli_anchor, which failed before this commit.

Floor lane: the 46 remaining failures are main's, not this PR's

Main is red (33145062452). Diffing this PR's floor FAIL set against main's own gives exactly one difference, in the right direction:

• only on main: v2.lens.mandatory_tag.corpus_scan_witness_test.corpus_live_clean_tree_wall_holds
• only on this PR: (none)

47 failures on main, 46 here — this PR removes its target and introduces nothing.

[gunbai-bot]

Thanks — review 57231's first two findings were correct and are fixed in a178f288. The third I'm pushing back on.

Findings 1 and 2 (duplicated extdeps authorities) — fixed. Both named declarations exist with byte-identical locators, so the new anchors were re-mints:

• extdeps.git.enumeration and extdeps.git.worktree_enumeration now import git_for_each_ref_external_authority_anchor / git_worktree_external_authority_anchor from extdeps.git and bind the conventional name to them. (The module path is extdeps.git, not extdeps.git.git — the review's git.dag:349/:457 pointers were right about the declarations.) No cycle: nothing under extdeps.git imports either decoder.
• The three pid_control_* modules now consume extdeps.bmc.pid_control_program's authority. That required an importable name, because the conventional one is per-module and cannot be imported into a module that must also declare it — so the program module names its literal phosphor_pid_control_external_authority_anchor and binds the conventional name to that. This is the same split the rfc_8118 NewAmbiguity (CI, namespace-wave-admission) forced earlier in this PR.

Two defects surfaced doing it, both caught by running the wall's oracle rather than by reading the diff: data X: T = with its value on the next line is not accepted by the grammar (five modules unparseable, module index refused all of them), and the module-path panic above.

Finding 3 (hand-Rust gate) — I don't think this applies, and I'd rather say so than add a receipt for a rule I can't locate. Two reasons:

1. I can't find the gate as described. DESIGN's §6 scaffold obligation is over net-new scaffolds, and the authority governing v1 Rust is gunbc.v1_maintenance_standing v1_seed_standing — SemanticsFrozen { maintenance: MaintenanceActive }, whose admission test is PURPOSE (2026-08-20 operator ruling), with MaintenanceAdmissionInstance an explicitly open receipt list, not a membership test. Neither asks for a deleted scaffold, a census shrink, or a ROADMAP row as the price of editing an existing function. If there is a concrete gate I've missed, name it and I'll comply.
2. On the merits it's an admitted change, not growth: this is DefectRepairDiagnosticsMayMove — the seed doing something incorrect (reporting missing: for a module that declares its anchor), not the seed failing to do something it never did. It adds no module, no builtin, no admission row, no public surface — the five MaintenanceRefusal classes are the growth surfaces and it touches none of them. It edits the body of an existing projection and adds two tests.

Worth noting the alternative: satisfying the wall by reshaping lotes_azifa072 to suit a reader that misreports it is precisely the §5 workaround — the corpus is correct and the reader was wrong.

On the floor lane's 46 failures: they are main's, not this PR's. Main's own floor run (33145062452) fails 47; this PR fails 46; the set difference is exactly one row — corpus_live_clean_tree_wall_holds, failing on main and passing here — with nothing new introduced.

— sent from wise-bear-641

[gunbai-bot]

Investigated the two failures at a178f288. There is no fix to push: both are main's red arriving through this branch, and one of them is just the aggregator reporting the other.

Re-derived just now rather than restated from my earlier comment:

• required-witnesses-build — pass (44m47s).
• required-witnesses-floor — phases_run=3 failed=1, FAILED PHASE floor, verdict=FloorRefused unexpected_failures=46. The namespace-wave-admission phase that failed on the earlier head (my NewAmbiguity) now passes.
• witnesses — the aggregation job. It fails because the floor lane did; it carries no subject of its own.

The 46 are main's, verified by set difference and not by eyeballing categories. Against main's own floor run (33145062452):

• main: 47 failures · this PR: 46 · only on main: v2.lens.mandatory_tag.corpus_scan_witness_test.corpus_live_clean_tree_wall_holds · only on this PR: none

So this branch removes exactly its target row and introduces nothing. And main has not moved since that run — origin/main is still 3a8344b5c38, the same commit as its last red run, and it is already merged into this head, so the 46 are the same 46.

A PR run tests the head merged into main, and the floor phase refuses on any unexpected failure. The required check therefore cannot go green on this branch — or on any branch — until main's remaining 46 are closed. They belong to other subjects (sole_constructor audit probes, doc reachability, self-host closure, cost/lens coverage) and are outside this node. A re-run will not help: these are deterministic corpus failures, not flakes.

Independent of CI, the node's own claim is measured green: cargo test -p v1-compiler --lib extdeps_external_authority_anchor_projection_tests is 6/6 on this tree, including corpus_live_clean_tree_wall_holds, which fails on main's tree.

— sent from wise-bear-641