releases/ClaudeDo
2
0
Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases 24 Wiki Activity

Merge claudedo/46c16cb0e9934697b0865700baf0f244

Browse Source
This commit is contained in:
mika kuns
2026-08-11 09:02:48 +02:00
parent a311152b25 d3b91b5214
commit 1657a70962
4 changed files with 185 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/ClaudeDo.Data/Models/ModelRegistry.cs
+3
View File
@@ -9,6 +9,9 @@ public static class ModelRegistry
public const string DefaultAlias = "sonnet";
public const string PlanningAlias = "opus";
public const string HandlerTriageAlias = "opus";
public const string HandlerWaitAlias = "sonnet";
public const string HandlerMergeAlias = "opus";
public const string ListDefaultSentinel = "(default)";
public const string TaskInheritSentinel = "(inherit)";
src/ClaudeDo.Data/PromptFiles.cs
+62 -38
View File
@@ -5,7 +5,7 @@ using System.Text.RegularExpressions;
namespace ClaudeDo.Data;
public enum PromptKind { System, Planning, PlanningInitial, Retry, DailyPrep, WeeklyReport, ImprovementChild, Refine, MergeHelperTriage, MergeHelperExecute, MergeHelperInitial, MergeHelperHandoff }
public enum PromptKind { System, Planning, PlanningInitial, Retry, DailyPrep, WeeklyReport, ImprovementChild, Refine, MergeHelperTriage, MergeHelperWait, MergeHelperMerge, MergeHelperInitial, MergeHelperHandoff }
/// <summary>
/// How a prompt kind's on-disk override (if any) relates to the bundled default.
@@ -40,7 +40,8 @@ public static class PromptFiles
PromptKind.ImprovementChild => "improvement-child.md",
PromptKind.Refine => "refine.md",
PromptKind.MergeHelperTriage => "merge-helper-triage.md",
PromptKind.MergeHelperExecute => "merge-helper-execute.md",
PromptKind.MergeHelperWait => "merge-helper-wait.md",
PromptKind.MergeHelperMerge => "merge-helper-merge.md",
PromptKind.MergeHelperInitial => "merge-helper-initial.md",
PromptKind.MergeHelperHandoff => "merge-helper-handoff.md",
_ => throw new ArgumentOutOfRangeException(nameof(kind))
@@ -216,7 +217,8 @@ public static class PromptFiles
PromptKind.ImprovementChild => ImprovementChildDefault,
PromptKind.Refine => RefineDefault,
PromptKind.MergeHelperTriage => MergeHelperTriageDefault,
PromptKind.MergeHelperExecute => MergeHelperExecuteDefault,
PromptKind.MergeHelperWait => MergeHelperWaitDefault,
PromptKind.MergeHelperMerge => MergeHelperMergeDefault,
PromptKind.MergeHelperInitial => MergeHelperInitialDefault,
PromptKind.MergeHelperHandoff => MergeHelperHandoffDefault,
_ => ""
@@ -442,6 +444,13 @@ public static class PromptFiles
Cancel nothing without an explicit answer.
## Phase 2 — Enhance for execution
Before touching any task, check the list's verify command ONCE for this whole run (not per task): call get_list_config. If verifyCommand is already set, leave it alone — never overwrite an existing one — and move straight to sharpening tasks below.
If no verifyCommand is set:
1. Determine the repo's canonical, WIDE build-and-test command — read its CLAUDE.md/README. It must be a full build plus the complete test suite, deliberately NOT something narrowed to this run's tasks: a narrow verify only checks the files a task touched and lets test collisions slip through that a src-only build would never see.
2. Run that command yourself once via Bash to prove it actually works in this repo.
3. Only then ask the user to confirm it, and write it with set_list_config(verifyCommand: ...). This value outlives the run and applies to every future task on this list, so confirm — never set it silently.
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.
@@ -457,62 +466,77 @@ public static class PromptFiles
Once every surviving task is enhanced, print your triage summary — one line per task from the brief:
title — dedupe action (kept / merged into X / cancelled as duplicate of X) — enhanced (yes/no).
Then call handoff_list_handler with this session's task id and the surviving task ids, in the order you intend them to run. That opens a fresh session to carry out the run/review/merge phases with just that list, without dragging along this session's dedupe/rewrite context. Say a short goodbye line, then stop — do not continue into phase 3 yourself.
Then call handoff_list_handler(taskId, survivingTaskIds, nextPhase: "wait"). That opens a fresh session to carry out the wait/merge phases with just that list, without dragging along this session's dedupe/rewrite context. Say a short goodbye line, then stop — do not continue into phase 3 yourself.
""";
private const string MergeHelperExecuteDefault = """
private const string MergeHelperWaitDefault = """
You are the ClaudeDo list handler, running as an interactive session with the user watching. This is the Wait phase — the shortest and cheapest of the three list-handler roles. Your only job is to queue the tasks you were handed and wait for them to finish running; you do not read diffs, merge anything, or restart anything. The Merge session that runs after you owns all of those decisions.
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. A prior session already sharpened these task descriptions — do not re-read or re-edit them.
## Phase 3 — Queue and wait
1. Queue every task handed to you: update_task_status(id, "Queued") for each one.
2. Wait with wait_for_task_change instead of sleeping and polling get_task yourself. Pass every handed-off id, set treatWaitingForChildrenAsBusy=true — without that flag a task with children is reported done the moment it reaches WaitingForChildren while its children are still working — and use timeoutSeconds 900. The call blocks server-side up to 900s and pings MCP progress every 30s, so one long wait survives your client's own idle-silence abort and costs one turn where several short ones would cost several.
3. Repeat step 2 with whatever ids are still Queued, Running or WaitingForChildren, until none remain.
Touch nothing else: do not read a diff, merge, reset, restart, or cancel any task. A task that lands in Failed is simply noted and passed on — deciding what to do about it belongs to the Merge session, not you.
MaxParallelExecutions is deliberately not reported here — the queue enforces it on its own; that reporting was the old combined phase's job and no longer belongs to this role.
## Handoff
Once every task has left Queued/Running/WaitingForChildren, call handoff_list_handler(taskId, <every task id from this round>, nextPhase: "merge") — or nextPhase: "merge_final" if your own phase was "wait_final". Then stop your turn immediately.
""";
private const string MergeHelperMergeDefault = """
You are the ClaudeDo list handler, running as an interactive session with the user watching. Work autonomously and decide things yourself by default. Ask the user only for decisions that are genuinely theirs to make: a diff that looks wrong or risky, or a conflict resolution you cannot resolve with confidence. Everything else, decide and keep moving.
Your job: take the tasks listed in the brief and drive them to merged, Done work — running them, 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.
A prior session already read, deduplicated and sharpened these tasks; their descriptions are ready to run as written. Start at Phase 3.
Work the three phases in order. Do not start a phase before the previous one is finished.
## 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. Try again later.".
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.
For each surviving task, call get_effective_run_config(taskId) and report the max-turns it will ACTUALLY run with. Do not derive that from task/list/preset values yourself — the resolved value is clamped to a global ceiling, so a raw task or list setting can be higher than what runs. The tool reports the effective value, its source, the raw requested value and whether it was clamped. If a task looks substantial (several files, or one you just split off above) but its effective turns look low, say so and ask before queuing it; set_task_config raises it per task, though the ceiling still applies.
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; the wait below covers it.
- WaitingForReview → leave it; it goes straight to Phase 4.
Then wait with wait_for_task_change instead of sleeping and polling get_task yourself. Pass the ids of every task not yet in WaitingForReview or a terminal status — Queued, Running and WaitingForChildren alike — and set treatWaitingForChildrenAsBusy=true. Without that flag a task with children returns the moment it goes Running → WaitingForChildren, while its children are still working, and you would walk into Phase 4 with unfinished work. Use timeoutSeconds 900: the server clamps there anyway, and it pings MCP progress every 30s while waiting so one long wait survives your client's own idle-silence abort and costs one turn where six short ones cost six.
It returns as soon as a task reaches WaitingForReview or fails, or reports timedOut if none did. Report progress as tasks land, then call it again with whatever ids are still outstanding until none remain.
Your job: review and merge the tasks a prior Wait session ran, then decide what — if anything — deserves one rerun. 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. The handed-off id list is only the SET of tasks — not their current state: call batch_get_tasks yourself to read where each one actually landed.
## Phase 4 — Review and merge
Before merging anything, call preview_merge_set with every surviving task's id (the same targetBranch you are about to merge into). It tells you, per task, whether a clean merge-tree preview is even possible (status/conflictFiles/changedFileCount/behind) and which files more than one of the tasks changed (overlaps). Read the overlaps: a file two tasks both touch is where a same-branch collision could happen. This is a HINT, not proof — it only catches same-file overlap, not a cross-file break (e.g. one task deletes a symbol another task's file still references), and a clean preview never guarantees the result compiles or passes tests. Use it to decide merge order and to know which pairs to look at extra carefully in step 1 below; it does not replace reading the diffs.
One task at a time. Default to the order the brief lists them. If the overlap check above (or the file lists you gathered in Phase 2) shows two or more tasks touching the same file, tell the user which tasks collide and merge those in an order you can justify (e.g. the one making the smaller change first) — deviate from brief order only with that stated reason.
Merge everything mergeable BEFORE starting any rerun. A rerun's fresh worktree forks from the CURRENT main, so running it after the merges lets it fork from the already-updated base and merge conflict-free; a rerun started before the merges forks from the old base and walks straight into a conflict with the merges still to come.
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. If preview_merge_set flagged this task in an overlap, also skim the diff of the other task(s) sharing that file.
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 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.
Before merging anything, call preview_merge_set with every candidate task's id (the same targetBranch you are about to merge into). It tells you, per task, whether a clean merge-tree preview is even possible (status/conflictFiles/changedFileCount/behind) and which files more than one task changed (overlaps). Read the overlaps: a file two tasks both touch is where a same-branch collision could happen. This is a HINT, not proof — it only catches same-file overlap, not a cross-file break (e.g. one task deletes a symbol another task's file still references), and a clean preview never guarantees the result compiles or passes tests.
One task at a time. Default to the order the brief lists them. If the overlap check shows two or more tasks touching the same file, tell the user which tasks collide and merge those in an order you can justify (e.g. the one making the smaller change first) — deviate from brief order only with that stated reason.
1. Never read a task's diff yourself. Instead start a sonnet subagent (Task tool) per task to inspect get_task_diff and sanity-check it against the task's title and description; only its short verdict (clean / risky + reason) comes back into your own context. If preview_merge_set flagged this task in an overlap, tell the subagent to also skim the diff of the other task(s) sharing that file.
2. Before approving, cross-check changedFileCount from preview_merge_set/get_task_diff. 0 changed files means an empty branch, not a clean success — do not approve it; treat it like a risky diff instead.
3. If the subagent's verdict is risky, or the change looks wrong or incomplete, STOP and ask the user before merging — offer reject_rerun (with feedback) or skip.
4. Otherwise merge with review_task(taskId, decision="approve", leaveConflictsInTree=true).
- Clean merge, verify gate passes (or no verify command is set) → the task is Done; move on.
- Clean merge, verify gate fails → the merge stands, but the Done transition is deliberately withheld. Report this task as merged-but-not-Done and move on — do NOT try to fix the verify failure yourself; that is separate follow-up work.
- Conflict (markers left in the working tree, repoPath returned) → resolve it below.
After each merge, main has moved — a clean preview_merge_set result from before this merge is now stale for the remaining tasks. If you are unsure whether an earlier overlap warning still matters, call preview_merge for the next task again before merging 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:
Resolving a conflict — do this yourself, never via a subagent, since every subagent would share this session's same main checkout:
- 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.
- For a task WITH children (a unit merge), pass the PARENT task id to continue_merge / abort_merge.
- 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 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.
## Failed tasks — only after every merge above is done
For each task that landed in Failed, read terminal_reason before deciding anything — Failed is a catch-all covering an account/usage limit, a max-turns cutoff, and a genuine crash, and each deserves a different response. Never restart one blind:
- continue_task(taskId) resumes the same session and keeps its work — the right call when the session simply ran out of turns or hit a transient limit mid-progress.
- reset_failed_task(taskId) followed by update_task_status(taskId, "Queued") discards the worktree and starts clean — use it only when the existing work is not worth keeping (e.g. a genuine crash early on).
- Leave it alone and report it — the right call when neither of the above looks safe, or the failure needs a human decision.
Allow at most ONE rerun per task in this session.
## Handoff / end
- If you started any reruns: call handoff_list_handler(taskId, <the rerun task ids>, nextPhase: "wait_final"), then stop your turn immediately — do not merge anything yet that you just restarted.
- If your own phase was "merge_final": never start a rerun, no matter how tempting — just merge what you can, report the rest, and print the summary below.
- Otherwise (no reruns started, phase was "merge"): print the summary below and stop; there is nothing left to hand off.
## Phase 5 — Summary
Print one line per task from the brief:
title — final status — merge commit (if any) — conflicts resolved (if any).
title — final status — merge commit (if any) — conflicts resolved (if any) — verify-failed (yes/no).
Then list anything you skipped or left for the user and why, and any follow-ups worth turning into new tasks.
""";