[infra] Stale-branch friction is 8.6% fleetwide; auto-merge is already enabled, the gap is in how we merge

[twistedmelonman]

The measurement

8.6% of merged PRs fleetwide needed a branch update before they could merge —
64 of 741 since 2026-06-01. Concentrated, not uniform:

Repo	Stale rate
qwen-sidebar	33% (4/12)
tensegrity	30% (3/10)
mac-server-setup	21% (6/29)
github-workflows	20% (7/35)
kebab-tax-netlify	15% (6/39)
dotfiles	12% (12/100)
dev-env	9% (4/44)

Nine repos with 10+ merges sit at exactly zero.

Method: detect a Merge remote-tracking branch 'origin/main' commit on the PR
branch. Validated against a known-positive (#123) and known-negative (#121).
A rebase-style update leaves no such commit, so 64 is a floor.

What I expected, and what's actually true

The obvious fix was to enable allow_auto_merge fleetwide. It is already
enabled on 38 of 44 repos. The six without it should stay without it:

Repo	Why not
superpowers, superpowers-marketplace	Archived 2026-09-11
homebrew-brew, Instapaper-MCP	Forks, no longer maintained
claude-config-backup	Automated backup sink, zero PRs ever
cleanroom	6 merges, 0 stale, already strict: false

So the capability was never the gap.

The actual friction

gh pr merge <N> --squash --delete-branch — the only merge command Protocol 6
permits — does not pass --auto. When a PR is stale it fails outright, and the
fix is a manual update, a re-push, and a full CI cycle.

That collides with the merge-lock's 30-minute TTL. --auto would hand the
wait to GitHub, but the merge then completes outside the window with nobody
watching, so the natural move is to do it by hand instead. That is what
happened on #123 today.

Worth deciding

1. Should Protocol 6's permitted command include --auto, or a documented
   fallback for the stale case?
2. Does merge-lock need a mode that survives a pending auto-merge, or is
   re-authorizing after CI acceptable?
3. github-workflows at 20% is the awkward case — highest friction, and the
   repo where a semantic conflict has the widest blast radius (its floating
   tag feeds 40+ callers). Strict mode is doing real work there; it just costs
   the most there too.

Not in scope

Turning off required_status_checks.strict. The measurement was gathered to
inform that question, and the answer looks like "keep it, fix the workflow" —
but that is a separate decision from this issue.

Data: docs/superpowers/plans/2026-09-11-w3-readiness/ and the session that
produced it.

[twistedmelonman]

W3 pilot executed 2026-09-11 — relevant here because it adds a second required check to the three repos this issue measures.

Flipped

standards-check / run-standards-check is now required on:

Repo	contexts after
smartwatermelon/dev-env	claude-review / run-review, standards-check / run-standards-check
twistedmelonman/claude-config	same
twistedmelonman/dotfiles	same

Plus smartwatermelon/.github, which had contexts: [] and now requires standards-check alone (see #89).

An add, not a replace — claude-review / run-review is preserved on all three. Applied via the /required_status_checks/contexts endpoint rather than a full PUT; before/after diffs of the complete protection object show exactly 2 fields changed per repo (contexts and its checks mirror). strict, enforce_admins, required_conversation_resolution, force-push and deletion settings all unchanged.

The gate was observed, not assumed

PR #129 was opened immediately after the flip and watched:

BLOCKED | claude-review=QUEUED, standards-check=QUEUED
CLEAN   | claude-review=COMPLETED:SUCCESS, standards-check=COMPLETED:SUCCESS

That is the part the readiness doc insisted on — a required check that has never been seen blocking is indistinguishable from one that is not enforced. This one held the merge while pending and released it on success.

Check-run names were verified against real emitted output on each repo's last merged PR (standards-check / run-standards-check, app_id=15368) rather than inferred from the workflow files.

Bearing on this issue

Two required checks means two chances to go stale before merge, so the 8.6% staleness rate measured here is now the floor for these repos, not a steady state. dotfiles at 12% and dev-env at 9% are the ones to watch. If the rate climbs, that strengthens the case for resolving the --auto question rather than weakening it.