Automatic merge conflict resolution on open PRs

[jrf0110]

Parent

Part of #204 (Phase 4: Hardening)

Problem

When using the pr merge strategy, open PRs can develop merge conflicts as the base branch evolves. The PR sits in a conflicted state until someone manually resolves the conflicts. The alarm loop polls PR status but doesn't detect or act on conflict state.

Solution

Extend PR polling to detect merge conflicts and automatically dispatch an agent to resolve them.

Detection

In pollPendingPRs(), check each open PR's mergeable status:

GitHub: GET /repos/{owner}/{repo}/pulls/{number} returns mergeable: false and mergeable_state: "dirty" when there are conflicts. The merge_commit_sha is null.

GitLab: GET /projects/{id}/merge_requests/{iid} returns has_conflicts: true and detailed_merge_status: "conflict".

Resolution flow

1. Alarm detects PR has conflicts
2. TownDO creates a merge_conflict bead (or reuses the existing MR bead with a status update)
3. A polecat is dispatched with a focused prompt:

PR #{number} for bead "{title}" has merge conflicts. Your job is to resolve them.

1. Ensure you're on the PR branch: git checkout {branch}
2. Fetch and merge the target branch: git fetch origin {targetBranch} && git merge origin/{targetBranch}
3. Resolve all conflicts. Use your understanding of the codebase and the PR's intent.
4. Run quality gates to verify the resolution doesn't break anything.
5. Commit the merge resolution and push.
6. Call gt_done when complete.

If the conflicts are too complex to resolve confidently (e.g., large structural 
changes to the same functions), call gt_escalate with the conflict details.

4. Agent resolves conflicts, runs gates, pushes
5. PR becomes mergeable again ���¢ normal PR flow resumes

Avoiding re-triggering

Once a conflict resolution agent is dispatched, mark the MR bead with metadata conflict_resolution_in_progress: true to prevent re-dispatching on the next alarm tick. Clear the flag when the agent completes or fails.

Acceptance Criteria

• PR polling detects merge conflict state (GitHub mergeable: false / GitLab has_conflicts: true)
• Agent dispatched to resolve conflicts with a focused merge-resolution prompt
• Agent resolves conflicts, runs quality gates, and pushes
• Complex/uncertain conflicts are escalated rather than guessed at
• Conflict resolution doesn't re-trigger while an agent is already working on it
• Works with both GitHub and GitLab integrations

Notes

• No data migration needed
• The agent needs access to the same branch the PR was created from Ã�Ã�Ã�¢ the rig's worktree should have that branch or be able to fetch it
• GitHub's mergeable status can take a few seconds to compute after a push Ã�Ã�Ã�¢ the API may return mergeable: null temporarily. Poll should handle this gracefully (skip, don't flag as conflict).
• Consider a configurable toggle: some teams may prefer to handle conflicts manually. Default to enabled.
• This is distinct from the refinery's merge conflict handling (which happens at merge time on the direct strategy). This is about PRs that develop conflicts while waiting for human review.