# Git Merge/Review Rework — Parallel Kickoff Prompts (Layer B & Layer C) These are self-contained prompts to paste into two fresh ClaudeDo sessions, each in its own git worktree, run **in parallel** with the main session's Layer A work. **Prerequisite — branch point:** Both sessions must branch from `main` **at or after** the foundation commit `feat(ui): add conflict-resolution worker contract (foundation for merge rework)` (Phase 0, Task 0.3 of `docs/superpowers/plans/2026-06-05-git-merge-review-foundation-layerA.md`). That commit adds the frozen `IWorkerClient` conflict contract both layers rely on. Do not start B/C until that commit is pushed. **Integration:** Neither session pushes to `main` or merges. Each leaves its branch/ worktree for the orchestrator (the main session) to review and merge. Design reference for both: `docs/superpowers/specs/2026-06-05-git-merge-review-rework-design.md` --- ## Layer B — Multi-worktree merge cockpit ``` We're reworking ClaudeDo's merge/review UX. Your job is Layer B: a multi-worktree merge cockpit. The overall design is in docs/superpowers/specs/2026-06-05-git-merge-review-rework-design.md (read the "Layer B" section and "Parallel boundaries" table first). A shared foundation commit ("add conflict-resolution worker contract") is already on main — branch from it. First, create an isolated worktree for this work (use the superpowers:using-git-worktrees skill). Then write a plan (superpowers:writing-plans) for just Layer B and implement it with superpowers:subagent-driven-development (sonnet subagents, TDD, commit per task). Scope: - Rework WorktreesOverviewModalView + WorktreesOverviewModalViewModel into a batch-merge cockpit: list mergeable worktrees, multi-select N, pick ONE target branch, "Merge all". - Skip-and-continue: loop the EXISTING IWorkerClient.MergeTaskAsync(taskId, target, removeWorktree:false, msg) over the selected tasks. Clean ones merge; conflicting ones (MergeTaskAsync returns Status=="conflict", auto-aborts leaving the tree clean) are collected into a "needs resolution" list shown with live progress. - Each conflict row gets a "Resolve" button that invokes a seam: public Func? RequestConflictResolution { get; set; } // (taskId, targetBranch) Define this callback property on the cockpit VM; leave it unwired (the orchestrator wires it to Layer C's resolver at merge time). Do NOT reference any ConflictResolver type. - Migrate WorktreeModalView's bespoke inline diff onto the canonical DiffLinesView control (src/ClaudeDo.Ui/Views/Controls/DiffLinesView.axaml) using DiffFileViewModel/ DiffLineViewModel/UnifiedDiffParser (src/ClaudeDo.Ui/ViewModels/Modals/). This removes the last duplicate diff renderer. Reuse these existing IWorkerClient methods (already implemented): MergeTaskAsync, GetMergeTargetsAsync, GetWorktreesOverviewAsync, SetWorktreeStateAsync, CleanupFinishedWorktreesAsync, ForceRemoveWorktreeAsync. Do NOT touch (other layers own them): any worker-side files (WorkerHub, TaskMergeService, GitService), IWorkerClient.cs / WorkerClient.cs, WorkConsole.axaml, DetailsIslandViewModel.cs, or create the ConflictResolver UI. Build with: dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release (a running Worker locks Debug — use Release). Keep locales/en.json and de.json keys in parity if you add any. If you change IWorkerClient (you shouldn't need to), update the hand-rolled fakes in tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs and tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs. No tests that spawn the real claude CLI. Commit per task with Conventional Commits. Do NOT push to main and do NOT merge — leave your worktree/branch for the orchestrator. Flag any AXAML layout for visual verification rather than claiming it works. ``` --- ## Layer C — Inline conflict resolver ``` We're reworking ClaudeDo's merge/review UX. Your job is Layer C: an in-app, VSCode-style inline conflict resolver, plus the worker plumbing it needs. The overall design is in docs/superpowers/specs/2026-06-05-git-merge-review-rework-design.md (read the "Layer C", "Frozen worker conflict contract", and "Parallel boundaries" sections first). A shared foundation commit ("add conflict-resolution worker contract") is already on main — branch from it. That commit already wired the CLIENT side (IWorkerClient + WorkerClient call these hub methods by name); your job includes implementing the matching WORKER hub methods. First, create an isolated worktree (superpowers:using-git-worktrees). Then write a plan (superpowers:writing-plans) for Layer C and implement it with superpowers:subagent-driven-development (sonnet subagents, TDD, commit per task). Worker side — implement these 5 hub methods in WorkerHub (names/params/returns MUST match the client calls already shipped in the foundation): - StartConflictMerge(string taskId, string targetBranch) -> MergeResultDto Calls TaskMergeService.MergeAsync with leaveConflictsInTree:true (the overload/flag already exists — used today by PlanningMergeOrchestrator). Leaves .git/MERGE_HEAD in the list's WorkingDir, returns Status="conflict" + conflict file list. - GetMergeConflicts(string taskId) -> MergeConflictsDto For each conflicted file (git diff --name-only --diff-filter=U), read ours/theirs/base via `git show :2:` / `:3:` / `:1:`. Add GitService helpers as needed. - WriteConflictResolution(string taskId, string path, string resolvedContent) -> void Write resolvedContent to the file in WorkingDir and `git add` it. - ContinueMerge(string taskId) -> MergeResultDto Wrap the EXISTING TaskMergeService.ContinueMergeAsync (git add -A → re-check diff --diff-filter=U → git commit). Currently service-level only; expose it on the hub. - AbortMerge(string taskId) -> void Wrap the EXISTING TaskMergeService.AbortMergeAsync (git merge --abort). Define worker-side DTO records that serialize identically to the client records already in WorkerClient.cs: MergeConflictsDto(string TaskId, IReadOnlyList Files) ConflictFileDto(string Path, IReadOnlyList Hunks) ConflictHunkDto(string Ours, string Theirs, string? Base) (place beside the other hub DTOs in WorkerHub.cs). MergeResultDto already exists. UI side — new files only: - ConflictResolverViewModel + ConflictResolverView. On open: StartConflictMergeAsync then GetMergeConflictsAsync(taskId). Per conflict hunk show ours vs theirs stacked with buttons Accept Current / Accept Incoming / Accept Both / Edit manually, plus a free-text box for the merged result of that hunk. Use the UI conflict model from the design (ConflictFile { Path, Hunks[] }, ConflictHunk { Ours, Theirs, Base, Resolution }) — shape it so a future 3-way pane needs no model change. - When every file is resolved: WriteConflictResolutionAsync per file, then ContinueMergeAsync(taskId) (Status "merged" closes; "conflict" means not fully resolved, stay open). AbortMergeAsync(taskId) cancels. - Expose a factory Func and a Func ShowConflictResolver dialog delegate for the orchestrator to wire to Layer A/B's RequestConflictResolution(taskId, target) seams. Do NOT touch (other layers own them): WorkerClient.cs, IWorkerClient.cs (already wired), WorkConsole.axaml, DetailsIslandViewModel.cs, WorktreesOverviewModalView/VM. You WILL need to add the 5 worker hub methods + GitService conflict reads. Tests: add worker tests for the conflict reads / continue / abort using real SQLite + real git (follow existing GitService/TaskMergeService test patterns). NEVER spawn the real claude CLI. If you change IWorkerClient (you should NOT — client is frozen), update the fakes in both test projects. Build with: dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release and dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release (a running Worker locks Debug). Keep locales/en.json and de.json in parity for any new UI strings. Commit per task with Conventional Commits. Do NOT push to main and do NOT merge — leave your worktree/branch for the orchestrator. Flag the resolver UI for visual verification. ```