[JacobStephens2]

Summary

After the PR is confirmed, thirdshift merges the Base branch into the Issue branch. It never rebases. A conflicting merge goes to a conflict Repair session.

 run
   implement session                       (…-implement.jsonl)
   push; check PR (open, targets base)
+  fetch origin <base>; merge --no-edit --ff origin/<base>
+    clean / nothing to merge → (fall through)
+    conflict → leave merge in progress
+      conflict Repair session             (…-repair-1.jsonl, same timestamp)
+      fail unless the merge was finished and origin/<base> is an ancestor of HEAD
+  push
   print PR URL

• Worktree gains merge_base_branch, ensure_base_branch_merged and push. Git gains succeeds, for commands whose exit status is the answer.
• The conflict Repair prompt follows the spec word for word, and the session runs with the same plugin and flags.
• Test harness changes:
  • The fake claude can run a different script per session (claude-script.sh.<n>), and it records whether a merge is in progress.
  • The test origin now sets receive.denyNonFastForwards, so a rebase or force-push fails any scenario.

Out of scope: repeating the merge-then-CI loop, CI watching and the Repair cap belong to #9. The Failed run path (failure commit, draft demotion) belongs to #5.

Evidence

tests/mergeable.rs covers these scenarios through the CLI:

base advanced, no conflict       → origin issue-7 = merge(Add feature, main); 1 session
base unchanged                   → origin issue-7 = [Add feature, Initial commit]; 1 session
base conflicts on feature.txt    → session 2 gets the conflict Repair prompt with merging=true;
                                   its resolution is pushed as a fast-forward
logs                             → <prefix>implement.jsonl and <prefix>repair-1.jsonl
Repair leaves the merge unfinished → non-zero exit, "merge of origin/main is still in progress"
Repair runs `git merge --abort`  → non-zero exit, "origin/main is not merged into issue-7"

• Before: on main without the implementation, 4 of the first 5 scenarios failed. Only "base unchanged" passed. The abort case would have exited 0.
• After: cargo test passes all 14 tests, and cargo clippy --all-targets -- -D warnings and cargo fmt --check are clean.

Merge Danger

Door: two-way

The only thing this pushes to origin is a merge commit on the Issue branch, and that is always a fast-forward.

Blast Radius: runs

Every Run now fetches and merges the Base branch before it reports success. A Run whose conflict Repair fails now exits non-zero. Until #5 lands, that exit leaves the PR as it is.

Unaddressed findings

Standards

• Shallow interface / locality: the merge → Repair → check → push sequence still lives in run.rs, not in one deeper module. I agree with the reviewer's own advice to wait for CI watching, CI-fix Repair and the Repair cap #9's loop and CI-fix Repair, because deepening now would be speculative.
• Primitive Obsession (session kinds as strings): "repair-1" stays a literal. CI watching, CI-fix Repair and the Repair cap #9 adds the Repair counter, and that is the point where a SessionKind type pays for itself.
• Duplicated MERGE_HEAD check in the fake claude: left as is on purpose. The fake observes the merge state independently of the code under test.

Spec

• Scope creep: the unfinished-merge guard fails the run: kept and extended. Pushing after a Repair that didn't merge would report a conflicting PR as success. The Failed run path #5 will route this failure through the Failed run path, which aborts the merge.
• Harness changes affect every scenario: kept. A fast-forward-only origin is the direct evidence for "No rebase or force-push ever reaches origin", and all existing tests still pass.

Closes #8

🤖 Generated with Claude Code