Design a required phase that compiles one v2 entry: today an emission break reached main and no gate could see it

[briansrls]

What escaped

On 2026-08-23 gunbc compile --source-root dag --source-root src/v2 --entry src/v2/compiler/03_ingest.dag refused outright on main — no emitted tree, no cargo log — while every required phase stayed green for hours. It was found by a hand-run probe, not by a gate.

The required run has three phases: the src/v1 .dag parse sweep, --required-regen, and the witness floor. None of them compiles a v2 entry. The specimen was a trailing // annotation block with no declaration after it, authored under dag/test/manual/ — which no required phase parses either. Two independent misses, one artifact.

The measurement that decides the design

An --entry compile is scoped in what it EMITS (the reference-derived closure) and whole-tree in what it PARSES: every indexed module outside the closure enters the name census, so the census parse reaches all of dag + src/v2 whichever entry is named. Measured locally on this branch (both of the day's fixes resolved in — see Baseline below):

entry	closure	census	emitted	wall
dag/std/abi.dag	4	3,847	9	135s
src/v2/compiler/03_ingest.dag	~180	~3,670	176	349s

And with the real specimen planted back into dag/test/manual/, the small entry refuses, naming the file and byte range:

required-v2-emission: entry=dag/std/abi.dag closure=4 census=3847 emitted=0 blocking=1 advisory=0 wall_ms=114902
required-v2-emission: REFUSED v2-emission compile of dag/std/abi.dag produced 1 hard diagnostic(s):
  source annotation names no subject: no module item follows it. Move it above the declaration
  it describes. (dag/test/manual/process_argv_expansion_receipt_test.dag:4217-4274)

So 03_ingest's extra 214s buys emission coverage of the compiler's own closure — not coverage of the class that actually escaped. The entry is dag/std/abi.dag, and it is a .dag row (gunbc.ci_layer_roots required_v2_emission_entries, a List<String>) so re-deciding that trade is an authoring change, never a Rust edit.

The line, and what it does not catch

The refusal predicate is not new: it is v1_compiler_compile stage0_self_compile_refusal_message, the same authority gunbc compile already stops on — a blocking diagnostic, or an empty emitted file set. Restating "blocking, or zero files" here would be a second representation of one rule.

Advisory diagnostics are counted and reported, never refused on. 03_ingest carries 503 advisory and 0 blocking today; a gate on any diagnostic is permanently red and useless.

Named rather than left to be inferred, this phase does not catch:

• a rustc error in the emitted tree (nothing here compiles the emission);
• a semantic regression that still emits;
• an emission break confined to a closure the configured entry does not reach.

A fourth, which arrived as supporting evidence from a peer, failed on execution, and then turned into something sharper than either account:

• a name whose resolution depends on which entry you compiled. gunbc.command_runner calls stat_owner_user_name_command with no import of extdeps.tools.stat (repaired in command_runner: the import #8919's builder call needs, and the census that closes the class at two #9045). Measured on one tree with one binary:

  entry	closure	verdict on the same unchanged file
  dag/gunbc/fleet_converge_cli.dag	665 sources	no diagnostic
  a probe importing gunbc.command_runner	96 sources	function 'stat_owner_user_name_command' not found in scope

  A peer isolated the variable: adding one import of gunbc.host_effect_realize (which does import extdeps.tools.stat) to a firing 397-source entry takes it to 654 sources and the diagnostic disappears, nothing else changed. I reproduced the firing direction independently at 96 sources rather than taking it on report.

  A bare name resolves against the flat namespace of whatever modules happen to be in the closure. So compile's verdict on a module is not a property of that module — it is a property of the entry someone chose. The interpreter resolves through each module's own imports and rejects the call either way, so the two paths disagree and the eval path is the stricter one: compile admits what eval refuses.

What that means for this phase, answered here because a reviewer will ask. It does not claim to answer "is the corpus name-clean" — on this compiler that question has no single answer to gate on, only an answer per entry, and a green over one entry could in principle be produced by an unrelated import entering that entry's closure. So:

• a green here licenses exactly one statement — the configured entry emitted — and must not be cited as name-resolution coverage;
• this is a property of the compiler's resolution, not of the gate, and widening the entry roster does not fix it (a bigger closure resolves more bare names, not fewer — the 665-source entry is the silent one);
• the entry-independent check that would close it is a different mechanism, not a widening of this one: resolve each module against its own imports, which is what the eval path already does. That is this class's next-rung trigger, and it is not this PR.

Named at this length because the failure mode is inviting: an emission gate looks like it covers resolution, and on this compiler it cannot.

For scale on that class rather than on this gate: main's own green run 32664434197 carries 59 distinct unresolved symbols across 137 no such function occurrences (known_red_runtime_errored=143), measured by a peer — of which at least 8 are deliberate red fixtures by name, and the triage is not done. Those rows are enrolled as expected reds and the floor does not gate on that counter, so they are neither passing nor failing: absent while being counted as a roster. This phase does not touch them.

Say the closure/census one out loudSay the closure/census one out loud, because the PR's own title invites the wrong reading.** "Compiles one v2 entry" sounds like emission coverage; the gate's reach is the census (whole-tree parse of dag + src/v2), not the closure (4 modules under the enrolled entry). A break confined to a closure no configured entry touches stays invisible to it. Widening reach is a row on required_v2_emission_entries and a cost decision — 03_ingest's closure costs +214s.

It does subsume a whole-tree .dag parse sweep of dag + src/v2, because the census parses all of it.

That retires the "do not add a second parse sweep beside the existing one" objection rather than working around it: the choice does not exist. One phase, not a phase plus a sweep. And it sharpens the diagnosis of what was missing — the gap was never about which directory a sweep walks; it was that no required phase ran the compiler over the v2 source roots at all, so dag/test/manual/ was unreached for the same reason every other out-of-closure module was.

The gate refuses on main, right now, on the real break

Not a planted fixture and not a hypothetical. dag/test/manual/command_runner_local_argv_receipt_test.dag on current origin/main still ends with a standalone // block and no declaration after it — the original 2026-08-23 specimen. #9027 moves the test fn back under that block and is still open.

Substituting only that file's main content into an otherwise-passing tree and running the phase:

required-v2-emission: EmissionRefused entry=dag/std/abi.dag closure=4 census=3849 emitted=0 blocking=52 advisory=0 wall_ms=128832
required-v2-emission: EmissionRefused entry=dag/std/abi.dag phase=emit cause=… produced 52 hard diagnostic(s)
required-v2-emission: entries=1 not_completed=1

Restore the file and the same command reports EmissionCompleted … emitted=9 blocking=0. So the phase's red and green are both produced by real main content, with one file as the only variable.

And main's own required run is green while carrying it. That is the whole argument for this PR in one pair of facts: the break is on main, the required run cannot see it, and this phase sees it in 125s.

(The specimen is a parse break, which is the class the census actually covers. A resolution defect such as #9045's stranded import is not this class and is not caught — see the fourth limitation above, where that distinction is worked out at length.)

Evidence, executing

claim_executor --required-v2-emission-selftest — two controlled fixture roots under fixtures/v2_emission_gate/, differing in one thing. red/subject.dag carries the real specimen (trailing block, no following declaration); green/subject.dag has the same block moved above the declaration it describes, the placement DESIGN §4c admits. Red must refuse on the annotation cause (a refusal for any other reason is reported as a failure); green must emit. Runs in milliseconds — its oracle is authored independently of the corpus it will judge.

Mutation-confirmed, not just observed green:

# red fixture mutated so the block leads a declaration
required-v2-emission-selftest: FAIL selftest RED did not refuse: 6 file(s) emitted from the trailing-annotation fixture
# restored
required-v2-emission-selftest: OK red fixture refused on the annotation cause, green fixture emitted

One producer, not two callers

The gate consumes the same emission transaction as the cargo board. It did not when first pushed, and this is worth recording as an instance rather than a fixed bug:

The gate, as reviewed and approved, was resolving a different module set than the board. It ran under the strict pool index; the board runs --dependency-pool-index primary-precedence. So the gate could have gone green on a tree the board refuses — which is the exact hole the gate exists to close, present in the gate itself. It was found by asking one question about provenance ("are those the same producer, or two callers of one?"), not by any check, and no approval would have caught it: both halves were correct in isolation and only the arrow between them was missing.

The gap in detail: the phase was a second caller reproducing the closure load, the census assembly, the refusal check and the silent-pick gate beside gunbc compile's — and it had already drifted on one of the three parameters, resolving under the strict pool index where the board runs --dependency-pool-index primary-precedence. A gate that resolves different modules from the board can green while the board refuses.

The transaction now lives in cli_run compile_entry_emission, and both consumers call it:

• gunbc compile --entry <M> --target rust — the board's producer, invoked by docs/probes/curated_cargo_probe_one.sh, whose EMIT_REFUSE verdict is that command exiting nonzero;
• claim_executor --required-v2-emission — the gate, which drops the tree and reads only the disposition.

The refusal predicate inside it is v1_compiler_compile stage0_self_compile_refusal_message (a blocking diagnostic, or an empty emitted file set) plus the CLI's silent-pick gate, because that gate is also part of the board's nonzero exit — a phase that skipped it would green on a tree gunbc compile refuses.

Verified by execution that the CLI path is unchanged by the extraction: dag/std/abi.dag → 4 closure / 3,847 census / 9 emitted; the board's exact invocation on 03_ingest → 177 emitted by the compiled: line, 0 blocking, 503 advisory, exit 0 (176 by find -name '*.rs' — the known two-instrument split).

Three states, not two

Option<refusal> beside a counts line was a two-state carrier asked to express three, and the third is the dangerous one: a run that never reached the compiler rendered as emitted=0 blocking=0, byte-identical to a clean run of an empty subject, told apart only by whether an adjacent line existed. A parser reading one line at a time cannot make that distinction.

EntryEmissionDisposition is now Completed { emitted_count } / Refused { phase, cause } / NotExecuted { earlier_phase, cause }. The tag is on the counts line, and the count fields read n/a — deliberately not 0 — on any path that never ran. All three arms confirmed by execution:

required-v2-emission: EmissionCompleted entry=dag/std/abi.dag closure=4 census=3847 emitted=9 blocking=0 advisory=0 wall_ms=120784
required-v2-emission: EmissionRefused   entry=dag/std/abi.dag closure=4 census=3847 emitted=0 blocking=1 advisory=0 wall_ms=125344
gunbc compile: entry-read: entry file does not exist: dag/std/does_not_exist.dag

The invariant is that emission COMPLETED — never a file count. A legitimate compiler change may alter a closure's size, so emitted == 177 is a change detector wearing an invariant's clothes.

Enrolment, and what it is not credited for

Enrolled as --required-ci phase 3, ordered ahead of the floor, on the relayed operator ruling. Measured cost +135s against the floor's ~30–40 minutes.

The ordering is report order only: the phases are independent and every one runs after an earlier failure, so this does not stop the floor starting on an unemittable tree. Making it an early prerequisite (an exit before the floor) would change this mode's stopped-line audit design and is a scheduling decision left to the operator with the number attached. No second binary-provenance path: it runs in the same claim_executor process from the same built artifact as the other phases.

This gets admission-integrity credit and zero rustc-convergence credit. It makes "the canonical v2 board subject emits" an admission invariant; it does not move the board.

Dissolution trigger — carried on gunbc.ci_layer_roots required_v2_emission_dissolution, not just stated here: when the authentic self-host product receipt is itself required on every admitted candidate and carries this exact emission boundary (same producer, stopping before cargo), the standalone gate dissolves into it and the row, its host reader and the phase delete together. Without that trigger, emission preflight / self-host probe / product receipt / cargo census become four permanent implementations of one transaction.

CI history on this branch, corrected

An earlier revision of this section said this PR's CI would stay red until #9036 landed. That was wrong, and it is rewritten rather than annotated. #9036 closed unmerged at 17:44Z because #9031 absorbed its content, not because the fix was abandoned — this branch was carrying a pre-17:00 merge of #9031 that had its argv half and not its expected-red half.

What the two runs measured:

• 32657155521 (head 6570ec5) — phases_run=4 failed=1, the single failure being floor refused: ExpectedRedIdentityDidNotExecute count=3 on the three compile_accepted_unevaluable_program_control identities. Parse OK (51 files), regen first_generation_equal=true, zero argv errors. The v2-emission phase completed on that run (see above) — the red was the stale merge, not this change.
• Current head merges origin/fix/argv-command-ls-seal@a47aded, whose floor_expected_red_is_live now excludes those three identities.

This branch therefore carries #9027 and #9031 to get a measurable baseline. Every number above was taken on a tree carrying both and stays valid — only the vehicle needs cleaning. This PR is not to be merged while its diff carries them: landing three repairs under one title makes each harder to revert independently. Once they are on main, main is merged in here and the diff becomes this change alone; the measurement is not re-taken, because it was taken on exactly that content.

[gunbai-bot]

Both halves of review 55117 verified against the branch. First is fixed; second I am declining, with reasons.

The contradiction was real and is fixed (pushed). The comment beside --required-v2-emission-selftest was written in the revision before the enrolment and survived the one that added phase 3, so the diff carried prose asserting the phase is opt-in beside code making it required. Rewritten, not annotated — two accounts of one fact is what produced the contradiction in the first place. It now states the enrolment plainly, cites the relayed operator ruling and the +135s, explains what the two standalone flags are actually for (running the emission alone, or only its evidence, are real local actions — the same reason the src/v1 .dag parse sweep keeps its own bin beside its required phase), and records why the sentence was wrong so the next reader does not re-derive it. Good catch: exactly the premise-contamination class, in a comment a grep would land on.

On unbound_dissolution — declining, because it is answering a question the row does not ask. The scaffold-admission doctrine governs whether debt may be created, and that approval is external to the diff and cannot be self-declared. A dissolution condition governs how admitted work ends. Those are two different questions and the doctrine is explicit that only the first is an admission.

This gate is not admitted debt: it is the delivered construction, required on an operator ruling relayed 2026-08-23 at a measured +135s. What the row records is that the standalone gate is not terminal — when the authentic self-host product receipt is required on every admitted candidate and carries this same emission boundary, the gate dissolves into it rather than becoming a fourth permanent implementation of one transaction.

unbound_dissolution is the correct constructor here rather than a weaker one: no bounded ref exists for "the product receipt becomes required," and picking a ref to look bound would be a fabricated trigger — worse than an honest unbound one, because it would read as a scheduled event that nothing schedules.

What the finding did surface is that the row was silent on its enrolment authority, which is what made it look self-declared. Fixed in the same push: gunbc.ci_layer_roots now names the enrolment authority immediately above the row and says explicitly that the dissolution condition is not, and may not be read as, the admission that created it.

— sent from deep-otter-200

[gunbai-bot]

Both notes from review 55128 addressed — the first is fixed, the second I'm leaving as-is with the reviewer's own reasoning.

Selftest RED coupling on diagnostic wording — fixed (pushed). The finding is right: cause.contains("source annotation names no subject") was a second spelling of a sentence that std_source_annotation annotation_attachment_refusal_message already owns, and a rewording invalidates it silently. The expected sentence is now asked for from that authority, keyed on the typed variant the fixture provokes:

let expected = annotation_attachment_refusal_message(
    AnnotationAttachmentRefusal::UnattachedAtScopeEnd { origin: … },
);
if !cause.contains(&expected) { … }

So the identity being asserted is the variant, not the wording, and a rewording moves both sides together. Confirmed by execution in both mutation directions, including the one I had not previously exercised:

# red fixture made legal
FAIL selftest RED did not refuse: 6 file(s) emitted from the trailing-annotation fixture
# red fixture refusing for an UNRELATED cause
FAIL selftest RED refused for the wrong cause; expected the UnattachedAtScopeEnd refusal
     (source annotation names no subject: …), got: … produced 1 hard diagnostic(s)
# restored
OK red fixture refused on the annotation cause, green fixture emitted

That is a stronger check than "grounding it on a typed diagnostic identity would retire it" implies — the string never reaches the check as a literal, so there is nothing left to rot.

unbound_dissolution — leaving it. The review reaches the same conclusion I did on the earlier pass: it is honest for the current state, because the receipt is not yet required and no bounded ref exists for "the product receipt becomes required." Picking one to look bound would be a fabricated trigger — worse than an honest unbound one, since it would read as a scheduled event that nothing schedules. The enrolment authority is named separately above the row so the dissolution condition is not mistaken for the admission that created it.

— sent from deep-otter-200

[gunbai-bot]

CI on fc12cac (run 32661323507): phases_run=4 failed=1, and the failing phase is the floor, not this change. Investigated rather than reported.

What the floor actually said. failed=0, stale_quarantine=0, interrupted_before_verdict=0, route_gap_unenrolled=0, host_tool_unresolved=0. The single unclean field is completed_over_cost_requirement=1:

required-floor: COMPLETED-OVER-COST-REQUIREMENT
  test.claim.qualified_spelling_identity_witness_test.qualified_spelling_takes_the_shared_layer
  … cost exactly 60665ms against 5000ms.
[over-cost] … wall_ms=60833 cpu_ms=60665 line_ms=1552 outcome=timed_out

It is not an interaction with the new phase, and I checked that rather than assuming it. The obvious worry was that a corpus-scale compile running in-process immediately before the floor changes the conditions the floor's per-witness CPU budgets are measured under. It does not explain this. Measured locally, in a fresh process with nothing else run in it:

gunbc run --claim-run … --function qualified_spelling_takes_the_shared_layer   → PASS, 1m34.7s
gunbc run --claim-run … --function bare_spelling_shared_layer_is_unchanged     → PASS, 1m36.4s

~95s standalone against a 5000ms budget. No amount of process warming moves a 19× overshoot to under. The direction is in fact the opposite of the worry: only one of the two arms shows up over-cost in CI, which is consistent with the first arm paying the corpus-wide scope and the second running warm — so a heavier process before the floor makes this witness cheaper, not dearer.

Why it surfaces here first. Both arms landed in #9022 (68c525eaf, merged today 10:44). Every floor run since has refused at compile on the argv break — main's own latest run 32646482842 never emitted a required-floor: planned= line at all. This branch carries the argv fix, so its floor is the first to complete far enough to measure that witness's cost. The number is newly visible, not newly true.

Not fixable from inside this PR. Closing it means either making compile_dag_rust_emit_check cheaper or re-deciding that witness's budget — both are someone else's subject, and editing either here would put a third unrelated repair in a diff already committed to shedding two. Flagged to the parent for routing.

I am not touching it, and I am not proposing a budget bump to go green — a budget raised to accommodate a measurement is the ratchet, not a fix.

— sent from deep-otter-200

[gunbai-bot]

Correction to my previous comment — the conclusion stands, one number in it was compared against the wrong instrument.

I wrote "~95s standalone against a 5000ms budget… a 19× overshoot". Those are two different counters, and putting them either side of "against" is the same class of error this repository keeps finding:

• ~95s is process wall — gunbc run --claim-run end to end, including the corpus-scale bare-reference edge index build (load=28441.5ms, edge_index_tree_census=21.26s of which _miss=21.19s, over source_files=3851).
• The 5000ms budget is the per-witness eval counter. Measured on that counter, the witness is cpu=236ms; its sibling is 44ms alone and 5ms when run second in the same batch.

So "the witness costs 95 seconds" and "the witness costs 236ms" are both true of different universes, and neither refutes the other. My arithmetic quoted the first against the second's budget.

What this does not change: the phase in this PR is still not the cause, and the reason is now sharper rather than weaker. The floor is a third instrument — it charges cpu=60665ms to this witness, while a claim_batch run of the same entry attributes that same work to a different entry entirely (31.7s on dag/gunbc/output_policy.dag, 0.18s on the witness's own). The floor's per-witness CPU accounting folds the shared build into whoever triggered it. That is first-touch attribution, which makes the row a cost-attribution defect, not a cost debt — and it is exactly what my one-of-two observation was showing: in one process the first arm pays the corpus scope and the second runs warm (44ms → 5ms); in two processes each pays its own.

A heavier process ahead of the floor therefore makes this witness cheaper, so the new phase cannot be the cause. It remains true that both arms landed in #9022 at 10:44 today and that no floor run since has completed far enough to measure them — the cost is newly visible, not newly true.

Owned elsewhere (work item adhoc-1219d13f-06d); already eliminated by that lane: the index build is already once-per-process and correctly memoized, so only "make the cold build cheaper" survives. Nothing for this PR to do.

— sent from deep-otter-200

[gunbai-bot]

Review 55167 addressed. One of the two items was a defect in this PR, not a suggestion — thank you for surfacing it even though the review rationalised it as intentional.

declared_import_closure_live_paths was deleted by accident. The edit that inserted the emission transaction spliced over a region that ended past it, and nothing failed because it is #[cfg(feature = "test_hooks")] with no current caller — so it vanished silently and I did not notice. It is the host twin for the Class B declared-import controls; removing it was never part of this change. Restored verbatim. The diff against the merge base now removes zero lines, which is the check I should have run before pushing and now have.

The review's note that it "has no remaining callers (git grep empty)" is true and is exactly why the deletion was invisible. A feature-gated function with no live caller is the shape that disappears without a failure — worth naming, because the same splice could have taken something load-bearing.

Double index build — fixed. compile_entry_emission now builds one MultiEntryIndex and hands it to both the closure loader and the census fill, instead of load_sources_for_entry_with_pool_index building one and the census building another over ~3,800 modules. Beyond the parse, this removes the possibility that the closure and the census are computed against different populations, which is a correctness property rather than only a cost one. Strict routes through process_shared_index, so a second --entry compile in one process is a cache hit.

No speedup is claimed. Measured 134s after against 126s before — inside this host's noise, and in the wrong direction if read naively. The change stands on removing the duplicate parse and the second population, not on a number I did not observe. Behaviour identical by execution: abi still 4 closure / 3847 census / 9 emitted, selftest green, CLI path unchanged.

Also merged current main, which brings in #9031 (so the argv and expected-red halves are both present), #9042 (expected-red roster deleted) and #9044 (the qualified-spelling cost root-caused — it was a whole-tree policy resolve, not name resolution, which is a better answer than the cost-attribution reading I had).

— sent from deep-otter-200