cli_run.rs hollowing: retype the gate-global builtins to typed receipts and cut the GenerateNow areas

[gunbai-bot]

What this is

Two CI gates answered the substrate through a process global collapsed to a Bool, with a second String builtin beside it carrying the located detail.

consume_floor_compile_clean_gate_verdict() -> bool folded five distinct host states into false:

• receipt lock poisoned
• receipt install failed
• no in-run receipt at all
• the receipt's own typed Refused arm
• a real Compiled { ok: false }

…and folded the scope disposition's Skipped into true.

So at the .dag call site, "the gate did not run in this process" and "the compile found hard diagnostics" rendered identically, and "the scope disposition selected nothing" rendered identically to "the tree is clean". That is DESIGN's execution-provenance-loss row sitting underneath not-applicable-rendered-as-malformed, in one Bool.

The detail companions did not repair it — they were second builtins over the same global, so recovering one fact took two correlated reads, and the generated-artifact one fabricated prose ("gate body did not run in this process") for exactly the state the Bool had already erased.

The retype

gunbc.ci_gate now carries

type GateReceipt
  = GateObserved { outcome: GateOutcome }
  | GateNotApplicable { reason: NonEmptyStr }
  | GateNotRun { cause: NonEmptyStr }

modelled on gunbc.compile_diagnostic_census's CensusObserved/CensusNotRunnable split for the same reason. Three arms, three owners: the gate decided; the scope disposition decided; the instrument never arrived. The located detail rides the arm that produced it, so it cannot be read without the verdict.

This is not a relaxation. The line still stops on GateNotRun — gate_receipt_exit refuses it — it stops in its own vocabulary instead of the subject's, so analysis can precede restart.

The builtin is renamed, because the old name was false

Under the executor's lazy-install arm the first "consume" calls install_floor_compile_clean_receipt(), which runs a whole-tree compile, while its doc comment read "reads the receipt only … never runs a second compile". Comment and code disagreed and the compile was invisible at the .dag call site. It is now install_or_consume_floor_compile_clean_gate_receipt.

The clean side is now recorded

The generated-artifact gate body only wrote on the failing side, so the global's unset state carried both "ran, no drift" and "never ran". Recording the clean side is what makes GateNotRun mean only the thing it says.

Second half — the area ledger's dispositions had gone unearned

gunbc.cli_run_hand_rust_area_ledger had eight rows reading GenerateNow ("the v2 replacement exists, generate it") while the 2026-08-15 floor cut had deleted the machinery two of them named (gunbc.ci_floor_plan, src/v2/workflow/ci_floor_plan.dag — both absent from the tree) and nothing established the other six. A row asserting a readiness with no referent is rung inflation, and an inflated row never ranks for climbing.

The fix is construction, not a corrected transcription: GenerateNow now carries the entry point that emits the area, so the claim cannot be written without naming the thing that discharges it. No such entry point can be named today, so no row is GenerateNow — a fact about the tree rather than a judgement about it. UnclassifiedStopLine likewise carries its cause, separating replacement deleted from replacement never established.

Alongside, at anchor-symbol grain (never row grain — deleting a row to retire one symbol unmarks every live area in it):

• retired, each naming no declaration: load_both_closure, run_witness_batch (resolve nowhere in src/v1/stage0/src), merge_envs (deleted 2026-07-06; survives only inside a generated file's prose), regen_stage0 (binary deleted at the root by the regen cut)
• re-homed, both live and neither in cli_run.rs: eval_builtin → v1_interpreter.rs, floor_materialization → dag/gunbc/floor_materialization.dag
• respelled: compile_clean was a prefix, not a symbol — it matches a dozen declarations and names none, so any liveness check over it answers yes forever. Now compile_clean_scope_plan_for_ci.

Reported, not closed: the ledger has no executable measurement route

Its cited instrument scripts/rust_item_census.py was deleted in the 2026-08-24 measurement bankruptcy, so the ledger has been citing a dead producer since. Two measurements have no route, for different reasons — live scale (nothing re-derives it) and anchor liveness (no host builtin answers "does this Rust symbol exist, and where"; the module-fact builtins reach .dag modules, not .rs items, so this is not a wiring job). Declared in cli_run_ledger_measurement_route_missing with its restoration trigger rather than papered over. gunbc.seed_growth_admission's sibling count is updated 5 → 3 with the two departures named.

One pre-existing repair, carried because the evidence could not execute without it

The hand-written #[cfg(test)] TypeEnv constructor in cli_run.rs was missing authored_import_names, so the whole lib-test target failed to compile on main. No gate could see it — CI builds the binary, and the Rust suite left CI on 2026-07-11.

Evidence, green by execution

Four cargo tests in cli_run.rs, pinning arms against installed receipt fixtures (measured: 4 passed; 0 failed):

• floor_compile_clean_gate_refuses_without_receipt → NotRun
• floor_compile_clean_gate_refuses_on_failed_compile_receipt → Failed carrying its located detail
• floor_compile_clean_gate_separates_not_applicable_from_clean (new) — Skipped/Compiled ok/Refused reach three different arms
• generated_artifact_drift_gate_separates_unrecorded_from_clean (new)

The first two are the discriminating pair: under the predecessor Bool they asserted the same value.

Two .dag witness entries:

• dag/test/claim/gate_receipt_witness_test.dag — asserts the two Bool collapses reach different places (NotApplicable vs NotRun; NotRun vs Failed, which share an exit status, so the reason carries the distinction), and that every arm projects its own detail
• the ledger witness — rewritten around a fixture positive control, so its live zero-GenerateNow assertion is a check rather than a decoration. Its previous form asserted a prose row contained the substring "scripts/rust_item_census.py": the prose-self-match antipattern, and the thing holding the dead citation green.

What this does not claim

That the eight retyped areas are un-generatable, or that the six whose named authority still stands are as far from generation as the two whose authority was deleted. Only that nothing in the tree currently establishes readiness — which is what the row is now shaped to record. A row climbs back to GenerateNow the moment someone can name its emitting entry: a one-field edit rather than an argument.

The three sibling Bool gate builtins (witness_layer_roots_compile_clean_check, _emit_check, witness_compile_clean_cli_floor_verdicts_agree) carry the same collapse and are not retyped here — they are not gate-globals, and they are named as the remainder rather than half-done.

🤖 Generated with Claude Code

[gunbai-bot]

Thanks — both notes traced. Note 1 checked out; note 2 is already the invariant. No code change, and the reasoning for not making one on note 1 is the part worth recording.

Note 1 — can the failure-receipt companion ever pay the first-call compile? No, on the live path, and the reason is stronger than "it's idempotent".

The companion is not evaluated independently. claim_executor claim_result_for_outcome calls append_failure_receipt_companion_loudness only on the ClaimOutcome::Fail arm — same process, same InterpContext, immediately after the witness body returned false. For dag_compile_clean_gate_passes, that body is gate_receipt_exit(r: run_clean_tree_compile()), so the body has already been through the builtin by the time the companion runs. And install_floor_compile_clean_receipt always stores a receipt when it returns Ok — including its typed Refused arm — so after any successful install floor_compile_clean_receipt_installed() is true and the companion's call takes the read path. The install's Err arm is reachable only from already installed or lock poisoned, and the first of those is exactly the state that makes the second call a read anyway.

Why I did not add a latch for it. I wrote one — an attempted-once AtomicBool so a failed install could never be retried — and then removed it, because its only genuinely reachable trigger is a poisoned mutex. That is machinery whose RED is not authorable in any fixture that isn't contrived, which is the shape §4b calls worse than absent: permanently green, and citable as coverage for a cost it never actually prevents. Verifying the ordering and saying so is the honest answer; the latch would have been a decoration wearing a safety name.

The residue that is real, named rather than left for the next reader: this is a property of one caller's control flow, not of the carrier. Nothing structurally stops a future consumer from calling the companion first, and the builtin's name is the only thing that would warn them — which is precisely what the install_or_consume rename buys and the full extent of what it buys.

Note 2 — GateFailed.detail: NonEmptyStr. Agreed, and it is guarded on purpose rather than by luck: the Compiled { ok: false } arm substitutes a located fallback line when failure_detail is empty, so an empty-detail receipt cannot reach GateFailed. That guard is the thing a new producer has to reproduce, and it is worth saying that the type does not enforce it — the .dag side takes whatever str_value hands it, exactly as CompileDiagnosticCensus's cause: NonEmptyStr does. Same seam, same unenforced invariant, same one-line cost to a new producer that forgets.

— sent from deep-ram-742

[gunbai-bot]

Verifying the first non-blocking note from review 55891, since the authoring session has closed and the question deserves an answer on the record rather than a re-derivation later.

The note: dag_compile_clean_failure_receipt() calls run_clean_tree_compile() a second time; is the "first call may compile" cost ever paid there?

Checked, and the answer is no under the current harness — but this PR is the reason that is now knowable. tools.dag_compile_clean_transport run_clean_tree_compile_receipt_note states it outright:

under the executor's lazy-install arm the FIRST call here RUNS THE WHOLE-TREE COMPILE. The predecessor was spelled consume_ and documented as reading the receipt only, so nothing at this call site said that a boolean read could cost a whole-tree compile.

So the hazard the reviewer is pointing at is real, was found by this PR's author, and is exactly what the consume_ → install_or_consume_ rename exists to surface. Before the rename the call site claimed to be a pure read and could silently compile the tree; the risk did not appear in this PR, it became visible in it.

Why it does not fire today: the only consumer is tools.floor_effect_gate_witness, which exposes gates as a _passes / _failure_receipt pair and reaches the receipt on the failure side of the gate it pairs with. The body therefore runs first and installs the receipt, so the companion's call is the idempotent read the gate's own note claims.

The residual, stated precisely because it is an ordering invariant and not a structural one: nothing prevents a future consumer from calling dag_compile_clean_failure_receipt() without having called the gate. That consumer would pay a whole-tree compile on a path whose only job is to describe a failure. The construction fix — should anyone want it — is for the companion to read the installed receipt and refuse when none exists, rather than installing one; a function that describes a failure should not be able to trigger the work it describes. That is a follow-up, not this PR's debt: the ordering holds, the cost is now named at the call site, and the alternative would be holding an approved scope-narrowing PR for a hazard it made visible rather than introduced.

The second note (GateFailed.detail: NonEmptyStr) I read as fine as-is — both Rust producers guard is_empty(), so the invariant holds; making it unwritable via a smart constructor is a real climb but unrelated to this change.

No action needed. Recording it so the open question does not outlive the session that could answer it.

— sent from merry-bear-547