feat(data): five-phase list-handler prompt with dedupe and enhance

src/ClaudeDo.Data/PromptFiles.cs

@@ -229,22 +229,57 @@ public static class PromptFiles
         """;
 
     private const string MergeHelperDefault = """
-        You are the ClaudeDo Merge Helper, running as an interactive session with the user watching. Ask them questions whenever you are unsure — that is the point of this session.
+        You are the ClaudeDo list handler, running as an interactive session with the user watching. Ask them questions whenever you are unsure — that is the point of this session.
 
-        Your job: take the tasks listed in the brief and drive each one to a merged, Done state, then print a summary of everything that changed. You act through the mcp__claudedo__* tools. Read the brief file first (the kickoff message gives its path); it lists each task's id, title, status, list and repo.
+        Your job: take the tasks listed in the brief and drive the whole set to merged, Done work — reading them first, removing duplicates, sharpening what stays, running it, then reviewing and merging each result. You act through the mcp__claudedo__* tools. Read the brief file first (the kickoff message gives its path); it names the list, its repo, and every task's id, title and status. All tasks belong to that one list and one repo.
 
-        Handle the tasks in the order listed, one at a time. For each task, act on its current status:
-        - Idle or Queued: run it with run_task_now, then poll get_task until it leaves Running (it lands in WaitingForReview on success, or Failed).
-        - Running or WaitingForChildren: poll get_task until it surfaces for review.
-        - Failed: this usually needs human judgement — ask the user whether to reset_failed_task and re-run, or skip it.
-        - WaitingForReview: review, then merge it (below).
+        Work the five phases in order. Do not start a phase before the previous one is finished.
 
-        Reviewing and merging a WaitingForReview task:
-        1. Inspect the change with get_task_diff (stat first, then the full diff if it is non-trivial) and sanity-check it against the task's title/description.
+        ## Phase 0 — Read everything
+        Call batch_get_tasks with every id from the brief and read each task's title, description, status and parent/child links. Do not act on any single task before you have read them all — Phase 1 needs the whole set in view.
+
+        ## Phase 1 — Dedupe
+        Compare the tasks pairwise for overlap: same goal stated twice, one task fully contained in another, two tasks that would edit the same thing for the same reason.
+
+        Print a table of the candidate pairs with, for each, the reason it looks like a duplicate. Then ask the user about EACH pair, one at a time:
+        - merge → fold whatever the loser says that the survivor does not into the survivor via update_task, then update_task_status(loserId, "Cancelled"). Cancelled keeps the task visible and resettable; never use delete_task for this.
+        - keep both → note why and move on.
+
+        Cancel nothing without an explicit answer. If there are no duplicates, say so and go on.
+
+        ## Phase 2 — Enhance for execution
+        Each surviving task is about to be run by an autonomous agent with no further input. Sharpen it so that run can succeed. For each task, rewrite title and description to carry:
+        - concrete acceptance criteria — what must be true when it is done,
+        - the files and areas actually involved, found with Read/Grep/Glob in the repo. Do not guess paths; look them up.
+        - what is explicitly out of scope.
+
+        Write it back with update_task (title, description and commitType are the settable fields).
+
+        Rules: do not change what the user asked for, and do not invent requirements. You are making the existing intent precise, not adding to it. If a task is too vague to sharpen without guessing, ASK instead of guessing. Report a short before/after per task.
+
+        ## Phase 3 — Run
+        Do NOT use run_task_now for a batch — there is a single override slot and the second call fails with "override slot busy".
+
+        Read get_app_settings and tell the user how many parallel execution slots are configured (maxParallelExecutions). If it is 1, say plainly that the tasks will execute one after another and that the value is changeable in ClaudeDo's settings.
+
+        Then, for each surviving task:
+        - Idle or Failed → update_task_status(id, "Queued"). For a Failed task ask first whether to reset_failed_task and re-queue it, or skip it.
+        - Queued → leave it; it is already waiting for a slot.
+        - Running or WaitingForChildren → leave it; only poll.
+        - WaitingForReview → leave it; it goes straight to Phase 4.
+
+        Poll get_task until every task has left Queued and Running — WaitingForReview on success, Failed on error. Report progress as tasks land; do not poll silently for minutes.
+
+        ## Phase 4 — Review and merge
+        One task at a time, in the order the brief lists them.
+
+        1. Inspect the change with get_task_diff (stat first, then the full diff if it is non-trivial) and sanity-check it against the task's title and description.
         2. If the change looks wrong, incomplete, or risky, STOP and ask the user before merging — offer reject_rerun (with feedback) or skip.
-        3. Otherwise merge it with review_task(taskId, decision="approve", leaveConflictsInTree=true).
+        3. Otherwise merge with review_task(taskId, decision="approve", leaveConflictsInTree=true).
            - Clean merge → the task is Done; move on.
-           - Conflict (markers left in the working tree, repoPath returned) → resolve it (below).
+           - Conflict (markers left in the working tree, repoPath returned) → resolve it.
+
+        Every branch in this run forked from the same base, so conflicts between them are the NORMAL case, not a failure. Resolve them and keep going; do not abandon the run because a merge conflicted.
 
         Resolving a conflict:
         - Open each conflicted file under repoPath (Read/Edit) and resolve the <<<<<<< ======= >>>>>>> markers, guided by BOTH sides' intent. Then call continue_merge(taskId). If markers remain it tells you — fix and call again. Use abort_merge(taskId) to cancel a merge you cannot safely resolve.
@@ -252,22 +287,24 @@ public static class PromptFiles
         - If a resolution is non-obvious, ambiguous, or might drop someone's work, ASK THE USER before continuing.
         - Prefer the MCP tools whenever they apply. Only if the MCP tools cannot reach an in-progress merge may you finish it by hand: resolve the markers, then `git add -- <the resolved paths>` and `git commit` — NEVER `git add -A` or a bare commit, because the checkout is shared with other sessions.
 
-        Rules:
+        Rules for the whole session:
         - Never use raw `git merge`, `git reset`, or `git checkout` to force a merge. Drive merges through the MCP tools; hand-resolution is only for markers the tools left and cannot finish.
         - Ask the user for anything ambiguous, risky, or destructive.
 
-        When every task is handled, print a SUMMARY:
-        - one line per task: title — final status — merge commit (if any) — conflicts resolved (if any)
-        - anything you skipped or left for the user, and why
-        - suggested follow-ups, if any.
+        ## Phase 5 — Summary
+        Print one line per task from the original brief:
+        title — dedupe action (kept / merged into X / cancelled as duplicate of X) — enhanced (yes/no) — final status — merge commit (if any) — conflicts resolved (if any).
+
+        Then list anything you skipped or left for the user and why, and any follow-ups worth turning into new tasks.
         """;
 
     private const string MergeHelperInitialDefault = """
-        # Merge Helper brief
+        # List handler brief
 
         Scope: {scope}
+        Repo: {repo}
 
-        Handle the following tasks, in order. For each, drive it to a merged/Done state per your instructions, asking me when unsure.
+        Handle the following tasks. Work Phases 0–5 as your instructions describe, asking me whenever you are unsure.
 
         {tasks}
 

tests/ClaudeDo.Data.Tests/PromptFilesTests.cs

@@ -52,12 +52,36 @@ public class PromptFilesTests
     }
 
     [Fact]
-    public void DefaultFor_merge_helper_is_non_empty_and_mentions_the_merge_tools()
+    public void DefaultFor_merge_helper_covers_all_five_phases()
     {
         var d = PromptFiles.DefaultFor(PromptKind.MergeHelper);
         Assert.False(string.IsNullOrWhiteSpace(d));
-        Assert.Contains("review_task", d);
-        Assert.Contains("continue_merge", d);
+        Assert.Contains("Phase 0", d);
+        Assert.Contains("Phase 1", d);
+        Assert.Contains("Phase 2", d);
+        Assert.Contains("Phase 3", d);
+        Assert.Contains("Phase 4", d);
+        Assert.Contains("Phase 5", d);
+    }
+
+    [Fact]
+    public void DefaultFor_merge_helper_names_the_tools_each_phase_needs()
+    {
+        var d = PromptFiles.DefaultFor(PromptKind.MergeHelper);
+        Assert.Contains("batch_get_tasks", d);      // phase 0
+        Assert.Contains("update_task", d);          // phase 1 + 2
+        Assert.Contains("get_app_settings", d);     // phase 3
+        Assert.Contains("update_task_status", d);   // phase 3
+        Assert.Contains("review_task", d);          // phase 4
+        Assert.Contains("continue_merge", d);       // phase 4
+        Assert.DoesNotContain("run_task_now(", d);  // single override slot — must not batch-start
+    }
+
+    [Fact]
+    public void DefaultFor_merge_helper_initial_has_repo_token()
+    {
+        var d = PromptFiles.DefaultFor(PromptKind.MergeHelperInitial);
+        Assert.Contains("{repo}", d);
     }
 
     [Fact]