Incident 2026-08-08: merges from stale branches replaced main and discarded five merged PRs (fixed; regression test needed)#212

STATUS: incident record + one follow-up. The fix is MERGED (PR #5464); decision needed: none — follow-up test is queued work.

What happened: six design-sweep branches were cut from the same main and merged sequentially. The merge endpoint's ref update is a bare git update-ref base head, which replaces base — only a true merge when base is an ancestor of head. Each merge therefore replaced main with that branch's tip, discarding the previously merged ones. After all six, main contained only the last branch; PRs #5457–#5462 read "merged" while their commits were absent from main. Production deployed the impoverished main.

Why it was caught: post-deploy browser verification (the render-in-browser rule) — /notifications didn't show its merged fix. Every commit survived on its branch; PR #5464 restored all of them via true merges and added the guard.

The fix (shipped): both update-ref sites (src/lib/pr-merge.ts executeGitMerge — the shared executor — and src/routes/merge-queue.tsx) now check git merge-base --is-ancestor base head first; non-fast-forward heads route through mergeWithAutoResolve, producing a genuine merge commit (no AI needed for clean merges; conflicted-and-behind fails honestly).

Follow-up (this issue): add a regression test — repo fixture where main advances after branch creation; merging the stale branch must (a) keep main's newer commit reachable and (b) produce a merge commit; and the merged-PR "Files changed" recovery (PR #5445) should be re-checked against merge commits produced by this new path.

Why 3,000+ prior merges never hit it: the platform's own development was strictly sequential — every branch was cut from the then-current main, so update-ref was always a legitimate fast-forward. The first parallel-agent session exposed it within an hour.