[JacobStephens2]

Summary

Merge runs for issues 147, 148 and 158 failed with origin/main is not merged into issue-N and left draft PRs, even though each conflict Repair had resolved and pushed a correct merge. origin/main is shared by every worktree. During the roughly 20-minute Repair, other Runs merged their PRs and fetched, so the ref moved. The check after the Repair then compared the branch against a newer main that the Repair was never asked to merge.

 RepairLoop::run
-  if merge_base_branch(base) == Conflicted
+  if let Conflicted(pending) = merge_base_branch(base)   # pending = MERGE_HEAD, pinned at merge time
     run_session(conflict Repair)
-    ensure_base_branch_merged(base)     # is origin/main (now moved) an ancestor of HEAD?
+    ensure_merged(&pending)             # is the commit we asked it to merge an ancestor of HEAD?
     continue                            # next round fetches and merges whatever main moved to

The same change applies to the conflict Repair for new commits pushed to the Issue branch (take_in_foreign_commits). The two ensure_*_merged wrappers are now one ensure_merged(&PendingMerge).

Evidence

• Before: the new test merges_a_base_branch_that_moved_again_during_the_conflict_repair (main moves on during the conflict Repair, then the Repair fetches) fails with the same error seen in production:

  thirdshift: repair-1: session ended after 0s
  thirdshift: pushing issue-7
  thirdshift: origin/main is not merged into issue-7
  

  After: it passes. The Run merges the newer main in the next round, and origin's issue-7^2 == main. The full cargo test suite passes. The existing tests for a Repair that aborts the merge or leaves it unfinished still fail the Run as they should.

• The production timeline for issue-148: the Repair began merging main at e37f549. c935a2b (Release script refuses a release that can't be cut #166) landed on main at 03:03Z. The Repair committed its merge of e37f549 at 03:12:54Z, and the check against c935a2b failed at 03:13:03Z.

Merge Danger

Door: two-way

Only the check after a Repair changes. A plain revert restores the old behaviour.

Blast Radius: narrow

This affects only Runs that hit a merge conflict. The main risk would be accepting a bad Repair, but an aborted merge still fails (the pinned commit isn't in HEAD) and so does an unfinished one (MERGE_HEAD is still present). The foreign-commits path has no dedicated test; it uses the same check.

🤖 Generated with Claude Code