Repository navigation
fix(ci): debounce the release PR before CI, not after - #293
Merged
Merged
Conversation
wenzowski
marked this pull request as ready for review
August 11, 2026 17:53
wenzowski
force-pushed
the
claude/release-branch-ci-debounce-xaac5u
branch
from
August 11, 2026 17:53
3eba36a to
a3589cc
Compare
wenzowski
marked this pull request as draft
August 11, 2026 17:53
The release PR was opened ready, so release-plz's refresh on every push to `main` was a `synchronize` on a non-draft PR and bought a full matrix over a version bump and a changelog entry. `release-due` sat behind the green check in auto-release-land, so it decided the hold after those minutes were already spent: it throttled the tag and nothing about CI. Measured over one 37-minute window, 5 of 30 `ci.yml` runs were on the release branch, four of them discarded by the next refresh. The PR now opens as a draft (`pr_draft`), which the existing `draft == false` job guards already skip, and auto-release-land runs the debounce first: draft + hold costs nothing, draft + due readies the PR so exactly one matrix runs on the SHA that lands, ready + hold re-drafts to close the tap again. That makes a wholly skipped check set the normal state rather than a corner case, and the inline jq the workflow used filtered `skipped` out before counting — CLOUD-327's false green with a second author. `ci-wait`'s predicate moves into `mise-tasks/checks-green`, which both callers now share, so there is one definition of what green means. `ci-local-parity` gains the sensor on `pr_draft` so the mechanism ships with its gate. Refs: CLOUD-346
wenzowski
marked this pull request as ready for review
August 11, 2026 18:00
wenzowski
force-pushed
the
claude/release-branch-ci-debounce-xaac5u
branch
from
August 11, 2026 18:00
a3589cc to
5358549
Compare
wenzowski
marked this pull request as draft
August 11, 2026 18:05
actionlint's shellcheck leg (SC2129) reads three consecutive appends to $GITHUB_OUTPUT as a style defect. Refs: CLOUD-346
wenzowski
marked this pull request as ready for review
August 11, 2026 18:08
wenzowski
force-pushed
the
claude/release-branch-ci-debounce-xaac5u
branch
from
August 11, 2026 18:08
5358549 to
bf8c42e
Compare
|
Contributor
Author
|
/fast-forward |
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 11, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. #293's set was `final failure` plus five `cancelled`; `final` is a fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
A cancelled run judged nothing. It is the absence of an answer, exactly like the draft-era `skipped` CLOUD-327 taught this repo not to read as a conclusion — but `checks-green`'s catch-all bucketed it with `failure`, and the two rules composed into a trap with no exit. Measured on #293: `land` readied then force-pushed, both events reached the same `concurrency: ci-<ref>` group two seconds apart, and the run on the SHA that would land was the one cancelled. `ci-wait` reported red, `land` re-drafted and stopped — correctly, given "red". Re-running it could not recover: HEAD was unchanged so the push moved nothing, the verify receipt still held, and `graded_runs` counted `cancelled` as graded, so the ready that would have replaced those runs was skipped. Two consecutive invocations died on the identical stale set, neither able to create a single new check-run. The only escape was a hand-minted SHA, which is a manual step outside the loop `land` exists to drive. Both halves move together or the trap survives the first fix: * `checks-green` — `cancelled` joins `skipped` in the no-verdict set (exit 3). The bucket now carries the conclusion beside the name, so a stall that has two spellings can still be diagnosed: `required check(s) with no verdict: ci cancelled, cross skipped`. * `land` — `graded_runs` drops `cancelled`, so a cancelled set reads as "no graded run" and the next lap re-fires the ready. It gains `neutral`, which `checks-green` has always graded: the same drift with the sign reversed, buying a second run for a head that already carried its verdict. The precedence between the two buckets is now load-bearing and says so. fan-in, so its failure was a consequence of the cancellations rather than a judgement on the tree. Testing "no answer" before "red" is what keeps that set recoverable, and a real failure leaves the bucket empty and still exits 1. This does not re-order ready/push. Making a cancellation recoverable is the smaller, more general fix: it holds for a manual cancel and a runner reclaim too. Refs: CLOUD-363
This was referenced Aug 12, 2026
wenzowski
pushed a commit
that referenced
this pull request
Aug 12, 2026
Measured on PR #280: `land` pushed and readied, the head carried exactly two graded runs — `commit-lint` and a third-party analyzer — and `ci-wait` printed "every required check terminal and green". Two minutes later the same head carried `ci`, `cross` and `darwin-link` all in_progress, plus `final`, which had not registered at all. The fast-forward bot was then rejected: `Required status check "final" is expected`. Branch protection held the line, and that is also the tell — this repo's gate and GitHub's required set disagreed about whether the head had an answer, and GitHub was right. Reproducible in one line against the committed roster: CHECKS_GREEN_RUNS=$'completed\tsuccess\tcommit-lint' ./mise-tasks/checks-green => EXIT 0 `pending == 0` is trivially satisfied when the jobs do not exist, so a poll landing between the push and GitHub creating the check-runs saw a small, fully graded set and called it green. ABSENCE IS LEGITIMATE FOR EXACTLY TWO NAMES, and each earns it twice over: `zizmor` and `action` are `paths:`-filtered AND their workflows declare no `types:`, so they take the default [opened, synchronize, reopened] — which omits `ready_for_review`, precisely the event `land`'s `--undo` re-fire emits. The second reason was written down nowhere. `CI_ABSENT_OK_CHECKS` carries the list, and unset or empty is the STRICT direction: everything must be present, because a stall is recoverable and a false green is not. THE ORDERING IS THE SUBTLE PART, and it is asserted rather than assumed. A real failure OUTRANKS a missing name, which is the opposite of how the cancelled bucket works — and the asymmetry has a reason. A cancelled sibling can MANUFACTURE a fan-in failure (CLOUD-363's #293 set), so no-verdict must precede red there. An absent name manufactures nothing; it is a run that has not started, so a failure beside it is an independent verdict and must still re-draft the PR. Not mirrored into `land`'s `graded_runs`: that asks "does any name carry an answer" to decide whether to fire the ready, and requiring presence there would read a healthy partial set as 0 and buy a second run. `tests/checks-green.bats`'s "an absent path-filtered check is not a skipped one" is REWRITTEN — it asserted this false green with a single-name reading. Two things worth knowing for the next reader of this suite: * IN `ci-wait.bats` THE BREAKAGE IS A HANG, NOT A FAILED ASSERTION. The poll is unbounded by design, so a `resp.last` missing a mandatory name never terminates and the rows using a bare `run "$WAIT"` stall the whole suite rather than reporting. That is why the fixture helper emits the full mandatory set rather than the one name each row cares about. * A LATENT ORDERING WART decided the helper's shape: a 3-field TSV row always outranks a 5-field row of the same name, because the empty `started_at` makes the sort key start with `|` (0x7C), which sorts above any ISO-8601 digit. It is fail-closed in effect today, so it is recorded rather than changed here. `ci-wait`'s check-runs request also gains `?per_page=100`, matching every other reader. After this, `land`'s `graded_runs` is the only one left on the default 30. Verified: 33 rows green across both suites; shfmt, shellcheck and taplo clean. Refs: CLOUD-337 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CzqP3AFxFqCm3F4DfCdS92
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CLOUD-346.
The defect
release-plzrefreshes therelease-plz-*branch on every push tomain. That PR was opened ready (release-plz.tomlset nopr_draft), andci.yml/commit-lint.ymltrigger onpull_request: synchronizewith no branch filter and only adraft == falsejob guard — so every refresh bought a full matrix over a version bump and a changelog entry.The debounce was the last gate in
auto-release-land.yml, behind the green check, so it decided the hold after those minutes were already spent. It throttled the tag and nothing about CI.Measured,
ci.ymlruns 2026-08-11T16:49Z–17:25Z: 30 runs, 5 of them onrelease-plz-2026-08-11T15-08-10Z— one per push tomain. Run31516819543:ci242s,darwin-link60s,cross37s,msrv34s,final4s ≈ 6.3 job-minutes, ~10 billed once each job rounds up, plus the pairedcommit-lint. Four of the five ended in a hold and were discarded by the next refresh.The change
The PR is now a draft until the debounce says due, so a hold costs nothing and the one matrix that is spent is spent on the SHA that lands.
release-plz.toml—pr_draft = true. Verified against the pinnedrelease-plz 0.3.160: the key parses (a bogus sibling key errors at parse; this one does not)..github/workflows/auto-release-land.yml— the debounce runs first, and the job is one four-state machine: draft+hold → nothing; draft+due →gh pr ready(with the PAT, since aGITHUB_TOKENready_for_reviewfires no workflow); ready+hold →gh pr ready --undo, closing the tapmainreopened; ready+due → judge the checks, then/fast-forward.mise-tasks/checks-green(new) — the green predicate as one command. Draft-by-default makes a wholly-skipped check set the normal state, and the inline jq this replaces filteredskippedout before counting, so that set read as zero outstanding, i.e. green. That is CLOUD-327's false green with a second author; without this the change would land a SHA no CI run of ours judged.mise-tasks/ci-wait— keeps the poll, ETag and interval; delegates the verdict. Its own exit codes and output are unchanged, andtests/ci-wait.batsis untouched as the regression net proving the predicate survived the move.mise-tasks/ci-local-parity— a fifth property:pr_draft = truemust be declared. The mechanism ships with its gate, on both surfaces it is already wired to (hk.pkl,verify).mise-tasks/land'sgraded_runsis deliberately untouched: it asks for a count of graded runs, not a verdict, and rewriting the landing loop is not this change.Verification
mise run test:bats— 734/734, includingtests/checks-green.bats(9 new cases: all-skipped → 3, third-party successes over a skip set → 3, pending → 3, empty reading → 3, required failure → 1 and named, third-party failure → no veto, absent path-filtered check → 0, unset roster → 2) and three newci-local-paritycases.mise run ci-local-parity— green on the real tree; the new property bites on a fixture without the key, with it set tofalse, and on a missing file.mise run lint:actions,mise run fmt— clean.mise run verify— green before readying.Acceptance is observable after landing rather than asserted here: the next push to
mainshould refresh the release PR as a draft, and itsci.ymlrun should carry onlyskippedjobs (unbilled) instead of a graded matrix.Generated by Claude Code