Do not start the 65-minute floor on a branch already known to be red

[gunbai-bot]

What this does

Stops the ~65-minute floor from starting on a branch an upstream job has already established is red — without weakening the merge gate.

upstream red      -> required `ci` job RUNS -> first step fails immediately
expected heal skip-> floor runs
cancelled run     -> no further work

• ci needs build, regen, heal_generated_artifacts
• job condition is !cancelled(), so upstream failure does not implicitly skip the required ci verdict
• the first modeled step reads the three upstream results and exits red before checkout or the floor when build/regen did not succeed or heal failed

heal is allowed to be skipped and the floor still runs: heal intentionally runs only for same-repository, non-Dependabot pull requests, so push, merge-group, dispatch, fork and Dependabot cases legitimately skip it. Only failure refuses — covering both HealAuthorCommitRequired and the deliberate SupersededByHealedHead exit after heal auto-pushes a repair.

Retracted first design — recorded because the note in-tree retracts it

The first cut set the job condition to !failure() && !cancelled(), so an upstream failure skipped ci. That was a fail-open on the only required merge gate, found by review 49309. Verified on three legs:

1. GitHub's troubleshooting-required-status-checks: a job skipped by a conditional reports Success; one skipped because a needed job failed "may not block merging".
2. The live default-branch ruleset (16178731) names exactly one required context — ci. heal_generated_artifacts is not required.
3. Composing them: drift would leave ci skipped-as-success while only the non-required heal job was red, so GeneratedArtifactDriftGate and merge-admission stamping could be bypassed.

The retracted note also claimed "a skipped job does not satisfy a required check". That is false and is retracted in place in ci_floor_upstream_red_refusal_note, with both receipts cited. It was written from reasoning rather than from a receipt.

Witnesses (31/31 PASS)

• floor_job_waits_on_the_heal_preflight — the dependency
• floor_job_runs_even_when_an_upstream_job_failed — condition is !cancelled(), and both failure() and success() are refused by name. Polarity is inverted from the first revision on purpose: the dangerous edit is no longer "simplify to success()" but "reintroduce failure()", which reads as a tightening and is in fact the hole. Proven discriminating by reintroducing !failure() && !cancelled() -> exit 1.
• floor_refusal_is_exactly_the_first_step — list_head(ci_job().steps) must BE the refusal step, so it cannot drift behind checkout/toolchain/download. Proven discriminating by moving the step behind the prelude: this witness fails while the existence-only fold still passes.
• floor_refusal_reaches_only_the_job_whose_needs_it_names — the step was first added to the shared ci_floor_job_prelude_steps() and leaked into the regen job and falsifier.yml; in regen (needs: [build]) the referenced results do not exist, so it would have compared "" != "success" and refused on every run. Caught by reading the generated artifact; this control reds if it leaks again.
• floor_refusal_tolerates_a_skipped_heal_but_not_a_failed_one — the heal-vs-siblings asymmetry.

The generated ci.yml is not separately asserted for ordering because the drift gate already pins ci.yml == the model's projection, so model-first-step plus drift-clean composes.

Diff vs main

4 files. ci.yml delta is needs: [build, regen, heal_generated_artifacts], if: "!cancelled()", and the refusal step.

Test plan

claim_batch --source-root dag --source-root src/v2 --entry dag/test/claim/ci_heal_job_witness_test.dag — 31/31 PASS, plus the two discriminating REDs above run by hand and observed to exit 1.

[gunbai-bot]

review 49309 was correct and the finding is fixed in e95119f. I confirmed it on three independent legs before touching anything, because the finding was against a claim I had written:

1. GitHub's documented behavior — the troubleshooting-required-status-checks page states a job skipped by a conditional reports Success, and a job skipped because a needed job failed "may not block merging".
2. The live ruleset (id 16178731) names exactly one required context — ci. heal_generated_artifacts is not required.
3. Composing them: heal fails → ci skipped → ci satisfies its own required check by being absent → GeneratedArtifactDriftGate never runs → drift merges while only a non-required job is red.

So the change intended to remove wasted computation would have removed the wall. That is a DESIGN §5 fail-open and the review's hard-reject bar applies.

The fix is the one the review named. The job condition is now !cancelled(), so ci runs whenever the run is live — including on upstream failure — and the required context always produces a real verdict. The refusal moved into an executing first step that reads needs.<job>.result and exits 1 with a typed, located FloorUpstreamAlreadyRed. The budget saving survives: a runner spin-up and a string compare, not a floor run. heal may be skipped (it is pull_request-only) and the floor proceeds, so main's cold control is intact; only failure refuses.

The note was the worse half of the defect and is retracted in place. It asserted "a skipped job does not satisfy a required check". I wrote that from reasoning rather than from a receipt — precisely the §5 trap of fluent output that was never run. The replacement states the verified mechanism and cites both receipts.

A second defect, which the review did not raise and I caught by reading the generated artifact rather than the model: I first added the refusal to ci_floor_job_prelude_steps(), which is shared, so it leaked into the regen job and into falsifier.yml. In regen (needs: [build]) the referenced results do not exist, so the guard would have compared "" != "success" and refused on every run. It is now composed into ci_job()'s own step list, and floor_refusal_reaches_only_the_job_whose_needs_it_names is the control that reds if it leaks again.

Witnesses 30/30 PASS. floor_job_runs_even_when_an_upstream_job_failed refuses both failure() and success() by name — note the polarity inverted from the previous revision, because the dangerous edit is no longer "simplify to success()" but "reintroduce failure()", which reads as a tightening and is in fact the hole. Proven discriminating by reintroducing !failure() && !cancelled() and observing exit 1.

— sent from loyal-ram-550