While attributing #8489 it emerged that the compiler-output-regression job's "Gate native-ABI proof compiler output" step did not execute at all between 2026-07-30 and 2026-08-17.
The earlier "Gate native-region proof compiler output" step was failing, and a failing run: step aborts the remaining steps in the job. The native-ABI step only began reporting once region-proof went green on Aug 18 — which is why the control_flow change looked like it appeared from nowhere on Aug 20, two days later, when its actual cause (40e2ce86d, #8457) landed inside that window and would have been caught immediately had the step been running.
This is CLAUDE.md's fourth failure mode verbatim — "the gate runs but its subject never did" — and the most dangerous one, because the job is genuinely present in the run list and its failure is attributed to whichever step happens to fail first. A three-week blind spot in a compiler-output change detector is exactly what that section warns about.
Why it matters beyond this one instance
The steps are independent subjects: region-proof failing tells you nothing about native-ABI proof. Chaining them in one job means any long-lived failure in an earlier step silently suspends every later one, and the suspension is invisible — the job is red either way, so nobody looks for the second finding hiding behind the first.
Options
- Split the steps into separate jobs, so each reports independently. Costs runner slots (the header of
test.yml notes the 20-slot org constraint, which is why these were consolidated).
- Keep one job but let the steps run to completion — collect failures and fail at the end, rather than aborting on the first. Cheapest in slots and preserves the current structure.
- Assert liveness: have each gate emit a "subject ran" marker and fail the job if a marker is missing, so a skipped subject is distinguishable from a passing one.
I have not changed the workflow — reordering steps or adding continue-on-error changes CI semantics and deserves a deliberate decision rather than a drive-by edit.
Found while working #8489 (attributed in #8854).
While attributing #8489 it emerged that the
compiler-output-regressionjob's "Gate native-ABI proof compiler output" step did not execute at all between 2026-07-30 and 2026-08-17.The earlier "Gate native-region proof compiler output" step was failing, and a failing
run:step aborts the remaining steps in the job. The native-ABI step only began reporting once region-proof went green on Aug 18 — which is why thecontrol_flowchange looked like it appeared from nowhere on Aug 20, two days later, when its actual cause (40e2ce86d, #8457) landed inside that window and would have been caught immediately had the step been running.This is CLAUDE.md's fourth failure mode verbatim — "the gate runs but its subject never did" — and the most dangerous one, because the job is genuinely present in the run list and its failure is attributed to whichever step happens to fail first. A three-week blind spot in a compiler-output change detector is exactly what that section warns about.
Why it matters beyond this one instance
The steps are independent subjects: region-proof failing tells you nothing about native-ABI proof. Chaining them in one job means any long-lived failure in an earlier step silently suspends every later one, and the suspension is invisible — the job is red either way, so nobody looks for the second finding hiding behind the first.
Options
test.ymlnotes the 20-slot org constraint, which is why these were consolidated).I have not changed the workflow — reordering steps or adding
continue-on-errorchanges CI semantics and deserves a deliberate decision rather than a drive-by edit.Found while working #8489 (attributed in #8854).