Required CI: the measuring process adjudicates the receipt it writes, so a refused phase reaches the exit

[gunbai-bot]

What

claim_executor --required-ci maps phase outcomes to a process exit in two places. Without --measurement-receipt it refuses on a non-empty phase-failure set. With the flag it wrote the receipt and returned ExitCode::SUCCESS unconditionally — because the D0 design it was written for published the receipt and let a separate step adjudicate it.

So the lane printed a complete, typed, located refusal and then answered success:

required-ci: floor refused: REQUIRED-FLOOR REFUSAL cause=ChangedWitnessObservationFailed ...
required-ci: lane=witnesses phases_run=2 phases_failed=1
required-ci: FAILED PHASE floor refused: ...

…with the step and the job both conclusion=success. Verified against the GitHub jobs API, not only the log: run 35503853026 (head cb39f95, floor job 106060214538) and run 35510547600 (head e78927a, floor job 106077573881).

The refusal itself is correct and is untouched. When a changed kernel file such as dag/std/types.dag makes the base side impossible to reconstruct, the changed-witness sublane declines to plan rather than widening to everything or narrowing to nothing. What was wrong is only the exit status and what the PR view was told.

The two repairs

1. The write is not the verdict. The measuring process now adjudicates the file it just wrote and returns that verdict, reaching the exit through the same function --adjudicate-measurement-receipt uses. One relation, one exit. Readback, JSON transport and version agreement are all inside the verdict, so a receipt that serialized its blockers away is a refusal rather than a pass.

2. A second leak in the same branch, found by the audit the first one forced. The blocker set written into the receipt was synthesized from the phase-failure list by comparing a blocker's phase to the whole failure sentence, and the failure spelled exactly floor was exempted by name. So a floor reporting not-clean while yielding no blockers of its own produced a MeasurementCompleted receipt with an empty blocker set — a failed phase with nothing to adjudicate, i.e. a green built by construction. The test is now phase word against phase word, and no phase is exempt.

Audit of the lane's other refusal arms: all 22 appends to phase_failures (lane-roster, parse, generated-artifact stage0-mirrors / docs-projections / carrier / unadjudicated, regen-fixed-point incl. its unmeasured and refused arms, dag-artifact-identity incl. subject-unobtainable, floor incl. floor-refused, lane-roster ran-set, source-root ingest receipt) now reach the blocker set, and the blocker set is what the exit is derived from. One arm is deliberately not a phase and stays as it is: --measurement-unreached-receipt seals a MeasurementUnreached standing for a separate adjudicator to read, and that standing is typed non-admitted — it says so in the receipt rather than by an exit.

Compatibility

This is the seed-side half and it depends on neither #11829 nor #11836; it is correct under either. It takes no position on which should land.

Evidence

• Discriminating red + green control, executing the relation rather than asserting a string, in v1_compiler::cli_run::required_ci_measurement. Six tests; the pair that matters is a completed measurement carrying one blocker is never admitted and a clean one is, each also run through the write and the readback. Mutation-verified: forcing the blocker arm to return Admitted reds 2 of the 6 and leaves the green controls green.
• Route: cargo test --release -p v1-compiler --lib (gunbc.repo_self_build repo_self_test_command) — 6 passed. This is why the receipt types moved out of the binary: gunbc.rung_drop rust_unit_tests_off_the_merge_path already declares that no CI step runs it, and a #[cfg(test)] module beside the binary has no documented route at all. The rung is stated honestly in the failure-mode row rather than claimed at the merge path.
• cargo clippy --all-targets -p v1-compiler -- -D warnings: clean. cargo fmt --all --check: clean.

The discriminating control, on real CI

Not planned — it arrived while this PR sat red, and it is the comparison the unit controls cannot make.

	corpus	phases	step conclusion
without this change — merge_group job 106103511181 (run 35520456015, queue branch for pr-11769)	same broken parse, 13× source annotation sits inside a declaration body	phases_run=2 phases_failed=2	success
with this change — job 106102498242 (run 35520066541, head 9ae301c)	same	phases_run=2 phases_failed=2	failure

It then reproduced on a second, unrelated cause. After #11875 repaired the annotations, parse went clean (6455 file(s) parse-clean) and the declarations sub-check began refusing two different things that had landed on main (IMPORT-MEMBER-ABSENT in dag/test/claim/machine_intake/jade_first_contact_model_witness_test.dag, from #11758; LENS-AUTHORSHIP-ABSENT in src/v2/lens/reference_derived_residency_reading.dag, from #11740). Queue floor job 106184155659 (run 35550476069, queue branch for pr-11676) carried both diagnostics and concluded success; job 106184184120 (run 35550463080, head 5e1a5035a44), this branch with the same two diagnostics, concluded failure.

And the green control arrived too. On head 46a4a6306f2, once main was clean, run 35645340055 floor job 106484305229 passed in 39m31s with the lane exiting 0 — so the pair is complete on live CI: a refused phase reds (twice, on two unrelated corpora), and a clean lane greens.

Same corpus, same refused phases, opposite verdicts. That is a real red and a real green of the mapping on live CI — which no unit test in this repository could have produced, because the thing under test is a process exit read by a CI job.

Two consequences worth stating plainly:

• This PR is red because it is correct. Its own floor fold is FloorClean (planned=401 executed=401 claims_failed=0); it refuses because main's parse phase is refusing. It cannot go green until main's parse is repaired, and that repair is not this PR's to author — it is open separately as Main repair: hoist three in-body annotations to their module items (parse refuses fleet-wide) #11875, after which this branch takes one merge and one re-run.
• The defect is live on the landing path, not only the PR path. The last four completed merge_group runs are all success, so commits are being admitted to main by a required gate that declined every phase it ran. That is a plausible mechanism for main having broken twice in one afternoon: the breakages land green.

An earlier draft of this section claimed a red on this PR as evidence the fix worked. That was wrong when written — the only comparison available then failed identically with and without the change — and it is replaced by the table above rather than quietly dropped.

Blind window, stated as what the emission shows

--measurement-receipt appears zero times in the workflow emitted at 85c1356300c (#11742). gunbc#11791 (merged 2026-09-20 05:18 UTC) restored a floor job carrying the receipt-bearing command into a workflow with no adjudicating step. So the window opens there and not earlier; within it, a required run whose floor phase refused reported green with its changed-witness observation never made. Two such runs are named above. No claim is made about how many others fell in it.

Ledger

dag/gunbc/recurring_failure_mode/gate_reported_success_on_a_phase_it_refused.dag — the general class (a gate reporting success on a phase it refused), with both runs as receipts, rung found at mitigatable, rung now mechanically preventable with the honesty bound stated, ceiling structurally impossible, and a next-rung trigger naming the capability (the lane's phase-outcome-to-exit decision as a .dag fold returning std.process ProcessExit). It is bounded explicitly against #11836's measure_mode_command_emitted_into_a_lane_with_no_adjudicator rather than duplicating it: that class is about an emission and its wall is at the emitter; this one is about what the instrument returns when nothing adjudicates.

🤖 Generated with Claude Code

[gunbai-bot]

Addressed in e0b1a103575. The finding in review 69681 is correct, I verified it against the code rather than taking it on faith, and it is a defect this PR itself introduced.

Confirmed: generated-artifact carries six distinct failure sentences in this lane (claim_executor.rs:763, 779, 795, 842, 848, 862) and regen-fixed-point four. Deduping by phase word meant only the first cause per phase reached the published receipt. The exit stayed non-zero because the set stayed non-empty — which is precisely why it was invisible: the status was right while the located diagnostic was gone. That is this PR's own class one layer in, and the receipt is what the separate --adjudicate-measurement-receipt consumer prints.

The rule that survives both defects, rather than a revert to the old predicate (which held only the first property, as its repair held only the second):

• a failure sentence carrying its own cause is its own located diagnostic and always publishes; only an exact duplicate cause is suppressed
• a failure spelled exactly as the bare phase word is a summary of blockers the phase already minted, so it is suppressed only when that phase actually has some — and published when it does not, which keeps the original empty-blocker-set leak closed

Made executable. The fold moved to the library as synthesize_phase_blockers with five controls, including the discriminating red for this finding (three distinct generated-artifact causes must all reach the receipt) and the guard that a bare summary does not stack on real identified blockers. It has now been wrong twice in two directions and neither was visible from the process status, so it earns an executing test rather than a loop at a call site.

Mutation-verified: restoring the phase-word dedupe gives MUTANT_TEST_EXIT=101, 2 of 11 failing; the clean code passes 11/11. (Three earlier attempts at that check were themselves broken — output swallowed by tail, a waiter matching its own echoed command, and a cargo fmt reflow that made the patch silently no-op. Each would have handed me a confident "verified" backed by nothing, so the final run asserts the mutation applied before trusting the result.)

I also corrected the ledger row, which claimed "every one of them now reaches the blocker set." That was false as written; it now records the miss with its review id instead of restating the claim.

— sent from still-crane-198