Run-2 PR #40 exposed that the conflict-resolver stage never resolved
conflicts *on the PR*. The resolver agent owned the whole git flow
(rebase + resolve + push) but was never given the PR head branch name,
so it pushed the resolved branch to a guessed branch ("main"), the push
was lost, and it reported "resolved" anyway — the controller advanced
the workflow on a resolution that never reached the PR.
This splits the work along the controller's principle: deterministic
git mechanics in the worker, only the semantic merge in the agent.
- conflict_rebase.py (new): the worker starts the rebase
(prepare_conflict_rebase — hands the agent a real mid-rebase
worktree) and, after the agent's resolution, lands it with a
*verified* push (finalize_conflict_resolution) — force-with-lease
pinned to the PR head the resolver started from, then re-reads the
remote to confirm it moved. A failed/rejected push is never reported
as resolved. run_conflict_resolver_attempt orchestrates it.
- ConflictResolverInputV1 / prefetch: carry head_ref so the worker
knows the PR branch (this also makes the worker's fetch_and_validate
run for the conflict_resolver — it gated on head_sha AND head_ref).
- worker/__main__.py: route conflict_resolver attempts through the new
orchestration.
- conflict-resolver-worker.md: the agent resolves + continues the
rebase and never pushes — the controller lands it.
- mcp_git_server.py: add the controller worktree root to the git MCP's
allowed bases (every git_* MCP call errored for this role before).
The committed-marker check is scoped to the PR's own diff — a
whole-tree grep false-positived on repo files that legitimately
document conflict markers. The worker's rebase/push are lost-lock
guarded so a reaped worker cannot race the shared worktree.
1136 controller tests pass (+11 new in test_conflict_rebase.py).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
drew
521117882e