main is red: import mutation_status_is_commit_ambiguous from the module that declares it

[gunbai-bot]

main is red on the declarations phase; this is the one-line repair

declarations FAIL IMPORT-MEMBER-ABSENT dag/gunbc/cloudflare/r2_token_mint_run.dag:69:3:
  `gunbc.cloudflare.r2_token_mint_run` imports `mutation_status_is_commit_ambiguous`
  from `gunbc.secret_provision_actuator`, which declares no such name

The symbol has exactly one declaration in the corpus — extdeps.transports.rest at rest.dag:111 — and secret_provision_actuator.dag:238's own annotation already names that as its home ("extdeps.transports.rest mutation_status_is_commit_ambiguous / classify_rest_outcome"). The importing module already imports extdeps.transports.rest at line 8, so this moves one name between two import lists that both already exist. Nothing is renamed, added, or deleted.

Measured on both arms, not asserted

gunbc compile --entry dag/gunbc/cloudflare/r2_token_mint_run.dag, same instrument, same tree except the edit:

arm	blocking	advisory
unfixed (origin/main)	1 — the exact CI wording	815
fixed	0 (132 files emitted)	815

The RED control is the load-bearing half: without it a green would not distinguish "fixed" from "this compiler never checked import members". The advisory count is identical across arms, so the edit moved exactly the one thing it claims to.

One trap for anyone verifying: the compile exits 0 while carrying a blocking error. The N blocking error(s) line is the signal; the exit status is not.

How it reached main, since it is worth not repeating

Corrected: the line came in with #10925 (23598caecca, "The R2 account and bucket are declarations, and the mint refuses before it creates"). An earlier revision of this PR body named #10923; that was wrong and I withdraw it — r2_token_mint_run.dag does not exist on #10923's head at all, so it could not have introduced a line in a file it does not contain. My error was mechanical: I ran git log -S against secret_provision_actuator.dag, the file where the symbol appears only inside an annotation, and attributed the PR that added that annotation. Wrong subject, plausible answer, no check.

The provenance that survives:

#10925 head pushed        04:31:15Z
its floor concluded RED   05:34:30Z   (during the megarac parse outage, red on another file)
it merged                 13:48:36Z   (on that ~8-hour-old verdict)

That red was correctly attributable to megarac_media_attach.dag, not to #10925 — and that is exactly what made merging past it look safe. The floor's own step text says a red "does not establish whether its subject was evaluated"; while parse refuses, the checks behind it do not run, so nothing ever judged this import.

Measured rather than asserted, with a positive control because a zero and a broken grep look identical: in a parse-passing floor log the runner emits required-ci: declarations … lines (2 of them); in the parse-blocked log from that window there are 0, while required-ci: phase matches 5 in both — so the instrument works on the file where the count is zero. One precision owed: declarations is not among the five announced phases (parse, namespace-wave-admission, floor, generated-artifact, regen-fixed-point), though the adjudicator does emit BLOCKING phase=declarations. The announced roster and the adjudicator's phase keys disagree, which is worth someone's attention independently of this PR.

The rule, which is the part worth carrying: attribution establishes that a red is not yours; it does not establish that your own subject was ever evaluated. A stale attributable red and an evaluated green are indistinguishable in the summary and opposite in meaning.

Cut as its own change rather than folded into #10864, the census PR that surfaced it: one PR, one question.

🤖 Generated with Claude Code

https://claude.ai/code/session_016jFtgPtXxTj1kE8wwZUNsG

---

The admission row's own lifecycle, stated so nobody has to derive it

On merge this row becomes CONSUMED, not STALE. The distinction matters because a stale row refuses every unrelated PR in the repository, and a consumed row does not. admission_consumed_at_base decides it, and for a Binding subject it is:

rows.get(&(in_declaration, spelling))
    .is_some_and(|set| set.len() == 1 && set.contains(target))

After this merges, the base binds (mint_r2_object_read_token, mutation_status_is_commit_ambiguous) to exactly {extdeps.transports.rest} — a single-element set, as this PR's own green run reports for the head side. So the predicate holds and the row reports consumed. That is precisely what the target field is for: "a row that cannot name where its name went is not an admission of a relocation."

Consumed rows are not globally blocking — consumed_due = roster_touched && !consumed_admissions.is_empty() — so the row comes due for deletion on the next change that touches this roster, adjudicated by the declaring-module join rather than by anybody remembering. That is the same lifecycle the two #10818 rows just completed: consumed on merge, deleted by the next roster-touching change, which is why the roster was empty at this PR's base.

Who prunes it: whoever next touches NAMESPACE_TRANSITION_ADMISSIONS, because the mechanism will report it due at that moment. If it is still there when I next touch the roster, I delete it. Any blocked lane may delete it too — it needs no permission from me, and the TRIGGER doc-comment beside the row states the condition in the source rather than only here.

— sent from bright-swift-678

[gunbai-bot]

Investigated. The floor red is a real verdict about this diff — and the refusal is a defect in the wall, not in the repair

Good news first, because it is what this PR was for: parse FAILs = 0 and declarations FAILs = 0. The import break this PR exists to fix is gone, and the phases behind parse are lit again. The single remaining blocker is a different one:

namespace-wave-admission (1 unadjudicated delta(s), 0 stale admission(s), 0 consumed admission(s))
NewPoolCoincidenceResolution binding
  gunbc.cloudflare.r2_token_mint_run::mint_r2_object_read_token
  `mutation_status_is_commit_ambiguous` — base {} -> head {extdeps.transports.rest}

base {} is the break: the name resolved to nothing. head {extdeps.transports.rest} is the repair.

Why the wall picked the refusing arm

binding_disposition returns AuthoredReferenceResolution (auto-admits) when authored_here, and NewPoolCoincidenceResolution (refuses) otherwise. authored_here comes from locally_authored_claim_added, whose operative check is:

let names_leaf = |r| r.imports.iter().any(|c| c.members.iter().any(|(m, _)| m == leaf));
if names_leaf(head_record) && !names_leaf(base_record) { return true; }

names_leaf asks whether the module names the leaf in any import — it never looks at which module the import targets. Base named it (from the wrong module), head names it (from the right one), so true && !true = false. The other two branches don't fire either: declares is false on both sides, and the blanket-import count is 1 on both.

This is the exact case the arm was created for. From gunbc.compiler_frontend_program_interlock:

AuthoredReferenceResolution WAS SPLIT OUT OF NewPoolCoincidenceResolution on 2026-08-27, by operator ruling … after the wall refused gunbc#9485 — a one-line import repair that made three dangling names resolve … versus this module's own author writing the import that resolves a name it was already spelling (the repair the wall exists to want). The wall was refusing the second while naming it the first.

My module was already spelling that name — from the wrong target. The predicate can only see a name appearing where it was previously absent, never a name whose source changed, so it cannot recognise the most literal instance of the case it was built for.

The part that decides it is not a style question

Had I written a worse diff — a redundant blanket import extdeps.transports.rest beside the member import that already exists — the third branch would have fired and auto-admitted. So the gate refuses the minimal correct repair and admits the redundant one. Writing the redundant form to satisfy the wall is a workaround in DESIGN §5's sense, and noticing that is the line-stop signal, so I have not done it and will not.

What I have done instead

Escalated, because both remedies are above my authority: an operator-authored transition admission naming this delta (the documented escape — "REFUSES unless an exact operator-authored transition admission names it"), or making names_leaf target-aware, which is a change to a merge-gating wall in the frozen v1 seed. I recommended the admission to unblock now, with the predicate as the durable fix.

No fix pushed here, because every diff I could push either fails the same predicate or games it.

— sent from bright-swift-678

[gunbai-bot]

Attribution, third and final revision: neither PR is wrong in isolation

I have now had this wrong twice in opposite directions, so here is the version with the evidence attached to each half.

#10925 wrote the import line	at 23598caecca, mutation_status_is_commit_ambiguous was declared in gunbc.secret_provision_actuator — verified: git grep -cE "^fn mutation_status_is_commit_ambiguous" 23598caecca -- dag/gunbc/secret_provision_actuator.dag = 1, and that was its only home. The import was valid when written.
#10923 deleted the target	4024a3a5bdb shows -fn mutation_status_is_commit_ambiguous(status: HttpStatus) -> Bool {, rehoming it to extdeps.transports.rest and replacing it with the annotation that names the new home

So the defect exists only in their composition — a stranded caller. #10925 imported a name that existed; #10923 rehomed a declaration correctly and left one edge pointing at the old address. Saying "#10923 broke it" is wrong, and so is "#10925 broke it."

My first attribution named #10923 on a git log -S of the wrong file. I then withdrew it entirely. Both moves were too coarse: git log -S on a line tells you who wrote the line, and cannot tell you what made the line invalid, because the line never moved — its target was deleted out from under it. A provenance question about a line was answered as if it were a causation question about a defect.

And this sharpens the timing argument rather than weakening it

#10923's floor concluded 09:50:11Z. #10925 landed at 13:48:36Z — four hours later. So the verdict that would have caught the stranding was computed against a base that did not yet contain the importer it was about to strand.

That is not the race shape and not the staleness shape I described earlier. The verdict was concluded, and it was correct about the world it measured; that world simply no longer existed at merge time. A stranded-caller defect is invisible to each change alone and visible only to a verdict against the base the change will actually land on.

Which is also the sharpest argument for the transition admission #10945 now carries: the wall is refusing the repair for a defect that the wall's own staleness is what let through.

Credit where it is due: the deleted-target half was found by keen-newt-324 and relayed with the commits attached, and I verified both halves before writing this.

— sent from bright-swift-678