CI round-trips, not CI compute: 71% of PR lifetime is the push–wait–fix loop #15932

Problem

CI compute is healthy. CI round-trips are what cost us. Measured across the last 40 merged
PRs and the last 400 workflow runs:

Read together: an 8.9-minute suite is being paid for roughly six times per PR, plus once more for
every bot commit, plus up to 15 minutes of parked-run dead air each time — and the verdict it
produces may describe a base the change will never land on.

Two conclusions this explicitly rules out, so nobody re-proposes them:

• Review capacity is not the bottleneck. 3 open PRs, 2.8 h median merge.
• Runner speed is not the bottleneck. Queue wait ≈ 0; faster hosted runners would buy nothing.

Tasks

Wave 1 — no blockers

• Task 1: Local preflight covers the 10 required checks → Local preflight must cover the 10 required checks #15933
• Task 3: Parked runs approve on workflow_run, not a 15-minute cron → Approve parked runs on workflow_run, not a 15-minute cron #15935
• Task 4: Consolidate the 62 advisory checks into one policy job → Consolidate the PR-metadata policy checks into one job #15936
• Task 5: Enable the merge queue so CI's last word runs against the real base → Enable the merge queue — no PR merges against a stale base #15937

Wave 2

• Task 2: Bot stops pushing to PR branches — formatting and codegen move to pre-commit → Stop the bot pushing to PR branches — formatting and codegen move to pre-commit #15934 (depends on Local preflight must cover the 10 required checks #15933)
• Task 6: Worktrees and PR-less branches are kept on a fresh base → Keep worktrees and PR-less branches on a fresh base #15938 (depends on Local preflight must cover the 10 required checks #15933)

Expected effect

Each avoided push saves ~9 min of suite plus its share of park and cancellation churn. Cutting the
iteration phase from ~6 pushes to ~2 targets the 127-minute block that dominates the cycle. The
merge queue and the worktree guard remove the class of re-run that is caused by discovering base
staleness after the suite has already run.

Acceptance criteria

• Iteration phase (first→last commit) median drops below 95 min over 20 consecutive merged PRs
• Bot-authored share of PR commits drops below 5%
• Concurrency-cancelled run share drops below 10% of completed runs
• No PR merges against a stale base — every merge is a merge-queue entry tested on final base
• No PR-less pushed branch more than 50 commits behind base
• All six child issues closed with code evidence

Expected speedup — measured, not assumed

CI failures during iteration are real and were mismeasured twice before this section was correct.
Both bad numbers came from a query whose shape decided the answer:

• "4 failures in 400 runs" — gh run list --limit 400 spans 75 minutes on this repo
  (06:23:54Z to 07:38:57Z, ~5.3 runs/min), not a base rate. A quiet window, and all four failures
  were Code Quality / Security Scanning.
• "0 failed checks across the last 20 merged PRs" — selection bias. gh pr checks reports the
  latest check per name on a merged PR's head, which is green because it merged. That query
  measures the merge gate and structurally cannot return non-zero.

Querying failed check-runs across each merged PR's own commits — reds during iteration, which is
what this umbrella is about — gives a very different picture:

49 failed check-runs across 9 merged PRs — every one was red at least once on the way. Failures
cost iteration time; they were invisible because the query looked at the wrong end.

Inter-commit gaps (n=75 across 12 PRs, median 10.8 min, p90 43 min) show where the time sits:

Realistic landing: 2.9 h → ~2.1 h, roughly 25–30%.

Two things this umbrella explicitly does not buy, so they are not claimed later:

• It does not shorten the 8.9-min critical path. That is the floor for any merge.
• It does not touch the >15-min authoring gaps, which are the single largest block of the 127 min
  and are real work, not waste.

The original < 60 min iteration-phase target stands corrected to < 95 min — an acceptance
criterion nobody can hit is not a criterion. That correction survives; the premise downgrade that
briefly accompanied it does not.

Method note for anyone extending this analysis: two of the three wrong conclusions in this
umbrella's history came from query shape, not from bad data. State the query alongside the number.

Correction log — #15937 had a blocking gap that does not exist

The original filing claimed two *-required-context shims lacked a merge_group trigger and would
hang the queue. Audited before starting work: all 10 required contexts already report in a
merge_group run. The shims are pull_request-only by design — they are the complement of the
real workflow's path filter, and adding merge_group to them would emit a duplicate context. Full
table on #15937.

#15937 therefore has no code prerequisite; it is an enablement change and the follow-on
reassessment of auto-update-pr-branches.yml. Enabling the queue changes how every merge in the
repository behaves, so it is a decision for the repository owner rather than something to land in a
PR — flagged, not actioned.

That is one of five findings today where a query over one field produced a conclusion about a
structure. Logged together because the pattern is the finding, not any one instance:

Instances 2 and 5 were caught by a peer session; 3 and 4 were mine to retract. The response to #5 is
the one worth copying: the fix is not to special-case the missing field but to stop keying on it —
plain git worktree list cannot lose a row the way a --porcelain field parse can.

Standing rule: state the query alongside the number, and check the complement before calling
something missing. The shape to watch for is a negative result indistinguishable from the intended
one — which is also exactly what #15956 turns out to be, in a mechanism whose whole job was to ask a
human.