ci: one merge to base triggers ~200 workflow runs — the freshness guarantee costs N-open-PRs full suites #16203

One merge to base costs ~200 workflow runs, and the cost scales with how many PRs are open

Measured over a 35-minute window on 2026-09-10, immediately after #16118 merged into
Dev_new_gui:

total workflow runs in the window          308
  triggered by pull_request                271
  triggered by push                         12
14-day total for scale                   56,777   (~4,055/day average)

308 runs in 35 minutes is roughly 3x the 14-day average rate, sustained only because a merge
had just landed.

The cascade is per parked branch, and it isolates cleanly

Runs by head branch in that window:

issue-16157-real-candidate   56     <- also had its own session pushes
issue-15938-fresh-base       54     <- also had its own session pushes
issue-16188-lazy-imports     47     <- also had its own session pushes
issue-16179-git-scrub        26     <- bot update only
issue-16026-manifest-cache-ttl 26   <- bot update only
issue-15950-enforce          25     <- bot update only
issue-16190-nul-delimited    24     <- bot update only
issue-16198-import-hermetic  22     <- bot update only
Dev_new_gui                  13

The four branches nobody pushed to during the window all land at 24-26 runs, which isolates the
auto-merger's own contribution from session activity. So:

one base merge → ~25 workflow runs per parked branch × N open PRs

With 8 parked branches that is ~200 workflow runs per merge, before the base branch's own 13.

Why this is a tension, not simply a bug

The auto-merger (#15938) exists for a good reason, and the freshness rule it enforces is one this
repository is right to have: a green run on a stale merge base is a verdict about a tree that will
not be the one landing. Merging a PR that is behind is how a guard added to base turns the branch
red after the fact, with no file overlap to warn you.

So the cascade is the freshness guarantee being paid for. The question is not whether to keep
branches fresh — it is whether every parked branch needs a full suite on every base merge.

Observations that might inform a fix, offered as measurements not proposals

• The suite is ~25 workflows per update. Many are cheap gates (PR Template Check,
  Validate PR Issue Link, No commit trailers) that cannot be affected by a base merge into a
  branch whose own diff did not change.
• CI Dispatch Watchdog, SSOT Coverage, PR Blocking Findings and Docker Smoke Test each ran
  12 times in the window — once per branch.
• A base merge changes the merge result, not the PR's own diff. Checks that read only the PR diff
  (template, issue link, trailers, batching) have the same input before and after.
• The 14-day figure requires a created>= filter to be truthful; without one the endpoint returns a
  capped 40000 rather than the real 56,777.

Acceptance criteria

• The per-base-merge workflow-run cost is measured before and after any change, using a
  created>= filtered count, and recorded on this issue.
• Checks whose input is the PR's own diff do not re-run when only the merge base moved, OR a
  recorded decision explains why each must.
• Branch freshness is preserved — a PR that is behind base must still not merge on a stale green.
  Any fix that trades the freshness guarantee for runner minutes is the wrong trade and should be
  rejected on this issue.
• The cost model is stated in the workflow's own documentation, so the next person adding a
  workflow knows it is multiplied by the number of open PRs.

Provenance

Measured while sweeping the queue after #16118 merged and finding all nine open PRs simultaneously
re-running. Related: #15938 (the auto-merger), #16152 (the ceiling that keeps parked branches
around).