resolve-merge-conflict

Resolve a merge conflict (preserve both intents, branch-only)

An approved delivery branch (gaffer/…) conflicts with the default branch: work landed there after this branch forked, and the edits collide. You run headless in a throwaway worktree with the delivery branch checked out. Your job is to reconcile both sides honestly ON THE BRANCH. Afterwards the runner reopens the ticket for re-review, a human re-approves the resolved diff, and a later merge lands it.

How the runner uses your output: the text of your final message becomes the resolution summary the re-reviewer reads. You get one pass: if the branch conflicts again, it goes to a human.

Steps

1. Understand both sides before touching anything.
   • This branch: git log --oneline <default>..HEAD and git diff <default>...HEAD.
   • What landed since the fork: git log --oneline HEAD..<default> and git diff HEAD...<default>.
   • The ticket's ACs via get_ticket: they define what this branch must still do.
2. Merge the default branch INTO the branch, showing the base. git -c merge.conflictStyle=zdiff3 merge <default> — the local <default> ref; do not fetch (on git older than 2.35 use diff3). zdiff3 shows the common ancestor between ||||||| and =======, which tells you what each side actually changed. List the conflicts with git diff --name-only --diff-filter=U.
3. Resolve each hunk by intent. For every conflicted file:
   • Read base, ours and theirs (git show :1:<path>, :2:<path>, :3:<path>) and the commits that touched it on either side (git log --merge -p -- <path>).
   • Write the edit that keeps BOTH behaviours: both new imports, both new cases, the renamed function called with the new argument, and so on.
   • Take one side wholesale (git checkout --ours|--theirs <path>) only when the other side's change is provably subsumed; say so in the summary.
   • If the two intents are genuinely incompatible, keep what this ticket's ACs require, adapt the other side's behaviour as far as possible, and name exactly what was set aside.
   • Generated files (lockfiles, snapshots, compiled output) are regenerated with their tool, never hand-merged. If that tool is an install the safety hook blocks, stop (see below).
   • Stage each file once it is resolved (git add <path>). Never git add -A or git add .: the runner's .claude/ wiring in this worktree is untracked and must never be committed.
4. Hunt semantic conflicts — the ones git did not flag. For every symbol that either side renamed, removed or changed the signature of, grep the merged tree for callers from the other side. Check that the other side's new code still satisfies this ticket's invariants (validation, locking, error handling).
5. Verify the tree. No markers remain: git diff --check and git grep -nE '^(<<<<<<<|>>>>>>>|\|\|\|\|\|\|\|)( |$)' both print nothing; git diff --name-only --diff-filter=U is empty.
6. Run the repo's tests (the run-tests skill) and lint (the run-lint skill). A failure after a merge usually means the intents really clash: fix the reconciliation, never the test. If tests cannot run in this worktree (for example, dependencies are not installed here and installs are hook-blocked), do not claim a pass: say "tests not run: " in the summary.
7. Commit the merge on the branch: git commit --no-edit (a normal two-parent merge commit). Confirm with git merge-base --is-ancestor <default> HEAD (exit 0) and git status --porcelain --untracked-files=no (clean).
8. Print the summary. 3–6 lines: which files conflicted, how each side was preserved, anything set aside and why, semantic checks done, test result. Put it as the last thing in your final message — that text is what the runner records and forwards. Do not call record_ac_evidence or mark_ticket_blocked: you hold no claim and the ticket is ready_for_merge, so both are refused.