4 号机刚 Approve，2 号机的代理又 force-push 了一次：合进去的到底是哪一版？（中英切换）

Thursday 4:00 p.m. Someone on machine 4 hits Approve on PR #42. Coupons are moving to per-line discounts. line_discount has pct = max(0, min(100, pct)); the review comment says "keep the clamp." Machine 6's Windows job wrote win-verify: success on the same SHA. Machine 7 is ready to merge.

At 4:12 the agent on machine 2 pushes again: "fixed a lint, amended." Same branch feat/coupon-v2. The green Approve is still there. CI goes green again. Machine 7 sees "reviewed + checks green" and merges.

The merged tree has no clamp. While tidying tests the agent also dropped test_line_clamp. A 150% discount ships. Finance asks the next morning.

First message in the chat: "Didn't we already Approve?" Second message is the real question: which SHA did Approve bind to, and which SHA actually merged?

I built a toy repo and a local simulation of GitHub review/status behavior. The git commits and amends are real. Reviews, commit statuses, isOutdated, and branch-protection knobs are simulated from documented behavior — not the live GitHub API. win-verify is a fake context name; nothing was run on Windows. Numbers below are from this run; the last section lists what was and wasn't live.

Scene: Approve A, force-push B

Toy repo shop: main has whole-order discounts in pricing.py. Feature branch feat/coupon-v2 commit A adds per-line discounts, VIP15, and the clamp the reviewer asked to keep. Simulate machine 4 Approving A, machine 6 writing win-verify: success on A, then machine 2 git commit --amend to commit B — clamp gone, edge-case test gone — and force-push.

Short SHAs from this run (rebuilds change them; the relationship does not):

Without gates: review_decision stays APPROVED, merge ships B

Default of many repos: dismiss_stale_reviews_on_push = false, require_last_push_approval = false, no "block force-push after Approve".

Results:

• force-push allowed
• review_decision still APPROVED
• that Approve's commit_id still on A (978581a); HEAD is B (e30f356)
• naive merge gate ("any Approve counts; any SHA success for a context counts") → mergeable_naive = true, ships unreviewed B

Harsher variant (scenario 1e): CI and win-verify both go green on B, Approve still on A. Naive merge still ships. A "statuses must be on HEAD" check also passes — they are on HEAD. The only pointer still on the old SHA is the Approve. So required status checks alone do not catch "review is stale"; you need "approval of the most recent reviewable push" or a custom headShaMustMatchApproved.

Status SHA skew: win-verify still on A

Common middle state: Linux CI is fast, Windows is slow. After B is pushed, ci is success on B; win-verify still only on A.

Scenario 2:

• HEAD = e30f356
• win-verify success only on 978581a
• even if machine 4 Approves B again, the strict gate still refuses
• check_merge_sha.py prints:

BLOCKED for HEAD e30f356:
  - requiredStatusesOnHead: win-verify not success on HEAD e30f356; seen ['978581a:success']

Naive merge is true here ("win-verify was green once"). That is the crack between machines 6 and 7: Windows verified the old artifact; merge ships the new one.

Inline comments: what goes outdated, what re-anchor can save

Before Approve, machine 4 left two threads on A: VIP15 (L9) and the clamp (L16). Then force-push.

Two runs:

3a — amend removes the clamp. Of 2 threads, 1 goes outdated (the clamp). VIP15's hunk fingerprint still matches. Local re-anchor by fingerprint: restored 0, failed 1. The comment says "keep the clamp"; the code no longer has it — re-anchor cannot restore deleted intent. Re-review.

3b — docstring-only prepend (+2 lines), clamp kept. Simulate GitHub marking both outdated when diff positions move, then re-anchor by hunk fingerprint: 2/2 restored (clamp 16→18, VIP 9→11). Content kept → line numbers can move. Content gone → moving them is pointless.

Outdated markers are a signal, not a bug. The danger is merging while everyone pretends the old threads still describe HEAD.

Five strategies on the same Approve → force-push

Same toy PR, five configurations:

*The "none" strict column is blocked because win-verify is not on HEAD; if statuses are also green on B (scenario 1e), no approval gate still ships.
†HEAD stays on A, so the reviewed SHA would merge.
‡Without dismiss, GitHub-style decision still shows APPROVED; the strict gate rejects by commit_id.
§Strict gate blocks; naive would ship — so this check must be a required check, not a human glance.

Trade-offs:

• dismiss_stale alone: force-push voids Approve; must re-review. Agents can still force-push; threads still go outdated; merge will not ship.
• plus require_last_push_approval: the new Approve must land on current HEAD. Native GitHub, cheapest fix.
• block force-push after Approve (ruleset / bot): hardest; HEAD cannot drift. Cost: agents cannot "just rebase"; conflict fixes need a ritual (comment, then force-push, then /ready).
• pre-merge script: also checks Approve SHA == HEAD and every required context success on HEAD. Useful when native knobs cannot change yet. It does not replace dismiss; with dismiss off the UI may still say APPROVED while the script fails the required check.

Mechanism: why the hole exists

A GitHub pull request review carries commit_id. If branch protection does not dismiss stale reviews and does not require approval of the most recent push, the merge rule "enough Approvals" only asks whether a non-dismissed Approve exists — not whether it points at HEAD. Commit statuses / check runs are stored per SHA; a UI that looks "all green" may be showing the latest success per context without insisting that success is on HEAD — especially home-grown Windows runners that write statuses via repository_dispatch.

Classic TOCTOU: machine 4 inspected A, machine 7 merges B, machine 2 changed the pointer in between. Agents hit this constantly because they amend + force-push when CI fails, when main moves, or when they want a cleaner squash — and they do not announce "this voids the Approve."

When this does not fit

• You never force-push after Approve. Different problem; these gates are friction.
• Force-push is already banned repo-wide. Stricter than "after Approve"; no need for the bot.
• Merge commits only, no rebase workflow. Lower risk; new commits still need dismiss / require_last_push so review covers HEAD.
• External verifiers cannot be queried by SHA. A Windows box that overwrites "passed" by branch name gives requiredStatusesOnHead nothing true to read — fix reporting first.
• Re-anchoring outdated comments as a silver bullet. In the lab, content edits make it fail. It helps when lines drift and logic did not change; it does not replace a new Approve.

How I know "naive merge" would really ship

Skepticism is fair: is the real Merge button stricter than the simulator? I did not run a destructive test against a live protected repo, so the honesty bound matters.

In GitHub's docs, dismiss_stale_reviews_on_push and require_last_push_approval are optional branch-protection fields, both off by default. When off, the review half of mergeability is "non-dismissed Approve count ≥ required" — the review's commit_id does not enter that count. github_sim.py follows that: with require_last_push_approval=False, any non-dismissed APPROVED yields review_decision=APPROVED, even if commit_id is the previous HEAD.

On the status side, GitHub's native required status checks already demand success on the current HEAD SHA. So scenario 2 (win-verify stuck on A) would also block on real GitHub if you only use native checks. The danger is two home-grown paths:

• a script or bot that decides "green" by context name and ignores SHA (my mergeable_naive);
• a Windows machine that overwrites status by branch name while readers assume it is HEAD.

Scenario 1e is the case where native statuses are already green on B and Approve is still on A: real GitHub, with those two review knobs off, will allow the merge. That is not the simulator being dramatic; it is the default configuration.

Reproduce locally: unpack the kit, then python3 build_repo.py && python3 run_lab.py && ./check-merge-sha.sh --state sample-blocked-state.json. SHAs in results.json change every rebuild; trust the booleans: ships_unreviewed_sha, push_allowed, outdated_after_push, reanchor_*.

Why agents hit this constantly

A human who changes code after Approve usually says so in chat or pings the reviewer. Agents do not. Their default loop is closer to: CI red → fix; main moved → rebase; commit message untidy → amend; then push --force-with-lease. To the agent that is "finishing the task." To the review system every one of those is a SHA swap.

The amend in the lab is typical: billed as lint, it removed the clamp the reviewer named, and dropped the matching test. The review UI does not pop up "the line you Approved is gone." Inline threads may go outdated; without dismiss, the Approve decision does not even go outdated — its commit_id just keeps pointing at the old SHA.

Three amplifiers:

1. Review machine ≠ dev machine. Machine 4 Approves and moves on; the agent on machine 2 is still "wrapping up." There is no shared "Approved — do not rewrite" lock unless branch protection or a bot adds one.
2. Windows is slower. When machine 6 queues by branch name, "verified A, merged B" is the default failure mode. If the status write omits the SHA, or the merge gate ignores SHA, the crack stays open.
3. The merge button's green is a collage. "Review passed" and "checks passed" sit side by side and feel like one snapshot. They are not. One is bound to an old review; the other (hopefully) to current statuses.

This is not "agents are worse people." It is "agents turn a rare TOCTOU into a hot path." Gates have to be designed for the hot path, not for "humans will announce."

Outdated comments are not the same bug

People say: after a force-push the comments go outdated, so the reviewer will look again. The lab does not support that optimism.

• Outdated threads are about diff anchors; whether Approve still counts is about branch-protection policy. Separate pipes. With dismiss off, every comment can be gray while Approve stays green.
• Re-anchor only helps when line numbers drift. Scenario 3b (+2-line docstring) restored 2/2; scenario 3a (logic removed) restored 0/1. Making "auto re-anchor" a merge condition assumes agents only move lines, never change meaning — the opposite of how they behave.
• What you must block is the merge, not the gray text in the thread list. Gray text can stay for archaeology; the merge key must stay red until SHAs align.

Rollout order (least friction first)

If you can change only one thing: enable dismiss stale + require last push approval. Scenarios 1b/1c show those two alone flip the decision from APPROVED back to REVIEW_REQUIRED and demand a new Approve on B. No code, no agent edits.

Second: make Windows (and any slow, machine-triggered check) write status/check runs by SHA, and mark them required. Scenario 2 is exactly this: Approve already on B, win-verify still on A, strict gate refuses.

Third: AGENTS.md rules plus a ruleset/bot that rejects force-push after Approve. Highest friction; fits repos where agents already rewrite after Approve. Keep an escape hatch for humans: comment → force-push → /ready.

Fourth: put the pre-merge script in required checks as a belt-and-suspenders on the native knobs, and to fail the check while the UI still says APPROVED during a transition with dismiss off.

Do not invert this: ship a re-anchor bot and leave dismiss off — the thread list looks tidier, and the merge can still ship unreviewed B.

What you can copy

1. Branch protection — turn on:

• Dismiss stale pull request approvals when new commits are pushed
• Require approval of the most recent reviewable push

Make ci, win-verify (or your Windows job), and the gate job below required.

2. Pre-merge workflow (merge-sha-gate.yml in the kit) runs check_merge_sha.py: fail if any Approve commit_id ≠ HEAD, or any required context's success is not on HEAD.

3. AGENTS.md on machines 1–3:

• No force-push / amend / rebase after Approve unless machine 4/5 asked
• If history must be rewritten: comment on the PR first, then push, then /ready <newsha> so machine 4 re-reviews and machine 6 re-runs Windows on that SHA
• Prefer additional commits over amend while review is open

4. Machine 7 before Merge: Approve commit == HEAD? win-verify SHA == HEAD? Two seconds; do not trust the green badge alone.

What was actually run

Run: real git commit/amend on the toy repo; five simulated strategies for Approve → force-push; check_merge_sha.py blocking on status SHA skew; two inline threads under "delete clamp" and "add docstring" (1/2 outdated and re-anchor failed; +2-line shift restored 2/2).

Not run: not live GitHub API; no real GraphQL isOutdated; no Windows execution (win-verify is a fake context); no seven-machine integration; workflow YAML validated via the script locally, not in Actions.

Kit: approve-force-push-kit.tar.gz — check_merge_sha.py, merge-sha-gate.yml, AGENTS.md snippet, simulator, results JSON/MD.

Smallest step today: enable dismiss_stale_reviews_on_push and require_last_push_approval, then run python3 check_merge_sha.py --github <owner> <repo> <pr> on a PR that was Approved and then force-pushed. If it says BLOCKED, you just saw which SHA almost merged.