Dependency upgrades have no release valve: majors and grouped PRs wait on review that does not scale

[twistedmelonman]

The problem

Auto-merge policy today is binary: patch/minor auto-merge, majors and grouped PRs go to manual review. The safety half is right. The review half does not scale — Andrew cannot review each one, and they cannot wait indefinitely, so they accumulate.

"I can't review each one and they can't wait indefinitely. ideally we should have a standard 'accept after a week' system." — 2026-09-10

There is no third state between "merge immediately" and "wait for a human who may never get to it."

Measured state, 2026-09-10

20 open Dependabot PRs fleet-wide. Ages run to 12 days. Of those checked:

State	Count	Meaning
CLEAN, checks green	3	Mergeable now; waiting only on attention
BEHIND	3	Need a branch update, otherwise fine
RED on own content	2	Genuinely need work (kebab-tax-netlify#280, cleanroom#13)
RED on an unrelated repo-wide failure	5	Blocked by someone else's problem

The cost is concrete, not hypothetical

All five red amelia-boone PRs (#67, #72, #73, #74, #75) were red because of the repo's audit gate failing on advisories unrelated to those PRs — issue #79, red since 2026-08-30. Verified directly: #72's CI failure is FAIL: advisories not in the accepted baseline: GHSA-px8p-9vwx-vf98 fflate, which has nothing to do with the minor-and-patch group it bumps.

So one unfixed red gate held five unrelated dependency PRs hostage for days, and nothing surfaced that. Four of the five should go green once #80 merges.

This is the compounding failure mode: a stalled queue hides which PRs are actually broken, because everything is red for the same borrowed reason.

What exists today

github-workflows/.github/workflows/dependabot-auto-merge.yml already does the hard correctness work and should be built on, not replaced:

• computes patch-vs-major from previous/new version itself rather than trusting steps.metadata.outputs.update-type (which mislabels reusable-workflow majors as patch)
• forces any multi-dependency group PR through the namespace-allowlist path, so a major cannot ride along inside a group that looks like a patch
• keeps a trusted-namespace allowlist for major bumps

The missing piece is purely the time dimension. Every decision is made at PR-open time and never revisited.

Proposed direction (needs design, not adoption as written)

A soak-then-accept tier between auto-merge and indefinite wait:

• Patch/minor — unchanged, auto-merge immediately.
• Majors and groups — become eligible for auto-merge after a soak of N days (a week, per the ask) provided CI has been continuously green for that window and the PR has not been touched.
• Never soak-merge — anything whose checks are red, anything in a repo whose default branch is red (avoids merging into a broken baseline), and any PR a human has explicitly marked hold.
• Escape hatch — a label that either forces the wait or skips it.

Open questions for the design pass:

1. Where does the timer live? A scheduled workflow that re-evaluates open Dependabot PRs is the obvious shape, since the existing workflow is pull_request-triggered and cannot observe elapsed time.
2. Does the soak clock reset when Dependabot force-pushes a rebase? It should, or the soak proves nothing about the code that actually merges.
3. How does "CI green for the whole window" get verified rather than "CI green right now"? The latter is trivially satisfiable by a single passing run and would not catch a flaky or intermittently red PR.
4. Should a repo with a red default branch block soak-merges into it? Argues yes, per the amelia-boone case above.
5. Does this interact with the merge-lock? These would merge without a human-typed lock by construction, which is a deliberate policy decision and should be recorded as one rather than emerge as a side effect.

Why this is worth doing now

The queue is at 20 and the oldest is 12 days. The failure is not that a bad upgrade might land — the existing workflow guards that well. It is that good upgrades do not land, security patches included, and a permanently-stalled queue trains everyone to ignore it. amelia-boone#79 sat red for 11 days on a check that was not a required context; nobody noticed because there was always something red.

Related: #75 (branch protection consistency), the amelia-boone#54 astro major that has been waiting on exactly this kind of decision.

https://claude.ai/code/session_01ESsw699T54JHARkQXrdL3o

[twistedmelonman]

Follow-up: the borrowed-failure claim, measured after the fix

amelia-boone#80 merged (closing #79), so the prediction in this issue — that five PRs were red for a borrowed reason — can be checked rather than asserted. It was mostly right, and wrong in an instructive way.

PR	Before	After the audit gate was fixed
#72 → #82	RED	CLEAN. Dependabot superseded #72 and closed it
#74 (eslint-plugin-astro 1.7 → 3.1, major)	RED	CLEAN
#75 (@netlify/functions 5 → 6, major)	RED	CLEAN
#67 (@shikijs/transformers 3 → 4)	RED	still RED — its own problem
#73 (astro 5 → 7)	RED	still RED — its own problem

Three of five were purely borrowed failures and went green with no change to their own content. Two majors among them had been sitting since 2026-09-05 for a reason that had nothing to do with them.

The two that stayed red are genuinely broken and worth naming, because they are the counter-example to a naive soak timer:

• Non-blocking review findings from PR #66 (2) #67 — @shikijs/types 4.4.3 and 3.23.0 coexist in the tree, so astro.config.ts fails to typecheck (ts(2322), ShikiTransformer not assignable to itself across versions).
• docs: mark the contamination handoff as superseded in part #73 — astro major; build and Netlify deploy preview both fail. This is the [infra] Migrate smartwatermelon/ repos to a new GitHub org for org-level secret management #54 migration.

What this sharpens for the design

A soak timer keyed on "CI green for N days" would have done the right thing here only after #79 was fixed. Before that, all five looked equally red, and a timer would have correctly refused to merge any of them — including the three that were actually fine.

That is the argument for open design question 4 (block soak-merges when the default branch is red): while main's own gate is failing, the queue carries no information, and the timer should not be accumulating credit. Otherwise a repo-wide breakage silently ages every PR toward eligibility on evidence that means nothing.

It also argues the policy should surface why a PR is red — borrowed vs. its own — since that distinction is what separates "wait" from "someone must do work."

https://claude.ai/code/session_01ESsw699T54JHARkQXrdL3o

[twistedmelonman]

Re-measured 2026-09-11: the numbers above are stale

The 20-PR backlog that motivated this issue is gone. 16 of the 20 merged as
soon as someone looked at them. They were not waiting on a policy decision —
they were waiting on a human noticing they existed.

Current queue, measured just now across all three owners:

Bucket	Count	Detail
Blocked by the pre-merge hook	1	personify#75 — NEUTRAL CodeQL
Failing non-required checks	4	kebab-tax-netlify#280, cleanroom#13, amelia-boone#73, amelia-boone#67
Mergeable and merely waiting	0	—

Why this changes the proposal

A soak-then-accept tier merges a PR after N days of green CI. None of the
five remaining PRs would ever qualify:

• Four are red. cleanroom#13 fails markdownlint (MD041/MD047 on
  cleanroom.spec.md, exit 1 — a real content failure, not the
  standards-check tooling bug fixed on 09-09). amelia-boone#73/#67 are
  majors with failing builds. kebab-tax-netlify#280 fails nine checks.
• One is blocked by a NEUTRAL check, which the timer would not clear either.

So the tier would have fired on exactly zero of the PRs that prompted it. The
backlog was a visibility problem wearing a policy problem's clothes: the
auto-merge workflow declines majors and grouped updates by design and then
emits no notification at all, so declined PRs fall silent.

What was built instead

dev-env#130 adds a daily digest that surveys all three owners and rewrites one
issue describing the queue, bucketed by what a human must actually do.

One design note worth recording, because it inverts the obvious approach: the
buckets mirror pre-merge-review.sh, not GitHub branch protection. All
four long-stalled PRs are MERGEABLE with every required check green while
their builds genuinely fail — so a digest built on branch protection would have
recommended merging PRs that are broken. It offers paste-ready merge-lock
lines only for PRs that pass the mechanical gates, and says plainly that the AI
review still has a vote.

Closing this in favour of #130. If a soak tier still looks worthwhile once the
digest has run for a while, the digest itself will be the evidence — it
measures exactly the population such a tier would act on.