Background
main is protected and the sole code-owner cannot self-approve, so merges are
routinely completed with an admin override (gh pr merge --admin --squash). The
override bypasses the required-checks gate — which is the point — but it also
bypasses any check on whether the checks actually ran.
What happened (2026-08-09)
PRs #239 and #240 were both merged after their CI runs had been
cancelled, not completed. ci.yml sets:
concurrency:
group: ci-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
so a superseding push cancels the in-flight run. A cancelled run reports no
failures, and the PR summary at merge time read as green. Both merged. main
went red on rustfmt and stayed red until commit cb44b56 repaired it.
This is not a hypothetical: it already produced a broken main on the branch
immediately preceding the v0.4.0 tag.
Problem
"No failing checks" and "all checks passed" are different predicates, and the
merge path only evaluates the first. A cancelled, skipped, or never-triggered
run is indistinguishable from a green one at a glance.
Proposed change
Pick one (or both):
(a) Verified pre-merge step. Before any --admin merge, assert every
required check is status == COMPLETED and conclusion == SUCCESS — not
merely "not failing". Encode it as a script (scripts/verify-pr-checks.mjs) so
it is one command, not a habit, and document it in CONTRIBUTING.md /
RELEASING.md as the mandatory pre-merge gate.
(b) Branch-protection change. Configure required status checks so that a
cancelled run blocks the merge, and reserve the admin override for cases where a
human has explicitly confirmed the run state.
Option (a) is cheap and available immediately; (b) is the durable fix.
Acceptance Criteria
Reference
Background
mainis protected and the sole code-owner cannot self-approve, so merges areroutinely completed with an admin override (
gh pr merge --admin --squash). Theoverride bypasses the required-checks gate — which is the point — but it also
bypasses any check on whether the checks actually ran.
What happened (2026-08-09)
PRs #239 and #240 were both merged after their CI runs had been
cancelled, not completed.
ci.ymlsets:so a superseding push cancels the in-flight run. A cancelled run reports no
failures, and the PR summary at merge time read as green. Both merged.
mainwent red on
rustfmtand stayed red until commitcb44b56repaired it.This is not a hypothetical: it already produced a broken
mainon the branchimmediately preceding the v0.4.0 tag.
Problem
"No failing checks" and "all checks passed" are different predicates, and the
merge path only evaluates the first. A cancelled, skipped, or never-triggered
run is indistinguishable from a green one at a glance.
Proposed change
Pick one (or both):
(a) Verified pre-merge step. Before any
--adminmerge, assert everyrequired check is
status == COMPLETEDandconclusion == SUCCESS— notmerely "not failing". Encode it as a script (
scripts/verify-pr-checks.mjs) soit is one command, not a habit, and document it in
CONTRIBUTING.md/RELEASING.mdas the mandatory pre-merge gate.(b) Branch-protection change. Configure required status checks so that a
cancelled run blocks the merge, and reserve the admin override for cases where a
human has explicitly confirmed the run state.
Option (a) is cheap and available immediately; (b) is the durable fix.
Acceptance Criteria
COMPLETED+SUCCESS; cancelled / skipped / queued all report FAIL--adminmergethe command must report FAIL for those
RELEASING.mdpre-flight references it, since the tag path assumes greenmainReference
acb8a86) and fix: atomic_write_file: warn on metadata failure instead of silently using 0600 #240 (de8857d) — merged on cancelled runscb44b56— repaired the resulting rustfmt breakage onmain.github/workflows/ci.yml:11-14— thecancel-in-progressconcurrency group