P0: the gate merged a PR while required checks were still running — cause of today's three main outages

[JSONbored]

The gate merged a PR while its required checks were still running — and they failed

#10177, from the GitHub check-runs API on its head SHA:

merged:          2026-07-31T11:20:43Z
validate-code    success   completed 11:14:00   (before the merge)
validate-tests   FAILURE   completed 11:23:59   (3 min AFTER the merge)
validate         FAILURE   completed 11:26:32   (6 min AFTER the merge)

validate is the required aggregator. It had not completed when the merge happened, and it subsequently failed. The PR was merged on an incomplete check set.

This is the cause of today's three main outages

main went red on dead-exports:check three times today — #9944, #10109, #10194 — each blocking every open PR until someone noticed by hand. Each was assumed to be an independent slip. They are the same failure: a PR merged before its checks finished, so the breakage landed on main and only surfaced afterwards.

For #10194 specifically: MCP_SERVER_NAME was dead in #10177's own tree — git grep MCP_SERVER_NAME 2cafde31b finds no reference outside src/mcp/server.ts. So this was catchable pre-merge. It was not caught because the merge did not wait.

Why this matters more than the individual breakages

The gate's entire safety argument is "green CI + passing gate + mergeable-clean ⇒ auto-merge". If merge can fire while required checks are still pending, that argument does not hold — the PR was never actually green. Every guard the repo has (the exhaustiveness checkers, the drift tests, the invariant suites) is downstream of a merge that waits for them.

It also silently undermines #10146: that escalation notices a workflow red across consecutive runs, but here the first red arrives after the merge that caused it, so by the time anything escalates the damage is already on main.

What to investigate

• Does the disposition treat "check not yet reported" as satisfied? assessMergeableState maps GitHub's unstable (checks failing OR still running) — and gate: an unstable merge state summons a human and then latches the manual-review label #10116 deliberately stopped that from holding. That change is correct for the manual-review label, but merge eligibility must still require the required checks to have COMPLETED, not merely to be non-failing. Worth confirming wouldMerge's mergeable === "clean" is actually sufficient here: GitHub reports clean when required checks pass, but the aggregate may be evaluated from a stale snapshot.
• Is the executor's live re-check reading a cached check-run set? refreshLiveCiAggregate and the durable CI-state cache are both in this path, and the cache is invalidated per check_suite.completed — a merge decision taken between the invalidation and the refetch would see the pre-completion snapshot.
• The 11:14 → 11:20 gap between validate-code succeeding and the merge suggests the decision was made on a partial set that looked complete.

Priority

P0 in effect: it is the mechanism by which broken code reaches main, and it has fired three times in one day. Every other guard in the repo assumes it does not happen.

Found while investigating why #10194's dead export was not caught pre-merge.

[linear-code]

JSO-7120

[JSONbored]

Reproduced live, observed in real time

#10204 (verdict-stability backoff), checked seconds after it merged:

{"state":"MERGED","failed":[],"pending":["validate-tests"]}

Merged with validate-tests still running. This is the fourth instance today and the first one observed as it happened rather than reconstructed afterwards, so there is no ambiguity about check-run timing or API lag: the PR was merged while a required check had not reported.

Same shape as #10177 in the issue body:

#10177 merged 11:20:43 · validate-tests FAILURE 11:23:59 · validate FAILURE 11:26:32

There, the still-running checks went on to fail and took main red. Here they may well pass — but that is luck, not a control. The merge decision did not depend on the outcome either way, which is the defect.

Why this raises the priority

Every other guard in this repo — the exhaustiveness checkers, the drift tests, the invariant suites, the migration dialect check added today in #10143 — is downstream of a merge that waits for CI. If merge does not wait, none of them are load-bearing on main; they only tell you what broke, after it broke.

Concretely today: three main outages (#9944, #10109, #10194), each blocking every open PR until a human noticed, all explained by this one mechanism. main's state also stopped being trustworthy enough to cut a release from — beta.8 required hand-verifying that HEAD's CI had actually completed green before cutting, which is not a workflow that scales.

[JSONbored]

Retracted — the premise is wrong

I filed this claiming "the gate merged a PR while required checks were still running." That is false. Checking mergedBy, which I should have done before filing:

#10177  mergedBy=JSONbored  11:20:43
#10195  mergedBy=JSONbored  12:03:20
#10204  mergedBy=JSONbored  12:34:36

All three were merged manually by the maintainer, not by the gate. A maintainer choosing to merge ahead of CI is a deliberate call they are entitled to make, not a defect — and the "live reproduction" I recorded in the comment above was the same thing: me watching a human merge and attributing it to automation.

What I got wrong

I reasoned from timestamps — merge at 11:20:43, required check failing at 11:26:32 — to a mechanism, without checking the one field that identifies the actor. The timing evidence was real; the causal claim I hung on it was not. I then escalated it to P0 and called it "the most important finding of the session," which compounded the error.

What actually survives

Only this, and it is not a bug: the three main-red incidents today (#9944, #10109, #10194) are explained by PRs landing before their checks completed. That is a known and accepted consequence of merging early, and the fix is already in the maintainer's hands.

Nothing in the gate's merge path needs changing on this evidence. Closing.

dead-exports:check being the thing that breaks each time is still worth a glance — it is consistently the first checker to catch a bad merge, which makes it a useful early signal — but that is an observation, not an issue.