docs: record the operation-feedback state before the v2.10.0 cut

Plan checkboxes stood at zero although P0, A, B, C1 and D are all merged --
anyone reading it would have assumed nothing was built. Ticks the merged
packages, records A5's cancellation and the visual pass, and names the two
leftovers (the three unused ops.* keys from A3/A4, C2-C5 as the only open
group). Also corrects the batch_* tool count from eight to seven and puts the
OperationTiming kill-switch note in the Ui CLAUDE.md back into English.

.claude/settings.local.json

@@ -1,4 +1,7 @@
 {
+  "worktree": {
+    "baseRef": "head"
+  },
   "permissions": {
     "allow": [
       "Bash(git add:*)",

.gitea/workflows/audit.yml

@@ -0,0 +1,101 @@
+name: Dependency Audit
+
+on:
+  schedule:
+    - cron: '0 6 * * 1'   # Mondays 06:00 UTC
+  workflow_dispatch: {}
+
+jobs:
+  audit:
+    runs-on: ubuntu-latest
+    env:
+      DOTNET_ROOT: /home/mika/.dotnet
+      GITEA_API: https://git.kuns.dev/api/v1
+      REPO: releases/ClaudeDo
+      ISSUE_TITLE: 'Dependency audit: vulnerable packages detected'
+    steps:
+      - name: Checkout main
+        env:
+          TOKEN: ${{ secrets.GITEA_TOKEN }}
+        run: |
+          set -euo pipefail
+          git clone --depth 1 --branch main \
+            "https://oauth2:${TOKEN}@git.kuns.dev/${REPO}.git" src
+
+      - name: Scan for vulnerable / outdated packages
+        run: |
+          set -euo pipefail
+          export PATH="$DOTNET_ROOT:$PATH"
+          cd src
+
+          : > audit.log
+          : > vuln.md
+          found=0
+
+          # .slnx tooling needs .NET 9; iterate per-project to stay on .NET 8.
+          while IFS= read -r proj; do
+            echo "==== $proj ====" | tee -a audit.log
+            dotnet restore "$proj" >/dev/null
+
+            vuln="$(dotnet list "$proj" package --vulnerable --include-transitive 2>&1)"
+            echo "$vuln" | tee -a audit.log
+            if echo "$vuln" | grep -qi "has the following vulnerable"; then
+              found=1
+              {
+                printf '#### `%s`\n\n```\n' "$proj"
+                echo "$vuln"
+                printf '```\n\n'
+              } >> vuln.md
+            fi
+
+            # Outdated is informational only — never fails the run.
+            dotnet list "$proj" package --outdated 2>&1 | tee -a audit.log || true
+            echo "" | tee -a audit.log
+          done < <(find . -name '*.csproj' | sort)
+
+          if [ "$found" -ne 0 ]; then
+            echo "::error::Vulnerable packages detected — see log above." >&2
+            exit 1
+          fi
+          echo "No vulnerable packages found."
+
+      - name: Report vulnerabilities to a Gitea issue
+        if: failure()
+        env:
+          TOKEN:  ${{ secrets.GITEA_TOKEN }}
+          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+        run: |
+          set -euo pipefail
+          cd src
+
+          if [ -s vuln.md ]; then
+            DETAILS="$(cat vuln.md)"
+          else
+            DETAILS="The audit job failed before producing findings — check the run log."
+          fi
+          BODY="$(printf 'Automated weekly dependency audit found vulnerable packages.\n\n%s\n\n[View workflow run](%s)' \
+            "$DETAILS" "$RUN_URL")"
+
+          # Reuse an existing open issue if one is already tracking this.
+          EXISTING="$(curl -sS \
+            -H "Authorization: token ${TOKEN}" \
+            "${GITEA_API}/repos/${REPO}/issues?state=open&type=issues&limit=50" \
+            | jq -r --arg t "$ISSUE_TITLE" '.[] | select(.title==$t) | .number' | head -n1)"
+
+          if [ -n "$EXISTING" ]; then
+            echo "Commenting on existing issue #$EXISTING"
+            jq -n --arg body "$BODY" '{body:$body}' \
+              | curl -sS --fail-with-body -X POST \
+                  -H "Authorization: token ${TOKEN}" \
+                  -H "Content-Type: application/json" \
+                  -d @- \
+                  "${GITEA_API}/repos/${REPO}/issues/${EXISTING}/comments" >/dev/null
+          else
+            echo "Creating new issue"
+            jq -n --arg title "$ISSUE_TITLE" --arg body "$BODY" '{title:$title, body:$body}' \
+              | curl -sS --fail-with-body -X POST \
+                  -H "Authorization: token ${TOKEN}" \
+                  -H "Content-Type: application/json" \
+                  -d @- \
+                  "${GITEA_API}/repos/${REPO}/issues" >/dev/null
+          fi

.gitea/workflows/changelog.yml

@@ -0,0 +1,85 @@
+name: Changelog
+
+on:
+  push:
+    tags:
+      - 'v*'
+
+jobs:
+  changelog:
+    runs-on: ubuntu-latest
+    env:
+      REPO: releases/ClaudeDo
+    steps:
+      - name: Checkout main (full history)
+        env:
+          TOKEN: ${{ secrets.GITEA_TOKEN }}
+        run: |
+          set -euo pipefail
+          git clone "https://oauth2:${TOKEN}@git.kuns.dev/${REPO}.git" src
+          cd src
+          git fetch --tags --force
+          git checkout main
+
+      - name: Regenerate CHANGELOG.md
+        run: |
+          set -euo pipefail
+          cd src
+
+          emit_group() {
+            # $1 range, $2 conventional-type, $3 heading
+            local range="$1" type="$2" title="$3" lines
+            lines="$(git log "$range" --no-merges --pretty=format:'%s|%h' \
+              | grep -E "^${type}(\([^)]*\))?(!)?: " || true)"
+            [ -z "$lines" ] && return 0
+            printf '### %s\n\n' "$title"
+            while IFS='|' read -r subject hash; do
+              printf -- '- %s (%s)\n' "${subject#*: }" "$hash"
+            done <<< "$lines"
+            printf '\n'
+          }
+
+          emit_section() {
+            # $1 range, $2 tag, $3 date
+            printf '## %s — %s\n\n' "$2" "$3"
+            emit_group "$1" feat     "Features"
+            emit_group "$1" fix      "Fixes"
+            emit_group "$1" perf     "Performance"
+            emit_group "$1" refactor "Refactoring"
+            emit_group "$1" docs     "Documentation"
+          }
+
+          # Tags ascending by semver so we can pair each with its predecessor.
+          mapfile -t TAGS < <(git tag --sort=v:refname | grep -E '^v' || true)
+
+          {
+            printf '# Changelog\n\n'
+            for ((i=${#TAGS[@]}-1; i>=0; i--)); do
+              TAG="${TAGS[$i]}"
+              DATE="$(git log -1 --format=%ad --date=short "$TAG")"
+              if (( i > 0 )); then
+                RANGE="${TAGS[$((i-1))]}..${TAG}"
+              else
+                RANGE="$TAG"
+              fi
+              emit_section "$RANGE" "$TAG" "$DATE"
+            done
+          } > CHANGELOG.md
+
+          cat CHANGELOG.md
+
+      - name: Commit and push if changed
+        env:
+          TOKEN: ${{ secrets.GITEA_TOKEN }}
+        run: |
+          set -euo pipefail
+          cd src
+          if git diff --quiet -- CHANGELOG.md; then
+            echo "CHANGELOG.md unchanged; nothing to commit."
+            exit 0
+          fi
+          git config user.name  "ClaudeDo CI"
+          git config user.email "ci@kuns.dev"
+          git add CHANGELOG.md
+          git commit -m "docs(changelog): update for ${GITHUB_REF_NAME}"
+          git push origin main

.gitea/workflows/release.yml

@@ -145,18 +145,19 @@ jobs:
           ZIP_NAME="ClaudeDo-${VERSION}-win-x64.zip"
           ( cd bundle && zip -r -q "../assets/${ZIP_NAME}" app worker )
 
-          # 2) Installer single-file exe (renamed)
+          # 2) Installer single-file exe — STABLE name (no version) so the download URL
+          #    (…/releases/latest/download/ClaudeDo.Installer.exe) stays permanent.
           INSTALLER_EXE=$(ls out/installer/*.exe | head -n 1)
           if [ -z "$INSTALLER_EXE" ]; then
             echo "::error::No .exe produced by installer publish" >&2
             exit 1
           fi
-          cp "$INSTALLER_EXE" "assets/ClaudeDo.Installer-${VERSION}.exe"
+          cp "$INSTALLER_EXE" "assets/ClaudeDo.Installer.exe"
 
           # 3) Checksums (sha256, relative filenames)
           ( cd assets && sha256sum \
               "ClaudeDo-${VERSION}-win-x64.zip" \
-              "ClaudeDo.Installer-${VERSION}.exe" \
+              "ClaudeDo.Installer.exe" \
               > checksums.txt )
 
           echo "--- assets ---"
@@ -200,7 +201,7 @@ jobs:
           cd "$WORK/src/assets"
           for f in \
             "ClaudeDo-${VERSION}-win-x64.zip" \
-            "ClaudeDo.Installer-${VERSION}.exe" \
+            "ClaudeDo.Installer.exe" \
             "checksums.txt"
           do
             echo "Uploading: $f"

.gitignore

@@ -1,5 +1,6 @@
 # Local dev worktrees (created by using-git-worktrees skill)
 .worktrees/
+.claude/worktrees/
 
 # Brainstorming visual companion artifacts
 .superpowers/

CLAUDE.md

@@ -10,7 +10,14 @@ Two-process system communicating over SignalR (`127.0.0.1:47821`):
 - **ClaudeDo.Ui** — Views, ViewModels, SignalR client (MVVM with CommunityToolkit.Mvvm)
 - **ClaudeDo.Data** — SQLite data layer, repositories, models, GitService
 - **ClaudeDo.Worker** — ASP.NET Core hosted service, task queue, Claude CLI runner
-- **ClaudeDo.Worker.Tests** — xUnit integration tests with real SQLite and real git
+- **ClaudeDo.Localization** — `locales/en.json` + `locales/de.json` and the lookup service
+- **ClaudeDo.Releases** — Gitea release client (`IReleaseClient`), used by the Ui update check and the Installer
+- **ClaudeDo.Installer** — WPF (`UseWPF`) setup app; install/update/uninstall step pipeline
+- **tests/** — six xUnit projects (Worker, Data, Ui, Localization, Installer, Releases); Worker.Tests run real SQLite and real git
+
+Per-project `CLAUDE.md` files exist for **App, Data, Installer, Ui, Worker, and Worker.Tests** —
+those are the living per-project docs. Localization, Releases, and the other five test projects
+have none; this file plus the code is all there is for them.
 
 ## Tech Stack
 
@@ -35,7 +42,7 @@ Two-process system communicating over SignalR (`127.0.0.1:47821`):
 - EF Core migrations manage schema (Migrations/ folder in ClaudeDo.Data)
 - `IDbContextFactory<ClaudeDoDbContext>` used by singleton consumers (e.g. Worker)
 - Entity configuration via `IEntityTypeConfiguration<T>` in Configuration/ folder
-- Task status flow: Idle | Queued -> Running -> WaitingForReview -> Done | Failed | Cancelled. A standalone task's successful run lands in WaitingForReview (planning children go straight to Done); from review you can approve (merges the worktree into the target branch, then Done; conflicts keep it in WaitingForReview), reject-rerun (Queued, resumes the session with feedback), reject-park (Idle), or cancel (Cancelled). Tasks with no active worktree (sandbox run / improvement parent) are approved straight to Done.
+- Task status flow: `Idle | Queued -> Running -> WaitingForReview -> Done | Failed | Cancelled`; a task with children passes through `WaitingForChildren` first. **Approve is the single review+merge action** (no separate "Merge all"), and in the detail pane it's gated behind opening the diff. Full transition table → `src/ClaudeDo.Worker/CLAUDE.md`; merge/review/gate mechanics → `docs/explore-notes/review-merge.md`.
 - Worktree state flow: Active -> Merged | Discarded | Kept
 - The queue picker claims tasks by `Status=Queued` (with `BlockedByTaskId IS NULL`); the legacy tag system was removed
 - Interfaces live in an `Interfaces/` subfolder beside their consumers (namespace unchanged)
@@ -75,6 +82,9 @@ dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
 
 ## Docs
 
-- `docs/plan.md` — full architecture and design spec
-- `docs/open.md` — verification checklist and improvement backlog
-- `docs/improvement-plan.md` — prioritized improvement items
+- `docs/open.md` — open verification items and remaining code TODOs (the only doc kept current besides the CLAUDE.md files)
+- `docs/plan.md` — original design spec (historical; tag-queue/schema.sql parts are outdated)
+- `docs/improvement-plan.md` — improvement snapshot from 2026-04-13 (historical)
+- `docs/prompts-inventory.md`, `docs/mailbox-proposal.md` — reference material (mailbox integration is parked)
+- `CHANGELOG.md` — Keep a Changelog format, maintained on release
+- `docs/explore-notes/` — distilled maps of complex subsystems (detail too fine for a CLAUDE.md, read on demand). **Before** deep-exploring a subsystem, check for a matching note first; **after** a deep explore, distill durable findings back and bump its "verified against" commit. Always verify against current code before trusting. See `docs/explore-notes/README.md`. Current notes: `worker-task-pipeline`, `usage-monitoring`, `external-mcp`, `review-merge`, `conpty-sessions`, `installer-preflight`.

README.md

@@ -1,106 +1,429 @@
 # ClaudeDo
 
-A desktop task management app that executes tasks autonomously via [Claude CLI](https://docs.anthropic.com/en/docs/claude-code) in isolated git worktrees.
+A Windows desktop app that turns your to-do list into a work queue for [Claude Code](https://docs.anthropic.com/en/docs/claude-code).
 
-Queue up coding tasks, and ClaudeDo picks them up one by one — each running in its own worktree so your main branch stays clean.
+Write down what you want done. ClaudeDo picks the task up, runs Claude in an isolated git
+worktree, and hands you back a diff to review. Your main branch is never touched until you
+approve.
 
-## Architecture
+It looks and feels like a normal task app — lists, My Day, stars, due dates — except every
+task can also be *executed*.
 
-Two-process system communicating over SignalR:
+---
 
-| Project | Role |
-|---|---|
-| **ClaudeDo.App** | Avalonia desktop entry point, DI container setup |
-| **ClaudeDo.Ui** | Views, ViewModels, SignalR client (MVVM) |
-| **ClaudeDo.Data** | SQLite data layer, repositories, models, GitService |
-| **ClaudeDo.Worker** | ASP.NET Core hosted service, task queue, Claude CLI runner |
+## Contents
 
-```
-┌────────────────┐  SignalR    ┌────────────────┐
-│  ClaudeDo.App  │◄───────────►│ ClaudeDo.Worker │
-│  (Avalonia)    │ 127.0.0.1  │ (ASP.NET Core) │
-│                │  :47821     │                │
-│  ┌────────────┐│             │ ┌────────────┐ │
-│  │    Ui      ││             │ │ TaskQueue  │ │
-│  │(ViewModels)││             │ │ Claude CLI │ │
-│  └────────────┘│             │ └────────────┘ │
-└───────┬────────┘             └───────┬────────┘
-        │                              │
-        └──────────────┬───────────────┘
-                       │
-               ┌───────┴───────┐
-               │ ClaudeDo.Data │
-               │   (SQLite)    │
-               └───────────────┘
-```
+- [Is this for you?](#is-this-for-you)
+- [Requirements](#requirements)
+- [Install](#install)
+- [The window](#the-window)
+- [The core loop](#the-core-loop)
+- [Lists and repositories](#lists-and-repositories)
+- [Writing a task](#writing-a-task)
+- [Ways to run a task](#ways-to-run-a-task)
+- [Watching work happen](#watching-work-happen)
+- [Reviewing and merging](#reviewing-and-merging)
+- [Resolving conflicts](#resolving-conflicts)
+- [Worktrees](#worktrees)
+- [Staying inside your usage limits](#staying-inside-your-usage-limits)
+- [Your daily rhythm](#your-daily-rhythm)
+- [Settings](#settings)
+- [Letting Claude drive ClaudeDo](#letting-claude-drive-claudedo)
+- [Updates](#updates)
+- [Where your data lives](#where-your-data-lives)
+- [Keyboard shortcuts](#keyboard-shortcuts)
+- [Troubleshooting](#troubleshooting)
+- [For developers](#for-developers)
 
-## Tech Stack
+---
 
-- .NET 8.0
-- Avalonia 12.0.0 (Fluent theme)
-- SQLite (WAL mode) via Entity Framework Core (EF Core + Migrations)
-- SignalR for real-time IPC between UI and Worker
-- CommunityToolkit.Mvvm for source-generated MVVM
-- Git worktrees for task isolation
+## Is this for you?
 
-## Prerequisites
+ClaudeDo is built for one person running many small-to-medium coding jobs across several
+repositories, mostly unattended.
 
-- [.NET 8.0 SDK](https://dotnet.microsoft.com/download/dotnet/8.0)
-- [Claude CLI](https://docs.anthropic.com/en/docs/claude-code) installed and authenticated
+It fits when you:
+
+- have a backlog of contained changes ("rename this", "add that endpoint", "fix this bug")
+- want them worked on while you do something else
+- still want to read every diff before it lands on `main`
+
+It is *not* a CI system, not a team tool, and not a chat window. There are no pull
+requests, no reviewers but you, and no cloud component (unless you deliberately turn on the
+optional online inbox).
+
+## Requirements
+
+- Windows 10/11
+- [Claude Code CLI](https://docs.anthropic.com/en/docs/claude-code), installed and signed in
+  (ClaudeDo runs `claude` as *you* — it never handles your credentials)
 - Git
+- [.NET 8 Desktop Runtime](https://dotnet.microsoft.com/download/dotnet/8.0) — the installer
+  itself needs it, so install it first if the installer refuses to start
 
-## Getting Started
+## Install
+
+Run `ClaudeDo.Installer.exe`. It downloads the current release, writes its config, and
+starts the background worker.
+
+The wizard asks for:
+
+| Page | What it decides |
+|---|---|
+| **Welcome** | Install folder, and whether Claude may manage your tasks via MCP (see [below](#letting-claude-drive-claudedo)) |
+| **Data paths** | Where the database, logs, sandboxes and worktrees live |
+| **Worker** | Port, path to the `claude` binary, and whether the worker starts at logon |
+
+Re-running the installer later gives you **Update**, **Repair** and **Uninstall** instead
+of the full wizard. Uninstall asks separately before deleting your tasks and settings.
+
+ClaudeDo has two parts: the window you see, and a background **worker** that does the
+actual running. The worker starts at logon and keeps going even when the window is closed —
+so a long task finishes whether you are watching or not.
+
+## The window
+
+Three panes ("islands"), plus a footer:
+
+```
+┌──────────────┬────────────────────────────┬───────────────────────────┐
+│  LISTS       │  TASKS                     │  DETAILS                  │
+│              │                            │                           │
+│  My Day      │  ▸ Add a task…      ENTER  │  Fix login redirect       │
+│  Important   │                            │  ─────────────────────    │
+│  Planned     │  OVERDUE                   │  Steps      ▢ ▢ ▣         │
+│              │  ● Fix login redirect      │  Details    (markdown)    │
+│  Queue    3  │                            │  Files      (drop here)   │
+│  Running  1  │  TASKS                     │                           │
+│  Review   2  │  ● Add CSV export  RUNNING │  Worktree · Diff · Merge  │
+│              │  ● Bump deps      QUEUED   │                           │
+│  MY LISTS    │  ● Write changelog         │  Output │ Git │ Session   │
+│  LagerApp  7 │  ● Call the tax guy MANUAL │  ┌─────────────────────┐  │
+│  LogX      2 │                            │  │ live Claude output  │  │
+│  ClaudeDo 12 │                            │  └─────────────────────┘  │
+├──────────────┴────────────────────────────┴───────────────────────────┤
+│ ● Online   5h 41% · 7d 22%   worker log line…                    logs │
+└───────────────────────────────────────────────────────────────────────┘
+```
+
+- **Lists** (left) — smart lists, virtual work lists, and your own lists (one per repo)
+- **Tasks** (middle) — the selected list, grouped into Overdue / Tasks / Completed
+- **Details** (right) — everything about the selected task, including its live output
+- **Footer** — worker connection, usage pill, and the latest worker log line (clickable)
+
+On a narrow window the side panes fold away automatically.
+
+The grid icon in the title bar opens **Mission Control**, a separate window for watching
+several running sessions at once.
+
+## The core loop
+
+```
+   write it down  →  queue it  →  Claude runs it  →  you review  →  merge
+      (Idle)         (Queued)       (Running)      (Waiting for      (Done)
+                                                      Review)
+```
+
+1. **Capture.** Type into the add box. That is it — a task starts out as a plain reminder.
+2. **Queue.** Right-click → *Send to queue*. The worker claims queued tasks in order, as
+   many at a time as *Max parallel executions* allows.
+3. **Run.** ClaudeDo creates a git worktree off your repo (branch `claudedo/<id>`), runs
+   Claude there with your task as the prompt, and streams the output into the detail pane.
+4. **Review.** On success the task lands in **Waiting for Review** with a committed
+   worktree and a diff. Nothing has touched your working copy.
+5. **Merge.** *Approve & merge* merges the branch into the target you pick, then marks the
+   task Done. Or reject it with feedback, park it, or cancel it.
+
+A task that fails is marked **Failed** and keeps its worktree and its log, so you can look
+at what happened and either continue the same session or reset and retry from scratch.
+
+## Lists and repositories
+
+A list becomes *runnable* by giving it a **working directory** — a git repo. Tasks in that
+list get worktrees off that repo; tasks in a list without a working directory can still be
+run, but in a scratch sandbox with no git.
+
+- **Add repos as lists** (`Repositories` menu, or the folder icon) scans folders you point
+  it at and creates one list per git repo it finds. This is the fastest way to get started.
+- **List settings** (right-click a list) sets the name, working directory, default commit
+  type, the agent defaults for that list, and an optional verify command.
+- **Manual list** — mark a list as reminders-only. New tasks in it start out manual, so
+  automation never touches them. Good for a "Errands" or "Phone calls" list.
+- Drag a task onto another list to move it. ClaudeDo refuses to move a running task and
+  warns you when the two lists point at different repos.
+
+**Smart lists** are always there:
+
+| List | Contains |
+|---|---|
+| **My Day** | What you (or the daily prep) picked for today, plus a pinned Notes row |
+| **Important** | Starred tasks |
+| **Planned** | Everything with a date |
+| **Queue / Running / Review** | Live work — waiting, in flight, and awaiting your review |
+
+## Writing a task
+
+The detail pane is where a one-line reminder becomes a brief Claude can act on:
+
+- **Title + Details** — markdown, with an edit/preview toggle. This is the prompt.
+- **Steps** — a checklist. Handy for you, and included when you copy the task out.
+- **Files** — drag files onto the pane (or use *Add file…*) to attach reference material.
+  Attachments are handed to Claude as read-only paths, not pasted into the prompt.
+- **Star / Schedule / Add to My Day** — the usual task-app affordances.
+- **Agent settings** — per-task overrides for model, turn budget, extra system prompt,
+  agent file and skills. Anything you do not override shows an *inherited* badge pointing at
+  the list or global default.
+- **Refine** — hand the task to Claude to sharpen it: it rewrites the title and details into
+  a proper brief. Useful when you captured something in three words.
+- **Mark as manual** — a MANUAL badge; the queue, the daily prep and every automation skip
+  it. Use it for things only you can do.
+
+## Ways to run a task
+
+| Way | What it does | Use it when |
+|---|---|---|
+| **Send to queue** | Worker picks it up in order | The normal path |
+| **Run now** | Skips the queue, starts immediately | You want this one first |
+| **Continue** | Resumes the last session with a follow-up | "Almost right, now also…" |
+| **Reset & retry** | Throws the worktree away, re-queues from scratch | The run went sideways |
+| **Open ConPTY session** | Opens the *real* Claude terminal for this task in Mission Control | You want to drive it yourself, with the task as the starting brief |
+| **Open planning session** | An interactive session whose job is to break the task into subtasks | The work is too big for one run |
+| **Let Claude handle it** | Hands a whole list over in one go | You have a pile of small tasks |
+
+### Planning sessions
+
+A planning session is a conversation whose output is *structure*, not code. Claude creates
+child tasks under the parent. You then:
+
+1. **Finalize plan** — children are chained (each waits for the previous one) but stay Idle.
+2. **Queue plan** — when you are happy with the list, this queues them all.
+3. The parent waits in **Waiting for Subtasks** until every child is terminal, then surfaces
+   for review once — you review and merge the *whole unit*, not each child.
+
+A parked planning session is remembered; the next launch offers to resume, finalize or
+discard it.
+
+### "Let Claude handle it"
+
+Right-click a list → *Let Claude handle it*. You get a checkbox list of that list's open
+tasks. Confirm, and one Claude session works the selection end to end: it reads them,
+de-duplicates overlaps, enhances thin descriptions, queues the work, and merges the results.
+It shows up as its own MANUAL task so you can see what a given run covered, and you review
+the combined diff when it is finished.
+
+## Watching work happen
+
+- **Detail pane, three tabs** — *Output* (live Claude stream), *Git* (worktree, diff,
+  merge), *Session* (result, token/turn counts, subtask outcomes).
+- **Mission Control** — one tile per running or interactive session, in Focus or Overview
+  mode. ConPTY tiles are the real Claude TUI, embedded: keyboard, colors, `/` commands, all
+  of it. *New session* opens an ad-hoc one that belongs to no task.
+- **Roadblocks** — when a run gets stuck it reports a roadblock instead of silently failing.
+  The Session tab shows it as its own card with a reply box: answer the question and the
+  same session picks up where it stopped.
+- **Claude is asking** — an interactive session can put a question in front of you mid-run;
+  answer it inline in Mission Control and the run continues.
+- **Footer log strip** — the worker's latest event. Failures of your own actions flash here
+  too, instead of vanishing. Click it for the last 30 minutes of worker logs, with a
+  warnings-and-errors filter.
+
+## Reviewing and merging
+
+When a task reaches **Waiting for Review** you get four actions:
+
+| Action | Result |
+|---|---|
+| **Approve & merge** | Merges the work into the target branch, then Done |
+| **Reject** | Asks for feedback and re-runs the same session with it |
+| **Park** | Back to Idle so you can rewrite the task yourself |
+| **Cancel** | Done with it; the worktree stays until you clean it up |
+
+**You have to look before you approve.** When there is a diff to inspect, *Approve & merge*
+stays disabled until you have opened the diff viewer once. It re-locks after any new run.
+(The quick-approve on the task row itself is a deliberate bypass for when you already know.)
+
+The diff viewer shows a file tree on the left and the diff on the right, and can show a
+dirty worktree, a branch against its base, or a commit range. For a parent with children,
+*Review combined diff* shows per-subtask diffs plus a combined preview of the whole unit.
+
+**Verify command** (optional, per list) — a command that must exit 0 after a merge lands
+before the task is allowed to reach Done. Typically a build or a test run. If it fails, the
+merge stays (nothing is rewritten behind your back) but the task is held out of Done and the
+failure output is reported.
+
+## Resolving conflicts
+
+If a merge conflicts, ClaudeDo opens a three-pane merge editor in-app:
+
+```
+┌──────────────────┬──────────────────┬──────────────────┐
+│ MAIN             │ RESULT           │ INCOMING         │
+│ merge target     │ (editable)       │ task branch      │
+│                  │                ▐ │                  │
+│  ›               │  ← you build     │               ‹  │
+│                  │     the result   │                  │
+└──────────────────┴──────────────────┴──────────────────┘
+```
+
+- Whole files, syntax-highlighted, scrolling in sync
+- Each conflict starts *empty*. The gutter arrows toggle each side in or out — take main,
+  incoming, both (in the order you click), or neither
+- Only conflict regions are editable in the middle pane; type your own resolution if
+  neither side is right
+- `F8` / `Shift+F8` jump between conflicts; the ruler beside the result pane maps every
+  conflict in the file
+- A counter tells you how many files still need attention. *Resolve & continue* is disabled
+  until they are all done, and *Abort merge* always leaves the target branch as it was
+
+Binary conflicts cannot be resolved here — ClaudeDo says so and lists the paths.
+
+## Worktrees
+
+Every run gets its own worktree, so parallel tasks never fight over your checkout.
+
+The **Worktrees** overview (per list or global) lists them with state, diff size, age and
+outcome. From there you can show a diff, jump to the task, merge, batch-merge a selection
+into one target, mark one *Kept* or *Discarded*, or force-remove a leftover. Worktrees whose
+directory is gone from disk are flagged as *phantom*.
+
+Finished worktrees are auto-cleaned after a number of days you choose in Settings.
+
+## Staying inside your usage limits
+
+The footer pill shows your Claude usage: `5h 41% · 7d 22%`. Click it for the **Usage
+Monitor**:
+
+- Gauges for the 5-hour session window and the 7-day windows, each with a reset countdown
+- **Models** — token usage per model over a range you pick, split into ClaudeDo's own
+  consumption and everything else
+- **Tasks** — your biggest consumers, with run counts and totals
+
+And the part that matters when you are asleep: the **usage limit stop**. Set a percentage
+per window in Settings, and once usage reaches it the queue simply stops picking up new
+tasks. Running tasks finish normally, and the queue resumes by itself as the window rolls
+over. `0` turns a stop off. Manual actions — *Run now*, *Continue*, interactive and planning
+sessions — are never blocked.
+
+## Your daily rhythm
+
+- **My Day** — the day's shortlist. *Clear day* empties it.
+- **Prime Claude** (Settings → Prime Claude) — schedules for the days and times you pick.
+  At that time ClaudeDo runs a short prep session: Claude looks at your idle tasks, picks an
+  effort-aware subset up to your daily cap, and fills My Day. It also warms your usage
+  window for the day. Only runs while ClaudeDo is open; if you start the app within 30
+  minutes of a scheduled time it fires right away. *Plan day* runs it on demand.
+- **Notes** — a pinned row in My Day: dated bullet notes with a day navigator, for the
+  thoughts that are not tasks.
+- **Weekly report** (`Help` menu) — pick a range (defaults to "since your standup weekday")
+  and Claude writes up what actually happened, from your task and session history. Paths you
+  do not want in reports can be excluded in Settings.
+
+## Settings
+
+Most settings exist at three levels — **global → list → task** — and the more specific one
+wins. Overridden fields carry an *override* badge with a one-click reset; inherited ones say
+where they come from.
+
+**General**
+- Default instructions applied to every task
+- Default model, and a **per-model table** of reasoning effort and turn budget — so `haiku`
+  can be cheap and short while `opus` gets room to think
+- Permission mode for autonomous runs
+- Max parallel executions
+- Usage limit stops (see above)
+- Session skills applied to every task
+- Report exclusions, standup weekday
+- Accent color (Moss / Peat / Sea) and language (English / German)
+
+**Worktrees** — sibling or central placement, auto-cleanup age, and the manual cleanup and
+force-remove-all buttons.
+
+**Files** — open the prompt templates (system, planning, retry, daily prep, weekly report)
+in your editor, and restore the bundled default agent files.
+
+**Skills** — install a skill from a git URL, update it, remove it. Skills selected globally,
+per list and per task combine.
+
+**Prime Claude** — the schedules and the daily task cap.
+
+**Online Inbox** (optional, off by default) — mirrors your idle backlog to a server so you
+can capture tasks from your phone. Disabled means zero network traffic. Enabling it needs a
+URL plus a sign-in; the refresh token is stored encrypted on your machine, never in a config
+file.
+
+## Letting Claude drive ClaudeDo
+
+If you allowed it during install, ClaudeDo registers itself as an MCP server with the Claude
+CLI. Any Claude session on your machine can then read and manage your tasks: list and create
+tasks, add subtasks, queue and cancel runs, read logs and diffs, merge, review, manage lists
+and per-list config.
+
+Concretely, you can sit in a normal Claude Code session and say "put these five things in
+the ClaudeDo backlog for the LagerApp list", or "check whether the CSV export task is done".
+
+The MCP surface is deliberately narrow on the dangerous end: it can start and observe work,
+but it cannot rewrite your app settings, and a task with an active worktree cannot be forced
+to Done behind your back.
+
+## Updates
+
+ClaudeDo checks for new releases and shows a banner when one is out. *Update now* relaunches
+the installer, which stops the worker, swaps the binaries and starts it again. Your database,
+worktrees and settings are preserved. You can also check manually via `Help → Check for
+updates`.
+
+## Where your data lives
+
+Everything is under `%USERPROFILE%\.todo-app`:
+
+| Path | What |
+|---|---|
+| `todo.db` | Your tasks, lists, runs and worktree records (SQLite) |
+| `ui.config.json` | Window and UI settings |
+| `worker.config.json` | Worker settings — paths, port, worktree strategy |
+| `logs/` | Worker and task logs |
+| `agents/` | Your agent definition files |
+| `attachments/` | Files you attached to tasks |
+
+`Help → About` links straight to these folders. Nothing leaves your machine unless you turn
+on the online inbox.
+
+## Keyboard shortcuts
+
+| Key | Action |
+|---|---|
+| `Ctrl+K` | Focus search |
+| `Ctrl+N` | Focus the add-task box |
+| `Enter` | Add the task |
+| `Esc` | Leave the current text field / close a dialog |
+| `F8` / `Shift+F8` | Next / previous conflict (merge editor) |
+
+## Troubleshooting
+
+**"Worker not reachable"** — the background worker is not running. The dialog offers to
+start it; `Worker → Restart worker` does the same later. If it keeps happening, re-run the
+installer and choose *Repair*.
+
+**A task failed immediately** — usually the `claude` CLI is not signed in, or the list's
+working directory is not a git repo. Check the Output tab and the footer log.
+
+**A task is stuck in Running after a crash** — the worker sweeps orphaned runs to Failed on
+startup. Restart the worker.
+
+**Nothing is being picked up** — check the usage pill: if a usage stop is active the queue is
+paused on purpose. Also check whether the tasks are MANUAL, blocked by a predecessor, or
+scheduled for later.
+
+## For developers
+
+Architecture, build commands and per-project docs live in `CLAUDE.md` (root and one per
+project under `src/`). Short version: .NET 8, Avalonia UI, SQLite via EF Core, and a
+SignalR-connected worker process on `127.0.0.1:47821`.
 
 ```bash
-# Build
-dotnet build src/ClaudeDo.App
-dotnet build src/ClaudeDo.Worker
-
-# Run tests
-dotnet test tests/ClaudeDo.Worker.Tests
-
-# Run the app
-dotnet run --project src/ClaudeDo.App
-```
-
-## How It Works
-
-1. Create a task in the UI and tag it with **"agent"** to mark it for automated execution.
-2. The Worker picks up queued tasks and runs each one via Claude CLI in an isolated git worktree.
-3. When done, the worktree can be merged, kept for review, or discarded.
-
-**Task status flow:** `Manual | Queued → Running → Done | Failed`
-
-**Worktree state flow:** `Active → Merged | Discarded | Kept`
-
-## Configuration
-
-All data and config lives under `~/.todo-app/`:
-
-| File | Purpose |
-|---|---|
-| `todo.db` | SQLite database |
-| `ui.config.json` | UI settings |
-| `worker.config.json` | Worker settings (worktree strategy, etc.) |
-| `logs/` | Application logs |
-
-## Project Structure
-
-```
-ClaudeDo.slnx
-├── src/
-│   ├── ClaudeDo.App/        # Desktop entry point
-│   ├── ClaudeDo.Ui/         # Views & ViewModels
-│   ├── ClaudeDo.Data/       # Data access layer
-│   └── ClaudeDo.Worker/     # Background task runner
-├── tests/
-│   └── ClaudeDo.Worker.Tests/
-├── schema/
-│   └── schema.sql           # Database schema
-└── docs/
-    ├── plan.md              # Architecture & design spec
-    ├── open.md              # Verification checklist & backlog
-    └── improvement-plan.md  # Prioritized improvements
+dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
 ```
 
 ## License

docs/explore-notes/README.md

@@ -0,0 +1,50 @@
+# Explore-notes
+
+Distilled, reusable maps of complex subsystems, produced by deep code exploration.
+The goal: stop re-exploring the same subsystem from scratch in every new session.
+
+These sit **between** the CLAUDE.md files and the code:
+
+- **CLAUDE.md** — high-level orientation, hand-maintained, always-loaded.
+- **explore-notes** — deeper subsystem detail (flows, who-calls-whom, invariants) that is
+  too fine-grained for a CLAUDE.md but stable enough to be worth caching. Read on demand.
+- **code** — the only source of truth.
+
+## Index
+
+| Note | Covers |
+|---|---|
+| [worker-task-pipeline](worker-task-pipeline.md) | `TaskRunner` end-to-end: config resolution, worktree, CLI invocation, streaming, commit |
+| [usage-monitoring](usage-monitoring.md) | OAuth usage endpoint, gate, throttle, per-run token accounting, usage pill/modal |
+| [external-mcp](external-mcp.md) | The `claudedo` MCP tool surface + its two test-enforced conventions |
+| [review-merge](review-merge.md) | Approve=merge-unit, verify gate, `MergeCommit`/revert, diff stack, conflict resolver |
+| [conpty-sessions](conpty-sessions.md) | Interactive/planning/list-handler launch specs + the arg-flattening gotcha |
+| [installer-preflight](installer-preflight.md) | CLI version/login/auto-mode research, the `ExecutableResolver`/shim root cause, and the Installer's `Checks/`+`SystemCheckPage` implementation status |
+| [list-virtualization-spike](list-virtualization-spike.md) | Phase 2a gate spike: virtualized `ListBox` + the existing ghost-drag `InputHitTest` model, verified headless |
+
+## Rules
+
+- **Only stable structure.** Flows, responsibilities, entry points, invariants, relative
+  file paths. **No line numbers**, no exhaustive symbol dumps — those rot fastest.
+- **Verify before trusting.** A note is a starting map, not authority. Always confirm
+  against current code before acting on it. Each note records the commit it was verified
+  against so you can diff for drift.
+- **Not a substitute for CLAUDE.md.** If a fact belongs in orientation, put it there.
+
+## Header every note must carry
+
+```
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `<short-hash>` (<date>).
+> Drift check: `git log --oneline <short-hash>..HEAD -- <paths this note covers>`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+```
+
+## Workflow
+
+1. **Before** deep-exploring a subsystem, check for a matching note here and read it first;
+   explore only to fill gaps or confirm.
+2. **After** a deep explore, distill the durable findings into a new/updated note and bump
+   its "verified against" commit line.
+3. If the drift check shows the covered paths changed a lot since the verified commit, treat
+   the note as suspect and re-verify the parts you rely on.

docs/explore-notes/conpty-sessions.md

@@ -0,0 +1,303 @@
+# ConPTY interactive sessions & launch specs
+
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `79b3580` (2026-08-11).
+> Drift check: `git log --oneline bdee731..HEAD -- src/ClaudeDo.Worker/Planning src/ClaudeDo.Worker/Hub src/ClaudeDo.Worker/Runner/ClaudeArgsBuilder.cs src/ClaudeDo.Ui/ViewModels/MissionControlViewModel.cs src/ClaudeDo.Ui/Views/InteractiveTerminalView.axaml`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+Covers `InteractiveLaunchSpecService` and the four kinds of embedded ConPTY session the UI
+process hosts (real `claude` TUI in a Mission Control tile).
+
+Autonomous queue tasks are **not** covered here — they stay on the stream-json path via
+`TaskRunner`. See [worker-task-pipeline.md](worker-task-pipeline.md).
+
+## The four session kinds
+
+| Kind | Hub spec method | Notes |
+|---|---|---|
+| Task session | `GetInteractiveLaunchSpec` | Effort from the task/list model preset |
+| Ad-hoc | `GetAdHocLaunchSpec` | Effort from the global default |
+| Planning | (planning start/resume) | Effort from `PlanningAlias`; uses `--permission-mode default`, **not** `plan` |
+| List handler | `GetMergeHelperLaunchSpec` / `GetMergeHelperHandoffLaunchSpec` | Model + effort fixed per role (`ModelRegistry.HandlerTriageAlias`/`HandlerWaitAlias`/`HandlerMergeAlias`), **not** from list config; `--permission-mode` via `PermissionModeResolver` (unattended) |
+
+## ⚠️ Gotcha: never pass task free-text as a CLI argument
+
+**No ConPTY path ever passes task free-text (title / description / brief) as a CLI argument.**
+Every one of them writes it to a file first and hands `claude` a single-line kickoff pointing at
+that file, exposed via `--add-dir`.
+
+Two independent reasons:
+
+1. The ConPTY host flattens `Args` into **one command line** to spawn the process, and `claude`
+   re-splits that line on whitespace. Any token starting with `-` in real task text (e.g. `->`,
+   `--abort`) is then misread as an unknown option.
+2. A raw multi-line positional prompt truncates at its **first newline** regardless.
+
+A fresh task session's brief lives at `~/.todo-app/task-sessions/<taskId>/brief.md`
+(`InteractiveLaunchSpecService.BuildFreshTaskArgsAsync`). A task with neither title nor
+description skips the file **and** the positional arg entirely — it still gets `--session-id`.
+
+## Argument ordering
+
+Every spec passes `--effort <level>` from the relevant model's preset. It **leads** the args —
+except for a fresh task session with a brief, where `--add-dir <sessionDir>` must come first so
+`--effort` (a single-value flag) can sit directly before the positional kickoff.
+
+`--model` is deliberately **NOT** forced on an interactive session — the user can still switch
+models in the TUI.
+
+### ⚠️ Gotcha: no directory arg may end in a separator
+
+`PtyTerminalSession` hands `Args` to `TerminalControl.Args`, which the library flattens into ONE
+Windows command line with each token quoted. Windows argv rules read `\"` as an *escaped* quote,
+so a token like `"C:\repo\"` never closes and every following argument is swallowed by the
+preceding **variadic** flag. A list working dir stored as `C:\Dev\Repos\Bandel.Hub\` therefore
+fed `--add-dir` the repo, `--append-system-prompt-file`, its value **and** the positional kickoff:
+the CLI warned `brief.md is not a directory` and the session opened with no prompt at all
+(2026-08-06). `BuildForMergeHelperAsync`/`BuildForMergeHelperHandoffAsync` run the repo through
+`TrimTrailingSeparator`; session dirs the worker builds never carry one.
+
+The same data bit the UI's "Open in terminal" on 2026-08-10 (`wt -d "C:\…\StaplerTracking\"` →
+`Could not access starting directory "C:\…\StaplerTracking""`), so the fix moved to the write side:
+**`ListRepository.AddAsync`/`UpdateAsync` normalize `WorkingDir` via `Paths.TrimTrailingSeparator`**,
+which covers every writer (UI create, repo import, hub `UpdateList`, MCP `CreateList`/`UpdateList`) —
+the UI and worker keep their own defensive trim for rows written before that. Anything new that puts
+a **user-supplied** path on a command line should use `Paths.TrimTrailingSeparator` and, on the
+`ProcessStartInfo` side, `ArgumentList` rather than an interpolated `Arguments` string.
+
+Diagnosing this from code or a PowerShell repro is a dead end — PowerShell quotes correctly, so
+every repro passes. Read the real command line instead:
+`Get-CimInstance Win32_Process -Filter "Name = 'claude.exe'"`.
+
+## Resuming a task session (`TaskEntity.InteractiveSessionId`)
+
+`claude --session-id <uuid>` lets the caller pre-assign a conversation's session id instead of
+waiting for the CLI to generate one. `BuildForTaskAsync` uses this so a closed or aborted
+interactive task session can be resumed even if it never got far enough to write anything to its
+own transcript:
+
+1. **Resume check.** If the task isn't on a freshly (re)created worktree, `BuildForTaskAsync`
+   picks a session to resume with `task.InteractiveSessionId ?? run?.SessionId` — this task's own
+   last *interactive* conversation takes precedence over the latest *autonomous* run's session,
+   since they're distinct conversations even against the same worktree. A task that has only ever
+   run autonomously still resumes into that run's session the first time it's opened interactively
+   (this is the pre-existing behavior `run?.SessionId` alone used to provide).
+2. **Fresh path.** If neither is available (never run any way, or `isFreshWorktree`), a new
+   `Guid.NewGuid()` is generated and persisted to `TaskEntity.InteractiveSessionId` via
+   `TaskRepository.SetInteractiveSessionIdAsync` — **before** the `LaunchSpec` is returned, i.e.
+   before the ConPTY host ever spawns `claude`. `BuildFreshTaskArgsAsync` then passes it as
+   `--session-id <guid>`, placed as the single-value flag directly before the positional kickoff
+   (or, with no brief, right after `--effort`).
+3. **Fresh worktree wins.** `isFreshWorktree` forces `run` to `null` *and* is checked before
+   reading `task.InteractiveSessionId`, so a recreated worktree never resumes a stale id from
+   either source — it always takes the fresh path, which overwrites the stale
+   `InteractiveSessionId` with the new one.
+
+Net effect: reopening an interactive session for a task (pane closed, process killed, whatever)
+resumes the same claude conversation, because the id was committed to the DB before the previous
+launch even started.
+
+## List handler ("Let Claude handle it")
+
+`BuildForMergeHelperAsync`/`BuildForMergeHelperHandoffAsync` resolve `--permission-mode` via
+`PermissionModeResolver` (currently always `auto`, since none of the handler roles run on haiku)
+so the session runs unattended. The `--allowedTools` allowlist is the security boundary:
+`mcp__claudedo__*,Read,Grep,Glob,Edit,Bash,WebFetch,WebSearch,Skill,Task` (`Task` lets the Merge
+role delegate diff reviews to sonnet subagents).
+
+The run now spans up to **five** phase-scoped sessions instead of two, chained via
+`handoff_list_handler(taskId, survivingTaskIds, nextPhase)`: opus Triage → sonnet Wait → opus
+Merge → (only if Merge started reruns) sonnet Wait(final) → opus Merge(final). `nextPhase` (`wait`
+| `merge` | `wait_final` | `merge_final`, validated by `MergeHelperPhase.Validate`) picks both the
+system prompt (`PromptKind.MergeHelperWait`/`MergeHelperMerge`) and the model
+(`ModelRegistry.HandlerWaitAlias`/`HandlerMergeAlias`) for the next session; the `_final` variants
+share the same prompt/model as their non-final counterpart and differ only in one extra line
+rendered into the handoff kickoff file (`PromptKind.MergeHelperHandoff`) marking the final round
+and forbidding further reruns.
+
+Each handoff hands the SAME handler task id to a NEW tile, and `MissionControlViewModel.
+OpenMergeHelperHandoffConPtySessionAsync` closes the outgoing phase's pane (`CloseConPtySession`,
+which disposes its `PtyTerminalSession` and kills the underlying `claude` process) before opening
+the next one — every tile is a live process with the full `mcp__claudedo__*` surface, and the
+outgoing session is only ever told to end its turn, never to exit. This keeps the one-pane-per-
+`TaskId` invariant that `ConPtySessions` relies on elsewhere (`OpenConPtySessionAsync`'s dedupe,
+`OnPaneSubmitForReview`) — both use a plain `FirstOrDefault(s => s.TaskId == taskId)`, not a
+"newest wins" lookup.
+
+`MCP_TOOL_TIMEOUT` is 200 s here — `TaskWaitMcpTools` clamps its own timeout to 170 s to stay
+comfortably under it (see [external-mcp.md](external-mcp.md)).
+
+### The host task and its commit range
+
+The handler run **owns a real ClaudeDo task**, created by `CreateMergeHelperTask` (hub) →
+`InteractiveLaunchSpecService.CreateMergeHelperTaskAsync`, called by the UI *before* it opens
+the tile:
+
+- One new task per run in that list, `Idle` + `IsManual=true` (never queued).
+- Title/description localized via `missionControl.mergeHelperTaskTitle` /
+  `mergeHelperTaskDescriptionHeader`.
+- `TaskEntity.HandlerBaseCommit` stamped to the list repo's current HEAD.
+
+The host task **never gets a worktree of its own** — the handler commits straight into the
+list's working dir and merges the tasks it handles itself. Consequences:
+
+- `SubmitTaskForReview` branches on whether the task has a `WorktreeEntity`: with one, it
+  commits the worktree; without one, it stamps `HandlerHeadCommit` to the list repo's current
+  HEAD. Both paths then flip the task `Idle`/`Failed` → `WaitingForReview`.
+- `GetTaskDiff` and the UI's `DetailsIslandViewModel` / `MergeSectionViewModel` fall back to the
+  `HandlerBaseCommit`..`HandlerHeadCommit` range whenever `Worktree` is null.
+
+### UI flow
+
+`MergeHelperSelectionModalViewModel` — checkbox picker over one list's non-terminal, non-manual
+tasks, pre-ticking the actionable ones. **List-scoped only** (`Configure(listId, listName)`, no
+global scope). Opened from the list row's context menu, which is hidden when the list has no
+working dir.
+
+On confirm: `ListsIslandViewModel` raises `LetClaudeHandleRequested` → shell →
+`MissionControlViewModel.OpenMergeHelperConPtySessionAsync`, which calls
+`CreateMergeHelperTaskAsync` and then opens a **task-based** tile (deduped by `TaskId` like
+`OpenConPtySessionAsync`, **not** `CreateAdHoc`) running the five-phase handler prompt.
+
+## Tile lifecycle
+
+`ConPtyPaneViewModel` resolves its own launch spec — the ctor takes a descriptor **factory**,
+the host wires handlers and then calls `Start()`. So the tile appears **immediately** with its
+spinner while the worker is still preparing the worktree. A failed launch keeps the tile with an
+inline error banner instead of the tile never appearing.
+
+`SubmitForReviewCommand.CanExecute` also gates on `Terminal.IsStarting` / `StartError` /
+`HasExited` (not just `IsTaskBased`) — a starting or dead pane can't offer a review it would only
+have the worker reject, and `MissionControlViewModel.OnPaneSubmitForReview` sets the pane's
+`IsSubmitPending` flag for the duration of the round trip so a rapid double-click can't race two
+`SubmitTaskForReviewAsync` calls. A failed launch also offers `RetryCommand` (visible whenever
+`HasExited && StartError != null`) — it swaps in a fresh `InteractiveTerminalViewModel` and calls
+`Start()` again on the **same** pane/`TaskId` dedupe slot, since `PtyTerminalSession` throws on a
+second `StartAsync` call and can't be restarted in place.
+
+### ⚠️ Gotcha: the terminal library kills its child on visual-tree detach
+
+`Iciclecreek.Avalonia.Terminal`'s `TerminalView.OnDetachedFromLogicalTree` calls
+`CleanupProcess()` (kills the PTY child) unless `BeginReparent()` suppressed it — and Mission
+Control detaches pane views routinely (`RebuildOverviewGrid` recreates everything on any pane
+add/remove/column change; focus-mode tab switches re-present content). Two-part defense (since
+`aac84e4`):
+
+1. `PtyTerminalSession.StartAsync` puts the control in **permanent reparent mode** right after
+   `LaunchProcess()` — `EndReparent` is deliberately never called. Teardown is explicit only:
+   `ConPtyPaneViewModel.Dispose` → `Terminal.Kill()` (pane close, VM disposal via DI on exit).
+2. `ConPtyPaneHost` (the DataTemplate content for a pane) reparents **one long-lived
+   `ConPtyPaneView` per pane VM** (`ConditionalWeakTable`, view pins its own `DataContext`)
+   instead of letting the template instantiate a fresh view — a fresh view would render a dead,
+   empty terminal because the running session is bound to the original `TerminalControl`.
+   Hosts only steal the view while `IsEffectivelyVisible`; the layout toggle posts a reclaim
+   pass (`MissionControlView.ReclaimVisiblePaneHosts`) so the now-visible layout re-steals.
+
+`Ellipse.spinner` (IslandStyles) is the shared indeterminate spinner — used for a starting pane
+(`InteractiveTerminalViewModel.IsStarting`) and in place of the refine button while
+`TaskRowViewModel.IsRefining`.
+
+### ⚠️ Gotcha: env-var launch race across sessions
+
+`PtyTerminalSession.StartAsync` applies `TerminalLaunchDescriptor.Env` via
+`Environment.SetEnvironmentVariable` onto the **whole UI process** (Porta.Pty has no per-launch
+env seam — it always inherits the calling process's environment), then calls
+`TerminalControl.LaunchProcess()`. Two sessions starting back-to-back (e.g. planning sessions for
+two different tasks) could interleave: task B's `SetEnvironmentVariable` calls could land between
+task A's env-set and its `LaunchProcess()` fork, so task A's `claude` process inherits B's env
+(e.g. `CLAUDEDO_PLANNING_TOKEN`) and fails its own MCP auth. Fixed by serializing the
+set-env-then-launch critical section behind a process-wide `static SemaphoreSlim(1,1)` in
+`PtyTerminalSession`. Env leakage onto the whole process *after* a launch has forked remains a
+documented limitation — only the fork-time race is closed.
+
+### ⚠️ Gotcha: open-path dedupe races
+
+`MissionControlViewModel.OpenConPtySessionAsync` / `OpenPlanningConPtySessionAsync` dedupe by
+`TaskId` against `ConPtySessions`, but the check ran before an **awaited** DB title lookup and
+only `AddConPtyPane` registers the pane — two rapid invocations for the same task (e.g. a
+double-click) could both pass the dedupe check before either pane existed, opening two panes.
+`OpenMergeHelperConPtySessionAsync` was worse: it awaits `CreateMergeHelperTaskAsync` (which mints
+a brand-new task id every call) *before* any `TaskId` dedupe is even possible, so a double-trigger
+always minted two host tasks in the DB.
+
+Fixed with synchronous, pre-await claims: `_pendingTaskOpens` (shared by the two `TaskId`-keyed
+open paths) and `_pendingMergeHelperLists` (keyed by `listId`, guarding the whole method since
+there's no `TaskId` yet to dedupe on) are `HashSet<string>` fields checked-and-added at method
+entry, before any `await`, and released in a `finally`. A second overlapping call for the same key
+bails out immediately instead of racing past the collection-based dedupe.
+
+## Focus / key handling
+
+`InteractiveTerminalView` lives in `MissionControlWindow`, so the `FocusClearing` Escape handler
+(scoped to `MainWindow` via `AddClassHandler<MainWindow>`) never runs there — **Escape always
+reaches the PTY**. See the note in `src/ClaudeDo.Ui/CLAUDE.md`.
+
+`TaskRowViewModel.HasInteractiveSession` shows an accent "Interactive" chip instead of "Parked";
+tapping it jumps to that Mission Control pane. `TasksIslandViewModel.SyncInteractiveSessions`
+mirrors Mission Control's open panes onto the rows.
+
+### Queueing is gated on an open session (UI-only, since `d84607f`)
+
+A task-based session leaves the row `Idle` (sessions never write `Status`), so nothing on the
+worker side distinguishes it from a plain idle task. `TaskRowViewModel.CanSendToQueue` and
+`MissionControlViewModel.EnqueueTaskAsync` (drag-to-queue onto the Command Center window) both
+check for an open session before queueing — the row via `HasInteractiveSession`, the drag path via
+`ConPtySessions.Any(s => s.TaskId == taskId)` (Mission Control's own authoritative pane list,
+since the mirrored bool on the row could lag). Queueing a task open in a hand-driven ConPTY pane
+would otherwise let the picker spawn an autonomous `claude` process into the same worktree the
+user is editing. Both enqueue paths (`TasksIslandViewModel.SendToQueueAsync` and
+`MissionControlViewModel.EnqueueTaskAsync`) also route through `IWorkerClient.SetTaskStatusAsync`
+(hub `SetTaskStatus` → `TaskStateService.EnqueueAsync`) instead of a raw EF write, so the
+manual/draft-child guards apply on both paths too.
+
+## System-prompt matrix (autonomous vs. interactive)
+
+Autonomous and interactive sessions do **not** share a system prompt. Per start path:
+
+| Start path | Entry point | System prompt |
+|---|---|---|
+| Autonomous run/continue/retry | `TaskRunner.ResolveConfigAsync` → `ClaudeArgsBuilder.Build` | `--append-system-prompt <text>`, recomputed and re-sent on **every** invocation including a `--resume` continue (`PromptKind.System` + improvement/list/task overrides) |
+| Interactive task session, fresh | `InteractiveLaunchSpecService.BuildForTaskAsync` → `BuildFreshTaskArgsAsync` | none — no `--append-system-prompt(-file)` at all |
+| Interactive task session, resume | `InteractiveLaunchSpecService.BuildForTaskAsync` → `WindowsTerminalLauncher.BuildResumeArgs` | none — only `--resume <id>` (+ `--effort`) |
+| Ad-hoc directory session | `InteractiveLaunchSpecService.BuildForDirectoryAsync` | none |
+| Planning session start | `InteractiveLaunchSpecService.BuildPlanningStart` → `WindowsTerminalLauncher.BuildPlanningStartArgs` | `--append-system-prompt-file <path>` (`PromptKind.Planning`) |
+| Planning session resume | `InteractiveLaunchSpecService.BuildPlanningResume` → `WindowsTerminalLauncher.BuildPlanningResumeArgs` | none — only `--permission-mode default --allowedTools <planning allowlist> --resume <id>` |
+| List handler ("Let Claude handle it"), triage | `InteractiveLaunchSpecService.BuildForMergeHelperAsync` | `--append-system-prompt-file <path>` (`PromptKind.MergeHelperTriage` — phases 0–2 only), always fresh — this path never resumes |
+| List handler, post-handoff (wait/wait_final) | `InteractiveLaunchSpecService.BuildForMergeHelperHandoffAsync` | `--append-system-prompt-file <path>` (`PromptKind.MergeHelperWait` — phase 3 only), fresh session dir, same handler task id |
+| List handler, post-handoff (merge/merge_final) | `InteractiveLaunchSpecService.BuildForMergeHelperHandoffAsync` | `--append-system-prompt-file <path>` (`PromptKind.MergeHelperMerge` — phases 4–5 only), fresh session dir, same handler task id |
+
+So every interactive resume (task session and planning) drops the system prompt entirely — it's
+not that they inherit the autonomous one, it's that **no** `claude` process on any resume path
+ever passes `--append-system-prompt(-file)`.
+
+### Does `--resume` bring back a prior `--append-system-prompt`? No.
+
+Checked by reading real session transcripts (`~/.claude/projects/<cwd>/<sessionId>.jsonl`) for
+several autonomous ClaudeDo task runs, including ones with multiple invocations (initial run +
+`ContinueAsync`/retry on the same session id, confirmed via that project's `task_runs` history).
+Grepped for the `PromptKind.System` default text ("You are completing one well-defined task
+autonomously...") and for any `"type":"system"` entry or `message.role == "system"` anywhere in
+those files: the prompt text only ever showed up as ordinary tool-result content (e.g. a task
+that happened to read `PromptFiles.cs`'s own source), never as a persisted system/config entry.
+No session transcript — autonomous or interactive — carries a system-role message or a
+per-session record of the CLI flags it was launched with; there is no sidecar file next to the
+`.jsonl` either. The system prompt is purely a per-process request parameter the CLI builds fresh
+from that invocation's own flags, never replayed from a resumed session's history. This matches
+why `TaskRunner.ContinueAsync` (autonomous) explicitly re-resolves and re-passes
+`--append-system-prompt` on every continue instead of relying on `--resume` to carry it —
+if inheritance worked, that re-resolution would be redundant.
+
+**Conclusion: no leak.** An interactive resume (task or planning) does not pick up the autonomous
+run's `--append-system-prompt` text — including the "commit your work" / `CLAUDEDO_BLOCKED`
+instructions from `PromptKind.System`. It simply runs with the `claude` CLI's own baseline system
+prompt, same as every other path in this table that passes no system-prompt flag. No code change
+needed here.
+
+## Related hub methods
+
+`GetInteractiveLaunchSpec`, `GetAdHocLaunchSpec`, `GetMergeHelperLaunchSpec`,
+`CreateMergeHelperTask`, `SubmitTaskForReview`.
+
+Planning sessions: `StartPlanningSession`, `ResumePlanningSession`, `DiscardPlanningSession`,
+`FinalizePlanningSession`, `QueuePlanningSubtasks`, `GetPendingDraftCount`,
+`GetPlanningAggregate`, `BuildPlanningIntegrationBranch`.

docs/explore-notes/external-mcp.md

@@ -0,0 +1,255 @@
+# External MCP tool surface
+
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `38af549` (2026-08-11).
+> Drift check: `git log --oneline 38af549..HEAD -- src/ClaudeDo.Worker/External`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+Covers `src/ClaudeDo.Worker/External/` — the always-on MCP tools ClaudeDo exposes to general
+Claude sessions. Registered explicitly in `Program.cs`'s external app via `.WithTools<T>()`.
+Server name `claudedo`, registered globally by the installer's `RegisterMcpStep`, so callers
+need no `--mcp-config`.
+
+**Scope boundary:** these tools cover *starting* and *observing* sessions plus task/list CRUD
+and git/merge operations. They deliberately do **not** expose multi-turn control, planning
+session internals, or app-settings writes. Auth via an optional `X-ClaudeDo-Key` header.
+
+## Task ID resolution and numbering
+
+Every tool parameter accepting a task id — `taskId`, `parentId`, `taskIds` arrays, and similar —
+is wired through `TaskIdResolver`, which resolves:
+- `#123` (with or without the `#` prefix) → look up by `TaskEntity.Number`
+- Bare GUID string → use as-is
+- Unknown number → `InvalidOperationException` (`no task with number 123`)
+
+This is **not** ambiguous: a GUID is never all-digits, so a pure-integer parameter is always a
+number, not a partial GUID. All task-returning tools (`GetTask`, `ListTasks`, `AddTask`,
+`BatchGetTasks`, etc.) stamp the resolved task's `Number` in the DTO — both `TaskDto` and the
+lean `TaskRefDto` carry an `int Number` field. **Branch names and worktree paths** (`claudedo/{id}`)
+continue to use the GUID; the number is a display alias, never the identity.
+
+Every tool description carries a shared boilerplate clause (defined in `McpToolDocs.TaskNumberHint`)
+instructing the agent to **refer to tasks as `#<number>` when reporting results to the user** —
+without this the agent sees the number in every payload but never learns to speak it.
+
+## Conventions
+
+### Test-enforced
+
+1. **Every optional/filter parameter needs a C# default value** (e.g. `string? status = null`).
+   The MCP schema only marks a parameter optional when it has one — nullability alone does
+   not do it. `ExternalMcpToolSchemaTests` guards this by reflection.
+
+### Not test-enforced, but strongly observed
+
+2. **No tool returns bare `Task` or a nullable payload directly.** An MCP client cannot tell
+   an empty/omitted response apart from a dropped one.
+   - *Write* tools return a small confirmation record — `{ ok/deleted/removed/reset/started:
+     true, <id>, ... }` (`DeleteListResult`, `RunTaskNowResult`, `ResetFailedTaskResult`,
+     `RemoveAttachmentResult`; `SetListConfigResult` / `SetTaskConfigResult` additionally echo
+     the resulting config so the caller can see which fields were set vs. cleared to null).
+   - *Read* tools that may have nothing to return use an explicit `Found` / `Available` flag
+     alongside the nullable payload (`TaskConfigResult`, `BatchGetTaskResult`, `TaskLogResult`).
+   - The same flag-alongside-nullable-payload idiom also covers "which of two shapes did you
+     get": `ListTasks`/`BatchGetTasks` take `includeDescription` (default `false`) and return
+     `ListTasksResult`/`BatchGetTaskResult`, where exactly one of the lean (`TaskRefDto`) and
+     full (`TaskDto`, incl. Description/Result) fields is populated per the flag — keeps a
+     list of verbosely-described tasks from blowing past the response size limit by default.
+
+3. **Description style is documented in `McpToolDocs`** (same folder) and shared boilerplate
+   lives there as `const` strings. Rules: the first sentence says what the tool does *and* when
+   to reach for it (MCP clients rank tools by that text, so the trigger must not sit behind
+   return-shape prose); parameters are documented with `[Description]` **on the parameter**, not
+   in the tool description; result fields appear only where the caller must branch on them
+   before calling (`isEmpty`, `truncated`, `conflicts`, `available`); no design rationale or
+   "since this feature was introduced" history.
+
+4. `ExternalMcpExceptionFilter.Wrap` is registered as a call-tool filter so
+   `InvalidOperationException` / `ArgumentException` messages survive as `McpException` —
+   otherwise the SDK's catch-all replaces any non-`McpException` with a generic
+   *"An error occurred invoking 'X'."*
+
+## Tool classes
+
+### `ExternalMcpService` — task CRUD, execution, git
+
+Task: `ListTaskLists`, `ListTasks`, `GetTask`, `AddTask`, `AddSubtask`, `UpdateTask`,
+`UpdateTaskStatus`, `ReviewTask`, `RunTaskNow`, `ContinueTask`, `CancelTask`, `DeleteTask`.
+(`GetTaskStatusValues` was removed — a whole tool entry for static reference text. `GetTask`'s
+description is now the canonical place for what each status means.)
+
+Worktree/git: `GetTaskWorktree`, `GetTaskDiff`, `MergeTask`, `ContinueMerge`, `AbortMerge`,
+`PreviewMerge`, `PreviewMergeSet`, `RevertMerge`, `ListWorktrees`, `CleanupTaskWorktree`.
+
+Daily prep: `GetDailyPrepCandidates`, `SetMyDay`.
+
+### Other classes
+
+| Class | Tools |
+|---|---|
+| `BatchMcpTools` | `BatchGetTasks`, `BatchAddTasks`, `BatchUpdateTaskStatus`, `BatchCancelTasks`, `BatchDeleteTasks`, `BatchSetMyDay`, `BatchCleanupTaskWorktrees` |
+| `ListMcpTools` | `CreateList`, `UpdateList`, `DeleteList` |
+| `ConfigMcpTools` | `GetListConfig`, `SetListConfig`, `GetTaskConfig`, `SetTaskConfig`, `GetEffectiveRunConfig` |
+| `RunHistoryMcpTools` | `ListRuns`, `GetRun`, `GetTaskLog` |
+| `AgentMcpTools` | `ListAgents` |
+| `LifecycleMcpTools` | `ResetFailedTask` |
+| `AppSettingsMcpTools` | `GetAppSettings` (read-only) |
+| `TaskWaitMcpTools` | `WaitForTaskChange` |
+| `QueueStateMcpTools` | `GetQueueState` |
+| `AttachmentMcpTools` | `AddTaskAttachment`, `ListTaskAttachments`, `RemoveTaskAttachment` |
+
+## Per-tool behaviour worth knowing
+
+**`ListTasks`** — `includeDescription=false` (default) returns lean `TaskRefDto` references in
+`tasks` (`tasksFull` null); `includeDescription=true` returns full `TaskDto`s (incl.
+Description/Result) in `tasksFull` instead (`tasks` null). Filtering by `createdBy`/`status`
+happens before the lean/full projection either way.
+
+**`UpdateTaskStatus`** accepts `Idle` / `Queued` / `Cancelled` / `Done` only.
+- `Cancelled` goes through `TaskStateService.CancelAsync(..., allowFromIdle: true)` — the
+  **only** caller that opts into cancelling from `Idle`. `PlanningChainCoordinator` relies on
+  `Idle` staying a no-op there by default, because a child parked back to `Idle` mid-chain is
+  a manual opt-out signal.
+- `Done` goes through `TaskStateService.ForceSetStatusAsync` (the same unconditional write the
+  UI's "set status freely" affordance uses) but is **refused** for a task with an active
+  worktree, since that would skip `review_task`'s merge.
+
+**`AddTask`** — always creates the task; also returns `possibleDuplicates` (up to 3, id/title/status
+only, no descriptions) — open (non-terminal) tasks in the *same list* whose normalized title
+overlaps strongly with the new one. Cheap word-overlap heuristic (`ExternalMcpService`'s
+`FindPossibleDuplicatesAsync`/`NormalizeTitleWords`), no embeddings/LLM call, no blocking —
+the caller just gets a heads-up to relay. `BatchAddTasks` carries the same field per item.
+
+**`ReviewTask`** — `approve` / `reject_rerun` / `reject_park` / `cancel` for a
+`WaitingForReview` task. Approve is review+merge exactly like the hub's `ApproveReview`: unit
+merge for parents, worktree merge into optional `targetBranch` for childless tasks. Conflicts
+are reported in `ReviewTaskResult`.
+- A parent's approve also returns `emptyChildren`: the `Done` children about to be unit-merged
+  whose own review range contributed nothing (computed the same way as `PreviewMerge`'s
+  `isEmpty`, before the merge starts so it reflects what's about to be approved). Surfaces a
+  child that reported `CLAUDEDO_BLOCKED` and committed no code — previously that child reached
+  `Done` and merged silently with `changedFileCount: 0`, indistinguishable from a small-but-real
+  change. `TaskRefDto.roadblockCount` (on every task-returning tool, stamped by `TaskRunner` from
+  `result.Blocks.Count`) is the MCP-visible signal for *why* a child is empty.
+
+**`PreviewMerge`** — non-destructive `git merge-tree --write-tree` mergeability check for one
+task's worktree branch against `targetBranch` (default: the repo's current branch). Returns
+status / conflictFiles / changedFileCount / `behind` / `isEmpty`. Unlike
+`TaskMergeService.PreviewAsync`'s silent *"unavailable"*, this **throws a clear error** when the
+task has neither an active worktree nor a handler commit range, or the list's working dir is
+missing.
+- `isEmpty` = the review range contributed nothing — zero files changed against the worktree's
+  base commit, or (for a worktree-less list-handler host task) `HandlerBaseCommit ==
+  HandlerHeadCommit`. Distinguishes a genuinely empty branch from one that merely made a small
+  change (`changedFileCount: 0` alone reads as "tiny", not "nothing to review") — the gap that
+  let two blocked planning children reach `Done` with unmerged empty branches unnoticed.
+- A worktree-less handler task has no separate branch to `merge-tree`-preview (its commits
+  already sit in `list.WorkingDir`) — `PreviewMergeCoreAsync` falls back to a synthetic `clean`
+  preview over its own `HandlerBaseCommit..HandlerHeadCommit` diff-stat instead of throwing
+  "has no worktree".
+
+**`PreviewMergeSet`** — same preview for a batch (each entry also carries `isEmpty`), plus a
+file→tasks overlap report built from each task's own diff-stat. ⚠️ That overlap report is a
+**same-file-name hint only** — it is blind to cross-file collisions (e.g. the CS0103 case that
+motivated it). A task that fails to preview gets `error` set and is excluded from the overlap
+instead of aborting the batch.
+
+**`RevertMerge`** — undoes a previously merged task's merge commit on `targetBranch` via
+`git revert -m 1`. Always a **new commit**, never a reset/rewrite, because the target working
+directory is shared with other concurrent sessions.
+- Requires the task to be `Done` with a `Merged` worktree carrying a recorded
+  `WorktreeEntity.MergeCommit`. A task merged before that field existed has none and is
+  **refused rather than guessed** via `git log`.
+- On success the task returns to `WaitingForReview` and the worktree moves to `Kept` — not
+  `Active` (its directory/branch are typically already gone from the original merge's cleanup)
+  and not `Merged`/`Discarded` (`WorktreeMaintenanceService` sweeps those).
+- A conflicting revert is aborted immediately; no half-resolved state is left in the tree.
+
+**`BatchMcpTools`** — best-effort loops over the `ExternalMcpService` single-entity methods.
+**Sequential**, because the scoped `DbContext` is not thread-safe. Merge/review stay
+single-task. Every tool returns a per-item result array (`{ id/index, ok, error?, … }`) — a
+failing item never aborts the rest — and rejects batches over **100 items**.
+`BatchGetTasks` mirrors `ListTasks`'s `includeDescription` flag (default `false`): a found item's
+`BatchGetTaskResult` carries `task` (lean `TaskRefDto`) or `taskFull`, never both. `taskFull` is
+`BatchTaskDetailDto` — a batch-only shape, **not** `TaskDto` (`get_task` is untouched) — whose
+Description/Result are cut to `descriptionMaxChars` (default 1500, was unlimited) with
+`*Truncated`/`*FullLength` flagging it, and which `fields` (an optional name allow-list, e.g.
+`['title','roadblockText']`) can narrow further; unrequested fields come back `null`.
+`roadblockText` pulls just the bullet lines after `TaskRunner.ComposeReviewResult`'s roadblock
+marker out of `Result`, without needing the rest of it. The whole per-call response is also
+capped (`BatchMcpTools.MaxResponseChars`) — over that, the call throws naming which parameter to
+adjust instead of shipping an oversized payload (the incident that prompted this: 8 tasks'
+full Description/Result serialized to a single 51k-char line).
+
+**`GetTaskLog`** — latest run's log, tail-capped at 256 KB.
+
+**`WaitForTaskChange(taskIds, timeoutSeconds = 60, treatWaitingForChildrenAsBusy = false)`** —
+blocks until any given task leaves `Queued`/`Running`, or times out. Returns immediately for a
+task already outside those two (unknown ids reported as status `"NotFound"`, also immediate).
+- Implemented as an **async DB poll** (short-lived `DbContext` per check, 500 ms delay, no
+  held connection, no busy loop) rather than hooking `HubBroadcaster` — deliberately isolated
+  so it can't regress the existing broadcast callers.
+- `timeoutSeconds` is clamped server-side to `TaskWaitMcpTools.MaxTimeoutSeconds` (900 s),
+  comfortably under the `MCP_TOOL_TIMEOUT` (930 s) every ClaudeDo-owned claude launcher sets —
+  `ClaudeProcess` for headless queue runs, `InteractiveLaunchSpecService` for every embedded
+  ConPTY session (list handler, planning, interactive resume) — so the tool reports
+  `timedOut: true` instead of racing the client's own abort. A caller running claude with a
+  different (or default: 60 s) `MCP_TOOL_TIMEOUT` will still see its own client-side timeout
+  fire first; the server has no way to detect or compensate for that.
+- **`treatWaitingForChildrenAsBusy` pitfall (default `false`, backward-compatible):** a planning
+  parent with children goes `Running` → `WaitingForChildren` while children are still working,
+  and by default that already counts as "changed" (it's outside `Queued`/`Running`) — so waiting
+  on a parent returns immediately even though the unit isn't done. Set the flag to keep polling
+  through `WaitingForChildren`; the call then only reports changed once the parent reaches
+  `WaitingForReview` or a terminal status. Does not list or watch the parent's children —
+  callers still need their own ids for that.
+- Replaced the list handler's old "sleep + poll `get_task` in a loop" Phase 3 instruction.
+
+**`GetQueueState()`** — read-only snapshot so a caller doesn't have to infer queue state from
+`maxParallelExecutions` or repeated `wait_for_task_change` rounds:
+`{ configuredSlots, effectiveSlots, activeSlots: [{ slot, taskId, startedAt }], waitingTaskIds }`.
+- `configuredSlots`/`effectiveSlots` reuse `QueueService.GetSlotCountsAsync` — the same
+  configured-vs-throttled computation `QueueService.ExecuteAsync` uses each tick (see
+  [usage-monitoring](usage-monitoring.md) for the throttle staging) — so this tool can't drift
+  from the queue's actual refill decision.
+- `activeSlots` reuses `QueueService.GetActive()` (already the source for the Hub's `GetActive`):
+  `slot` is `"queue"` for a normal queue slot or `"override"` for the single
+  `run_task_now`/`continue_task` slot.
+- `waitingTaskIds` is a fresh read-only query mirroring `QueuePicker.ClaimNextAsync`'s
+  eligibility filter and order (`Queued`, unblocked, non-manual, due, `sort_order` then
+  `created_at`) — it does not claim or mutate anything.
+
+**`AttachmentMcpTools`** — re-attaching the same `fileName` overwrites. Add/remove refuse on a
+`Running` task.
+
+**`GetDailyPrepCandidates`** — Idle, non-blocked tasks in a git repo **not** excluded by
+`AppSettings.ReportExcludedPaths` and not already `IsMyDay`, plus the current Idle MyDay tasks
+and `maxTasks` (= `DailyPrepMaxTasks`). Repo-exclusion logic lives in the `DailyPrepFilter`
+helper in the same file.
+
+**`SetMyDay`** — sets `IsMyDay` (+ optional `SortOrder`). A server-side cap-guard rejects
+turning on MyDay beyond `DailyPrepMaxTasks` open (Idle) MyDay tasks.
+
+**`GetEffectiveRunConfig`** — read-only report of what a task will *actually* run with (model,
+max turns, effort, permission mode, agent path, whether a system prompt is set, skill names),
+each with its source (`task`/`list`/`preset`/`global`); max turns additionally reports the raw
+requested value and whether it was clamped to `AppSettings.MaxTurnsCeiling`. Unlike
+`GetAppSettings`/`GetTaskConfig` (raw, possibly-unused config values), this goes through the same
+`EffectiveRunConfigResolver.Resolve` that `TaskRunner` itself runs with — see
+[worker-task-pipeline](./worker-task-pipeline.md)'s model/effort/max-turns section — so it can't
+drift from the real run. Reads (not writes) `AppSettingsRepository.GetAsync`, which backfills
+`model_presets` on first read after a null column; that backfill is pre-existing shared behavior,
+not a new side effect introduced by this tool.
+
+## Model / max-turns on task creation
+
+Task-generating tools (`AddTask`, planning `CreateChildTask`, `SuggestImprovement`) accept an
+optional `model`, alias-validated via `ModelRegistry.NormalizeAlias` (`haiku`/`sonnet`/`opus`,
+blank = inherit), so Claude can assign the cheapest capable model at creation time — the
+planning/system/improvement prompts instruct it to do so, using
+`ModelRegistry.ByCostAscending` as the cost order.
+
+Planning's `CreateChildTask` **additionally** accepts an optional `maxTurns` (positive int;
+`0`/negative rejected with `ArgumentException`, null = inherit list/global default) so the
+planner can raise the turn budget for a subtask it knows will run long.
+`SuggestImprovement` and `AddTask` do **not** expose it.

docs/explore-notes/installer-preflight.md

@@ -0,0 +1,252 @@
+# Installer preflight: CLI version gate & environment checks
+
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `bdee731` (2026-08-05).
+> Drift check: `git log --oneline bdee731..HEAD -- src/ClaudeDo.Worker/Lifecycle/ClaudeCliPreflight.cs src/ClaudeDo.Worker/ClaudeDo.Worker.csproj src/ClaudeDo.App/ClaudeDo.App.csproj .gitea/workflows/release.yml src/ClaudeDo.Installer/Checks src/ClaudeDo.Data/Environment/ExecutableResolver.cs`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+## Implementation status (as of 2026-08-05)
+
+The research below (§1–5) led to an implementation, but it is **not on `main` yet** — it exists
+on two unmerged task branches:
+
+- `claudedo/06aca9b3afec4b939f59b627bfe21737` — `src/ClaudeDo.Installer/Checks/*`
+  (`GitCheck`, `GitIdentityCheck`, `WriteAccessCheck`, `PortCheck`, `ClaudeCliCheck`,
+  `ClaudeVersionCheck`, `ClaudeAuthCheck`, `PermissionModeAutoCheck`, `EnvironmentCheckService`,
+  `ClaudeCliLookup`) plus `SystemCheckPage` (the Fresh-Install wizard page hosting them) and its
+  own copy of `src/ClaudeDo.Data/Environment/ExecutableResolver.cs`.
+- `claudedo/40272c0bb3b14562b59c022d09c382b6` — the original `ExecutableResolver.cs`, plus wiring
+  it into `ClaudeDo.Worker`'s `ClaudeCliPreflight` and `ClaudeProcess` (the actual root-cause fix:
+  both used to spawn `claude` with `UseShellExecute = false` and no `.cmd`/`.bat` shim resolution,
+  so an npm-installed `claude.cmd` was invisible to the Worker even though it worked in a shell).
+
+The two branches were authored independently and each vendored its own copy of
+`ExecutableResolver.cs` (identical except `06aca9b3` adds a `FallbackDirectories()` diagnostic
+helper); merging both cleanly requires picking one copy, not literally running `git merge` twice.
+Two planned follow-up tasks — a "Claude Help Me" button and a Config-mode Diagnose section —
+never got past a blocked first step, precisely because this prerequisite work wasn't on `main`
+when they ran. See `Environment Checks` in `src/ClaudeDo.Installer/CLAUDE.md` and `docs/open.md`
+for the current gap and the manual verification checklist.
+
+What's confirmed as **matching the research below**: `ClaudeVersionCheck.MinimumVersion` is
+`2.1.220`, exactly the "verified-floor, not a proven minimum" constant from §3. `ClaudeAuthCheck`
+uses `claude auth status --json` exactly as recommended in §4, parsing only the `loggedIn` field.
+`PermissionModeAutoCheck` is the static "is `auto` listed in `--help`" check recommended in §2 —
+real org/model/plan eligibility is deliberately **not** checked, matching the recommendation not
+to build that (a real task run surfaces a startup rejection fast enough on its own). No .NET
+Desktop Runtime check was implemented as an `IEnvironmentCheck` (§5's registry-key detection
+remains a documented-but-unbuilt option, not currently gating anything).
+
+---
+
+Pure research, no code changed. Answers the five questions from the "Root Cause
+`--permission-mode auto`" task. Sources: the locally installed CLI (`claude --version` /
+`--help`), the official docs at `code.claude.com` (fetched 2026-08-05), and this repo's own
+csproj/workflow files.
+
+## 1. Why can `--permission-mode auto` fail?
+
+**It is very rarely a CLI-version problem.** Per the official permission-modes doc
+(`code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode`), auto mode
+requires **all** of:
+
+- **Plan**: any plan (Free/Pro/Max/Team/Enterprise) qualifies in principle.
+- **Organization**: on Team/Enterprise, on by default; an admin can disable it org-wide via
+  `permissions.disableAutoMode: "disable"` in managed settings. When disabled this way, the CLI
+  **"rejects `--permission-mode auto` at startup"** (verbatim from the doc) — not a runtime
+  fallback, a hard reject.
+- **Model**: on the Anthropic API / Claude Platform on AWS — Opus 4.6+, Sonnet 4.6+, or Fable 5.
+  On Bedrock / Vertex / Foundry / signed-in gateway sessions — only Sonnet 5, Opus 4.7+, Fable 5.
+  Older models (Sonnet 4.5, Opus 4.5, Haiku, claude-3-*) are **not supported on any provider**.
+  A per-org `availableModels` restriction that only allows an old model would silently make
+  auto mode unavailable even on a Team/Enterprise org that hasn't touched `disableAutoMode`.
+- **Provider opt-in (historical)**: on Bedrock/Vertex/Foundry/gateway, CLI **v2.1.158–v2.1.206**
+  required `CLAUDE_CODE_ENABLE_AUTO_MODE=1`; **v2.1.207** removed that requirement. This does
+  **not** apply to a normal claude.ai / Console (Anthropic API) login — only to those four
+  provider types.
+
+A separate, easy-to-hit trap: `defaultMode: "auto"` in **project or local** settings
+(`.claude/settings.json`, `.claude/settings.local.json`) is silently **ignored** since v2.1.142
+— it must live in `~/.claude/settings.json` (user scope). A repo that ships `defaultMode: auto`
+in its own `.claude/settings.json` will start in Manual mode with **no error at all**. This
+doesn't apply to ClaudeDo's case (it passes `--permission-mode auto` as an explicit CLI flag,
+not via a checked-in settings file), but is worth knowing if the failure mode was "silently
+starts in Manual" rather than "CLI errors out".
+
+Quoted from the docs, verbatim: *"If Claude Code reports auto mode as unavailable, one of these
+requirements is unmet; this is not a transient outage."*
+
+**Not verifiable**: which of the above actually hit the colleague — we have no diagnostic from
+their machine (no `claude auth status --json` output, no `claude --version`, no org name). Do
+not guess; if this recurs, capture `claude auth status --json` and `claude --version` from the
+affected machine before further debugging.
+
+## 2. How to reliably detect whether `auto` is supported
+
+**Static, cheap, always safe (no API call):**
+- `claude --version` — semver string, e.g. `2.1.220 (Claude Code)`.
+- `claude --help` — the `--permission-mode <mode>` line lists the accepted enum. Confirmed by
+  testing an invalid value locally:
+  ```
+  $ claude -p "test" --permission-mode bogus
+  error: option '--permission-mode <mode>' argument 'bogus' is invalid. Allowed choices are
+  acceptEdits, auto, bypassPermissions, manual, dontAsk, plan.
+  ```
+  This is validated by the CLI's arg parser (Commander.js) **before any network call** — exits
+  1 immediately. So checking that `auto` is one of the listed choices is a legitimate, free,
+  fast static check — but it only proves the *flag* is recognized, **not** that auto mode is
+  actually usable (org/model/plan gating happens later, at session start, not at arg-parse time).
+- `claude auth status --json` — cheap, local/fast, **does not send a prompt**. Returns:
+  ```json
+  { "loggedIn": true, "authMethod": "claude.ai", "apiProvider": "firstParty",
+    "email": "...", "orgId": "...", "orgName": "...", "subscriptionType": "team" }
+  ```
+  This is the answer to question 4 (see below) and also gives `subscriptionType`/`orgName` —
+  useful context but **still not a direct "is auto mode eligible" answer** (doesn't report the
+  active model or `disableAutoMode` policy).
+
+**No cheap subcommand exists for full eligibility.** Checked `claude auto-mode --help`: it only
+has `config` (effective auto-mode *rule* config — allow/deny lists, not eligibility),
+`defaults` (same, shipped defaults), `critique`, and `reset`. None report plan/model/org
+eligibility. `claude doctor` (non-interactive) does **not** report auto-mode eligibility either
+— it explicitly says *"For a full setup checkup that can also fix issues, run `/doctor` in a
+session"*; the in-session `/doctor` slash command is the one the docs say proposes
+`defaultMode: auto` when eligible, but that requires an interactive session, not a scriptable
+preflight.
+
+**Dynamic (real probe) is the only way to fully confirm eligibility**, and per the docs an
+org-disabled or otherwise-ineligible account **rejects at startup** (fast, before any model
+turn) — so a probe doesn't have to be a full expensive run. A minimal probe such as
+`claude -p "ok" --permission-mode auto --max-turns 1 --output-format json` would fail fast on
+ineligibility (reject at startup) but still costs one real turn + tokens on the success path,
+and still requires a working prompt/response round trip on the happy path. **Recommendation**:
+don't build this into an automated preflight; a static version+flag check plus `auth status`
+covers the reliably-detectable ground, and a real first task run will surface an auto-mode
+rejection immediately and cheaply (fails at startup, not mid-task) if it's actually unavailable.
+**Implemented as:** `PermissionModeAutoCheck` (Warning) — the static flag-listed check only.
+
+## 3. Minimum CLI version for the flags ClaudeDo uses
+
+Flags used (from `ClaudeArgsBuilder` per `src/ClaudeDo.Worker/CLAUDE.md`): `--permission-mode
+auto`, `--effort`, `--agents`, `--json-schema`, `--append-system-prompt`, `--output-format
+stream-json --verbose`, `--resume`, and (installer) `claude mcp add --transport http --scope
+user`.
+
+**Not verifiable precisely.** All eight of these are foundational, long-established flags.
+The official changelog (`raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md`)
+only retains roughly the last ~40 entries (oldest visible: `2.1.181`); auto mode itself, and
+`--json-schema`/`--resume`/`mcp add --transport` all clearly predate that window (the earliest
+found reference is a *bug fix* mentioning "sessions created before v2.1.85" for `--resume`,
+implying `--resume` existed well before 2.1.85). There is no accessible source that pins an
+"introduced in vX" date for any of these eight flags — guessing one would violate the task's
+explicit instruction not to invent a source-less root cause.
+
+What **is** sourced, from the docs fetched 2026-08-05:
+- `--json-schema` + invalid-schema handling: before v2.1.205, an invalid schema was silently
+  ignored (returned unstructured text); v2.1.205 made it a hard `Error: --json-schema is not a
+  valid JSON Schema` exit. Not a "does it exist" gate, but changes error-handling behavior
+  ClaudeDo might currently rely on failing loudly.
+- `--output-format stream-json --verbose` + `system/init.capabilities` array requires v2.1.205+
+  (absent before). Not currently consumed by ClaudeDo per the Worker CLAUDE.md's stream handling
+  description, so not a hard requirement today.
+- `system/init.mcp_server_errors` field requires v2.1.219+. Not currently consumed by ClaudeDo.
+- Manual-mode label/`manual` alias requires v2.1.200+ — irrelevant, ClaudeDo passes `auto`
+  explicitly, never `manual`.
+- Auto mode's Bedrock/Vertex/Foundry/gateway opt-in-env-var requirement was removed in v2.1.207
+  — irrelevant for a direct claude.ai/Console login (this machine: `apiProvider: "firstParty"`).
+
+**Decided constant** (see below) is therefore **the newest version we can positively confirm
+works end-to-end on this machine** (`2.1.220`), not a proven theoretical minimum — because no
+lower true minimum is derivable from available sources without guessing.
+**Implemented as:** `ClaudeVersionCheck.MinimumVersion = new Version(2, 1, 220)` (Error).
+
+## 4. Detecting "CLI is logged in" without sending a prompt
+
+`claude auth status --json` (confirmed working, instant, no API/model call):
+```json
+{ "loggedIn": true, "authMethod": "claude.ai", "apiProvider": "firstParty",
+  "email": "...", "orgId": "...", "orgName": "...", "subscriptionType": "team" }
+```
+This is the CLI's own maintained answer — cheaper and more robust than parsing
+`.credentials.json` directly (format may be internal/undocumented and is a hard-blocked file
+for this task's own tooling; the docs page confirms it lives at
+`%USERPROFILE%\.claude\.credentials.json` on Windows but say nothing about its schema being a
+stable public contract). `claude auth status --text` is available for a human-readable variant;
+`--json` is the default and the right one for a preflight to parse.
+**Implemented as:** `ClaudeAuthCheck` (Error) — parses only the `loggedIn` boolean; any other
+field, or a non-zero exit code, or unparseable JSON, becomes `Unknown` rather than `Failed`.
+
+## 5. .NET runtimes required by the published `app\` / `worker\` artifacts
+
+From `.gitea/workflows/release.yml` (the only build/publish pipeline in this repo) and the two
+csproj files:
+
+- **`ClaudeDo.App`** (`net8.0`, Avalonia, `WinExe`) — published via
+  `dotnet publish ... -r win-x64 --self-contained true`. **Self-contained**: bundles its own
+  .NET 8 runtime. **No .NET runtime needs to be pre-installed** on the target machine for the
+  app itself.
+- **`ClaudeDo.Worker`** (`net8.0`, `Microsoft.NET.Sdk.Web`, ASP.NET Core) — same treatment:
+  `-r win-x64 --self-contained true`. Also fully self-contained; no ASP.NET Core runtime needs
+  to be pre-installed.
+- **`ClaudeDo.Installer`** (`net8.0-windows`, WPF) is the one exception: published
+  `--self-contained false -p:PublishSingleFile=true` — **framework-dependent**. The csproj
+  comment explains why: *"the WPF runtime pack isn't distributed for cross-compile on Linux CI,
+  which made self-contained bundles crash on startup with AV in the apphost."* The target
+  machine **must** have the **.NET 8 Desktop Runtime (x64)** installed before running
+  `ClaudeDo.Installer.exe` — this is the actual runtime-preflight gap, not the app/worker.
+
+**How to check on a target machine**:
+- `dotnet --list-runtimes` — look for a `Microsoft.WindowsDesktop.App 8.0.x` line (Desktop
+  Runtime, required by the installer). Requires the `dotnet` CLI itself to be on PATH; not
+  guaranteed present on a fresh machine that never installed the SDK, only the runtime — in
+  that case `dotnet` may not exist at all even though the runtime DLLs do.
+- Registry fallback (works even without the `dotnet` CLI on PATH):
+  `HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.WindowsDesktop.App` —
+  each installed version is a subkey/value here. This is the standard documented detection
+  mechanism for .NET Desktop Runtime presence on Windows and is what most installer-detection
+  tooling (e.g. Squirrel, WiX bundles) uses instead of shelling out to `dotnet`.
+- **Not independently verified in this task**: the exact registry key shape wasn't inspected
+  live (would require reading `HKLM\SOFTWARE\dotnet\...` on this machine, which is standard
+  .NET installer-detection convention, but out of scope to screenshot/dump here since the task
+  is docs-only and this is a well-documented, non-project-specific Windows convention).
+  **Not implemented** as an `IEnvironmentCheck` — none of the shipped checks verify the Desktop
+  Runtime; if the Installer itself is running at all, .NET 8 Desktop Runtime is implicitly
+  present (framework-dependent publish would otherwise fail to launch).
+
+## Beschlossene Konstanten
+
+| Constant | Value | Confidence |
+|---|---|---|
+| Minimum CLI version | `2.1.220` | **Verified-floor, not a proven minimum.** This is the newest version confirmed installed and working end-to-end on a dev machine for every flag ClaudeDo uses. No lower true minimum could be sourced (see §3) — treat any lower value as a guess. |
+| Credentials file path | `%USERPROFILE%\.claude\.credentials.json` (Windows) | Sourced from official docs; content/schema not inspected (hard-blocked secrets file). |
+| Login-check command | `claude auth status --json` | Verified locally, instant, no model call. Fields: `loggedIn`, `authMethod`, `apiProvider`, `email`, `orgId`, `orgName`, `subscriptionType`. |
+| App/Worker runtime requirement | **None** — self-contained win-x64 publish | Sourced from `.gitea/workflows/release.yml`. |
+| Installer runtime requirement | **.NET 8 Desktop Runtime (x64)** must be pre-installed | Sourced from `.gitea/workflows/release.yml` comment + `ClaudeDo.Installer.csproj`. |
+
+## Erkennungsstrategie pro Check
+
+| Check | Type | Command | Expected pass output | Implemented as |
+|---|---|---|---|---|
+| git present + version | static | `git --version` (via `ExecutableResolver`) | resolves, exit 0 | `GitCheck` (Error) |
+| git identity set | static | `git config --get user.name` / `user.email` | both non-empty | `GitIdentityCheck` (Warning) |
+| install dir + data dir writable | static | probe-file write/delete | succeeds | `WriteAccessCheck` (Error) |
+| SignalR/ExternalMcp ports free | static | `TcpListener` bind probe + owning-process lookup | free, or owned by running `ClaudeDo.Worker` | `PortCheck` (Warning) |
+| CLI present + version | static | `claude --version` | `X.Y.Z (Claude Code)`; parse and compare `X.Y.Z >= 2.1.220` | `ClaudeCliCheck` (Error) / `ClaudeVersionCheck` (Error) |
+| `auto` recognized as a flag value | static | `claude --help` (or trigger the parse error path) | `--permission-mode <mode>` help text lists `auto` among the choices | `PermissionModeAutoCheck` (Warning) |
+| CLI logged in | static/cheap | `claude auth status --json` | exit 0, `loggedIn: true` | `ClaudeAuthCheck` (Error) |
+| Auto mode actually eligible (org/model/plan) | **not statically detectable** | none exists | N/A — see §2; don't build this, let a real task run surface a fast startup rejection instead | not implemented (by design) |
+| .NET Desktop Runtime present (installer only) | static | `dotnet --list-runtimes` (if `dotnet` on PATH) or registry `HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.WindowsDesktop.App` | a `Microsoft.WindowsDesktop.App 8.0.x` entry exists | not implemented (see §5) |
+| App/Worker runtime present | **not needed** | — | self-contained, nothing to check | not implemented (not needed) |
+
+## Not verifiable (explicit)
+
+- The actual root cause on the colleague's machine — no diagnostic data was captured from it.
+- Exact stderr/exit-code wording the CLI prints when auto mode is rejected at startup for an
+  ineligible org/model (docs state the *behavior* — "rejects `--permission-mode auto` at
+  startup" — but not the literal message; this machine's account is eligible, so it couldn't be
+  reproduced locally).
+- A true (not just "newest confirmed") minimum SemVer for `--effort`, `--agents`,
+  `--json-schema`, `--append-system-prompt`, `--resume`, `claude mcp add --transport http
+  --scope user` — all predate the retrievable changelog window.
+- Live inspection of the `HKLM\SOFTWARE\dotnet\Setup\InstalledVersions` registry shape on this
+  machine (documented Windows convention, not independently screenshotted here).

docs/explore-notes/list-virtualization-spike.md

@@ -0,0 +1,114 @@
+# List virtualization spike (Phase 2a gate)
+
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `6a2a19c` (2026-08-10).
+> Drift check: `git log --oneline 6a2a19c..HEAD -- src/ClaudeDo.Ui/Views/Islands/TasksIslandView.axaml src/ClaudeDo.Ui/Views/Islands/TasksIslandView.axaml.cs src/ClaudeDo.Ui/Views/Controls/TaskDragController.cs`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+Gate task for [ui-reaktivitaet-und-listen-performance-design](../superpowers/specs/2026-08-07-ui-reaktivitaet-und-listen-performance-design.md)
+Phase 2, Risk 1. Answers the five open questions before any rework of the real
+`TasksIslandView`/`TasksIslandViewModel`. No production code changed for this spike.
+
+## Method
+
+A throwaway Avalonia-headless xUnit test (`Avalonia.Headless` + `Avalonia.Themes.Fluent`,
+temporarily added to `ClaudeDo.Ui.Tests`, removed again after this report was written — not
+committed) built a plain `ListBox` with an explicit `VirtualizingStackPanel` and 1000 mixed
+items (≈14% "complex" two-line/badge rows, mirroring the 68px/90–110px split from the design
+doc), then drove it programmatically: forced layout/render passes, scrolled the `ScrollViewer`,
+called the same `TopLevel.InputHitTest` the production drag code uses, and counted realized
+`ListBoxItem` containers via the visual tree. No screenshots — every number below came from an
+actual headless run of that harness on 2026-08-10.
+
+One harness-only wrinkle: `InputHitTest` walks the **compositor's rendered scene**, not just the
+layout tree, so the test had to call `window.CaptureRenderedFrame()` after each layout-affecting
+change before hit-testing. A real windowed app renders every frame continuously, so this isn't a
+production concern — noted here only so the method is reproducible.
+
+## Q1 — Does a virtualized `ListBox` actually bound the number of realized containers at 1000 items?
+
+**Geht.** Realized `ListBoxItem` count stayed at 22–23 across the whole scroll range (top, 25%,
+50%, 75%, bottom) with 1000 source items in the list:
+
+```
+realized containers @ top:        22
+realized containers @ 25% scroll: 22
+realized containers @ 50% scroll: 22
+realized containers @ 75% scroll: 23
+realized containers @ 100% scroll: 22
+```
+
+Matches the design doc's estimate (~19 visible + overscan ≈ 22–25) almost exactly. The
+`ListBox`/`VirtualizingStackPanel` combination genuinely recycles containers instead of building
+one per item.
+
+## Q2 — Does the existing ghost-drag `InputHitTest` model survive container recycling?
+
+**Geht.** Scrolled from top to 60% (forcing recycling), then called `TopLevel.InputHitTest` at the
+*same screen point* both times — exactly what `RowButtonAt`/`ListItemUnder` in
+`TasksIslandView.axaml.cs` do live during a drag:
+
+```
+hit-test @ top, screen point (450,600):        Task[8]
+hit-test @ 60% scroll, same screen point:      Task[577]
+expected DataContext at that point (geometry): Task[577]
+```
+
+The hit-test result matches the geometrically-correct row after recycling, and correctly changed
+(it did *not* keep returning the stale top-of-list row). The production pattern —
+`topLevel.InputHitTest(pt)` then walk ancestors to the row `Button`/`ListBoxItem` — is
+recycling-safe: it's a live geometric query against whatever is currently realized, with no
+per-row state to go stale.
+
+## Q3 — Variable row heights (68px vs 90–110px): does the scrollbar/`Extent` estimate drift?
+
+**Geht, mit einer Einschränkung.** Measured actual template heights in this harness: header
+57px, simple task row 53px, complex (two-line + badges) row 90px. Hand-summing all 1000 rows by
+their real measured height gives 58275px; `VirtualizingStackPanel`'s reported `Extent.Height` was
+58228px — **0.1% error**. Avalonia's own extent bookkeeping for variable-height virtualized rows
+is not the "gross estimate that drifts" risk the design doc worried about.
+
+The real risk is a **hand-rolled** pixel↔index conversion. Scrolling to `index * 68px` (a naive
+"assume every row is 68px" offset) while targeting logical row #700 actually landed on row
+**#790** — a 90-row drift, because ~14% of the preceding rows were taller. Anything that
+computes a scroll offset from `index * fixedRowHeight` (a natural shortcut for a "scroll to
+selected row" or a custom auto-scroll speed curve) will misfire. The existing
+`ScrollSelectedIntoView` in `TasksIslandView.axaml.cs` already avoids this trap — it finds the
+realized control by `DataContext` and calls `BringIntoView()`, not index-times-height math. Phase
+2b must keep using `ListBox.ScrollIntoView(item)` / `Control.BringIntoView()`, never index
+arithmetic, for any "jump to row" behavior.
+
+## Q4 — Is auto-scroll-while-dragging feasible with the existing central-pointer-handler model?
+
+**Geht.** Auto-scroll doesn't exist today and has to be built, but the mechanism it needs — the
+same UI-thread pointer-moved handler (or a `DispatcherTimer` it starts) mutating
+`ScrollViewer.Offset` directly while a drag is in progress — was exercised directly: nudging
+`Offset` by 400px in one synchronous step kept the realized-container count constant (22 before,
+22 after) and an immediate subsequent `InputHitTest` at the same screen point resolved correctly
+to the new row under the cursor (`Task[388]`), with no async delay or stale state. Since
+`TasksIslandView`'s drag handlers already run on the UI thread via tunnelled pointer events, a
+`DispatcherTimer` (or a direct `Offset` nudge inside `OnPointerMovedDrag` when the cursor is near
+the list's top/bottom edge) has no threading obstacle. This still needs to be built in Phase 2b;
+this spike only confirms the approach isn't blocked by virtualization/recycling.
+
+## Q5 — Mixed item types (header rows vs. task rows) via a template selector, under virtualization
+
+**Geht.** Used `ListBox.DataTemplates` with two `FuncDataTemplate<T>` entries keyed by type
+(`HeaderRow` / `TaskRow`) instead of an explicit `IDataTemplate.Match` selector — Avalonia's
+implicit per-type template lookup is the idiomatic equivalent and needs no selector class. Both
+types showed up among the realized containers throughout scrolling
+(`Q5 distinct realized DataContext types: HeaderRow, TaskRow`), confirming the design's flat
+`Rows` (`HeaderRow | TaskRowViewModel`) collection will virtualize and template correctly.
+
+## Recommendation for Phase 2b
+
+**Geht — proceed**, with two carry-overs into the implementation:
+
+1. Any "scroll to row" logic (selection scroll, auto-scroll speed/targeting) must go through
+   `ScrollIntoView`/`BringIntoView` against the realized control, never `index * rowHeight` math
+   (Q3).
+2. Auto-scroll is new work, not a retrofit risk — build it as an `Offset` nudge from the existing
+   UI-thread drag handlers (Q4).
+
+No evidence surfaced against the Phase 2 design as written. The `ITaskListFilter` risk (#3 in the
+design doc) is unrelated to virtualization and out of this spike's scope.

docs/explore-notes/review-merge.md

@@ -0,0 +1,280 @@
+# Review, merge & conflict resolution
+
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against `fc9df7f` (2026-08-11), which added the conventional merge-commit default
+> and the `MergeProgress` broadcast.
+> Planning mode renders per file and `DiffLinesView` is retired.
+> Drift check: `git log --oneline 20bce9b..HEAD -- src/ClaudeDo.Worker/Lifecycle src/ClaudeDo.Worker/State src/ClaudeDo.Worker/Planning src/ClaudeDo.Ui/ViewModels/Conflicts src/ClaudeDo.Worker/External`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+Covers the review→merge path: `TaskStateService` review transitions, `TaskMergeService`,
+`PlanningMergeOrchestrator`, the post-merge verify gate, and the UI conflict resolver.
+
+## Approve = merge the whole unit
+
+`ApproveReview` (hub) and `review_task` approve (MCP) are the **single** review+merge action.
+There is no separate "Merge all" entry.
+
+- **Task with children** → drives `PlanningMergeOrchestrator`: merges the parent worktree if
+  `Active`, then each `Done` child in order, then sets the parent `Done`. A mid-merge conflict
+  pauses for `ContinuePlanningMerge` / `AbortPlanningMerge`.
+- **Childless task** → `TaskMergeService.ApproveAndMergeAsync`. A conflict keeps the task in
+  `WaitingForReview`.
+- **No active worktree** (sandbox run) → straight to `Done`.
+
+Review transitions all live in `TaskStateService`: `SubmitForReviewAsync`,
+`SubmitForChildrenAsync`, `ApproveReviewAsync`, `RejectToQueueAsync`, `RejectToIdleAsync`,
+`ClearReviewFeedbackAsync`.
+
+`ReviewFeedback` (nullable string on `TaskEntity`) is the reviewer's rejection comment: set by
+`RejectToQueueAsync`, consumed and cleared by `QueueService` on the next re-run, where it
+becomes the next-turn prompt of the resumed Claude session.
+
+## Unified parent model
+
+Every parent — planning **or** improvement — flows
+`… → WaitingForChildren → WaitingForReview → Done`, advanced by the single
+`TaskStateService.TryAdvanceParentAsync`. It surfaces any `WaitingForChildren` parent for
+review once all children are terminal; failed/cancelled children are **annotated on the
+result, not wedged**.
+
+- A planning parent enters `WaitingForChildren` at `FinalizePlanningAsync` (or
+  `WaitingForReview` directly if it has no children).
+- An improvement parent enters it from `TaskRunner.HandleSuccess` when its run spawned children.
+- Planning/improvement **children** go straight to `Done` — no individual review. Only the
+  parent is reviewed.
+
+A child that hits a roadblock (fails, or reports `CLAUDEDO_BLOCKED` roadblocks) does **not**
+advance the parent — the parent stays in `WaitingForChildren` until every child is terminal.
+The UI surfaces blocked children on the parent's Session tab (`ChildOutcomes` + a "children
+need attention" band) so the roadblock is visible without forcing a transition.
+
+A blocked planning/improvement child still goes straight to `Done` per the unified parent model
+above — it committed nothing, but nothing prevents its (empty) branch from being unit-merged
+like any other `Done` child once the parent is approved. The MCP surface has no UI equivalent of
+`ChildOutcomes`, so `review_task`'s approve on a parent additionally returns `emptyChildren` (the
+`Done` children whose review range is empty) and every task-returning tool exposes
+`TaskRefDto.roadblockCount` → [external-mcp.md](external-mcp.md) → `ReviewTask`/`PreviewMerge`.
+An empty branch is still mergeable by design (some tasks — e.g. an audit — legitimately produce
+no diff); this is a visibility fix, not a merge gate.
+
+## Cancel is blocked while a unit merge is draining
+
+`ApproveReview` on a task with children awaits `PlanningMergeOrchestrator.StartAsync` /
+`DrainAsync` synchronously — the parent sits in `WaitingForReview` for the whole (potentially
+minutes-long, one-child-at-a-time) drain. Without a guard, a concurrent `CancelReview` (UI or
+`update_task_status`/`cancel_task` via MCP) could flip the parent to `Cancelled` mid-drain while
+the orchestrator kept merging children's worktrees onto the target branch; `FinalizeParentDoneAsync`
+then finds the parent no longer `WaitingForReview` and gives up, leaving the merged children's
+diffs stranded with no rollback.
+
+`TaskStateService.CancelAsync` now rejects with a `TransitionResult` reason whenever
+`PlanningMergeOrchestrator.HasActiveMerge(taskId)` is true for the task being cancelled, before any
+DB write. Cycle note: `TaskStateService` can't take a direct constructor dependency on
+`PlanningMergeOrchestrator` (which itself depends on `ITaskStateService`), so it takes a lazily-resolved
+`Func<IActiveMergeState>` instead — same cycle-breaking shape as the existing `Func<ITaskStateService>`
+handed to `PlanningChainCoordinator`. `IActiveMergeState` (`Planning/Interfaces/`) is `PlanningMergeOrchestrator`'s
+only public surface `TaskStateService` needs.
+
+The UI mirrors this as polish: `DetailsIslandViewModel.IsMergeDraining` (set on
+`PlanningMergeStartedEvent`, cleared on `PlanningMergeAborted`/`PlanningCompleted` for the bound
+task) gates `CancelReviewCommand`'s `CanExecute` — same shape as `WorktreesOverviewModalViewModel.IsMerging`
+gating `CanMergeAll`. The worker-side guard remains the actual correctness fix; the button gate
+just avoids inviting a click the worker would reject. `CancelReviewAsync`'s catch now raises
+`ErrorReported` (→ shell `FlashFooterError`) instead of swallowing the rejection silently.
+
+## Merge commit message
+
+`MergeAsync` takes a `commitMessage`, but **every caller passes it blank** and lets
+`TaskMergeService.DefaultMergeMessage` build `CommitMessageBuilder.BuildMerge(task.CommitType,
+list.Name, task.Title, task.Id)` → `fix(my-list): merge <title>` + `ClaudeDo-Task:` trailer. Same
+`type(scope)` shape as the task's own worktree commits, so merges stay Conventional-Commits-clean.
+The only non-blank caller is the user editing the field in the merge modal, which is prefilled from
+`GetMergeTargets().DefaultCommitMessage` (the UI can't build it — it knows neither the commit type
+nor the list name). Callers used to hand-roll `"Merge task: {title}"` / `"Merge {branch}"` /
+`"Merge subtask"`; don't add a fourth.
+
+## Post-merge verify gate
+
+A list can set `ListConfigEntity.VerifyCommand` (List Settings modal → Verification).
+Null/blank (the default) = **no gate**, behavior bit-identical to before the feature existed.
+
+When set, `TaskMergeService` runs it via `VerifyCommandRunner` (`cmd.exe /c <command>`,
+10-minute fixed timeout, output tail-captured) in `list.WorkingDir` right after a successful
+`MergeNoFfAsync` / `ContinueMergeAsync` **and** worktree cleanup, but **before** the task is
+allowed to reach `Done`.
+
+| Outcome | Effect |
+|---|---|
+| Exit 0 | Unchanged flow — worktree `Merged`, task `Done` if it was `WaitingForReview`. |
+| Non-zero exit or timeout | The git merge is **deliberately left in place** (no auto-revert — that's a separate, unbuilt feature). The worktree is still marked `Merged` (it's already gone from disk when `removeWorktree` was requested), but the task stays out of `Done`. |
+
+On failure `MergeResult.Status` comes back `TaskMergeService.StatusVerifyFailed`
+(`"verify_failed"`) with an output excerpt in `ErrorMessage`. This flows through
+`MergeResultDto` (hub) and `ReviewTaskResult` (`review_task`) unchanged, because both already
+treat any non-`blocked`/`conflict` status generically. All three UI merge entry points handle it
+explicitly (detail-pane Approve, merge modal, worktrees batch) — a generic fallback there showed
+the raw status string instead of the failure.
+
+**Worktree-less approvals are gated too.** A task with no active `WorktreeEntity` — a sandbox run,
+or a list-handler task that commits straight into `list.WorkingDir` — skips the merge entirely,
+but `ApproveAndMergeAsync` still runs the verify command (same per-repo gate, working dir =
+`list.WorkingDir`) before the task may reach `Done`. Without that, the run that lands the most on
+the target branch at once would be the one run nothing checks.
+
+**The gate is what makes a merge look broken.** A verify command that builds and tests a solution
+occupies the whole `MergeTask` hub call — measured at ~5m 46s on this repo. `TaskMergeService`
+therefore broadcasts `MergeProgress(taskId, phase, elapsedSeconds)`: `PhaseMerging` before the
+per-repo gate wait, `PhaseVerifying` when the verify starts and again on every
+`ProgressReportInterval` tick (30 s, shared with the MCP progress reports), plus one
+`WorkerLog` Info line so the footer strip shows it too. The merge modal renders that as a spinner
+plus phase text; without it the only feedback was the disabled Submit button, which reads as a
+dead app for minutes while the merge has in fact already landed.
+
+**Serialization:** a process-wide `ConcurrentDictionary<string, SemaphoreSlim>` keyed by
+`list.WorkingDir` serializes `MergeAsync` / `ContinueMergeAsync` (git ops + verify) per repo,
+so a verify run can't be interrupted by a second merge landing in the same working dir
+mid-build.
+
+### Verify in the preview, not just post-merge
+
+`TaskMergeService.PreviewAsync(taskId, targetBranch, runVerify, ct)` can additionally build/test a
+clean `git merge-tree` result *before* anything is merged. It never touches the real working tree:
+the tree `PreviewMergeAsync` would write is wrapped in a throwaway commit
+(`GitService.CommitTreeAsync`, parent = the target branch's current tip) and checked out into a
+detached-HEAD scratch worktree under the OS temp dir (`GitService.WorktreeAddDetachedAsync`), which
+is always removed afterward (`finally`, non-cancellable cleanup). No verify command configured, or
+`runVerify=false`, reproduces the pre-existing preview exactly — no delay, no scratch worktree.
+
+Wired into `ExternalMcpService`: `preview_merge` (single task) always requests a verify run when the
+list has a command configured; `preview_merge_set` only does when its `runVerify` parameter is
+explicitly set (default `false`) — a set preview never starts N builds unasked. The Hub's
+`PreviewMerge` (the UI's live mergeability indicator) always passes `runVerify: false`, since
+running a build on every poll would be a bad regression; `MergePreviewDto` carries the
+verify fields anyway so a future UI entry point can opt in. Result fields: `VerifyExitCode` (null =
+not run; `-1` = timed out or failed to start; mirrors the post-merge gate's convention),
+`VerifyDurationMs`, `VerifyOutputTail` (tail of output, only populated on non-zero exit, via the
+same `TailOutput` helper the post-merge gate uses).
+
+## `MergeCommit` and revert
+
+`WorktreeEntity.MergeCommit` (nullable) is the SHA of the merge commit this worktree's branch
+produced on the target branch. Stamped by `TaskMergeService` the moment a merge/continue-merge
+succeeds, written **only** by `WorktreeRepository.SetMergedAsync` (which atomically sets
+`State=Merged` and stamps the SHA in one update).
+
+It is the only thing that makes `revert_merge` possible without heuristically searching
+`git log` — see [external-mcp.md](external-mcp.md) → `RevertMerge`. Null for any worktree
+merged before the field existed.
+
+## Review gate in the UI
+
+**Approve & Merge is gated behind opening the diff.** When there is something to inspect
+(worktree diff / merged range / children combined diff), the button stays disabled until the
+diff or combined-diff viewer has been opened once. The gate **re-locks per run** — any state
+change resets it. Tasks with nothing to inspect are never gated.
+
+The row-level quick-approve in the task list is an **intentional bypass**.
+
+Implementation: `MergeSectionViewModel` owns merge-target selection, the mergeability
+indicator (`MergePreviewPresenter` over `PreviewMergeAsync`), and `OpenDiffAsync` /
+`ReviewCombinedDiffCommand` — both build a `DiffViewerViewModel`, call `ShowDiffViewer`, and
+fire the `DiffViewed` callback. `HasReviewableDiff` reports whether anything is inspectable
+and feeds the gate.
+
+## Conflict resolver (in-app Rider-style 3-pane merge editor)
+
+`ConflictResolverViewModel` + `Views/Conflicts/ConflictResolverView`. Handles **both**
+single-task and planning unit-merge conflicts.
+
+### Model
+
+Single-task mode starts the conflict merge, then parses each conflicted file into stable and
+conflict `MergeFileSegment`s via the worker's `GetMergeConflictDocuments`. Types live in
+`ConflictModels`: `MergeFile` / `MergeFileSegment` / `MergeConflictBlock`.
+
+Exposed per active file: `ActiveOursText` / `ActiveResultText` / `ActiveTheirsText`
+(reconstructed from `MergeFile.OursText/ResultText/TheirsText`; Result seeds unresolved
+conflicts with Ours), plus `ActiveFile` / `SelectFileCommand` (multi-file switcher),
+`Current` / `Next` / `Previous` (focused-conflict nav), a per-file `PositionText` readout,
+per-block `AcceptOurs/Theirs/Both/Base` + `MergeFile.Compose`, and `CanContinue` gated on
+**every file resolved + no binary**. Each file is written via `WriteConflictResolution`.
+
+**Planning mode** via `OpenForPlanningAsync(parentId, subtaskId)` loads the current subtask's
+mid-merge conflicts **without re-starting the merge** and routes continue/abort to
+`ContinuePlanningMerge` / `AbortPlanningMerge`, so a unit-merge conflict re-opens the editor
+per subtask via the `PlanningMergeConflict` broadcast.
+
+**Except when an MCP session is driving the merge.** `PlanningMergeOrchestrator.StartAsync` takes
+an `externallyDriven` bool (default `false`; `ExternalMcpService.review_task`'s parent-with-children
+path passes `true`, since a running Claude session — not the UI — will resolve conflicts via
+`continue_merge`/`abort_merge`). The flag rides along on the `PlanningMergeConflict` broadcast
+(4th arg); `IslandsShellViewModel.OnPlanningMergeConflict` only auto-opens the resolver when it's
+`false` — otherwise it shows a persistent, non-auto-dismissing banner
+(`IsExternalMergeBannerVisible`) with a manual "Open resolver" button, cleared on
+`PlanningMergeAborted`/`PlanningCompleted`. This exists because two parties (a human and the
+driving session) could otherwise end up editing the same shared checkout at once.
+`PlanningMergeOrchestrator.GetActiveExternalConflictsAsync` (hub: `GetActiveExternalPlanningMergeConflicts`)
+re-derives this state by checking `GitService.IsMidMergeAsync` rather than trusting the in-memory
+flag alone, so a UI restart mid-merge (or a stale entry left behind if something resolved the
+repo outside the normal Continue/Abort path) can't show a phantom banner — the Ui calls it on
+`ConnectionRestoredEvent`. The childless single-task conflict path
+(`TaskMergeService.ApproveAndMergeAsync`) has no equivalent broadcast — it only sends the generic
+`TaskUpdated` — so it never auto-opened the resolver and needed no change.
+
+### View
+
+Three **AvaloniaEdit** panes showing the whole file: MAIN/ours (read-only) | editable Result |
+INCOMING/theirs (read-only). TextMate highlighting by extension (theme `StyleInclude` in
+`App.axaml`).
+
+- A code-behind `IBackgroundRenderer` tints each conflict block (unresolved/resolved) across
+  panes. Tints live in `Tokens.axaml` (`Merge*TintBrush`).
+- An `IReadOnlySectionProvider` + `TextAnchor` regions keep **only conflict spans** editable in
+  Result; edits flow back to the block.
+- Each unresolved conflict starts **EMPTY** (a thin marker bar).
+- The between-pane gutter controls **toggle** each side in/out of the result: `›`/`‹` add
+  MAIN/INCOMING in click order (first pick on top), clicking again removes that side — so a
+  conflict can take main, incoming, both, or **neither**.
+- `FilesSummary` shows how many files still have conflicts. The three panes share a
+  proportional synced vertical scroll.
+- A conflict overview ruler right of the Result pane (`ConflictMap`) maps every conflict in the
+  file proportionally; click a tick to jump. Useful for long files.
+
+### Entry points
+
+Review **Approve** on conflict, and the **Merge** button in the Diff window (a conflicting
+`MergeTask` hands off via `RequestConflictResolution`).
+
+## Hub methods
+
+- Review/merge: `ApproveReview(taskId, targetBranch) -> MergeResultDto`,
+  `ContinuePlanningMerge` / `AbortPlanningMerge`, `PreviewMerge(taskId, targetBranch) ->
+  MergePreviewDto`, `RejectReviewToQueue`, `RejectReviewToIdle`, `CancelReview`, `MergeTask`,
+  `GetMergeTargets`
+- Single-task conflict resolver: `StartConflictMerge`, `GetMergeConflictDocuments`,
+  `WriteConflictResolution`, `ContinueConflictMerge`, `AbortConflictMerge` — note the
+  service-level `TaskMergeService.ContinueMergeAsync` / `AbortMergeAsync` keep their own names.
+- Broadcast events: `PlanningMergeStarted`, `PlanningSubtaskMerged`, `PlanningMergeConflict`,
+  `PlanningMergeAborted`, `PlanningCompleted`
+
+## Diff stack (UI)
+
+`UnifiedDiffParser` (static) parses `git diff` output into `DiffFileViewModel`s, detecting
+added/deleted/renamed/binary files and per-line numbers. `DiffModels.cs` holds the shared types
+(`DiffLineViewModel`, `DiffFileViewModel`, `DiffLineKind`, `DiffFileStatus`, `SubtaskDiffRow`,
+`DiffTreeNodeViewModel`, `DiffTree`).
+
+`DiffViewerViewModel` is one unified read-only viewer with two modes:
+- **Files** — dirty worktree / branch-vs-base / commit-range. Loads via `GitService`, folder
+  file-tree left + per-file diff pane right, Merge button for a live branch source.
+- **Planning** — per-subtask diffs via `GetPlanningAggregateAsync`, subtask list left + one
+  editor per file right (`PlanningFiles`), combined integration-branch toggle.
+
+Both modes render through `DiffAlignment` (pure — pairs diff lines into side-by-side rows and
+computes word-diff spans) and `DiffTextView` (AvaloniaEdit + TextMate highlighting keyed off the
+file extension, unified/split layout, optional line wrap, synced scrolling). Files mode hosts one
+`DiffTextView` for the selected file; Planning mode hosts one per file in `PlanningFiles` so each
+gets its own grammar (one editor can only carry one TextMate grammar). The split/wrap toggles
+persist to `ui.config.json` via `AppSettings` and reach the per-file editors in Planning mode
+too.

docs/explore-notes/usage-monitoring.md

@@ -0,0 +1,181 @@
+# Usage monitoring, gate & throttle
+
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `f6cb825` (2026-08-05), plus the uncommitted per-bucket-throttle /
+> draggable-gauge change of 2026-08-06 (this note already describes that newer state).
+> Drift check: `git log --oneline f6cb825..HEAD -- src/ClaudeDo.Worker/Usage src/ClaudeDo.Worker/Queue src/ClaudeDo.Ui/ViewModels/UsagePillViewModel.cs`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+Covers `src/ClaudeDo.Worker/Usage/`, the queue's throttle/gate integration, per-run token
+accounting, and the UI surfaces (usage pill + usage monitor modal).
+
+## Data source
+
+`GET https://api.anthropic.com/api/oauth/usage` — an **undocumented** Anthropic endpoint,
+authenticated with the Bearer access token Claude Code itself keeps fresh at
+`~/.claude/.credentials.json`. ClaudeDo reads that token, never refreshes it, never logs it.
+
+Because the endpoint is undocumented and can change without notice, **every consumer
+fails open**. That is the single most important invariant here.
+
+## Components (`Usage/`)
+
+| Type | Role |
+|---|---|
+| `UsageModels` | `UsageBucket` / `UsageLimitRow` / `UsageSnapshot`. `UsageBucket.Utilization` is already a 0–100 percent — compare directly against thresholds, don't rescale. |
+| `ClaudeOAuthUsageClient` | Reads the token, calls the endpoint. Defensive parsing: missing/null buckets → null, missing `limits` → empty list. |
+| `UsageState` | Threadsafe singleton. A failed poll **never** overwrites the last good snapshot — it only sets `LastError`. |
+| `UsageMonitorService` | `BackgroundService`; polls on `usage_poll_interval_seconds` (default 60, clamped to min 15 on config load), one poll at startup. Logs a failure at most once per distinct error message. Broadcasts `HubBroadcaster.UsageUpdated` after **every** tick, success or failure. |
+| `UsageSnapshotBuilder` | Builds the Hub-facing `UsageSnapshotDto` from `UsageState` + `IUsageGate` + `AppSettings`. The one shared place for stale/threshold/gate logic — `WorkerHub.GetUsageSnapshot` and `UsageMonitorService` must not diverge. |
+| `UsageGate` | Hard pause decision → `UsageGateDecision(IsBlocked, Reason)`. |
+| `UsageThrottle` | Pure static staging of parallelism ahead of the gate. |
+| `TranscriptUsageReader` | Aggregates token usage from Claude Code transcripts. |
+
+Interfaces in `Usage/Interfaces/`: `IUsageClient`, `ITranscriptUsageReader`, `IUsageGate`.
+
+## The gate (hard pause)
+
+Thresholds: `AppSettings.UsageGateFiveHourPct` / `UsageGateSevenDayPct` (defaults 80/90).
+Blocked once `five_hour >= UsageGateFiveHourPct` **or** `seven_day >= UsageGateSevenDayPct`
+(`>=`, not `>`). Threshold `0` = that bucket never gates.
+
+What it pauses: **only the queue's slot-fill loop** — new queued tasks don't start.
+Unaffected: already-running runs, `RunNow`, `ContinueTask`, interactive ConPTY sessions,
+planning sessions, daily prep (all bypass the queue).
+
+**Fail-open**: no snapshot yet, a failed last poll, or an app-settings read error all
+resolve to not-blocked.
+
+There is **no persistent pause state**. Recovery is just the queue's 30 s backstop timer
+(`queue_backstop_interval_ms`) re-evaluating the gate on its own once usage drops back
+under the threshold. A blocked↔free transition is logged and broadcast (`WorkerLog`, Warn
+on block / Info on resume) exactly **once per change**, not every tick.
+
+## The throttle (staged parallelism)
+
+`UsageThrottle.EffectiveSlots(configuredSlots, fiveHourPct, fiveHourThresholds, sevenDayPct,
+sevenDayThresholds)` — pure static, no state. `UsageThresholds(SoftPct, HardPct, GatePct)` is the
+per-bucket triple (same file).
+
+Thresholds are **per bucket** (`usage_throttle_five_hour_{soft,hard}_pct` /
+`usage_throttle_seven_day_{soft,hard}_pct`, defaults 50/65 each) because the 5h and 7d windows fill
+at very different rates. Each bucket is staged independently and the **strictest** bucket wins —
+not "whichever is more utilized", so a bucket that is lower but tightly configured can be the one
+that throttles:
+
+| Utilization (per bucket) | That bucket's slots |
+|---|---|
+| below soft | full configured `max_parallel_executions` |
+| `>= softPct` | capped at 2 |
+| `>= hardPct` | capped at 1 |
+| `>= gatePct` | 0 — same hard block as `UsageGate` |
+
+A threshold of `0` disables that stage for that bucket, and a bucket with no reading (null) never
+throttles. The `0` return is deliberately kept in sync with `UsageGate`'s hard block because both
+read the same gate thresholds — change one, change both.
+
+Only **new** slot fills are affected; a run already occupying a slot when the stage tightens
+runs to completion. Same fail-open policy: no snapshot means no throttling.
+
+The effective stage (configured vs. effective slots + the decisive bucket, `ThrottleBucket`
+= `"five_hour"` / `"seven_day"`) rides along on `UsageSnapshotDto` purely for UI display.
+It does **not** change what the gate gates on.
+
+## Queue integration (`Queue/QueueService`)
+
+Per loop tick:
+
+1. `GetEffectiveMaxParallelAsync` reads `AppSettings.MaxParallelExecutions` and steps it
+   down via `UsageThrottle.EffectiveSlots` against the current `UsageState` snapshot.
+   A missing/failed snapshot fails open to the configured value. A **stage change** (not
+   every tick) logs once.
+2. Separately, `IUsageGate.EvaluateAsync` — if blocked, the slot-fill loop is skipped
+   entirely for that tick.
+
+## Per-run token accounting
+
+`task_runs` stores four raw token fields: `tokens_in` / `tokens_out` /
+`cache_read_tokens` / `cache_write_tokens`.
+
+These are **not** read from the stream-json `result` event's `usage.input_tokens` — that is
+only the uncached remainder of a single API call and undercounts the real prompt size by
+orders of magnitude once caching kicks in.
+
+Instead `TaskRunner.ApplyUsageAsync` calls
+`ITranscriptUsageReader.ReadSessionTotalsAsync(sessionId)` — the session transcript's
+cumulative raw totals across every assistant message, located by `{sessionId}.jsonl` — and
+stores the **delta** against prior `task_runs` rows sharing the same `session_id`, so a
+`--resume`'d run doesn't double-count turns already billed to an earlier run.
+
+A missing/unreadable transcript leaves all four fields `null`; it never fails the run.
+
+### `TranscriptUsageReader` details
+
+Reads `~/.claude/projects/**/*.jsonl`, aggregating by date / model / scope (ClaudeDo vs
+Other), deduped by `requestId`, with a per-file length+mtime cache.
+
+`ReadAsync` **skips any file whose mtime predates the window start minus one day** — it cannot hold
+a record inside the range, and the full history is large (measured 2026-08-06: 501 files / 230 MB /
+77k lines ≈ 1.7 s to parse cold; a 7-day range touches ~190 files / ~106 MB). The one-day slack
+absorbs local-vs-UTC skew between mtime and record timestamps. `ReadSessionTotalsAsync` is
+unaffected — it looks up a single `{sessionId}.jsonl`.
+
+`<synthetic>`-model lines are skipped **everywhere** — they are not real API calls.
+
+## UI surfaces
+
+- **`UsagePillViewModel`** — one shared instance backs the `UsagePill` control in both the
+  footer and the Mission Control header. Loads via `GetUsageSnapshotAsync`, updates live off
+  `IWorkerClient.UsageUpdatedEvent`. Dot state priority is mutually exclusive:
+  **blocked > stale > warn > normal**. `IsThrottled` (effective slots below configured, and
+  not gate-blocked) adds a tooltip line naming effective/configured slots + decisive bucket.
+  The pill's click handler (`IslandsShellViewModel.OpenUsageMonitor`) **shows the window before
+  loading** (`BeginLoad`) — awaiting the load first made the pill feel like a dead click, because
+  the first `GetModelUsage` per worker process scans the whole transcript history.
+- **Draggable stage markers** — each of the two real gauges carries three markers (soft/hard/gate).
+  `UsageGaugeBar` (`Views/Controls`) draws them against its own width and does the pointer work;
+  the math is a pure static, `UsageThresholdDrag` (in the modal VM's file), which keeps
+  soft ≤ hard ≤ gate and treats a neighbour of `0` as off. Release fires the row's
+  `CommitCommand` → read-modify-write via `GetAppSettings` + `UpdateAppSettings`, so only the
+  dragged bucket's three fields change. Plan-dependent `weekly_scoped` gauges are read-only.
+- **Legend = numeric editor.** Under each adjustable bar sit three legend rows whose colour swatches
+  match the markers (soft `TextDimBrush`, hard `StatusReviewBrush`, gate `StatusErrorBrush`), each
+  with a `NumericUpDown`. `NumericUpDown` has no commit command, so the box's `Tag`
+  (`soft`/`hard`/`gate`) plus two code-behind handlers (`LostFocus`, Enter) call the row's
+  `CommitSoft`/`CommitHard`/`CommitGate` command. Those run the typed value through the **same**
+  `UsageThresholdDrag.Apply` clamp as a drag, so a box can't invert the order and only the edited
+  stage moves. ⚠️ The `KeepLastNumber` converter is mandatory on those bindings — see the
+  `NumericUpDown` null gotcha in `src/ClaudeDo.Ui/CLAUDE.md`.
+  Rows are updated **in place** on each snapshot (keyed by limit kind) so a poll landing mid-drag
+  doesn't replace the bound instance.
+- **`UsageMonitorModalViewModel`** — opened from the pill. Renders one gauge **per row** in
+  `UsageSnapshotDto.Limits` — deliberately **dynamic**, because the `seven_day_opus` /
+  `seven_day_sonnet`-style buckets the raw API returns are plan-dependent and come back
+  `null` on plans that don't have them; a fixed gauge layout would break. Also shows model
+  usage (`GetModelUsageAsync`, ClaudeDo-vs-Other split per model) and top-task usage
+  (`GetTaskUsageAsync`) over a 7d/30d preset or custom range.
+
+## Hub surface
+
+- `GetUsageSnapshot() -> UsageSnapshotDto` — percentages/limits/`FetchedAtUtc` are null and
+  `IsStale=true` when no snapshot has landed yet. `IsStale` also trips on a failed last poll
+  or a snapshot older than 3× `usage_poll_interval_seconds`.
+- `GetModelUsage(from, to)` — thin wrapper over `ITranscriptUsageReader.ReadAsync`.
+- `GetTaskUsage(from, to)` — top consumers from `task_runs` joined to task/list, grouped per
+  task. Null token columns count as **0**, never drop the row. `Model` comes from that task's
+  most recent run. Sorted by total tokens descending, capped at 100.
+- `UsageUpdated` event carries the same `UsageSnapshotDto`.
+
+## Settings columns
+
+`app_settings`: `usage_gate_five_hour_pct` / `usage_gate_seven_day_pct` (80/90),
+`usage_throttle_five_hour_{soft,hard}_pct` / `usage_throttle_seven_day_{soft,hard}_pct` (50/65 per
+bucket). All six clamped 0..100 by `AppSettingsRepository.UpdateAsync`, which does **not** enforce
+soft ≤ hard ≤ gate — the ordering is a UI-side drag constraint, and an out-of-order stored config
+degrades instead of throwing. Worker config: `usage_poll_interval_active_seconds` /
+`usage_poll_interval_idle_seconds`.
+
+The gate percentages are editable in **two** places that both write the same `app_settings` row:
+Settings → General (typed) and the usage-monitor gauges (dragged). The throttle stages are
+gauge-only — `SettingsModalViewModel` therefore carries them load→save verbatim so saving Settings
+can't reset a dragged value.

docs/explore-notes/worker-task-pipeline.md

@@ -0,0 +1,177 @@
+> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
+> Last verified against commit `cc90600` (2026-08-06).
+> Drift check: `git log --oneline cc90600..HEAD -- src/ClaudeDo.Worker`
+> Stable structure only (no line numbers). See docs/explore-notes/README.md.
+
+# Worker: Task Execution Pipeline
+
+How a task moves Queued → Running → terminal, across `src/ClaudeDo.Worker`
+(Queue, Runner, Lifecycle, State, Agents, Worktrees, Hub).
+
+## End-to-End Flow (Queued → Terminal)
+
+1. **Enqueue** — `ITaskStateService.EnqueueAsync()` (State/TaskStateService.cs)
+   - Idle → Queued, then wakes the dispatcher via `IQueueWaker.Wake()`.
+
+2. **Dispatch** — `QueueService` loop (Queue/QueueService.cs)
+   - `BackgroundService`; waits for a wake signal or a backstop timer.
+   - Reads the max-parallel limit from settings; claims a free slot if under limit.
+
+3. **Atomic Claim** — `IQueuePicker.ClaimNextAsync()` (Queue/QueuePicker.cs)
+   - Raw SQL `UPDATE ... RETURNING` in one transaction: picks an eligible Queued task
+     (unblocked, due or unscheduled; sorted by sort_order/created_at), sets status→Running
+     + started_at, returns the row. Prevents two workers claiming the same task (TOCTOU).
+
+4. **Slot Execution** — `QueueService.RunInSlotAsync()` (Queue/QueueService.cs)
+   - For review feedback: resume the prior session if one exists, else fold feedback into
+     the prompt. Calls `TaskRunner.RunAsync()` / `ContinueAsync()` with `alreadyClaimed=true`.
+
+5. **Run Preparation** — `TaskRunner.RunAsync()` (Runner/TaskRunner.cs)
+   - Loads task, list config, subtasks, attachments from the DB.
+   - `StartRunningAsync()` (only if not pre-claimed): atomic claim to Running, **before any
+     resource is created**. A rejected claim (task already Running) bails out immediately —
+     no worktree, no MCP token file. Broadcasts TaskStarted.
+   - `PrepareRunDirectoryAsync()`: worktree (via WorktreeManager) if the list has a WorkingDir,
+     else sandbox. Generates a per-run MCP token, writes MCP config to disk.
+
+6. **Claude Execution** — `TaskRunner.RunOnceAsync()` (Runner/TaskRunner.cs)
+   - Creates a TaskRunEntity, points the task at the run's log path.
+   - Builds claude CLI args (ClaudeArgsBuilder), spawns the process via `IClaudeProcess.RunAsync()`
+     with prompt + working dir + streaming callback.
+   - Stream lines → NDJSON log + broadcast via TaskMessage. MCP tools (AskUser, SuggestImprovement)
+     are scoped by the per-run token.
+
+7. **Result Handling** — `TaskRunner.HandleSuccess()` / `MarkFailed()` (Runner/TaskRunner.cs)
+   - Success (exit 0 + result markdown): if worktree, commit + broadcast WorktreeUpdated; then
+     transition to Done / WaitingForReview / WaitingForChildren (CompleteAsync / SubmitForReviewAsync
+     / SubmitForChildrenAsync).
+   - Failure: if a session exists, auto-retry once via ContinueAsync; else MarkFailed → FailAsync.
+   - All terminal writes use `CancellationToken.None` so a task is never left Running.
+
+8. **Terminal States** — `ITaskStateService` transitions (State/TaskStateService.cs)
+   - **Done** CompleteAsync (Running → Done) — top-level success.
+   - **WaitingForReview** SubmitForReviewAsync (Running → WaitingForReview) — review gate.
+   - **WaitingForChildren** SubmitForChildrenAsync (Running → WaitingForChildren) — blocks on children.
+     Advances to WaitingForReview via `TryAdvanceParentAsync` once every remaining child is
+     terminal (Done/Failed/Cancelled) — including zero children left, e.g. after the last child
+     is deleted (`WorkerHub.DeleteTask` / `ExternalMcpService.DeleteTask` both call it).
+   - **Failed** FailAsync (Running/Queued → Failed).
+   - **Cancelled** CancelAsync (Running/Queued/WaitingForReview/WaitingForChildren → Cancelled).
+
+## Model, effort & max-turns resolution
+
+*(section added at commit `f6cb825`, 2026-08-05; resolver extraction added same day)*
+
+The resolution below lives in `Runner/EffectiveRunConfigResolver.Resolve` (not inlined in
+`TaskRunner` anymore) so `TaskRunner.ResolveConfigAsync` and the read-only
+`get_effective_run_config` MCP tool (`External/ConfigMcpTools.cs`) share one codepath and can't
+report different numbers for the same task. The tool additionally surfaces, per field, whether
+it came from the task/list/preset/global layer, and — for max turns — the raw requested value
+plus whether it was clamped.
+
+Step 6 builds the CLI args. Model and turn budget resolve like this:
+
+1. **Effective model** — task override → list config → `AppSettings.DefaultModel`.
+2. **Preset row** — `ModelPresets.For(global.ModelPresets, model, global.DefaultMaxTurns)`.
+   The model string is resolved through `ModelRegistry.TryNormalizeAlias` **first**, so a full
+   CLI model id (e.g. `claude-sonnet-4-6`, not just the bare `sonnet`/`opus`/`haiku`/`fable`
+   aliases) still hits its alias's preset row instead of missing every lookup. Only a model
+   that normalizes to nothing recognized falls back to a synthesized row using
+   `AppSettings.DefaultMaxTurns` — **never a hardcoded number, and it never throws**: an
+   unknown model must not block a run.
+3. The preset supplies `--effort` and the **global** max-turns default. Task/list `MaxTurns`
+   overrides still win over it.
+4. **Ceiling clamp** — `TaskRunner.ResolveMaxTurns` hard-clamps the resolved value to
+   `AppSettings.MaxTurnsCeiling` (default 80). An override above the ceiling still starts, just
+   capped, and a Warn logs the task id + requested + effective value.
+
+⚠️ **Trap:** if `app_settings.model_presets` is somehow null, the fallback path decides the turn
+budget — which is why `AppSettingsRepository.GetAsync` backfills shipping defaults on the first
+read after null. Ship preset turns are low (haiku 20, sonnet 30, opus 40, fable 25), so a task
+that genuinely needs a long run must set its own `MaxTurns`.
+
+Prompt composition: `TaskPromptComposer.Compose` injects attachment **absolute paths** as a
+read-only "## Reference files" section.
+
+## Component Responsibilities
+
+**Queue/**
+- `QueueService` — main dispatch loop; slot limit; decides when to start tasks.
+- `QueuePicker` — atomic Queued→Running claim via raw SQL.
+- `QueueWaker` — semaphore for non-blocking, idempotent wake signals.
+- `OverrideSlotService` — owns the RunNow / ContinueTask slot (bypasses the queue).
+
+**Runner/**
+- `TaskRunner` — orchestrates the run (prepare, execute, handle result).
+- `WorktreeManager` — creates/manages git worktrees; self-heals stale branches.
+- `ClaudeProcess` — spawns the claude CLI subprocess; manages streams/logs.
+- `TaskRunMcpService` — runtime MCP tools (AskUser, SuggestImprovement).
+- `TaskRunTokenRegistry` — per-run MCP identity for tool-access control.
+- `InteractiveLaunchSpecService` — config for the task's claude run.
+
+**State/**
+- `TaskStateService` — all task status transitions; guards preconditions; signals queue/hub.
+
+**Lifecycle/** (startup recovery)
+- `StaleTaskRecovery` — tasks stuck Running after a crash/restart → Failed. The underlying
+  `TaskStateService.RecoverStaleRunningAsync` bulk-flips Running→Failed, then re-runs the same
+  chain/parent-advance side effects as a normal `FailAsync` (per recovered id, best-effort) so a
+  crash mid-chain-child or mid-improvement-child doesn't leave a successor blocked forever or a
+  `WaitingForChildren` parent wedged.
+- `OrphanRecovery` — dequeues children whose parent is no longer planning (stays attached).
+- `AttachmentOrphanRecovery` — cleans orphaned attachment files.
+- `TaskResetService` — manual reset to Idle.
+- `TaskMergeService` — conflict resolution for worktree merges.
+
+**Hub/**
+- `HubBroadcaster` — single SignalR broadcast point (TaskStarted/TaskUpdated/TaskMessage/WorktreeUpdated…).
+- `WorkerHub` — SignalR hub + client methods.
+
+**Agents/**
+- `AgentFileService` — file I/O for custom agents.
+- `DefaultAgentSeeder` — seeds built-in agents on startup.
+
+**Worktrees/**
+- `WorktreeMaintenanceService` — cleanup, state tracking, overview reporting.
+
+## Entry Points & Call Chain
+
+```
+Program.cs (DI setup)
+ ├─ QueueService (BackgroundService) → ExecuteAsync loop
+ │   ├─ waits: IQueueWaker.WaitAsync() or timer
+ │   ├─ claims: IQueuePicker.ClaimNextAsync()
+ │   └─ runs:  TaskRunner.RunAsync() / ContinueAsync()
+ ├─ Hub clients → WorkerHub methods
+ │   ├─ Enqueue     → ITaskStateService.EnqueueAsync() → Wake()
+ │   ├─ RunNow      → OverrideSlotService.RunNow()      → TaskRunner.RunAsync()
+ │   ├─ ContinueTask→ OverrideSlotService.ContinueTask()→ TaskRunner.ContinueAsync()
+ │   └─ CancelTask  → QueueService.CancelTask()
+ ├─ Lifecycle recovery (startup): StaleTaskRecovery / OrphanRecovery / AttachmentOrphanRecovery
+ └─ State transitions → HubBroadcaster.TaskUpdated()
+```
+
+## Invariants & Conventions
+
+- **Atomic claiming** — QueuePicker's `UPDATE ... RETURNING` makes Queued→Running atomic.
+- **Slot limit** — respects MaxParallelExecutions; a backstop timer wakes even if a Wake() is missed.
+- **Pre-claimed tasks** — the dispatcher pre-claims via the picker; the override slot
+  (RunNow/ContinueTask) must call StartRunningAsync if a task is not pre-claimed.
+- **Claim before create** — `TaskRunner.RunAsync`'s unclaimed path calls `StartRunningAsync`
+  *before* `PrepareRunDirectoryAsync`. RunNow racing the picker for the same Queued row used to
+  create the worktree first and only claim afterwards, so the losing dispatch could hit
+  WorktreeManager's branch-collision self-heal and force-remove the winner's live worktree
+  mid-run. `OverrideSlotService.RunNow` also fast-rejects a task already Running in the DB
+  (defense in depth; the picker's atomic SQL claim is the real arbiter either way).
+  `RunCancellationRegistry.Register` refuses (and logs) a second registration for the same task
+  id instead of silently overwriting the first, so a losing dispatch's cleanup can't unregister
+  the winner's CTS out from under it.
+- **Terminal writes** — use `CancellationToken.None`; a task is never left Running after crash/cancel.
+- **Per-run MCP tokens** — each run gets a unique token scoping tool access; unregistered on end.
+- **Auto-retry** — one automatic retry if a session exists and the first run failed.
+- **Worktree self-heal** — on branch collision, remove phantom worktrees, prune, delete branch, retry add.
+- **Review feedback** — stored on the task; consumed once a run reaches a terminal state; a re-queued
+  task resumes the session or folds feedback into the prompt.
+- **Child tasks** — planning creates draft children; finalization requires no Queued children remain;
+  OrphanRecovery dequeues children if the parent is not planning.
+- **Lifecycle recovery** runs at startup: stale-Running → Failed; orphaned children → dequeued but attached.

docs/fix-plan-2026-07-24.md

@@ -0,0 +1,189 @@
+# Fix-Plan — Verifikations-Findings (Stand 2026-07-24)
+
+Einstiegspunkt für eine **frische Fix-Session**. Sammelt die in der manuellen Verifikation
+(§7–§9 + Kanten §1/§3/§4) gefundenen Probleme, gruppiert nach **Fixbarkeit**. Volltext je
+Finding (mit Kontext/Wiederholschritten) steht in `docs/open.md`; hier steht der Fix-Blick:
+Root-Cause, konkreter Ansatz, Loc/Test-Hinweise, und **welche Punkte vor der Umsetzung eine
+Entscheidung brauchen**.
+
+**Immer zuerst:** file:line-Angaben gegen den aktuellen Code prüfen (können minimal driften).
+Build/Test-Regeln + Gotchas s. Projekt-`CLAUDE.md` (u.a. `.slnx` braucht .NET 9 → einzelne
+`.csproj -c Release`; Localization.Tests erzwingt en/de-Parität; Subagents `sonnet`, Dateien
+pfad-scoped stagen). Pro Fix ein Conventional Commit.
+
+---
+
+## Bearbeitungsstand (Session 2026-07-24, nicht gepusht)
+
+**Erledigt & committed:**
+- Gruppe A #1–5 + beide Optional-Nits (Icon.Plus gefüllt, Gear-PathIcon, Skills-Empty-State,
+  „Subtasks"-Terminologie, Conflict-Continue-Hinweis, Rename-Darstellung, Turns/Tokens-Reload).
+- Gruppe B #7 (Resume-Fehler surfacen) + #8 (Attachment-Drop-Diagnose).
+- Gruppe C #9 (AskUser-Banner in Detail-Insel via geteiltem `TaskMonitorViewModel`),
+  #11 (OUTCOME zeigt `summary` statt rohem JSON: Worker-Unwrap + UI-Sicherheitsnetz).
+- Gruppe D #13 (Kind-Rows live-refresh bei Parent-Planning-Transitionen) + #14 (Idle-Chip auf
+  Planning-Parents ausgeblendet). *Visual-Verification für #13 (Finalize/Discard live) offen.*
+
+**#6** war im aktuellen Code bereits abgedeckt (Worker wirft `HubException` bei `blocked`
+→ UI-Dialog); zusätzlich als ClaudeDo-Task `f9809a93` erfasst. Nicht angefasst.
+
+**Offen:**
+- **#10 + #12** — bewusst gebündelt mit dem ConPTY-Planning-Task `5d627df8` (dort lässt sich
+  die Session-Id sauber greifen bzw. das MCP-Permission-Verhalten klären). Sofort-Schutz für
+  #10 (Resume ausgrauen wenn keine Id) wurde NICHT gebaut — bräuchte Worker-Plumbing, das der
+  ConPTY-Umbau ohnehin liefert; der #7-Fix verhindert bereits das stille Scheitern.
+- **Gruppe E** — nur noch design-/feature-behaftete Punkte. Der scheinbare Quick-Win
+  „Dequeue-X auf blockierten Kettengliedern" wurde bewusst NICHT umgesetzt: einzelnes Dequeue
+  eines Kettenglieds hinterlässt hängende Nachfolger (deren `BlockedByTaskId` zeigt weiter auf
+  das nun idle Glied) → braucht Chain-Repair-Design.
+
+---
+
+## Gruppe A — Mechanisch, sofort fixbar (keine Entscheidung nötig)
+
+Ideale Kandidaten für den Start / parallele Subagents (disjunkte Dateien).
+
+1. **„New session"-Button unsichtbar (Icon.Plus strich-only)**
+   `IslandStyles.axaml` (`Icon.Plus` = `M12 5v14M5 12h14`, reine Linie) wird in einem
+   `<PathIcon>` (MissionControlView.axaml, füllt Geometrie) unsichtbar gerendert.
+   **Fix:** `Icon.Plus` als gefüllte Geometrie authoren ODER als gestricheltes `Path`
+   rendern (vgl. `Path.plan-icon`). **Andere `Icon.Plus`-Verwendungen mitprüfen.**
+
+2. **Agent-Settings-Gear weicht vom Listen-Gear ab**
+   `TaskHeaderBar.axaml:68` rendert `<TextBlock Text="⚙">`; überall sonst `Icon.Settings`
+   (PathIcon, IslandStyles.axaml:110). **Fix:** den `⚙`-TextBlock durch
+   `<PathIcon Data="{StaticResource Icon.Settings}" Width=".." Height=".."/>` ersetzen.
+
+3. **Session-Skills-Tab ohne Empty-State**
+   Bei 0 Skills nur nackte Fläche. **Fix:** Empty-State-Text unter der Install-Zeile
+   (z.B. „No skills installed — paste a GitHub URL above"). **Loc:** neue Keys in en.json
+   **und** de.json (Parität!). Datei: `SessionSkillsSettingsTab*`.
+
+4. **„Waiting for Improvements" für Planning-Parents (Terminologie)**
+   `en.json` `taskStatus.waitingForChildren`/`agentStatus.children`/`childOutcomesLabel`
+   sagen „Improvements". Seit unified-parent gilt `WaitingForChildren` auch für Planning.
+   **Fix:** auf neutrales „Waiting for Subtasks"/„Subtasks"/„SUBTASKS" umstellen — en **und**
+   de (Parität).
+
+5. **Conflict-Resolver: Continue-Button klickbar trotz offener Konflikte**
+   Merge passiert korrekt erst nach Auflösung, aber der Button ist nicht disabled → früher
+   Klick = stummer No-op. **Fix:** `CanContinue`/`AllResolved` an `IsEnabled` binden (ggf.
+   Hinweis „N Konflikte in M Dateien offen"). Datei: `ConflictResolverView(.axaml)` +
+   `ConflictResolverViewModel`.
+
+Optional-Nits (gleiche Gruppe, niedrige Prio):
+- **Diff-Viewer Rename schwach dargestellt** (alt→neu-Pfad + „renamed"-Label statt „+0 −0").
+- **Header-TurnsText `0/max`** bei terminalem Reload — `Turns` aus `task_runs.turnCount`
+  restaurieren.
+
+---
+
+## Gruppe B — Error-Surfacing (klare Richtung: kein stiller/leerer Fehlerpfad)
+
+Leitlinie `feedback_ui_error_surfacing`: User-Action-Fehler in den Footer
+(`FlashFooterError`) bzw. Dialog, nie leerer `catch`/stiller No-op.
+
+6. **Approve & Merge schluckt „blocked" still**
+   `DetailsIslandViewModel.ApproveReviewAsync` reagiert nur auf `Status == "conflict"`; bei
+   `"blocked"` (z.B. dirty Ziel-Tree) passiert nichts. **Fix:** bei `blocked`/unerwartetem
+   Status `result.ErrorMessage` surfacen. *(Als ClaudeDo-Task `f9809a93` erfasst — koppelt
+   „Approve erzwingt Diff/Review vor Merge".)*
+
+7. **„Resume planning session" verschluckt den Fehler (Teil-Fix hier, Rest → Gruppe C #10)**
+   `TasksIslandViewModel.ResumePlanningSessionAsync` (~Zeile 870) hüllt alles in `catch { }`.
+   **Sofort-Fix:** den Fehler surfacen statt schlucken. Der eigentliche Resume-Defekt braucht
+   eine Entscheidung → #10.
+
+8. **Attachments: intermittenter erster-Drop-Fehler („An error occurred")**
+   Einmalig beobachtet (erster Drop der Session, nichts persistiert), nicht reproduzierbar.
+   **Fix (diagnostisch):** `AddFilesAsync`/`OnDrop` robustes Error-Logging geben (die genaue
+   Exception fehlt, weil `DropStatus` nur `{fileName}: {ex.Message}` zeigt) — damit der
+   nächste Fall auswertbar ist. Kandidaten-Ursachen: SQLite-Contention (UI schreibt `todo.db`
+   direkt, während der Worker sie hält) oder Drop-Stream-Pfad (`IStorageFile.OpenReadAsync`
+   im Code-Behind, außerhalb des `try`).
+
+---
+
+## Gruppe C — Erst Entscheidung/Brainstorm, DANN umsetzen (nicht blind fixen)
+
+9. **AskUser-Interaktion auch in der Detail-Insel** *(von Mika ausdrücklich gewünscht)*
+   Der `ask_user`-Banner + Inline-Antwort existiert nur in Mission Control
+   (`MonitorPaneView`); die Detail-Insel zeigt für den laufenden Task nichts.
+   **Entscheidung:** wie den Zustand teilen — `TaskMonitorViewModel` hält ihn bereits; für
+   die Detail-Insel replizieren, teilen, oder ein gemeinsames Banner-Control? Danach:
+   Banner + `AnswerDraft`/`SubmitAnswer` in `DetailsIslandView(Model)` einhängen.
+
+10. **„Resume planning session" grundsätzlich kaputt (Session-Id nie erfasst)**
+    `PlanningSessionManager.ResumeAsync:238` wirft immer „No Claude session ID captured yet",
+    weil `TaskRepository.UpdatePlanningSessionIdAsync:322` **keinen Aufrufer** hat →
+    `planning_session_id` bleibt NULL. **Entscheidung:** (a) claude-Session-Id der
+    wt-Planning-Session erfassen + via `UpdatePlanningSessionIdAsync` persistieren (echtes
+    Resume) ODER (b) Resume entfernen/deaktivieren, wenn keine Id vorliegt. Hängt mit der
+    Design-Entscheidung „Planning über embedded ConPTY statt wt" zusammen (ClaudeDo-Task
+    `5d627df8`) — dort ließe sich die Session-Id sauber greifen.
+
+11. **OUTCOME-Karte rendert rohes Structured-Output-JSON**
+    `TaskMonitorViewModel.ApplyOutcome` setzt bei Tasks ohne Roadblock `SessionOutcome`
+    = `task.Result` wörtlich; der Worker legt dort rohes `{"summary":…}` ab.
+    **Entscheidung:** (a) UI parst JSON-Result und zeigt `summary`, oder (b) Worker schreibt
+    `summary`/`resultMarkdown` statt JSON in `task.Result`.
+
+12. **Planning-Session prompted nach MCP-Tool-Permission**
+    Trotz `--allowedTools "mcp__claudedo__*,…"` + `--permission-mode plan` prompted die
+    wt-Planning-Session beim ersten `create_child_task`. **Untersuchen/Entscheiden:** matcht
+    der `mcp__claudedo__*`-Glob in CLI 2.1.207 nicht (Syntax evtl. ganzer Server-Name), oder
+    gated Plan-Mode MCP-Writes generell? Gekoppelt an ConPTY-Planning-Task `5d627df8`.
+
+---
+
+## Gruppe D — Erst Root-Cause pinnen (Investigation)
+
+13. **Kind-Rows aktualisieren nach Parent-Planning-Transitionen nicht live**
+    Nach **Finalize** bleiben Kind-Badges „Draft" statt „Planned"; nach **Discard** bleiben
+    die (in der DB gelöschten) Kind-Rows sichtbar — bis Listen-Reload. Doppelt verifiziert §3.
+    **Untersuchen:** wie wird die Kinderliste/-gruppierung auf ein Parent-`TaskUpdated`
+    reagierend neu aufgelöst? Vermutlich fehlt ein Regroup/Refetch der Children beim
+    Parent-Broadcast (`TasksIslandViewModel` hierarchie-Regrouping). Fix danach: Children bei
+    Parent-Transition live neu auflösen.
+
+14. **Planning-aktiver Parent zeigt weiter „Idle"**
+    Parent `planning_phase=active` hat `Status=Idle` (korrekt im Modell), aber der Row-Chip
+    zeigt „Idle"; `PlanningBadge` überschreibt das nicht sichtbar. **Untersuchen/Design:** ein
+    klarer „Planning/Draft aktiv"-Zustand, der den Idle-Chip überschreibt. (Verwandt mit #13 —
+    Row-Statusdarstellung.)
+
+---
+
+## Gruppe E — UX-Nits / Feature-Wünsche (niedrige Prio, sammeln)
+
+- **Conflict-Resolver: mehrere Konfliktdateien schlecht erkennbar** — prominentere Datei-Liste
+  / „x von y Dateien".
+- **Blocked-by-Kette nicht visualisiert** — Reihenfolge/Abhängigkeit darstellen
+  („wartet auf <Vorgänger>").
+- **Dequeue-„X" fehlt auf blockierten Kettengliedern** — `CanRemoveFromQueue` erweitern
+  (`IsWaiting` einschließen).
+- **„Open ConPTY session" erneut = Prompt wird neu gesendet** — Resume-Affordance / Re-Open-
+  Warnung (bewusst kein Session-Persist).
+- **Conflict-Resolver: farbliches Hervorheben übernommener Zeilen im Result-Pane** (Feature).
+
+---
+
+## Nicht anfassen / Kontext
+
+- **§1 DiffModal-Fehler-State** (`vm.diff.unavailable`) ist **defensiver, über die UI
+  unerreichbarer** Code — alle Aufrufer sind gegated (`CanDiffMergedRange` verlangt base+head
+  non-null; `ConfigureWorktree` nur mit existierendem Pfad). Kein Fix nötig.
+- **`--permission-mode auto` + `haiku` denied Writes** — modellabhängiges Verhalten, keine
+  Regression; Default (sonnet) unbetroffen. Beobachten (Memory `auto_permission_haiku_footgun`).
+- **§10 Daily Prep/Weekly** — Verifikation zurückgestellt bis zum geplanten Rework.
+
+---
+
+## Empfohlene Reihenfolge
+
+1. **Gruppe A** (mechanisch, schnell, teils parallel) → sofort sichtbare Wins.
+2. **Gruppe B** (Error-Surfacing, klein & risikoarm).
+3. **Gruppe C** — pro Punkt kurz brainstormen/entscheiden, dann umsetzen (#10 + #12 zusammen
+   mit der ConPTY-Planning-Entscheidung betrachten).
+4. **Gruppe D** — Investigation, dann Fix (#13 zuerst — betrifft mehrere Planning-Flows).
+5. **Gruppe E** — nach Bedarf.

docs/handoff-list-handler-2026-08-05.md

@@ -0,0 +1,226 @@
+# Handoff — List-handler run on list "Claude do", 2026-08-05
+
+> **✅ COMPLETED 2026-08-05 (follow-up session).** Everything in §1 and §2 is merged and `main`
+> verified green. Read §0 below before §1–§8 — §5's diagnosis turned out to be **wrong** and the
+> rest is now history. Still nothing pushed.
+
+Repo: `C:\Private\ClaudeDo` · List id: `5f973815-050a-4136-94f0-1506a5d4560a` · Branch: `main` (nothing pushed)
+
+---
+
+## 0. What the follow-up session did (and what §5 got wrong)
+
+**All merged, `main` green after every step** (Worker 811/811, Data 143/143, Ui 292/292,
+Localization 16/16, builds 0 new warnings):
+
+| Merged | Task | Merge commit |
+|---|---|---|
+| §1 #1 | `9e307199` revert_merge + merge-SHA persistence | `3e7126b` |
+| §1 #2 | `0b2fbb48` post-merge verification gate | (conflict-resolved) |
+| §1 #3 | `8c1c2130` roadblock reply box | `519ea5a` |
+| §2 #42 | `c1df5b9a` Hub surface for usage | `6e2158d` |
+| §2 #43 | `f74b44d9` Usage pill | `7661129` |
+| §2 #45 | `06068810` gate thresholds in settings | `5115cfc` |
+| §2 #44 | `82488d2a` Usage Monitor modal | `338fc39` |
+| §2 #46 | `9c8cffe0` docs | `5872666` |
+| parent | `439a4daf` Usage Monitor unit | approved → Done (empty unit merge; all children already `Merged`) |
+
+Plus one hand-fix on `main`: `677a4c1` — `UsagePillViewModelTests` never set `Loc.Current`
+(defaults to a key-echo localizer) and only passed because another test class happened to
+install a real `Localizer` first; #44's new tests changed the ordering and broke it on `main`.
+Classic "both branches green, `main` red".
+
+### §5 is wrong — `"exited with code 1 and no result"` is NOT (only) a CLI crash
+
+It is a **catch-all** hiding at least three causes. The truth is in the run log's last NDJSON
+line (`{"type":"result", …}` → `terminal_reason` / `errors` / `result`):
+
+- **`max_turns`** — what actually killed #40 and #42. `app_settings.model_presets` is `NULL`, so
+  `ModelPresets.Parse` falls back to the shipping defaults, and **sonnet's default is 30 turns**.
+  `AppSettings.DefaultMaxTurns` (100) is only the fallback for an *unrecognized* alias, so it
+  never applies. Every task without an explicit `maxTurns` override got 30 turns.
+  → Fix used here: `set_task_config(taskId, model="sonnet", maxTurns=200)` before queueing.
+- **`api_error`** + `"You've hit your session limit · resets 1pm (Europe/Berlin)"` — the account's
+  5-hour limit, which took out #43's first attempt. Nothing to fix; wait for the reset, re-queue.
+- Genuine process death — the case §5 describes.
+
+§5's *operational* advice still holds and is what saved #42: **never `reset_failed_task`** on one
+of these; check the worktree, build/test it, then set the task `Queued` so the agent resumes its
+own session and commits. #42's worktree held a complete green implementation (773/773).
+
+Follow-up tasks: `ca6e55c0` (surface the real failure reason) is new; the turn-budget/presets side
+is already covered by the Idle task `2de2f008` (`b0317ec7` fixed only the unknown-alias half).
+
+### Still open
+
+- **Visual passes** (nobody has looked at these in a running app): usage pill in the footer *and*
+  the Mission Control header; Usage Monitor modal (gauges, tables, stale/blocked bands, dark/light);
+  the roadblock reply box; the verify-command field in the List Settings modal. See `docs/open.md`.
+- **`~/.todo-app/prompts/planning.md` still shadows the compiled default** (§7.1) — unchanged.
+- **`wait_for_task_change` is merged but not in the running Worker**, so it isn't callable over MCP
+  until the Worker is restarted. §3's sqlite poll was used instead.
+- One rough edge in the verify gate: if the verify command fails, the worktree has already been
+  removed and its state set `Merged` while the task stays `WaitingForReview` — re-approving is then
+  refused. Recovery is `update_task_status(..., "Done")` once `main` is fixed.
+
+Predecessor session ran the five-phase list handler over 11 briefed tasks and, along the way,
+absorbed the 9-child "Usage Monitor" unit. **Phases 0–3 are complete for the brief.** What is
+left is Phase 4 (review + merge) for three tasks, plus the Usage chain.
+
+---
+
+## 1. Do this first — three brief tasks sit in WaitingForReview
+
+Merge in **this order** (the order was chosen with the user and matters):
+
+| # | Task | Id | Note |
+|---|------|----|------|
+| 1 | Feat: Merge zurücknehmen — Merge-Commit festhalten + `revert_merge` | `9e307199-2eca-4eb7-9057-d2c675cc57ca` | Migration + new tool. Merge **before** #2 |
+| 2 | Feat: Verifikations-Gate nach dem Merge | `0b2fbb48-d44c-4155-8c21-d3464c0bd5c2` | Depends on #1's merge-SHA persistence; both edit `TaskMergeService.cs` |
+| 3 | Feat: Antwortfeld auf der Roadblock-Karte | `8c1c213004574c4fad6beb75b84b70d7` | UI + localization (en **and** de) |
+
+For each one:
+
+1. `get_task_diff(taskId, stat=true)`, then the full diff if non-trivial. Sanity-check against
+   the task description (they are long and precise — the acceptance criteria are the checklist).
+2. `review_task(taskId, decision="approve", leaveConflictsInTree=true)`.
+3. On conflict: open the files under the returned `repoPath`, resolve keeping **both** sides'
+   intent, then `continue_merge(taskId)`. Conflicts are expected and normal here.
+4. **After every merge, verify `main`** (see §4). This is non-negotiable — see §5.
+
+Expected conflicts: `TaskMergeService.cs` between #1 and #2; `src/ClaudeDo.Worker/CLAUDE.md`
+and `src/ClaudeDo.Data/CLAUDE.md` in nearly every merge (doc bullet lists — trivial, keep both
+sides' entries).
+
+## 2. Then the Usage Monitor unit
+
+Parent `439a4daf166f4ab5b0fa415693d2c80d` ("Usage Monitor hinzufügen") is `WaitingForChildren`
+and has **no worktree of its own**. It has 9 children. Four are merged, one is in flight, four
+are Idle.
+
+| Child | Id | State |
+|---|---|---|
+| #38 Data: Usage-Gate-Schwellen + Modell-Spalte | `c1c999b6-b800-4b6b-a821-fbc028c15772` | merged `b1efcdc` |
+| #39 Worker: OAuth-Usage-Client + Poller | `f657e316-ad72-4f45-8036-460841fc8997` | merged `b126a21` |
+| #40 Worker: UsageGate | `06a7cc32-6ab7-4758-98f4-bee77149b2bf` | merged `1ee21b5` |
+| #41 Worker: TranscriptUsageReader | `840fdb98-1c0e-4219-8062-c8769233fc14` | merged `334cf1e` |
+| #42 Worker: Hub-Surface für Usage | `c1df5b9a-b911-4fe8-aab4-5876d9d85793` | **re-queued, in flight — read §5 before touching** |
+| #43 UI: Usage-Pill | `f74b44d9-7e48-4bfe-9d89-075e194d1fc9` | Idle — queue once #42 is merged |
+| #45 UI: Gate-Schwellen im Settings-Modal | `06068810-5b5c-4635-80dd-62eeba89fb8c` | Idle — queue once #42 is merged (parallel with #43) |
+| #44 UI: Usage-Monitor-Modal | `82488d2a-8ff7-41b8-b791-367959a8f827` | Idle — needs #42 **and** #43 merged |
+| #46 Docs: Usage Monitor | `9c8cffe0-8f7b-401e-a4f0-33b937047082` | Idle — last, after everything is merged |
+
+**The chain is strictly serial and you must respect it.** Every child forks from `main`, and each
+one's own description hard-requires the earlier ones. Queueing them all at once is exactly what
+produced the original roadblock: #40 ran, found its prerequisite types only on unmerged sibling
+branches, and returned `Done` having written **zero** code. So: merge a child → then queue the
+next → verify `main` → repeat.
+
+When the last child is merged the parent surfaces for review by itself; approve it to close the
+unit (it has no worktree, so it approves straight to Done).
+
+## 3. Cheap status polling — important
+
+`list_tasks` and `batch_get_tasks` return full descriptions and **blow the token limit** on this
+list (`list_tasks` over 52 tasks = ~206,000 chars; that is literally one of the bugs this run
+fixed). Do not poll with them. Poll the DB read-only instead:
+
+```bash
+PYTHONIOENCODING=utf-8 python - <<'EOF'
+import sqlite3
+c=sqlite3.connect("file:C:/Users/mika.kuns/.todo-app/todo.db?mode=ro",uri=True)
+for i,s in c.execute("select id,status from tasks"):
+    print(s, i)
+EOF
+```
+
+`list_worktrees` is also compact and safe. **New this run:** `wait_for_task_change(taskIds,
+timeoutSeconds)` is now merged and is the proper primitive — it returns as soon as any listed
+task leaves Queued/Running (server-clamped to 170 s). Prefer it over sleeping.
+
+## 4. Verify main after every merge
+
+```bash
+dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+dotnet test  tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
+dotnet test  tests/ClaudeDo.Data.Tests/ClaudeDo.Data.Tests.csproj   -c Release
+```
+
+For the UI/localization task (#3 above, and children #43–#45) also:
+
+```bash
+dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+dotnet test  tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+dotnet test  tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
+```
+
+`.slnx` needs .NET 9 — build individual csproj files, `-c Release` (a running Worker locks Debug).
+
+Baseline as of this handoff: Worker **753/753**, Data **143/143**, build 0 warnings.
+
+## 5. The trap that cost this run the most time
+
+Two children "failed" with `"Claude exited with code 1 and no result"`. **That is a CLI crash,
+not bad code.** In both cases the worktree held complete work that built with 0 warnings and
+passed the full suite (#40: 732/732, #42: 766/766) — the run just died before the auto-commit.
+
+- **Never `reset_failed_task` on such a task** — it discards the worktree and destroys the work.
+- Instead: `cd` into the worktree, `git status`, build + test it. If green, set the task
+  `Queued`. The worktree is preserved and the agent resumes its own session (`--resume`),
+  finds its work and commits it. That is how #40 was recovered.
+- #42 is mid-recovery right now via exactly this route. If it failed again, verify its worktree
+  (`C:\Private\.claudedo-worktrees\claude-do\c1df5b9a-b911-4fe8-aab4-5876d9d85793`) before
+  doing anything destructive.
+
+Second trap: git merges cleanly and the **compiler** still breaks. It happened again this run —
+`Usage/UsageModels.cs` was an add/add conflict, and `src/ClaudeDo.Worker/CLAUDE.md` merged
+"cleanly" into a file with the `Usage/` folder documented **twice**. Always read what a clean
+merge produced, and always run §4.
+
+## 6. Phase 0–3 decisions already made (do not redo)
+
+Dedupe: four candidate pairs examined, **nothing cancelled**. Decisions:
+
+- `05827da5` ↔ `81e37801` — kept both, and `05827da5` was **re-scoped**: its "lean status query"
+  half was removed because `81e37801`'s wait tool covers it. `05827da5` now owns only the
+  brief-description rendering. Both are merged.
+- `a76d9547` ↔ `99732497` — kept both, `99732497` merged first. Done.
+- `0b2fbb48` ↔ `9e307199` — kept both, `9e307199` merges first. **This is item #1/#2 in §1.**
+- `20c78c95` ↔ `a76d9547`(b) — kept both, different actors. Done.
+
+Phase 2: all 11 tasks carry acceptance criteria, real file+line references and out-of-scope
+sections. Three that were one-liners were researched and rewritten after asking the user
+(ConPTY fix approach, maxTurns-only scope, roadblock reply-box design).
+
+Run config: `maxParallelExecutions` = **3**. No list config exists, so effective max turns was
+the global **100**; it was raised to **200** per-task on the five heaviest via `set_task_config`.
+`0b2fbb48`, `9e307199` and `8c1c2130` still carry that override.
+
+## 7. Open follow-ups worth new tasks
+
+1. **`~/.todo-app/prompts/planning.md` shadows the planning prompt.** `PromptFiles.EnsureExists`
+   only writes a default when the file is absent, and that file exists (dated Jun 2). The
+   `maxTurns` guidance merged in `65db1cd` therefore **does not reach real planning sessions**
+   until that file is updated by hand. `system.md` and `agent.md` are shadowed too.
+   `merge-helper-system.md`/`merge-helper-initial.md` do **not** exist, so this run's handler
+   prompt changes are live.
+2. **MCP task DTOs expose no parent/child link.** The 9-child Usage unit had to be reconstructed
+   from `sortOrder` and creation timestamps. `get_task`/`list_tasks` should return
+   `parentTaskId` / `blockedByTaskId`.
+3. **Visual verification open** on: the ConPTY fix (open a tile on a task whose description
+   contains `->`), and — once merged — the roadblock reply box and the verify-gate field in the
+   list settings modal.
+4. **`"exited with code 1 and no result"` is too common.** Three runs died that way today, two
+   with finished work. Worth investigating whether the auto-commit step can be made to survive
+   a late CLI crash.
+5. Nothing has been **pushed**. `main` is 22 commits ahead of `8d7ba1e`.
+
+## 8. Rules this session operated under
+
+- Drive merges through the MCP tools. Never raw `git merge` / `reset` / `checkout`.
+- Hand-resolve only markers the tools left behind, then `continue_merge`. When committing by
+  hand is unavoidable, stage **explicit paths** — never `git add -A`: the main checkout is
+  shared with other sessions.
+- For a parent/children unit merge, pass the **parent** id to `continue_merge` / `abort_merge`.
+- Ask the user on anything ambiguous, risky, or destructive.
+- Never `delete_task` to dedupe — `Cancelled` keeps it visible and resettable.

docs/improvement-plan.md

@@ -1,5 +1,7 @@
 # ClaudeDo — Improvement Plan (Session 2026-04-13)
 
+> **Hinweis (2026-06-09):** Historischer Snapshot — bewusst nicht nachgepflegt. U.a. erledigt/überholt: IP-1 (Auto-Reconnect ist implementiert), `schema.sql` → EF-Core-Migrations, `StatusBarViewModel` existiert nicht mehr (Connection-State lebt in `IslandsShellViewModel`), Tags sind Junction-Tabellen statt JSON-Spalten. Offene Punkte stehen in `open.md`.
+
 Erfasst während manuellem Walkthrough der App. Priorisiert nach Schmerz/Aufwand.
 
 ---

docs/online-inbox-api-contract.md

@@ -0,0 +1,173 @@
+# ClaudeDo Online Inbox — API Contract & VPS build prompt
+
+Status: handoff doc. The **server side** (API + minimal web client) is built and deployed
+VPS-side by a separate Claude instance. This file is the source of truth for the contract
+both ends implement against. The desktop client in this repo is built to match it.
+
+---
+
+## 1. Concept
+
+ClaudeDo is a local desktop app that runs tasks autonomously via the Claude CLI; it is
+normally fully local (SQLite). The **Online Inbox** is an optional service that lets the
+single owner view their task lists and add new tasks from a phone/browser. The desktop app
+syncs against it.
+
+**Governing rule:** the online store mirrors EXACTLY the desktop's `Idle` backlog — nothing
+else. A task is present online only while it is `Idle` on the desktop. The moment the user
+queues it locally, the desktop removes it from the online store. Running / WaitingForReview /
+Done / Failed / Cancelled tasks never appear online.
+
+Sync directions (each one-way per entity → no conflict resolution needed):
+
+- **Lists**: desktop → online only. Desktop is the source of truth (full-replace catalog).
+- **Idle tasks**: desktop mirrors its Idle backlog up; the web can create new ones, which the
+  desktop pulls down and then owns.
+
+Single user today. Both the desktop and the web client authenticate as the **same Zitadel
+user**.
+
+**Multi-user readiness (`ownerId`).** Each resource is owned by a Zitadel subject (`sub`).
+`RemoteList`, `RemoteTask`, and `MirrorTask` carry an optional `ownerId` field. The desktop
+stamps its own `sub` (decoded from the access token) onto everything it pushes, and
+defensively ignores any pulled task whose `ownerId` is set to a *different* user; an absent
+`ownerId` is treated as unowned/legacy and still syncs. This keeps the contract ready for
+multiple users **without enforcing isolation client-side** — the server remains the
+authority that scopes every request by the token's `sub`. When the server goes multi-user it
+should partition all rows by owner and ignore (or validate) the client-supplied `ownerId`.
+
+**Access control (as of 2026-06-10).** Access is granted by assigning the **"user" project
+role** in the Zitadel project "ClaudeDo" (id `376787351902355727`, issuer
+`https://auth.kuns.dev`) — there is no app-side allowlist (the former `ALLOWED_USER_IDS`
+env var is gone). The access token carries the role in the claim
+`urn:zitadel:iam:org:project:roles` (or the project-scoped variant
+`urn:zitadel:iam:org:project:376787351902355727:roles`), an object keyed by role key, e.g.
+`{ "user": { "<orgId>": "<orgDomain>" } }`. The desktop OIDC client
+(id `376787352137302287`) has `accessTokenRoleAssertion` enabled, so any token issued
+after login/refresh includes the claim automatically — no extra scopes are needed.
+Granting/revoking access is purely a Zitadel role grant, nothing app-side.
+
+## 2. Idle backlog definition (desktop side)
+
+The desktop mirrors only "real" backlog items, not planning internals:
+
+- `Status == Idle`
+- `ParentTaskId == null` (no planning/improvement children)
+- `PlanningPhase == None`
+- `BlockedByTaskId == null`
+
+## 3. Data model (Postgres)
+
+```
+lists
+  id          text primary key            -- GUID supplied by the desktop; reuse verbatim
+  name        text not null
+  updated_at  timestamptz not null default now()
+
+tasks
+  id          text primary key            -- GUID; SHARED id space (see below)
+  list_id     text not null references lists(id) on delete cascade
+  title       text not null
+  description text
+  imported    boolean not null default false  -- false = web-created, awaiting desktop pull
+                                                -- true  = desktop-owned (mirrored or handed off)
+  created_at  timestamptz not null default now()
+  updated_at  timestamptz not null default now()
+```
+
+**Shared GUID id space.** Web-created tasks get a server-generated GUID; the desktop imports
+under that SAME id, so it never duplicates. Desktop-mirrored tasks arrive with their own GUID.
+All task writes are idempotent upserts keyed on id.
+
+**`imported` flag = ownership.**
+- Web `POST /tasks` inserts `imported=false`.
+- Desktop pulls `imported=false`, creates the task locally (reusing the id), then `POST
+  /tasks/{id}/imported` flips it to `true`. From then on the task belongs to the desktop
+  mirror.
+- `PUT /tasks/mirror` only ever inserts/updates/deletes within the `imported=true` partition.
+  It never touches `imported=false` rows (those are pending handoff).
+
+## 4. Endpoints
+
+All endpoints require a valid Zitadel access token (`Authorization: Bearer <token>`) that
+carries the **"user" project role** (see §1). Missing/invalid/expired token, or a valid
+token without the role → `401`. No anonymous access (imported tasks can trigger code
+execution on the user's machine). The desktop client treats a `401` as: force a
+refresh-token exchange and retry once; if a freshly issued token is still rejected, it
+surfaces "missing 'user' role in Zitadel" and pauses sync until the user signs in again.
+
+> **Auth (VPS/.NET):** use the in-house `KunsZitadel` nuget package (feed
+> `https://git.kuns.dev/api/packages/kuns/nuget/index.json`) — call `AddKunsZitadel(...)`
+> with the Zitadel authority/audience/client id to wire `JwtBearer` validation + CORS for
+> the web client origin. (`KunsZitadel` is server-side token *validation* only; the desktop
+> client acquires tokens via its own OIDC flow.)
+
+| Method & path | Caller | Body | Response |
+|---|---|---|---|
+| `PUT /lists` | desktop | `[{ "id", "name", "ownerId"? }]` — the FULL catalog | `200` |
+| `GET /lists` | web | — | `200 [{ "id", "name", "ownerId"? }]` |
+| `GET /lists/{id}/tasks` | web | — | `200` tasks in that list (`404` if list unknown) |
+| `POST /tasks` | web | `{ "title", "description"?, "listId" }` | `201` created task incl. `id` |
+| `GET /tasks?imported=false` | desktop | — | `200 [{ "id","listId","title","description","createdAt","ownerId"? }]` |
+| `POST /tasks/{id}/imported` | desktop | — | `200` (`404` if unknown) |
+| `PUT /tasks/mirror` | desktop | `[{ "id","listId","title","description","ownerId"? }]` — full Idle set | `200` |
+
+`ownerId` (optional, see §1) is the Zitadel `sub` of the owner. The desktop sends it on push
+and ignores pulled tasks owned by a different user; the server should derive/validate it from
+the token rather than trust the client value.
+
+Semantics:
+
+- **`PUT /lists`** — full replace: upsert all supplied, DELETE any list not in the payload
+  (cascades its tasks). Idempotent.
+- **`POST /tasks`** — `listId` must exist (`400`/`404` otherwise). Server generates the id.
+- **`PUT /tasks/mirror`** — full replace of the `imported=true` partition: upsert every task
+  in the payload (insert with `imported=true`, or update), and DELETE any `imported=true`
+  task whose id is not in the payload. `imported=false` rows are untouched. Idempotent.
+- All task ids are client-trusted within the shared space; the server never rewrites an id.
+
+## 5. Reconcile loop (desktop, runs each poll cycle)
+
+```
+1. PULL:  GET /tasks?imported=false
+          for each: if no local task with that id → create local TaskEntity
+                    { Id = remote.id, ListId = remote.listId, Title, Description,
+                      Status = Idle, CreatedBy = "online" }
+                    (skip + log if remote.listId has no local list)
+                    then POST /tasks/{id}/imported
+2. PUSH LISTS:  PUT /lists  with the full local catalog [{id, name}]
+3. PUSH TASKS:  PUT /tasks/mirror  with the current local Idle backlog set (§2)
+```
+
+Ordering matters: pull+import+flag first, so the just-imported tasks are part of the local
+Idle set computed in step 3 and survive the mirror replace.
+
+## 6. Minimal web client
+
+Integrate into the existing Nuxt app at claudedo.kuns.dev if present; else a minimal page.
+
+- Zitadel login.
+- Show lists (`GET /lists`); select one to see its Idle tasks (`GET /lists/{id}/tasks`).
+- Add-task form → `POST /tasks`.
+- Mobile-first (main use: jotting ideas from a phone).
+- **Create + read only.** No editing, reordering, status changes, or deletes.
+
+## 7. Security
+
+- Every route auth-gated (`401` on bad token); only static assets / login are public.
+- Validate `listId` on task creation; parameterized queries only.
+- CORS restricted to the web client origin.
+- Don't log task titles/descriptions at info level (user content).
+
+## 8. Deliverables from the VPS build
+
+Report back so the desktop can be configured:
+
+1. **API base URL.**
+2. **Zitadel app/client config the desktop must use**: issuer/authority, client id, scopes,
+   and the OAuth flow to use for a desktop app (device-code or auth-code + PKCE), plus how
+   refresh tokens are issued.
+3. Any env vars / README.
+
+Out of scope server-side: task execution (the desktop runs Claude), any task state other
+than the Idle mirror, multi-user / sharing / notifications.

docs/open.md

@@ -1,30 +1,247 @@
 # ClaudeDo — Offene Punkte
 
-Stand: 2026-06-04. **Nur noch offene Punkte.** Was erledigt ist, steht in den Commits und im Code — nicht hier.
+Stand: 2026-08-06. Der Findings-Block von 2026-07-24 wurde am 2026-08-06 **gegen den Code
+nachverifiziert** (statisch, nicht in der laufenden App); alles, was inzwischen gefixt ist, ist
+hier entfernt — Erledigtes steht in den Commits/im Code, nicht hier. Die alte Verifikations-
+Checkliste lebt in `docs/verification-handoff.md`.
 
 ---
 
-## Manuelle Verifikation (offen)
+## Bugs (offen)
 
-Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der Großteil der Pipeline ist laut User bereits in der Praxis getestet; hier das, was noch ein falsifizierbares Observable braucht.
+- **Verwaiste git-Worktrees sind für die App unsichtbar** (gefunden 2026-08-06). In `C:\Private\ClaudeDo` waren nach dem Cleanup 22 git-registrierte Worktrees + 26 `claudedo/*`-Branches vorhanden, die ClaudeDo-DB kannte davon nur zwei. Die Worktrees-Übersicht listet ausschließlich Zeilen aus `worktrees`, also kann der Nutzer diese Reste nicht über die App entfernen — und es gibt keinen Sweep dafür (`OrphanRecovery` räumt nur Task-Zeilen auf, keine Worktrees). Wunsch: entweder ein Startup-Abgleich `git worktree list` ↔ DB, der Unbekannte als „untracked" in die Übersicht aufnimmt, oder mindestens eine Warnung mit Anzahl.
 
-- **Worktree-Pipeline:**
-  - Worktree-Happy-Path → `worktrees.state='active'`, `head_commit` gesetzt, `diff_stat` non-empty, Branch `claudedo/<id>` auf Disk.
-  - No-Changes-Run → `status='Done'`, `head_commit IS NULL`, `diff_stat IS NULL`.
-  - Kein Git-Repo (`working_dir=C:\Temp`) → `status='Failed'`, **keine** `worktrees`-Row, Git-Fehler im Log.
-- **Feature-Walkthroughs:** Planning-Session-Flow (Draft→Finalize→Chain), Prime/Daily-Prep-Trigger, Weekly-Report-Generierung, Self-Update (Banner → Update → „up to date").
-- **Worker-Autostart am Gerät:** Logoff/Logon-Autostart, Update-Pfad, Uninstall entfernt die Startup-`.lnk`.
+## UX / Nits (offen)
 
-## Offene Code-Punkte
+- **Planning-aktiver Parent zeigt weiter „Idle":** Parent in `planning_phase=active` hat `Status=Idle` (korrekt im Modell), aber `TaskRowViewModel.StatusLabel` (Zeile 132) kennt nur `HasInteractiveSession`/`IsParked` als Overrides — der `PlanningBadge` ersetzt den Chip nicht sichtbar → liest sich wie ein normaler Idle-Task. Wunsch: klarer „Planning/Draft aktiv"-Zustand, der Idle überschreibt. (Kinder zeigen korrekt „Draft".)
+- **Blocked-by-Kette nicht sichtbar:** Nach Finalize ist die sequentielle Kette korrekt gesetzt (child[i] blocked-by child[i-1]), aber die UI stellt Reihenfolge/Abhängigkeit nicht dar — es gibt nur den „waiting"-Chip. Wunsch: Kette visualisieren (z.B. „wartet auf <Vorgänger>").
+- **Dequeue-„X" fehlt auf wartenden (blockierten) Kettengliedern:** `CanRemoveFromQueue = IsQueued || HasQueuedSubtasks` (TaskRowViewModel.cs:99), `IsQueued` verlangt leeres `blocked_by`. Ein gequeuetes, aber blockiertes Kind (`IsWaiting`) bekommt daher kein Remove-from-queue-X — nur Parent + erstes (entsperrtes) Kind.
+- **Session-Skills-Tab hat keinen Empty-State:** Bei 0 installierten Skills zeigt der Skills-Tab (Settings) nur eine nackte leere Fläche unter der Install-Zeile — kein erklärender Hinweis (z.B. „Noch keine Skills installiert — GitHub-URL oben einfügen"). Im `sessionSkillsTab`-Locale-Namespace (en.json:674) gibt es keinen `empty`-Key.
+- **Modal-Bodies sind unten abgeschnitten** (Sichtprüfung 2026-08-06, beobachtet in den Listen-Settings: der Hinweistext unter „Verify command" ist mitten in der Zeile vom Footer weggeschnitten und lässt sich nicht herunterscrollen; laut Mika „fast überall" in den Settings-Modals). Gemeinsames Muster: `<ScrollViewer Padding="20,16">` als Modal-Body — in `ListSettingsModalView:36`, `MergeModalView:33`, `WorktreesOverviewModalView:131`, `AboutModalView:20`, `MergeHelperSelectionModal:47`, `RepoImportModalView:45`, `LogVisualizerView:45` sowie `WorkConsole:295/395`. **Vermutete** Ursache (nicht verifiziert): das untere `Padding` des ScrollViewers zählt nicht zum scrollbaren Extent, die letzten Pixel sind also unerreichbar. Erst am echten Fall nachmessen, dann ggf. einheitlich das Padding vom ScrollViewer auf ein `Margin` des inneren Inhalts umziehen.
+- **Usage-Monitor-Modal: Analyse-Tabellen ausbaufähig** (Sichtprüfung 2026-08-06; Gauges, Info-Bänder, Presets/Custom-Range und Refresh-Button sind in Ordnung). Models-Tab: die Spaltenköpfe „OTHER CACHE" und „SHARE" kollidieren zu `OTHER CACHISHARE`; `claude-haiku-4-5-20251001` läuft in die IN-Spalte; alle Zahlen linksbündig und ohne Tausendertrenner (`506830708`). Tasks-Tab: Task-Titel wird ohne Ellipse hart an der LIST-Spalte abgeschnitten, der LIST-Text ebenfalls; MODEL ist bei Runs von vor der `task_runs.model`-Spalte leer (besser „—"). Wunsch: Zahlen rechtsbündig + `#,##0` (oder k/M), Spaltenbreiten/Truncation fixen.
+- **Conflict-Resolver: mehrere Konfliktdateien schlecht erkennbar:** Beim 2-Datei-Konflikt schwer zu sehen, dass zwei Dateien betroffen sind (File-Switcher/Anzahl zu unauffällig). Prominentere Datei-Liste / „x von y Dateien".
+- **Attachments: erster Drag&Drop der Session schlug einmalig fehl („An error occurred"):** Beim allerersten Drop-to-attach einer UI-Session zeigte die `DropStatus`-Zeile inline einen generischen Fehler und es wurde nichts persistiert (kein File, keine DB-Row); alle folgenden Drops derselben Session + der „Add file…"-Picker + Remove funktionierten fehlerfrei. Nicht reproduzierbar nach dem ersten Mal. Kandidaten: transiente SQLite-Contention (der UI-Prozess schreibt `todo.db` direkt via `new TaskAttachmentRepository`, während der Worker dieselbe DB hält) ODER ein Fehler im Drop-Stream-Pfad (`IStorageFile.OpenReadAsync` im Code-Behind, außerhalb des `try` in `AddFilesAsync`). Falls es erneut auftritt: `AddFilesAsync`/`OnDrop` mit robusterem Error-Logging versehen.
 
-- **Status-Bar Live-Update:** Prüfen, ob `RunNow`-Enable/Disable pro Task-Row bei Connection-Change sauber re-evaluiert. Connection-Status lebt in `IslandsShellViewModel` / `WorkerConnectionModalViewModel` (es gibt keinen `StatusBarViewModel` mehr). Erst messen, dann ggf. fixen. Klein.
+## Feature-Wünsche
+
+- **Conflict-Resolver: farbliches Hervorheben eingefügter Zeilen im Result-Pane** (grüner „flow" der übernommenen Zeilen).
+- **Die Handler-Session soll „Submit for review" selbst auslösen können** (Sichtprüfung 2026-08-06). Aktuell ist der Abschluss eines List-Handler-Laufs ein reiner Handgriff über die Schaltfläche in der Mission-Control-Kachel — die Session selbst hat kein Werkzeug dafür, obwohl sie am besten weiß, wann sie fertig ist. Wunsch: ein MCP-Tool auf der In-Task-Oberfläche, das denselben Pfad wie der Button nimmt.
+- **Handoff-Kachel besser beschriften** (Sichtprüfung 2026-08-06). Die zweite Kachel heißt `Merge Helper — <Liste> (Handoff)` bzw. „(Übergabe)" (`missionControl.mergeHelperHandoffTitleSuffix`, en.json/de.json:297). „Handoff" ist internes Vokabular und sagt nicht, was die Session tut. Besser etwas, das die Rolle nennt (Ausführen + Mergen der verbliebenen Tasks, Phasen 3-5).
+
+## Design-Entscheidungen (27.07.-Batch, Sichtprüfung am 2026-08-06 abgeschlossen)
+
+Der Sichtprüfungs-Block dieses Batches (Ctrl+K/`#`, Titel-Edit, ConPTY-/Refine-Spinner,
+Interactive-Chip, Diff-Viewer-Abstände, Manual-Tasks, Vorgaben-pro-Modell-Tabelle) ist von Mika
+verifiziert und deshalb hier entfernt. Es bleiben die Entscheidungen, die daran hängen:
+
+- Interaktive ConPTY-Sessions bekommen `--effort`, aber **kein** `--model` — die Session läuft weiter unter dem Modell aus Mikas Claude-Config, der Effort kommt aus dem Preset des Modells, das ClaudeDo für die Task auflösen würde. Falls ClaudeDo auch interaktiv das Modell erzwingen soll, ist das ein Folge-Task.
+- `AppSettings.DefaultMaxTurns` ist jetzt tatsächlich verdrahtet (`ModelPresets.For(..., global.DefaultMaxTurns)` in `TaskRunner.ResolveConfigAsync`): reiner Fallback für ein Modell, das auch nach `ModelRegistry.TryNormalizeAlias` auf keine Preset-Zeile trifft — vorher war das Feld tot (hartkodierte 30). Hat weiterhin keinen eigenen Editor mehr (nur die Preset-Tabelle pro Modell); Spalte könnte später entfallen, falls das nie zutrifft.
+
+## Beobachtung (offen — Entscheidung Mika)
+
+- **`--permission-mode auto` + Modell `haiku` → Writes werden denied:** Kontrolliert verifiziert (CLI 2.1.207): unter dem Default-Mode `auto` bekommt **sonnet** Writes auto-approved (`permission_denials:[]`), **haiku** wird `denied` (`permission_denials:[Write]`, keine Datei) — eine haiku-Task macht unter `auto` still nichts und landet ohne Änderung in `WaitingForReview`. Normalbetrieb (Default = sonnet) nicht betroffen. KEINE CLI-Regression, sondern modellabhängiges `auto`-Verhalten. Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf `acceptEdits`/`bypassPermissions` (modell-unabhängig). Mika: erstmal beobachten. Siehe Memory `auto_permission_haiku_footgun`.
+- ~~**`QueueServiceTests.UsageGate_TransitionLogging_FiresOncePerChange` ist zeitbasiert flaky**~~ — **am 2026-08-06 gefixt**: der feste `Task.Delay(200)` ist durch die schon im selben File vorhandene `AssertStableCountAsync` ersetzt (pollt bis der erste Backstop-Tick geloggt hat, wartet dann eine Karenzzeit und stellt sicher, dass kein weiterer Tick nachlegt). Historischer Befund zur Einordnung: Schlägt reproduzierbar fehl (`Expected 1, Actual 0` Warn-Log-Aufrufe), sowohl solo (`--filter`) als auch im Vollauf, auf einem sauberen `git worktree add` gegen `main` (bdee731) — also **kein** durch diese Abschluss-Session verursachter Regress (die Session hat keine `.cs`-Datei angefasst). Ursache: der Test verlässt sich auf einen festen `Task.Delay(200)`, um mehrere 50-ms-Backstop-Ticks abzuwarten (Kommentar im Test: „Several backstop ticks (50ms interval) all observe the same blocked state"); auf einer stark ausgelasteten Maschine (hier: viele parallele ClaudeDo-Worktrees/Builds) reicht das Fenster nicht immer. Zum Vergleich: derselbe Test lief in einer zweiten, isolierten Verifikation (Scratch-Merge für den Environment-Checks-Task) sauber durch (876/876). Fix wäre ein Poll-basiertes Warten statt fixem Sleep — aber außerhalb des Scopes dieser Doku/Verifikations-Session (keine Code-Änderung angefasst).
+
+---
+
+## Offene Verifikation (2026-07-27)
+
+- **List handler (2026-07-27)** — visual pass: the Broom button is gone from the lists footer,
+  the context-menu item appears only on lists with a working dir, and the selection dialog has no
+  LIST column. (Der real-Claude-Smoke-Run der fünf Phasen ist am 2026-07-29 gelaufen — 6/6 sauber
+  gemerged; nur die Sichtprüfung ist noch offen.)
+
+## Offene Verifikation (2026-08-05)
+
+- **List handler owns a task (2026-08-05)** — **visuell verifiziert am 2026-08-06** (Lauf über die
+  Liste `ClaudeDoTests` mit 4 Tasks, davon 2 absichtliche Dubletten): genau ein neuer Task, Mission-
+  Control-Tile task-basiert mit „Submit for review", Dedupe hat die Dublette erkannt,
+  Beschreibungen wurden angereichert, Submit → `WaitingForReview`, und die Diff-Karte zeigte alle
+  drei Dateien des Laufs. Korrektur zur Erwartung oben: der Task-Chip liest sich **„Interactive"**,
+  nicht `Idle` — das ist korrekt so (`HasInteractiveSession` überschreibt den Status-Chip, solange
+  die ConPTY-Session läuft). Die drei dabei gefundenen Punkte stehen unter „Bugs" bzw.
+  „Feature-Wünsche".
+- **Roadblock reply field (2026-08-05)** — **Kernfunktion am 2026-08-06 verifiziert**: auf einem
+  Task mit gemeldetem Roadblock erscheint das Antwortfeld unter dem Roadblock-Text, die Antwort
+  setzt die Session fort, und der Task landet danach sauber auf `WaitingForReview`. Dabei ist der
+  Bug oben aufgefallen (Feld deaktiviert, solange der Task seit vor dem Lauf offen ist). Layout der
+  Roadblock-Karte ist in Ordnung. **Noch offen:** Enter-zum-Senden, und dass ein „Override-Slot
+  besetzt"-Fehler im Footer-Strip landet (nicht als Modal) mit dem getippten Text weiterhin im
+  Feld. Design-Entscheidung dazu: der Review-Bereich lebt als zwei nullable Spalten
+  direkt auf `TaskEntity` (kein Phantom-`WorktreeEntity`), damit `list_worktrees`/die
+  Worktrees-Übersicht ihn nie sehen.
+
+- **Post-merge verify gate (2026-08-05)** — build + unit tests all green (incl. real-process
+  `VerifyCommandRunner` exit-code/output/timeout tests and `TaskMergeService` success/failure/
+  timeout paths via a fake runner), but **not visually verified**: open a list's Settings modal,
+  confirm the new "VERIFICATION" section renders below Agent with a settable/clearable
+  `VerifyCommand` field; approve a task on a list with a failing command configured and confirm
+  the footer/error surfacing (`ShowErrorAsync`) actually shows the verify failure message instead
+  of silently looking like nothing happened. Also no real-build smoke test (a real `dotnet build`/
+  `dotnet test` invocation as the configured command) — only fast synthetic commands (`exit N`,
+  `ping` for timeout) were exercised.
+
+## Offene Verifikation (2026-08-11, Task numbers in UI)
+
+Slice 4 der Task-Numbers-Features (UI-Display) ist gemerged (commit 38af549); Build + Tests grün,
+aber **nicht visuell verifiziert**:
+
+- **Task Row Display:** `TaskRowViewModel.Number` (Zeile 39, TaskRowViewModel.cs) zeigt die
+  Nummer als `#<number>` dimmed vor dem Titel in der Row an (`TaskRowView.axaml` Zeile 45+). Prüfen:
+  offene Task in der Übersicht hat sichtbar `#<number>` vor dem Titel.
+- **Detail Pane Header:** `DetailsIslandViewModel.TaskIdBadge` (Zeile 77, DetailsIslandViewModel.cs)
+  zeigt jetzt `#<number>` statt des alten GUID-Präfix. Prüfen: Task-Detail-Chip zeigt
+  `#<number>`.
+- **Worker Log Messages:** Geschäftsereignisse in `TaskRunner` (Zeile 199+), `TaskMergeService`
+  (Zeile 174+), und `TaskResetService` (Zeile 84+) prefixen Task-Titel mit `#<number>`. Prüfen:
+  Footer Worker-Log zeigt Task-Messages wie „`#42 finished`" statt nur dem GUID.
+
+## Offene Verifikation (2026-08-06, Fix-Batch aus der Sichtprüfung)
+
+Fünf Findings der Sichtprüfung sind gefixt, Build + Tests grün, aber **noch nicht in der App
+nachgeprüft** (der laufende Build ist älter — erst nach Neuinstallation testbar):
+
+- **NumericUpDown-Leeren wirft nicht mehr:** neuer `KeepLastNumberConverter` bildet beim
+  ConvertBack `null` auf `BindingOperations.DoNothing` ab, an allen acht nicht-nullbaren
+  NumericUpDowns im Settings-Modal verdrahtet. Prüfen: Wert löschen und neu tippen — keine
+  Exception, alter Wert bleibt stehen, bis eine echte Zahl kommt. Damit ist auch der offene Rest
+  von „MaxTurnsCeiling ändern → Hinweistexte ziehen mit" nachholbar.
+- **Verify-Gate greift jetzt auch ohne Worktree:** Approve auf einem List-Handler-Task mit
+  fehlschlagendem `VerifyCommand` muss `verify_failed` liefern und den Task aus `Done` halten
+  (vorher ging er kommentarlos auf `Done`).
+- **`verify_failed` im Merge-Modal und in der Worktrees-Übersicht:** Modal zeigt statt „Unknown
+  status" den echten Fehlertext und schließt sich **nicht** automatisch; die Batch-Übersicht
+  zeigt `VerifyFailed` und markiert die Zeile trotzdem als `Merged` (der Merge ist ja gelandet).
+- **Roadblock-Reply/Continue live:** Task offen lassen, während er in den Roadblock läuft — das
+  Antwortfeld und Continue müssen **ohne** erneutes Öffnen aktiv werden.
+- **Cleanup-Log:** ein Worktree-Cleanup über veraltete DB-Zeilen darf keine WARN-Flut mehr im
+  Footer erzeugen (die „schon erledigt"-Fälle gehen auf Debug).
+- **Handoff schließt die alte Kachel:** beim Übergang von Phase 2 auf Phase 3 muss die alte
+  Merge-Helper-Kachel verschwinden und die neue an ihrer Stelle stehen — keine leere Geister-Pane
+  mehr. (Entscheidung Mika 2026-08-06: automatisch schließen statt Output erhalten.)
+
+## Offene Verifikation (2026-08-06, Resume planning session)
+
+`planning_session_id` wurde nie befüllt (der Setter hatte keinen Aufrufer), weil die interaktive
+Planning-Session ihre claude-Session-Id nie zurückmeldet — Resume konnte deshalb nie
+funktionieren. `PlanningSessionManager.ResumeAsync` liest die Id jetzt beim ersten Resume aus dem
+Transkript, das Claude Code unter `~/.claude/projects/<encodiertes cwd>/<sessionId>.jsonl` für den
+Planning-Worktree ablegt (`PlanningTranscriptLocator`), und persistiert sie. Unit-Tests grün,
+**nicht visuell verifiziert**:
+
+- Planning-Session starten, Fenster/Pane schließen, Task erneut öffnen → „Resume" muss die
+  ConPTY-Pane mit der **fortgesetzten** Unterhaltung öffnen (nicht mit leerem Verlauf).
+- Ohne Transkript (z. B. Session nie wirklich gestartet): Fehlermeldung „No Claude session
+  transcript found…" landet sichtbar im Footer-Error-Strip (`Terminal.StartError` →
+  `ErrorReported`), nicht still.
+- **Risiko:** das Verzeichnis-Encoding (`~/.claude/projects/`, jedes Nicht-Alphanumerische wird
+  `-`) ist undokumentiertes CLI-Verhalten — ändert es sich, findet der Locator nichts und Resume
+  meldet sauber „cannot resume" (fail-safe, kein falscher Resume).
+
+## Offene Verifikation (2026-08-05, Usage Monitor)
+
+> **Kein Light-Theme.** `App.axaml:6` setzt `RequestedThemeVariant="Dark"` fest, es gibt keinen
+> Umschalter und `Tokens.axaml` kennt keine Light-Variante. „Dark/Light"-Checks sind deshalb
+> überall aus dieser Datei entfernt — sie waren nie erfüllbar.
+
+- **Visueller Pass Usage-Pill** (Footer **und** Mission-Control-Header) — **am 2026-08-06
+  verifiziert**: Text/Tooltip lesbar, Dot-Zustände plausibel, Pill in Footer und
+  Mission-Control-Header identisch.
+- **Visueller Pass Usage-Monitor-Modal** — **am 2026-08-06 verifiziert**: Gauges (dynamisch aus
+  `limits[]`), Info-Bänder (der Throttle-Hinweis „Queue throttled: 1/3 slots (7d)" stand real an),
+  7d/30d-Presets + Custom-Range. Die Analyse-Tabellen sind ausbaufähig → siehe „UX / Nits".
+- **E2E Gate**: das Gate greift real, sobald ein Bucket (`five_hour`/`seven_day`) die
+  konfigurierte Schwelle reißt — Queue-Nachschub pausiert, laufende Runs/`RunNow`/ConPTY/
+  Planning/Prime bleiben unberührt — und die Queue nimmt nach dem Reset selbstständig wieder
+  auf (30s-Backstop, kein persistenter Pause-Zustand).
+- **Risiko:** der Usage-Endpoint (`GET https://api.anthropic.com/api/oauth/usage`) ist
+  undokumentiert und kann sich ändern; bei Ausfall/Formatänderung ist das Gate wirkungslos
+  (fail-open by design — kein Blocker, aber der Schutz fällt dann aus, ohne dass es auffällt).
+
+### Nachtrag 2026-08-05: 429-Fix (Poll-Kadenz + Refresh-Button)
+
+Der 60s-Poll lief in 429s. Neu: aktivitätsabhängige Kadenz (5 Min. solange ein Task `Running`
+ist, sonst 15 Min.), 429-Backoff mit `Retry-After`, und ein „Jetzt aktualisieren"-Button im
+Usage-Monitor-Modal (`RefreshUsage` → `UsageMonitorService.RefreshNowAsync`, 10s-Cooldown).
+Unit-Tests grün, **offen**:
+
+- **Visueller Pass Refresh-Button** im Modal — **am 2026-08-06 verifiziert** (Button, Hinweiszeile
+  „Polled every 5 min while a task runs, otherwise every 15 min.").
+- **E2E:** über ≥20 Min. mit und ohne laufenden Task beobachten, dass keine 429s mehr im
+  Worker-Log auftauchen und die Pill trotzdem aktuell bleibt.
+- **Beachten:** die Pill wird jetzt erst nach 3× 15 Min. als `stale` markiert — ein echter
+  Endpoint-Ausfall fällt vorher nur über `LastError` auf (der `IsStale` sofort setzt).
+
+## Offene Verifikation (2026-08-05, Max-Turns-Ceiling)
+
+Build + unit tests grün (`ResolveMaxTurns`-Klemmung, Repository-Backfill von `model_presets`,
+Migration `AddMaxTurnsCeiling` gegen eine Scratch-DB angewendet), aber **nicht visuell
+verifiziert**:
+
+- Agent-Settings-Editor (Task **und** Liste): Max-Turns-Feld auf einen Wert über der Ceiling
+  (Default 80) setzen, Hinweistext unter dem `NumericUpDown` erscheint ("Runs are capped at
+  {N} turns…").
+- Settings → Allgemein → Vorgaben pro Modell: eine Zeile über 80 setzen, derselbe Hinweistext
+  erscheint unter der Zeile.
+- `MaxTurnsCeiling` ist seit `2975f90` selbst editierbar (Settings → Allgemein,
+  `SettingsModalView.axaml`) — Feld prüfen: Wert ändern, speichern, Hinweistexte oben ziehen mit.
+
+## Offene Verifikation (2026-08-05, Environment Checks / SystemCheckPage)
+
+Checks + SystemCheckPage (`claudedo/06aca9b3…`) und das ExecutableResolver-Wiring im Worker
+(`claudedo/40272c0b…`) sind seit 2026-08-06 auf `main` gemerged; die frühere „erst mergen"-
+Voraussetzung ist erledigt. Details → `installer-preflight` in `docs/explore-notes/README.md`
+und der Abschnitt „Environment Checks" in `src/ClaudeDo.Installer/CLAUDE.md`.
+
+**Update (2026-08-06):** beide Folge-Features sind jetzt implementiert und auf `main`.
+
+- Diagnose-Sektion (Config-Modus/`SettingsWindow`): `Pages/DiagnosePage/` + geteilte
+  `Checks/CheckListViewModel.cs`/`Checks/CheckListView.xaml` (auch von `SystemCheckPage`
+  genutzt, keine zweite Implementierung). Unit-getestet
+  (`tests/ClaudeDo.Installer.Tests/Pages/DiagnosePage/DiagnosePageViewModelTests.cs`).
+- „Claude Help Me"-Button: `Core/ClaudeHelpLauncher.cs` + `SystemCheckPageViewModel`/-View,
+  unit-getestet (`tests/ClaudeDo.Installer.Tests/Core/ClaudeHelpLauncherTests.cs`).
+
+Beides **nicht visuell verifiziert**:
+
+- [x] Help-Me-Button ist deaktiviert, wenn `claude-cli` nicht `Ok` ist oder `claude-auth`
+      `Failed` ist (bleibt aktiv bei `Unknown`), mit erklärendem Tooltip — unit-getestet.
+- [ ] „Claude Help Me" öffnet tatsächlich ein Terminal mit laufender Claude-Session, und die
+      Session hat den Diagnose-Report gelesen — **nicht verifiziert** (der eigentliche
+      Terminal-Start/`wt.exe`-Zusammenspiel und die Session-Qualität sind nur über die
+      injizierte `IProcessLauncher`-Fake getestet, nie mit einem echten Terminal/CLI).
+- [ ] Platzierung des Help-Me-Buttons: er sitzt seit dem Merge der Diagnose-Sektion in einer
+      **eigenen Zeile unter** dem geteilten Check-Listen-Footer (der reservierte Slot *im*
+      Footer entfiel mit der Extraktion nach `CheckListView.xaml`). Optisch prüfen, ob das
+      so bleiben soll oder ob der Button in den geteilten Footer gehört.
+- [ ] Diagnose-Sektion im Config-Modus: Öffnen von SettingsWindow löst keinen Prüflauf aus, Klick
+      auf „Erneut prüfen" schon; zeigt die echten installierten Pfade/Ports (nicht die
+      InstallContext-Defaults), und der laufende Worker auf dem konfigurierten SignalR-Port gilt
+      nicht als Konflikt — **unit-verifiziert, visueller Durchlauf noch offen.**
+
+Weitere Punkte, gebaut + unit-getestet auf `main`, aber **nicht visuell verifiziert**:
+
+- [ ] SystemCheckPage: Layout, Icon-/Farbwirkung der vier Status (Ok grün / Warnung orange /
+      Fehler rot / Unbekannt grau — `StatusGreenBrush`/`StatusOrangeBrush`/`StatusRedBrush`/
+      `StatusGrayBrush`), Lesbarkeit der Hint-Texte, DE und EN.
+- [ ] Weiter-Button gesperrt bei einem echten blockierenden Fehler (z. B. `claude` nicht im
+      PATH → `claude-cli` Error/Failed), und der Grund ist in der Zusammenfassungszeile
+      sichtbar (nennt den/die blockierenden Check(s) namentlich).
+- [ ] „Erneut prüfen" wechselt einen Status live (z. B. git-Identity setzen → Warnung
+      verschwindet), ohne dass ein zweiter paralleler Lauf startet, wenn währenddessen erneut
+      geklickt wird.
+- [ ] Update-Modus zeigt die SystemCheckPage **nicht** (Wizard bleibt Welcome + Install).
+- [ ] Auf einem Rechner mit npm-installiertem `claude.cmd`: `claude-cli`-Check findet es
+      (Detail-Text „Resolved via a shim…"), und ein Task läuft im Worker durch (bestätigt, dass
+      `ClaudeProcess`/`ClaudeCliPreflight` den Shim über `cmd.exe /c` tatsächlich startet, nicht
+      nur, dass der Check ihn findet).
 
 ---
 
 ## Bewusst verworfen (nicht erneut vorschlagen)
 
 - **CI-Build/Test-Pipeline** — push-to-main + release-on-push deckt das ab; Tests laufen am Ende jeder Session.
-- **Real-`claude`-Smoke-Test als xUnit-Test** — kein Claude in `dotnet test`; bleibt manueller Check (siehe oben). Tests nutzen `FakeClaudeProcess`.
-- **`architecture.md` / ADRs** — die per-Projekt-`CLAUDE.md`-Dateien sind die lebende Doku; ADRs lohnen solo nicht.
-- **Task-Mailbox-Integration** — geparkt; das generische `mcp__mailbox__*`-Plugin reicht (Begründung in `mailbox-proposal.md`).
-- **Tag-Negation, Tag-Multi-Select, Notes-`lists.kind`-Switch, Install-Service-Skript** — durch die aktuelle Architektur überholt (Tag-System entfernt, Notes/Autostart anders gelöst).
+- **Real-`claude`-Smoke-Test als xUnit-Test** — kein Claude in `dotnet test`; bleibt manueller Check. Tests nutzen `FakeClaudeProcess`.
+- **`architecture.md` / ADRs** — die per-Projekt-`CLAUDE.md`-Dateien sind die lebende Doku.
+- **Task-Mailbox-Integration** — geparkt; das generische `mcp__mailbox__*`-Plugin reicht (`mailbox-proposal.md`).
+- **Tag-Negation, Tag-Multi-Select, Notes-`lists.kind`-Switch, Install-Service-Skript** — durch die aktuelle Architektur überholt.

docs/plan.md

@@ -1,5 +1,7 @@
 # ToDo-App mit autonomem Agent-Worker — Design
 
+> **Hinweis (2026-06-09):** Historisches Design-Dokument vom Projektstart — bewusst nicht nachgepflegt. Überholt sind insbesondere: die Tag-basierte Queue (entfernt; der Picker nutzt `Status=Queued` + `BlockedByTaskId IS NULL`), `schema.sql` (Schema läuft über EF-Core-Migrations) und das Projektlayout (inzwischen sechs Testprojekte). Lebende Doku sind die `CLAUDE.md`-Dateien pro Projekt.
+
 ## Context
 
 Ziel: eine persönliche ToDo-App als Desktop-Anwendung, in der mehrere Listen verwaltet werden können. Ein Teil der Tasks soll autonom von Claude abgearbeitet werden (z.B. Recherche, Code-Aufgaben, Notizen-Verarbeitung). Die Autonomie läuft in einem getrennten Hintergrund-Prozess, damit die UI davon entkoppelt bleibt.

docs/superpowers/plans/2026-06-05-git-merge-review-foundation-layerA.md

@@ -0,0 +1,432 @@
+# Git Merge/Review — Shared Foundation + Layer A Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Build the shared worker conflict contract (so parallel Layer B/C sessions branch from frozen interfaces) and rework the Git tab into a single Approve+merge cockpit.
+
+**Architecture:** Phase 0 adds the conflict-resolution contract to `IWorkerClient`/`WorkerClient` (real `_hub.InvokeAsync` bodies — the worker hub methods are implemented later by Layer C; calls simply fail at runtime until then) plus client-side DTOs and test-fake updates, then commits + pushes so B and C branch from it. Phase A reworks `WorkConsole.axaml`'s Git tab and routes single-task merge/approve conflicts into a `RequestConflictResolution` seam (wired to Layer C's resolver by the integrator at merge time).
+
+**Tech Stack:** .NET 8, Avalonia 12 (Fluent), CommunityToolkit.Mvvm, SignalR, xUnit. Build individual csproj with `-c Release` (`.slnx` needs .NET 9; a running Worker locks `Debug`).
+
+**Reference spec:** `docs/superpowers/specs/2026-06-05-git-merge-review-rework-design.md`
+
+**Note on the canonical diff renderer:** the unified diff model/control already exists — `DiffFileViewModel`/`DiffLineViewModel`/`UnifiedDiffParser` (in `src/ClaudeDo.Ui/ViewModels/Modals/`) rendered by `DiffLinesView` (`src/ClaudeDo.Ui/Views/Controls/DiffLinesView.axaml`). `DiffModalView` and `PlanningDiffView` already use it. So "consolidate diff renderers" for this scope is just verifying that (Task A.3); migrating `WorktreeModalView`'s bespoke diff onto `DiffLinesView` is Layer B's job.
+
+---
+
+## File Structure
+
+**Phase 0 (foundation — pushed before B/C branch):**
+- Modify `src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs` — 5 new method signatures.
+- Modify `src/ClaudeDo.Ui/Services/WorkerClient.cs` — 5 `InvokeAsync` bodies + 3 new DTO records.
+- Modify `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs` — 5 new `virtual` no-op methods.
+- Modify `tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs` — 5 new methods on `FakeWorkerClient`.
+
+**Phase A (Layer A — this session, after foundation commit):**
+- Modify `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs` — `RequestConflictResolution` seam; route Approve/Merge conflicts into it.
+- Modify `src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml` — fuse REVIEW + MERGE sections into one cockpit block.
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandPlanningTests.cs` (or a sibling test file in the same folder).
+
+---
+
+## Phase 0 — Shared Foundation
+
+### Task 0.1: Add the conflict contract (interface + client + DTOs)
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs`
+- Modify: `src/ClaudeDo.Ui/Services/WorkerClient.cs`
+
+- [ ] **Step 1: Add the 5 method signatures to `IWorkerClient`**
+
+In `src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs`, after the existing
+`Task CancelReviewAsync(string taskId);` line (line 45), add:
+
+```csharp
+    // ── Conflict resolution (worker hub side implemented by Layer C) ──
+    Task<MergeResultDto> StartConflictMergeAsync(string taskId, string targetBranch);
+    Task<MergeConflictsDto> GetMergeConflictsAsync(string taskId);
+    Task WriteConflictResolutionAsync(string taskId, string path, string resolvedContent);
+    Task<MergeResultDto> ContinueMergeAsync(string taskId);
+    Task AbortMergeAsync(string taskId);
+```
+
+- [ ] **Step 2: Add the 3 DTO records to `WorkerClient.cs`**
+
+In `src/ClaudeDo.Ui/Services/WorkerClient.cs`, immediately after line 534
+(`public record MergeTargetsDto(...)`), add:
+
+```csharp
+public record MergeConflictsDto(string TaskId, IReadOnlyList<ConflictFileDto> Files);
+public record ConflictFileDto(string Path, IReadOnlyList<ConflictHunkDto> Hunks);
+public record ConflictHunkDto(string Ours, string Theirs, string? Base);
+```
+
+- [ ] **Step 3: Add the 5 client method bodies to `WorkerClient.cs`**
+
+In `src/ClaudeDo.Ui/Services/WorkerClient.cs`, right after the `MergeTaskAsync`
+method (ends at line 270), add:
+
+```csharp
+    public Task<MergeResultDto> StartConflictMergeAsync(string taskId, string targetBranch)
+        => _hub.InvokeAsync<MergeResultDto>("StartConflictMerge", taskId, targetBranch);
+
+    public Task<MergeConflictsDto> GetMergeConflictsAsync(string taskId)
+        => _hub.InvokeAsync<MergeConflictsDto>("GetMergeConflicts", taskId);
+
+    public Task WriteConflictResolutionAsync(string taskId, string path, string resolvedContent)
+        => _hub.InvokeAsync("WriteConflictResolution", taskId, path, resolvedContent);
+
+    public Task<MergeResultDto> ContinueMergeAsync(string taskId)
+        => _hub.InvokeAsync<MergeResultDto>("ContinueMerge", taskId);
+
+    public Task AbortMergeAsync(string taskId)
+        => _hub.InvokeAsync("AbortMerge", taskId);
+```
+
+- [ ] **Step 4: Build the UI project**
+
+Run: `dotnet build src/ClaudeDo.Ui/ClaudeDo.Ui.csproj -c Release`
+Expected: build FAILS — the two test projects won't compile yet, but the UI project
+itself should succeed. If the UI project reports "does not implement interface member"
+it means a body is missing; fix before continuing. (Test projects are fixed in 0.2.)
+
+### Task 0.2: Update the hand-rolled test fakes
+
+**Files:**
+- Modify: `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs`
+- Modify: `tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs`
+
+- [ ] **Step 1: Add 5 virtual no-ops to `StubWorkerClient`**
+
+In `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs`, after the `MergeTaskAsync` override
+(line 57), add:
+
+```csharp
+    public virtual Task<MergeResultDto> StartConflictMergeAsync(string taskId, string targetBranch) => Task.FromResult(new MergeResultDto("conflict", System.Array.Empty<string>(), null));
+    public virtual Task<MergeConflictsDto> GetMergeConflictsAsync(string taskId) => Task.FromResult(new MergeConflictsDto(taskId, System.Array.Empty<ConflictFileDto>()));
+    public virtual Task WriteConflictResolutionAsync(string taskId, string path, string resolvedContent) => Task.CompletedTask;
+    public virtual Task<MergeResultDto> ContinueMergeAsync(string taskId) => Task.FromResult(new MergeResultDto("merged", System.Array.Empty<string>(), null));
+    public virtual Task AbortMergeAsync(string taskId) => Task.CompletedTask;
+```
+
+- [ ] **Step 2: Add 5 methods to `FakeWorkerClient`**
+
+In `tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs`, after the
+`MergeTaskAsync` method (line 47), add:
+
+```csharp
+    public Task<MergeResultDto> StartConflictMergeAsync(string taskId, string targetBranch) => Task.FromResult(new MergeResultDto("conflict", System.Array.Empty<string>(), null));
+    public Task<MergeConflictsDto> GetMergeConflictsAsync(string taskId) => Task.FromResult(new MergeConflictsDto(taskId, System.Array.Empty<ConflictFileDto>()));
+    public Task WriteConflictResolutionAsync(string taskId, string path, string resolvedContent) => Task.CompletedTask;
+    public Task<MergeResultDto> ContinueMergeAsync(string taskId) => Task.FromResult(new MergeResultDto("merged", System.Array.Empty<string>(), null));
+    public Task AbortMergeAsync(string taskId) => Task.CompletedTask;
+```
+
+- [ ] **Step 3: Build both test projects**
+
+Run: `dotnet build tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release && dotnet build tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release`
+Expected: both BUILD succeed.
+
+- [ ] **Step 4: Run the UI test suite to confirm green baseline**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release`
+Expected: PASS (no behavior changed yet).
+
+### Task 0.3: Commit and push the foundation
+
+- [ ] **Step 1: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs src/ClaudeDo.Ui/Services/WorkerClient.cs tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs
+git commit -m "feat(ui): add conflict-resolution worker contract (foundation for merge rework)"
+```
+
+- [ ] **Step 2: Push so Layer B/C can branch from this commit**
+
+Run: `git push`
+Expected: pushed to `main`. (First push to git.kuns.dev may fail auth — retry once.)
+**This commit is the branch point for the Layer B and Layer C kickoff prompts.**
+
+---
+
+## Phase A — Layer A Review/Merge Cockpit
+
+### Task A.1: Conflict-resolution seam + route Approve/Merge conflicts into it (TDD)
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandConflictSeamTests.cs` (new)
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandConflictSeamTests.cs`. Mirror
+the VM-construction harness used in
+`tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandPlanningTests.cs` (same folder) —
+construct `DetailsIslandViewModel` exactly as that file does, including its
+`StubWorkerClient` subclass pattern. The test:
+
+```csharp
+[Fact]
+public async Task ApproveReview_OnConflict_InvokesConflictResolutionSeam()
+{
+    string? resolvedTaskId = null;
+    string? resolvedTarget = null;
+
+    // Construct the VM as in DetailsIslandPlanningTests, with a worker stub whose
+    // ApproveReviewAsync returns a conflict result:
+    //   public override Task<MergeResultDto?> ApproveReviewAsync(string id, string target)
+    //       => Task.FromResult<MergeResultDto?>(new MergeResultDto("conflict", new[]{"a.cs"}, null));
+    var vm = CreateVm(/* worker stub above */);
+    vm.RequestConflictResolution = (taskId, target) =>
+    {
+        resolvedTaskId = taskId; resolvedTarget = target;
+        return System.Threading.Tasks.Task.CompletedTask;
+    };
+    // assign a task in WaitingForReview + a SelectedMergeTarget = "main" via the same
+    // helpers DetailsIslandPlanningTests uses.
+
+    await vm.ApproveReviewCommand.ExecuteAsync(null);
+
+    Assert.Equal(/* the seeded task id */, resolvedTaskId);
+    Assert.Equal("main", resolvedTarget);
+}
+```
+
+- [ ] **Step 2: Run the test to verify it fails**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter ApproveReview_OnConflict_InvokesConflictResolutionSeam`
+Expected: FAIL — `RequestConflictResolution` property does not exist (compile error).
+
+- [ ] **Step 3: Add the seam property**
+
+In `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs`, beside the other
+view-wired delegates (`ShowDiffModal`, `ShowMergeModal` around line 387–390), add:
+
+```csharp
+    // Invoked when a single-task merge/approve hits a conflict. Wired by the
+    // integrator to Layer C's conflict resolver. Args: (taskId, targetBranch).
+    public Func<string, string, System.Threading.Tasks.Task>? RequestConflictResolution { get; set; }
+```
+
+- [ ] **Step 4: Route the Approve conflict branch into the seam**
+
+In `ApproveReviewAsync` (around line 1453), replace the conflict branch body so it
+prefers the seam, falling back to the current preview-text behavior:
+
+```csharp
+            var result = await _worker.ApproveReviewAsync(Task.Id, SelectedMergeTarget ?? "");
+            if (result?.Status == "conflict")
+            {
+                if (RequestConflictResolution is not null)
+                {
+                    await RequestConflictResolution(Task.Id, SelectedMergeTarget ?? "");
+                }
+                else
+                {
+                    var (text, _, _) = MergePreviewPresenter.Describe(
+                        new MergePreviewDto("conflict", result.ConflictFiles, 0));
+                    MergePreviewText = text; MergeIsClean = false; MergeIsConflict = true;
+                }
+            }
+```
+
+- [ ] **Step 5: Route the manual Merge conflict branch into the seam**
+
+In `MergeAsync` (around line 1170), apply the same pattern to its conflict branch:
+
+```csharp
+            var result = await _worker.MergeTaskAsync(Task.Id, SelectedMergeTarget ?? "", false, "Merge task");
+            if (result.Status == "conflict")
+            {
+                if (RequestConflictResolution is not null)
+                {
+                    await RequestConflictResolution(Task.Id, SelectedMergeTarget ?? "");
+                }
+                else
+                {
+                    var (text, _, _) = MergePreviewPresenter.Describe(
+                        new MergePreviewDto("conflict", result.ConflictFiles, 0));
+                    MergePreviewText = text; MergeIsClean = false; MergeIsConflict = true;
+                }
+            }
+            else
+            {
+                await RefreshMergePreviewAsync();
+            }
+```
+
+- [ ] **Step 6: Run the test to verify it passes**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter ApproveReview_OnConflict_InvokesConflictResolutionSeam`
+Expected: PASS.
+
+- [ ] **Step 7: Run the full UI suite (no regressions)**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release`
+Expected: PASS.
+
+- [ ] **Step 8: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandConflictSeamTests.cs
+git commit -m "feat(ui): route single-task merge conflicts into a resolution seam"
+```
+
+### Task A.2: Fuse the Git tab into one Approve+merge cockpit
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml`
+
+- [ ] **Step 1: Replace the two Git-tab sections with one cockpit block**
+
+In `src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml`, replace the entire Git
+`ScrollViewer` body (lines 255–313 — the `<!-- Git: ... -->` block containing the
+separate `REVIEW` `StackPanel` and the `MERGE & WORKTREE` `StackPanel`) with a single
+cockpit where Approve sits with the merge target/preview/actions. Keep the existing
+control class names (`section-label`, `field-label`, `btn`, `btn accent`, `meta`) and
+the existing bindings (`SelectedMergeTarget`, `MergeTargetBranches`, `MergePreviewText`,
+`MergeIsClean`, `MergeIsConflict`, `ShowMergePreviewMuted`, `OpenDiffCommand`,
+`ApproveReviewCommand`, `MergeCommand`, `ShowSingleMerge`, `OpenWorktreeCommand`,
+`ReviewCombinedDiffCommand`, `MergeAllCommand`, `CanMergeAll`, `MergeAllDisabledReason`,
+`MergeAllError`):
+
+```xml
+        <!-- Git: one Approve + merge cockpit -->
+        <ScrollViewer IsVisible="{Binding IsGitTab}" Padding="14,10">
+          <StackPanel Spacing="12" IsVisible="{Binding ShowMergeSection}">
+            <TextBlock Classes="section-label" Text="MERGE" />
+
+            <StackPanel Spacing="4">
+              <TextBlock Classes="field-label" Text="Target branch" />
+              <ComboBox ItemsSource="{Binding MergeTargetBranches}"
+                        SelectedItem="{Binding SelectedMergeTarget, Mode=TwoWay}"
+                        HorizontalAlignment="Stretch" />
+            </StackPanel>
+
+            <StackPanel Spacing="0">
+              <TextBlock Classes="meta" Text="{Binding MergePreviewText}" TextWrapping="Wrap"
+                         Foreground="{DynamicResource MossBrush}"
+                         IsVisible="{Binding MergeIsClean}" />
+              <TextBlock Classes="meta" Text="{Binding MergePreviewText}" TextWrapping="Wrap"
+                         Foreground="{DynamicResource BloodBrush}"
+                         IsVisible="{Binding MergeIsConflict}" />
+              <TextBlock Classes="meta" Text="{Binding MergePreviewText}" TextWrapping="Wrap"
+                         Foreground="{DynamicResource TextMuteBrush}"
+                         IsVisible="{Binding ShowMergePreviewMuted}" />
+            </StackPanel>
+
+            <!-- Primary action: Approve flows straight into the merge.
+                 Approve is the review-gated path; the plain Merge button covers
+                 already-reviewed / kept worktrees. -->
+            <WrapPanel Orientation="Horizontal">
+              <Button Classes="btn accent" Content="Approve &amp; Merge" Margin="0,0,8,8"
+                      Command="{Binding ApproveReviewCommand}"
+                      IsVisible="{Binding IsWaitingForReview}" />
+              <Button Classes="btn accent" Content="Merge" Margin="0,0,8,8"
+                      Command="{Binding MergeCommand}"
+                      IsVisible="{Binding ShowSingleMerge}" />
+              <Button Classes="btn" Content="Open Diff" Margin="0,0,8,8"
+                      Command="{Binding OpenDiffCommand}" />
+              <Button Classes="btn" Margin="0,0,8,8"
+                      Command="{Binding OpenWorktreeCommand}">
+                <StackPanel Orientation="Horizontal" Spacing="5">
+                  <TextBlock Text="Worktree" />
+                  <PathIcon Data="{StaticResource Icon.ArrowOut}" Width="11" Height="11" />
+                </StackPanel>
+              </Button>
+              <Button Classes="btn" Content="Review Combined Diff" Margin="0,0,8,8"
+                      Command="{Binding ReviewCombinedDiffCommand}" />
+              <Button Classes="btn accent" Content="Merge All Subtasks" Margin="0,0,0,8"
+                      Command="{Binding MergeAllCommand}"
+                      IsEnabled="{Binding CanMergeAll}"
+                      ToolTip.Tip="{Binding MergeAllDisabledReason}" />
+            </WrapPanel>
+
+            <TextBlock Text="{Binding MergeAllError}"
+                       Foreground="{DynamicResource BloodBrush}"
+                       TextWrapping="Wrap"
+                       IsVisible="{Binding MergeAllError,
+                           Converter={x:Static ObjectConverters.IsNotNull}}" />
+          </StackPanel>
+        </ScrollViewer>
+```
+
+Note: the cockpit now shows whenever `ShowMergeSection` is true. `ShowMergeSection`
+(DetailsIslandViewModel line 161) must be true while `IsWaitingForReview` so the
+Approve button appears. Check its expression in Step 2.
+
+- [ ] **Step 2: Verify `ShowMergeSection` covers the review state**
+
+Read `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs` line 161. If
+`ShowMergeSection` is false while `IsWaitingForReview` (e.g. it requires a non-review
+state), widen it to also be true when `IsWaitingForReview && WorktreePath != null`, and
+ensure `OnPropertyChanged(nameof(ShowMergeSection))` already fires on the relevant state
+transitions (it is notified via `NotifySessionSections`). Make the minimal change needed
+so the Approve button is visible in review state. If it already covers review, change
+nothing.
+
+- [ ] **Step 3: Build the app project**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: BUILD succeeds (pulls in Ui + Data).
+
+- [ ] **Step 4: Visual verification (manual — flag for the user)**
+
+This is an AXAML layout change with no automated coverage. Launch the app, open a task
+in `WaitingForReview`, open the Git tab, and confirm: the single MERGE block shows the
+target combo, the colored preview line, an "Approve & Merge" button (review state), and
+the diff/worktree/combined/merge-all actions. **Explicitly tell the user this needs a
+visual pass — do not claim it works without running it.**
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs
+git commit -m "feat(ui): fuse git tab into one approve+merge cockpit"
+```
+
+### Task A.3: Verify diff-renderer consolidation
+
+**Files:** none modified (verification only).
+
+- [ ] **Step 1: Confirm DiffModal + Planning already use the canonical renderer**
+
+Run: `rg -l "DiffLinesView" src/ClaudeDo.Ui/Views`
+Expected: matches in `Modals/DiffModalView.axaml` and `Planning/PlanningDiffView.axaml`.
+If `PlanningDiffView.axaml` does NOT use `DiffLinesView`, change its diff `ItemsControl`
+to a `<controls:DiffLinesView Lines="{Binding SelectedFile.Lines}" />` (matching
+`DiffModalView.axaml`'s usage) and rebuild the App project. If both already use it, this
+task is a no-op — record that and move on. (`WorktreeModalView`'s bespoke diff is
+intentionally left for Layer B.)
+
+---
+
+## Self-Review
+
+- **Spec coverage:** Foundation contract (spec §"Frozen worker conflict contract") →
+  Task 0.1. Test fakes (spec parallel-boundaries row) → Task 0.2. Branch point (spec
+  §"built & pushed this session") → Task 0.3. Layer A cockpit + Approve/merge flow
+  together (spec §"Layer A") → Task A.2. Single-task approve-on-conflict opens resolver
+  via seam (spec §"Layer A" + §"integration seams") → Task A.1. Diff consolidation
+  (spec §"One diff model") → Task A.3. Output-footer feedback unchanged → not touched
+  (correct). No spec requirement left unmapped for this session's scope.
+- **Placeholder scan:** none — every code step has concrete code; the only "mirror the
+  existing harness" reference (Task A.1 Step 1) points at a real file with a working
+  pattern, not a TODO.
+- **Type consistency:** `MergeConflictsDto`/`ConflictFileDto`/`ConflictHunkDto` and the
+  5 method names match between `IWorkerClient` (0.1 Step 1), `WorkerClient` (0.1 Steps
+  2–3), and both fakes (0.2). The seam `RequestConflictResolution` is
+  `Func<string,string,Task>?` everywhere (A.1 Steps 1, 3–5). DTO field names match the
+  spec.
+
+---
+
+## Integration notes (for the integrator merging A + B + C)
+
+- Wire `DetailsIslandViewModel.RequestConflictResolution` and Layer B's equivalent
+  callback to Layer C's `ConflictResolverViewModel` factory + `ShowConflictResolver`
+  dialog delegate.
+- Layer C implements the worker hub methods `StartConflictMerge`, `GetMergeConflicts`,
+  `WriteConflictResolution`, `ContinueMerge`, `AbortMerge`; the client side from Task
+  0.1 already calls them by name.

docs/superpowers/plans/2026-06-05-git-merge-review-prompts.md

@@ -0,0 +1,139 @@
+# 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<string, string, Task>? 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:<path>` / `:3:<path>` / `:1:<path>`. 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<ConflictFileDto> Files)
+    ConflictFileDto(string Path, IReadOnlyList<ConflictHunkDto> 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<string, ConflictResolverViewModel> and a
+  Func<ConflictResolverViewModel, Task> 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.
+```

docs/superpowers/plans/2026-06-05-layer-c-inline-conflict-resolver.md

@@ -0,0 +1,920 @@
+# Layer C — Inline Conflict Resolver Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Build the worker-side conflict plumbing (5 frozen hub methods + GitService reads) and a VSCode-style in-app inline conflict resolver UI for ClaudeDo's merge rework.
+
+**Architecture:** The worker performs a real merge that leaves conflicts in the list's working tree (`leaveConflictsInTree:true`), exposes ours/theirs/base per conflicted file via `git show :2:/:3:/:1:`, accepts written resolutions, and finishes via the existing `ContinueMergeAsync`/`AbortMergeAsync`. The UI presents each conflicted file's hunk with Accept Current/Incoming/Both/Edit-manually controls plus a free-text merged box, then writes resolutions and continues.
+
+**Tech Stack:** .NET 8, ASP.NET Core SignalR (WorkerHub), EF Core/SQLite, Avalonia MVVM (CommunityToolkit), xUnit + real git/SQLite fixtures.
+
+**Frozen client contract (already shipped in foundation commit `2dfc455`, DO NOT edit):**
+- `IWorkerClient` / `WorkerClient.cs` already call hub methods by name: `StartConflictMerge`, `GetMergeConflicts`, `WriteConflictResolution`, `ContinueMerge`, `AbortMerge`.
+- Client DTOs already exist in `WorkerClient.cs`: `MergeConflictsDto(string TaskId, IReadOnlyList<ConflictFileDto> Files)`, `ConflictFileDto(string Path, IReadOnlyList<ConflictHunkDto> Hunks)`, `ConflictHunkDto(string Ours, string Theirs, string? Base)`, plus existing `MergeResultDto(string Status, IReadOnlyList<string> ConflictFiles, string? ErrorMessage)`.
+- Worker-side DTOs must serialize identically (same record shape) and live in `WorkerHub.cs`.
+
+**Do NOT touch:** `WorkerClient.cs`, `Interfaces/IWorkerClient.cs`, `WorkConsole.axaml`, `DetailsIslandViewModel.cs`, `WorktreesOverviewModalView/VM`, `WorktreeModalView`. Test fakes for `IWorkerClient` already implement the 5 methods as no-op stubs (`StubWorkerClient` is `virtual` in Ui.Tests) — subclass/override, never edit the interface.
+
+**Build/test commands (.NET 8 — running Worker locks `Debug`, always `-c Release`):**
+```bash
+dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
+```
+
+---
+
+## File Structure
+
+**Worker / Data (create + modify):**
+- Modify `src/ClaudeDo.Data/Git/GitService.cs` — add `ShowStageAsync` (untrimmed blob read) + `AddPathAsync`; add `trimOutput` param to `RunGitAsync`.
+- Modify `src/ClaudeDo.Worker/Lifecycle/TaskMergeService.cs` — add records `MergeConflicts`/`ConflictFileContent`; add `GetConflictsAsync` + `WriteResolutionAsync`.
+- Modify `src/ClaudeDo.Worker/Hub/WorkerHub.cs` — add DTOs `MergeConflictsDto`/`ConflictFileDto`/`ConflictHunkDto` + 5 hub methods.
+
+**UI (create new only):**
+- Create `src/ClaudeDo.Ui/ViewModels/Conflicts/ConflictModels.cs` — `ConflictFile`, `ConflictHunk`.
+- Create `src/ClaudeDo.Ui/ViewModels/Conflicts/ConflictResolverViewModel.cs`.
+- Create `src/ClaudeDo.Ui/Views/Conflicts/ConflictResolverView.axaml` + `.axaml.cs`.
+
+**Wiring (modify):**
+- Modify `src/ClaudeDo.App/Program.cs` — register `ConflictResolverViewModel` + `Func<string, ConflictResolverViewModel>`.
+- Modify `src/ClaudeDo.Ui/ViewModels/IslandsShellViewModel.cs` — additive seam (`ConflictResolverFactory`, `ShowConflictResolver`, `RequestConflictResolutionAsync`).
+- Modify `src/ClaudeDo.Ui/Views/MainWindow.axaml.cs` — wire `ShowConflictResolver` dialog delegate.
+- Modify `src/ClaudeDo.Localization/locales/en.json` + `de.json` — `conflictResolver.*` keys (parity enforced by Localization.Tests).
+
+**Tests (create + modify):**
+- Modify `tests/ClaudeDo.Worker.Tests/Services/TaskMergeServiceTests.cs` — conflict-read / write-resolution / round-trip tests.
+- Create `tests/ClaudeDo.Ui.Tests/ViewModels/ConflictResolverViewModelTests.cs`.
+
+---
+
+## Task 1: GitService conflict-blob reads
+
+**Files:**
+- Modify: `src/ClaudeDo.Data/Git/GitService.cs`
+- Test: `tests/ClaudeDo.Worker.Tests/Services/TaskMergeServiceTests.cs` (GitService exercised here via real repo; add focused tests in Task 2 round-trip)
+
+- [ ] **Step 1: Add `trimOutput` param to `RunGitAsync`** so blob reads keep exact bytes.
+
+In `RunGitAsync` signature add `bool trimOutput = true`, and change the return to:
+```csharp
+return (proc.ExitCode, trimOutput ? stdout.TrimEnd() : stdout, stderr.TrimEnd());
+```
+(All existing callers keep the default `true`.)
+
+- [ ] **Step 2: Add `ShowStageAsync` + `AddPathAsync`** (place after `ListConflictedFilesAsync`):
+
+```csharp
+/// <summary>
+/// Reads a conflicted file's blob at a merge stage: 1=base, 2=ours, 3=theirs.
+/// Returns null when the stage doesn't exist (e.g. add/add conflict has no base).
+/// Output is NOT trimmed so file content round-trips exactly.
+/// </summary>
+public async Task<string?> ShowStageAsync(string repoDir, int stage, string path, CancellationToken ct = default)
+{
+    var (exitCode, stdout, _) = await RunGitAsync(repoDir, ["show", $":{stage}:{path}"], ct, trimOutput: false);
+    return exitCode == 0 ? stdout : null;
+}
+
+public async Task AddPathAsync(string repoDir, string path, CancellationToken ct = default)
+{
+    var (exitCode, _, stderr) = await RunGitAsync(repoDir, ["add", "--", path], ct);
+    if (exitCode != 0)
+        throw new InvalidOperationException($"git add '{path}' failed (exit {exitCode}): {stderr}");
+}
+```
+
+- [ ] **Step 3: Build the Data + Worker projects to verify compilation.**
+
+Run: `dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release`
+Expected: Build succeeded, 0 errors.
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add src/ClaudeDo.Data/Git/GitService.cs
+git commit -m "feat(git): add conflict-stage blob reads and single-path staging"
+```
+
+---
+
+## Task 2: TaskMergeService conflict reads + resolution writes
+
+**Files:**
+- Modify: `src/ClaudeDo.Worker/Lifecycle/TaskMergeService.cs`
+- Test: `tests/ClaudeDo.Worker.Tests/Services/TaskMergeServiceTests.cs`
+
+- [ ] **Step 1: Write failing tests** (append inside `TaskMergeServiceTests`, before `#region Test doubles`). Reuse the existing helpers `SeedListAndTask`, `SeedWorktree`, `BuildService`, and the `GitRepoFixture` conflict setup pattern from `ContinueMergeAsync_AfterUserResolves...`.
+
+```csharp
+[Fact]
+public async Task GetConflictsAsync_AfterConflictMerge_ReturnsOursAndTheirs()
+{
+    if (!GitRepoFixture.IsGitAvailable()) return;
+
+    var db = NewDb();
+    var repo = NewRepo();
+    GitRepoFixture.RunGit(repo.RepoDir, "branch", "-m", "main");
+    File.WriteAllText(Path.Combine(repo.RepoDir, "README.md"), "# main change\n");
+    GitRepoFixture.RunGit(repo.RepoDir, "commit", "-am", "main change");
+
+    var wtPath = Path.Combine(Path.GetTempPath(), $"wt_{Guid.NewGuid():N}");
+    _wtCleanups.Add((repo.RepoDir, wtPath));
+    GitRepoFixture.RunGit(repo.RepoDir, "worktree", "add", "-b", "claudedo/c1", wtPath, repo.BaseCommit);
+    File.WriteAllText(Path.Combine(wtPath, "README.md"), "# branch change\n");
+    GitRepoFixture.RunGit(wtPath, "commit", "-am", "branch change");
+
+    var (_, task) = await SeedListAndTask(db, workingDir: repo.RepoDir, status: TaskStatus.WaitingForReview);
+    await SeedWorktree(db, task.Id, wtPath, "claudedo/c1", repo.BaseCommit);
+
+    var (svc, _) = BuildService(db);
+    var start = await svc.MergeAsync(task.Id, "main", false, "msg", leaveConflictsInTree: true, CancellationToken.None);
+    Assert.Equal(TaskMergeService.StatusConflict, start.Status);
+
+    var conflicts = await svc.GetConflictsAsync(task.Id, CancellationToken.None);
+
+    Assert.Equal(task.Id, conflicts.TaskId);
+    var file = Assert.Single(conflicts.Files);
+    Assert.Equal("README.md", file.Path);
+    Assert.Contains("main change", file.Ours);     // ours = target (main) side after checkout
+    Assert.Contains("branch change", file.Theirs);  // theirs = merged-in branch
+    Assert.NotNull(file.Base);
+
+    GitRepoFixture.RunGit(repo.RepoDir, "merge", "--abort");
+}
+
+[Fact]
+public async Task WriteResolutionAsync_ThenContinue_CompletesMerge()
+{
+    if (!GitRepoFixture.IsGitAvailable()) return;
+
+    var db = NewDb();
+    var repo = NewRepo();
+    GitRepoFixture.RunGit(repo.RepoDir, "branch", "-m", "main");
+    File.WriteAllText(Path.Combine(repo.RepoDir, "README.md"), "# main change\n");
+    GitRepoFixture.RunGit(repo.RepoDir, "commit", "-am", "main change");
+
+    var wtPath = Path.Combine(Path.GetTempPath(), $"wt_{Guid.NewGuid():N}");
+    _wtCleanups.Add((repo.RepoDir, wtPath));
+    GitRepoFixture.RunGit(repo.RepoDir, "worktree", "add", "-b", "claudedo/c2", wtPath, repo.BaseCommit);
+    File.WriteAllText(Path.Combine(wtPath, "README.md"), "# branch change\n");
+    GitRepoFixture.RunGit(wtPath, "commit", "-am", "branch change");
+
+    var (_, task) = await SeedListAndTask(db, workingDir: repo.RepoDir, status: TaskStatus.WaitingForReview);
+    await SeedWorktree(db, task.Id, wtPath, "claudedo/c2", repo.BaseCommit);
+
+    var (svc, _) = BuildService(db);
+    await svc.MergeAsync(task.Id, "main", false, "msg", leaveConflictsInTree: true, CancellationToken.None);
+
+    await svc.WriteResolutionAsync(task.Id, "README.md", "# resolved by user\n", CancellationToken.None);
+    var result = await svc.ContinueMergeAsync(task.Id, CancellationToken.None);
+
+    Assert.Equal(TaskMergeService.StatusMerged, result.Status);
+    Assert.Equal("# resolved by user\n", File.ReadAllText(Path.Combine(repo.RepoDir, "README.md")));
+    Assert.False(await new GitService().IsMidMergeAsync(repo.RepoDir));
+}
+```
+
+- [ ] **Step 2: Run tests to verify they fail** (no such methods).
+
+Run: `dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --filter "GetConflictsAsync_AfterConflictMerge_ReturnsOursAndTheirs|WriteResolutionAsync_ThenContinue_CompletesMerge"`
+Expected: compile error / FAIL (methods don't exist).
+
+- [ ] **Step 3: Add records + methods to `TaskMergeService.cs`.**
+
+Add records beside `MergeResult` (top of file, after the existing record declarations):
+```csharp
+public sealed record MergeConflicts(
+    string TaskId,
+    IReadOnlyList<ConflictFileContent> Files);
+
+public sealed record ConflictFileContent(
+    string Path,
+    string Ours,
+    string Theirs,
+    string? Base);
+```
+
+Add methods inside the class (after `AbortMergeAsync`):
+```csharp
+public async Task<MergeConflicts> GetConflictsAsync(string taskId, CancellationToken ct)
+{
+    var (_, list, _) = await LoadMergeContextAsync(taskId, ct);
+    if (string.IsNullOrWhiteSpace(list.WorkingDir))
+        throw new InvalidOperationException("list has no working directory");
+
+    var files = await _git.ListConflictedFilesAsync(list.WorkingDir, ct);
+    var result = new List<ConflictFileContent>(files.Count);
+    foreach (var path in files)
+    {
+        var ours   = await _git.ShowStageAsync(list.WorkingDir, 2, path, ct) ?? "";
+        var theirs = await _git.ShowStageAsync(list.WorkingDir, 3, path, ct) ?? "";
+        var @base  = await _git.ShowStageAsync(list.WorkingDir, 1, path, ct);
+        result.Add(new ConflictFileContent(path, ours, theirs, @base));
+    }
+    return new MergeConflicts(taskId, result);
+}
+
+public async Task WriteResolutionAsync(string taskId, string path, string content, CancellationToken ct)
+{
+    var (_, list, _) = await LoadMergeContextAsync(taskId, ct);
+    if (string.IsNullOrWhiteSpace(list.WorkingDir))
+        throw new InvalidOperationException("list has no working directory");
+
+    var full = Path.Combine(list.WorkingDir, path.Replace('/', Path.DirectorySeparatorChar));
+    await File.WriteAllTextAsync(full, content, ct);
+    await _git.AddPathAsync(list.WorkingDir, path, ct);
+}
+```
+(Note: `Path` is `System.IO.Path` — the file already uses it via other helpers; the record property `Path` does not shadow it inside these methods because it's accessed as a static type, not an instance member.)
+
+- [ ] **Step 4: Run the tests to verify they pass.**
+
+Run: `dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --filter "GetConflictsAsync_AfterConflictMerge_ReturnsOursAndTheirs|WriteResolutionAsync_ThenContinue_CompletesMerge"`
+Expected: PASS (2 tests). If git unavailable they no-op.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Worker/Lifecycle/TaskMergeService.cs tests/ClaudeDo.Worker.Tests/Services/TaskMergeServiceTests.cs
+git commit -m "feat(merge): read conflict stages and write user resolutions"
+```
+
+---
+
+## Task 3: WorkerHub conflict methods + DTOs
+
+**Files:**
+- Modify: `src/ClaudeDo.Worker/Hub/WorkerHub.cs`
+
+- [ ] **Step 1: Add DTOs** beside the existing merge DTOs (after `public record MergeTargetsDto(...)`):
+
+```csharp
+public record MergeConflictsDto(string TaskId, IReadOnlyList<ConflictFileDto> Files);
+public record ConflictFileDto(string Path, IReadOnlyList<ConflictHunkDto> Hunks);
+public record ConflictHunkDto(string Ours, string Theirs, string? Base);
+```
+
+- [ ] **Step 2: Add the 5 hub methods** (after `PreviewMerge`). Names/params/returns MUST match the frozen client calls.
+
+```csharp
+public Task<MergeResultDto> StartConflictMerge(string taskId, string targetBranch)
+    => HubGuard(async () =>
+    {
+        var r = await _mergeService.MergeAsync(
+            taskId, targetBranch ?? "", removeWorktree: false, "Merge task",
+            leaveConflictsInTree: true, CancellationToken.None);
+        if (r.Status == TaskMergeService.StatusBlocked)
+            throw new HubException(r.ErrorMessage ?? "merge blocked");
+        return new MergeResultDto(r.Status, r.ConflictFiles, r.ErrorMessage);
+    });
+
+public Task<MergeConflictsDto> GetMergeConflicts(string taskId)
+    => HubGuard(async () =>
+    {
+        var c = await _mergeService.GetConflictsAsync(taskId, CancellationToken.None);
+        return new MergeConflictsDto(
+            c.TaskId,
+            c.Files.Select(f => new ConflictFileDto(
+                f.Path,
+                new[] { new ConflictHunkDto(f.Ours, f.Theirs, f.Base) })).ToList());
+    });
+
+public Task WriteConflictResolution(string taskId, string path, string resolvedContent)
+    => HubGuard(() => _mergeService.WriteResolutionAsync(
+        taskId, path, resolvedContent ?? "", CancellationToken.None));
+
+public Task<MergeResultDto> ContinueMerge(string taskId)
+    => HubGuard(async () =>
+    {
+        var r = await _mergeService.ContinueMergeAsync(taskId, CancellationToken.None);
+        if (r.Status == TaskMergeService.StatusBlocked)
+            throw new HubException(r.ErrorMessage ?? "continue failed");
+        return new MergeResultDto(r.Status, r.ConflictFiles, r.ErrorMessage);
+    });
+
+public Task AbortMerge(string taskId)
+    => HubGuard(async () =>
+    {
+        var r = await _mergeService.AbortMergeAsync(taskId, CancellationToken.None);
+        if (r.Status == TaskMergeService.StatusBlocked)
+            throw new HubException(r.ErrorMessage ?? "abort failed");
+    });
+```
+
+- [ ] **Step 3: Build the Worker project to verify compilation.**
+
+Run: `dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release`
+Expected: Build succeeded, 0 errors.
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add src/ClaudeDo.Worker/Hub/WorkerHub.cs
+git commit -m "feat(hub): expose conflict-resolution merge methods"
+```
+
+---
+
+## Task 4: Conflict UI model
+
+**Files:**
+- Create: `src/ClaudeDo.Ui/ViewModels/Conflicts/ConflictModels.cs`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/ConflictResolverViewModelTests.cs` (model tests added here in Task 5; this task is build-verified)
+
+- [ ] **Step 1: Create the model file.** Shaped so a 3-way pane needs no model change (`Base` retained per hunk).
+
+```csharp
+using System.Collections.Generic;
+using System.Linq;
+using CommunityToolkit.Mvvm.ComponentModel;
+using CommunityToolkit.Mvvm.Input;
+
+namespace ClaudeDo.Ui.ViewModels.Conflicts;
+
+public sealed partial class ConflictHunk : ObservableObject
+{
+    public string Ours { get; }
+    public string Theirs { get; }
+    public string? Base { get; }
+
+    [ObservableProperty] private string? _resolution;
+
+    public bool IsResolved => Resolution is not null;
+
+    public ConflictHunk(string ours, string theirs, string? @base)
+    {
+        Ours = ours;
+        Theirs = theirs;
+        Base = @base;
+    }
+
+    partial void OnResolutionChanged(string? value) => OnPropertyChanged(nameof(IsResolved));
+
+    [RelayCommand] private void AcceptCurrent()  => Resolution = Ours;
+    [RelayCommand] private void AcceptIncoming() => Resolution = Theirs;
+    [RelayCommand] private void AcceptBoth()     => Resolution = Ours + Theirs;
+    [RelayCommand] private void EditManually()   => Resolution ??= Ours;
+}
+
+public sealed class ConflictFile
+{
+    public string Path { get; }
+    public IReadOnlyList<ConflictHunk> Hunks { get; }
+
+    public ConflictFile(string path, IReadOnlyList<ConflictHunk> hunks)
+    {
+        Path = path;
+        Hunks = hunks;
+    }
+
+    public bool AllHunksResolved => Hunks.Count > 0 && Hunks.All(h => h.IsResolved);
+
+    /// <summary>The merged file content: concatenation of each hunk's resolution
+    /// (single whole-file hunk today; concatenation keeps it correct for multi-hunk later).</summary>
+    public string ComposeResolvedContent() => string.Concat(Hunks.Select(h => h.Resolution));
+}
+```
+
+- [ ] **Step 2: Build the Ui project to verify compilation.**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded.
+
+- [ ] **Step 3: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Conflicts/ConflictModels.cs
+git commit -m "feat(ui): add inline conflict model (file/hunk with resolution)"
+```
+
+---
+
+## Task 5: ConflictResolverViewModel
+
+**Files:**
+- Create: `src/ClaudeDo.Ui/ViewModels/Conflicts/ConflictResolverViewModel.cs`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/ConflictResolverViewModelTests.cs`
+
+- [ ] **Step 1: Write failing tests.** Subclass the existing `StubWorkerClient` (its conflict methods are `virtual`).
+
+```csharp
+using System.Collections.Generic;
+using System.Threading.Tasks;
+using ClaudeDo.Ui.Services;
+using ClaudeDo.Ui.ViewModels.Conflicts;
+using Xunit;
+
+namespace ClaudeDo.Ui.Tests.ViewModels;
+
+public class ConflictResolverViewModelTests
+{
+    private sealed class FakeWorker : StubWorkerClient
+    {
+        public string? WrittenPath;
+        public string? WrittenContent;
+        public bool Continued;
+        public bool Aborted;
+        public string ContinueStatus = "merged";
+
+        public override Task<MergeResultDto> StartConflictMergeAsync(string taskId, string targetBranch)
+            => Task.FromResult(new MergeResultDto("conflict", new[] { "README.md" }, null));
+
+        public override Task<MergeConflictsDto> GetMergeConflictsAsync(string taskId)
+            => Task.FromResult(new MergeConflictsDto(taskId, new[]
+            {
+                new ConflictFileDto("README.md", new[] { new ConflictHunkDto("ours\n", "theirs\n", "base\n") })
+            }));
+
+        public override Task WriteConflictResolutionAsync(string taskId, string path, string resolvedContent)
+        {
+            WrittenPath = path; WrittenContent = resolvedContent; return Task.CompletedTask;
+        }
+
+        public override Task<MergeResultDto> ContinueMergeAsync(string taskId)
+        {
+            Continued = true;
+            return Task.FromResult(new MergeResultDto(ContinueStatus, System.Array.Empty<string>(), null));
+        }
+
+        public override Task AbortMergeAsync(string taskId) { Aborted = true; return Task.CompletedTask; }
+    }
+
+    [Fact]
+    public async Task OpenAsync_LoadsConflicts_AndBlocksContinueUntilResolved()
+    {
+        var vm = new ConflictResolverViewModel(new FakeWorker(), "task-1");
+        var hasConflicts = await vm.OpenAsync("main");
+
+        Assert.True(hasConflicts);
+        var file = Assert.Single(vm.Files);
+        Assert.Equal("README.md", file.Path);
+        Assert.False(vm.CanContinue);                 // nothing resolved yet
+
+        file.Hunks[0].AcceptIncomingCommand.Execute(null);
+        Assert.True(vm.CanContinue);                   // every hunk resolved
+    }
+
+    [Fact]
+    public async Task Continue_WritesComposedResolution_AndClosesOnMerged()
+    {
+        var worker = new FakeWorker();
+        var vm = new ConflictResolverViewModel(worker, "task-1");
+        var closed = false;
+        vm.CloseRequested = () => closed = true;
+
+        await vm.OpenAsync("main");
+        vm.Files[0].Hunks[0].AcceptCurrentCommand.Execute(null);   // resolution = "ours\n"
+        await vm.ContinueCommand.ExecuteAsync(null);
+
+        Assert.Equal("README.md", worker.WrittenPath);
+        Assert.Equal("ours\n", worker.WrittenContent);
+        Assert.True(worker.Continued);
+        Assert.True(closed);
+    }
+
+    [Fact]
+    public async Task Continue_StaysOpenAndReportsError_WhenStillConflicted()
+    {
+        var worker = new FakeWorker { ContinueStatus = "conflict" };
+        var vm = new ConflictResolverViewModel(worker, "task-1");
+        var closed = false;
+        vm.CloseRequested = () => closed = true;
+
+        await vm.OpenAsync("main");
+        vm.Files[0].Hunks[0].AcceptBothCommand.Execute(null);
+        await vm.ContinueCommand.ExecuteAsync(null);
+
+        Assert.False(closed);
+        Assert.NotNull(vm.Error);
+    }
+
+    [Fact]
+    public async Task Abort_CallsWorkerAndCloses()
+    {
+        var worker = new FakeWorker();
+        var vm = new ConflictResolverViewModel(worker, "task-1");
+        var closed = false;
+        vm.CloseRequested = () => closed = true;
+
+        await vm.AbortCommand.ExecuteAsync(null);
+
+        Assert.True(worker.Aborted);
+        Assert.True(closed);
+    }
+}
+```
+
+- [ ] **Step 2: Run tests to verify they fail** (VM not defined).
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter "ConflictResolverViewModelTests"`
+Expected: compile error / FAIL.
+
+- [ ] **Step 3: Implement the ViewModel.**
+
+```csharp
+using System;
+using System.Collections.ObjectModel;
+using System.ComponentModel;
+using System.Linq;
+using System.Threading.Tasks;
+using CommunityToolkit.Mvvm.ComponentModel;
+using CommunityToolkit.Mvvm.Input;
+using ClaudeDo.Ui.Services;
+
+namespace ClaudeDo.Ui.ViewModels.Conflicts;
+
+public sealed partial class ConflictResolverViewModel : ObservableObject
+{
+    private readonly IWorkerClient _worker;
+    private readonly string _taskId;
+
+    public ObservableCollection<ConflictFile> Files { get; } = new();
+
+    [ObservableProperty] private bool _isBusy;
+    [ObservableProperty] private string? _error;
+    [ObservableProperty] private bool _canContinue;
+
+    public string TaskId => _taskId;
+    public Action? CloseRequested { get; set; }
+
+    public ConflictResolverViewModel(IWorkerClient worker, string taskId)
+    {
+        _worker = worker;
+        _taskId = taskId;
+    }
+
+    /// <summary>Starts the conflict merge and loads ours/theirs/base per file.
+    /// Returns true when there are conflicts to resolve (caller should show the dialog).</summary>
+    public async Task<bool> OpenAsync(string targetBranch)
+    {
+        IsBusy = true;
+        Error = null;
+        try
+        {
+            var start = await _worker.StartConflictMergeAsync(_taskId, targetBranch);
+            if (!string.Equals(start.Status, "conflict", StringComparison.Ordinal))
+            {
+                if (string.Equals(start.Status, "blocked", StringComparison.Ordinal))
+                    Error = start.ErrorMessage;
+                return false;
+            }
+
+            var conflicts = await _worker.GetMergeConflictsAsync(_taskId);
+            Files.Clear();
+            foreach (var f in conflicts.Files)
+            {
+                var hunks = f.Hunks.Select(h =>
+                {
+                    var hk = new ConflictHunk(h.Ours, h.Theirs, h.Base);
+                    hk.PropertyChanged += OnHunkChanged;
+                    return hk;
+                }).ToList();
+                Files.Add(new ConflictFile(f.Path, hunks));
+            }
+            RecomputeCanContinue();
+            return Files.Count > 0;
+        }
+        catch (Exception ex)
+        {
+            Error = ex.Message;
+            return false;
+        }
+        finally { IsBusy = false; }
+    }
+
+    private void OnHunkChanged(object? sender, PropertyChangedEventArgs e)
+    {
+        if (e.PropertyName is nameof(ConflictHunk.IsResolved) or nameof(ConflictHunk.Resolution))
+            RecomputeCanContinue();
+    }
+
+    private void RecomputeCanContinue()
+        => CanContinue = Files.Count > 0 && Files.All(f => f.AllHunksResolved);
+
+    [RelayCommand]
+    private async Task ContinueAsync()
+    {
+        if (!CanContinue) return;
+        IsBusy = true;
+        Error = null;
+        try
+        {
+            foreach (var file in Files)
+                await _worker.WriteConflictResolutionAsync(_taskId, file.Path, file.ComposeResolvedContent());
+
+            var result = await _worker.ContinueMergeAsync(_taskId);
+            if (string.Equals(result.Status, "merged", StringComparison.Ordinal))
+                CloseRequested?.Invoke();
+            else
+                Error = result.ErrorMessage ?? "Conflicts not fully resolved — review and retry.";
+        }
+        catch (Exception ex)
+        {
+            Error = ex.Message;
+        }
+        finally { IsBusy = false; }
+    }
+
+    [RelayCommand]
+    private async Task AbortAsync()
+    {
+        IsBusy = true;
+        try { await _worker.AbortMergeAsync(_taskId); }
+        catch (Exception ex) { Error = ex.Message; }
+        finally
+        {
+            IsBusy = false;
+            CloseRequested?.Invoke();
+        }
+    }
+}
+```
+
+- [ ] **Step 4: Run tests to verify they pass.**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter "ConflictResolverViewModelTests"`
+Expected: PASS (4 tests).
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Conflicts/ConflictResolverViewModel.cs tests/ClaudeDo.Ui.Tests/ViewModels/ConflictResolverViewModelTests.cs
+git commit -m "feat(ui): add inline conflict resolver view-model"
+```
+
+---
+
+## Task 6: ConflictResolverView + localization
+
+**Files:**
+- Create: `src/ClaudeDo.Ui/Views/Conflicts/ConflictResolverView.axaml`
+- Create: `src/ClaudeDo.Ui/Views/Conflicts/ConflictResolverView.axaml.cs`
+- Modify: `src/ClaudeDo.Localization/locales/en.json`
+- Modify: `src/ClaudeDo.Localization/locales/de.json`
+
+- [ ] **Step 1: Add localization keys** to `en.json` as a new top-level section (sibling of `"planning"`):
+
+```json
+  "conflictResolver": {
+    "windowTitle": "Resolve merge conflicts",
+    "modalTitle": "RESOLVE CONFLICTS",
+    "loading": "Loading conflicts…",
+    "current": "Current (ours)",
+    "incoming": "Incoming (theirs)",
+    "mergedResult": "Merged result",
+    "acceptCurrent": "Accept Current",
+    "acceptIncoming": "Accept Incoming",
+    "acceptBoth": "Accept Both",
+    "editManually": "Edit manually",
+    "continue": "Resolve & continue",
+    "abort": "Abort merge"
+  },
+```
+
+- [ ] **Step 2: Add the SAME keys to `de.json`** (German values, identical key set — parity enforced by Localization.Tests):
+
+```json
+  "conflictResolver": {
+    "windowTitle": "Merge-Konflikte lösen",
+    "modalTitle": "KONFLIKTE LÖSEN",
+    "loading": "Konflikte werden geladen…",
+    "current": "Aktuell (unsere)",
+    "incoming": "Eingehend (ihre)",
+    "mergedResult": "Zusammengeführtes Ergebnis",
+    "acceptCurrent": "Aktuelle übernehmen",
+    "acceptIncoming": "Eingehende übernehmen",
+    "acceptBoth": "Beide übernehmen",
+    "editManually": "Manuell bearbeiten",
+    "continue": "Lösen & fortfahren",
+    "abort": "Merge abbrechen"
+  },
+```
+
+- [ ] **Step 3: Create the View** (`ConflictResolverView.axaml`). A `Window` using `ModalShell`, mirroring `ConflictResolutionView.axaml`. Two stacked read-only boxes (ours/theirs), a button row, and a two-way merged-result box per hunk.
+
+```xml
+<Window xmlns="https://github.com/avaloniaui"
+        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
+        xmlns:vm="using:ClaudeDo.Ui.ViewModels.Conflicts"
+        xmlns:ctl="using:ClaudeDo.Ui.Views.Controls"
+        xmlns:loc="using:ClaudeDo.Ui.Localization"
+        x:DataType="vm:ConflictResolverViewModel"
+        x:Class="ClaudeDo.Ui.Views.Conflicts.ConflictResolverView"
+        Title="{loc:Tr conflictResolver.windowTitle}"
+        Width="760" Height="640" MinWidth="560" MinHeight="420"
+        CanResize="True"
+        WindowDecorations="BorderOnly"
+        ExtendClientAreaToDecorationsHint="True"
+        ExtendClientAreaTitleBarHeightHint="-1"
+        WindowStartupLocation="CenterOwner"
+        Background="{DynamicResource SurfaceBrush}">
+
+  <Window.KeyBindings>
+    <KeyBinding Gesture="Escape" Command="{Binding AbortCommand}"/>
+  </Window.KeyBindings>
+
+  <ctl:ModalShell Title="{loc:Tr conflictResolver.modalTitle}" CloseCommand="{Binding AbortCommand}">
+    <ctl:ModalShell.Footer>
+      <StackPanel Orientation="Horizontal" Spacing="8"
+                  HorizontalAlignment="Right" VerticalAlignment="Center">
+        <Button Classes="btn" Content="{loc:Tr conflictResolver.continue}"
+                Command="{Binding ContinueCommand}" IsEnabled="{Binding CanContinue}"/>
+        <Button Classes="btn" Content="{loc:Tr conflictResolver.abort}" Command="{Binding AbortCommand}"/>
+      </StackPanel>
+    </ctl:ModalShell.Footer>
+
+    <Grid RowDefinitions="Auto,*" Margin="16,12">
+      <TextBlock Grid.Row="0" Classes="meta" Margin="0,0,0,8"
+                 Text="{loc:Tr conflictResolver.loading}"
+                 IsVisible="{Binding IsBusy}"/>
+      <TextBlock Grid.Row="0" Classes="meta" Foreground="{DynamicResource BloodBrush}"
+                 Text="{Binding Error}" TextWrapping="Wrap"
+                 IsVisible="{Binding Error, Converter={x:Static ObjectConverters.IsNotNull}}"/>
+
+      <ScrollViewer Grid.Row="1">
+        <ItemsControl ItemsSource="{Binding Files}">
+          <ItemsControl.ItemTemplate>
+            <DataTemplate x:DataType="vm:ConflictFile">
+              <StackPanel Spacing="8" Margin="0,0,0,16">
+                <TextBlock Classes="path-mono heading" Text="{Binding Path}"/>
+                <ItemsControl ItemsSource="{Binding Hunks}">
+                  <ItemsControl.ItemTemplate>
+                    <DataTemplate x:DataType="vm:ConflictHunk">
+                      <Border BorderBrush="{DynamicResource BorderBrush}" BorderThickness="1"
+                              CornerRadius="6" Padding="10" Margin="0,0,0,8">
+                        <StackPanel Spacing="6">
+                          <TextBlock Classes="meta" Text="{loc:Tr conflictResolver.current}"/>
+                          <TextBox Text="{Binding Ours, Mode=OneWay}" IsReadOnly="True"
+                                   TextWrapping="NoWrap" AcceptsReturn="True" MaxHeight="120"
+                                   FontFamily="{DynamicResource MonoFont}"/>
+                          <TextBlock Classes="meta" Text="{loc:Tr conflictResolver.incoming}"/>
+                          <TextBox Text="{Binding Theirs, Mode=OneWay}" IsReadOnly="True"
+                                   TextWrapping="NoWrap" AcceptsReturn="True" MaxHeight="120"
+                                   FontFamily="{DynamicResource MonoFont}"/>
+                          <StackPanel Orientation="Horizontal" Spacing="6">
+                            <Button Classes="btn" Content="{loc:Tr conflictResolver.acceptCurrent}"
+                                    Command="{Binding AcceptCurrentCommand}"/>
+                            <Button Classes="btn" Content="{loc:Tr conflictResolver.acceptIncoming}"
+                                    Command="{Binding AcceptIncomingCommand}"/>
+                            <Button Classes="btn" Content="{loc:Tr conflictResolver.acceptBoth}"
+                                    Command="{Binding AcceptBothCommand}"/>
+                            <Button Classes="btn" Content="{loc:Tr conflictResolver.editManually}"
+                                    Command="{Binding EditManuallyCommand}"/>
+                          </StackPanel>
+                          <TextBlock Classes="meta" Text="{loc:Tr conflictResolver.mergedResult}"/>
+                          <TextBox Text="{Binding Resolution, Mode=TwoWay}"
+                                   TextWrapping="NoWrap" AcceptsReturn="True" MinHeight="80" MaxHeight="200"
+                                   FontFamily="{DynamicResource MonoFont}"/>
+                        </StackPanel>
+                      </Border>
+                    </DataTemplate>
+                  </ItemsControl.ItemTemplate>
+                </ItemsControl>
+              </StackPanel>
+            </DataTemplate>
+          </ItemsControl.ItemTemplate>
+        </ItemsControl>
+      </ScrollViewer>
+    </Grid>
+  </ctl:ModalShell>
+</Window>
+```
+**Note for the implementer:** if `MonoFont` / `path-mono` / `heading` / `meta` / `btn` resource keys or style classes don't resolve at build, drop the `FontFamily` attribute and unknown `Classes` (keep `btn`) — match whatever the existing `ConflictResolutionView.axaml` and app styles actually expose. Verify against `src/ClaudeDo.Ui/Views/Planning/ConflictResolutionView.axaml` and the app's style resources before finalizing.
+
+- [ ] **Step 4: Create the code-behind** (`ConflictResolverView.axaml.cs`):
+
+```csharp
+using Avalonia.Controls;
+using ClaudeDo.Ui.ViewModels.Conflicts;
+
+namespace ClaudeDo.Ui.Views.Conflicts;
+
+public partial class ConflictResolverView : Window
+{
+    public ConflictResolverView()
+    {
+        InitializeComponent();
+    }
+
+    protected override void OnDataContextChanged(System.EventArgs e)
+    {
+        base.OnDataContextChanged(e);
+        if (DataContext is ConflictResolverViewModel vm)
+            vm.CloseRequested = Close;
+    }
+}
+```
+
+- [ ] **Step 5: Build the App + run Localization tests.**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release && dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release`
+Expected: Build succeeded; localization parity tests PASS.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/Views/Conflicts/ConflictResolverView.axaml src/ClaudeDo.Ui/Views/Conflicts/ConflictResolverView.axaml.cs src/ClaudeDo.Localization/locales/en.json src/ClaudeDo.Localization/locales/de.json
+git commit -m "feat(ui): add inline conflict resolver view and localization"
+```
+
+---
+
+## Task 7: Wire factory + dialog seam for the integrator
+
+**Files:**
+- Modify: `src/ClaudeDo.App/Program.cs`
+- Modify: `src/ClaudeDo.Ui/ViewModels/IslandsShellViewModel.cs`
+- Modify: `src/ClaudeDo.Ui/Views/MainWindow.axaml.cs`
+
+These are additive seams only. The integrator connects Layer A/B's `RequestConflictResolution(taskId, target)` callback to `IslandsShellViewModel.RequestConflictResolutionAsync`.
+
+- [ ] **Step 1: Register the factory in `Program.cs`** (in the ViewModels region, near the other `Func<>` factories). Only the `Func<>` factory is needed — the VM is never resolved directly:
+
+```csharp
+sc.AddSingleton<Func<string, ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel>>(sp =>
+    taskId => new ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel(
+        sp.GetRequiredService<WorkerClient>(), taskId));
+```
+Then, after `IslandsShellViewModel` is registered, set the factory on it once resolved. Replace the existing `sc.AddSingleton<IslandsShellViewModel>();` registration with a factory that injects the conflict-resolver factory:
+
+```csharp
+sc.AddSingleton<IslandsShellViewModel>(sp =>
+{
+    var shell = ActivatorUtilities.CreateInstance<IslandsShellViewModel>(sp);
+    shell.ConflictResolverFactory =
+        sp.GetRequiredService<Func<string, ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel>>();
+    return shell;
+});
+```
+(`ActivatorUtilities.CreateInstance` resolves the existing big constructor + its `Func<>` deps exactly as the default registration did.)
+
+- [ ] **Step 2: Add the additive seam to `IslandsShellViewModel`** (near the other `Show*` delegate properties):
+
+```csharp
+// Layer C seam: composition root sets the factory; MainWindow sets the dialog opener.
+// The integrator connects Layer A/B's RequestConflictResolution(taskId, target) to this method.
+public Func<string, ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel>? ConflictResolverFactory { get; set; }
+public Func<ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel, Task>? ShowConflictResolver { get; set; }
+
+public async Task RequestConflictResolutionAsync(string taskId, string targetBranch)
+{
+    if (ConflictResolverFactory is null || ShowConflictResolver is null) return;
+    var vm = ConflictResolverFactory(taskId);
+    var hasConflicts = await vm.OpenAsync(targetBranch);
+    if (hasConflicts)
+        await ShowConflictResolver(vm);
+}
+```
+(Add `using ClaudeDo.Ui.ViewModels.Conflicts;` or use fully-qualified names as above.)
+
+- [ ] **Step 3: Wire the dialog opener in `MainWindow.axaml.cs`** inside `OnDataContextChanged`, alongside the other `vm.Show*` assignments:
+
+```csharp
+vm.ShowConflictResolver = async (resolverVm) =>
+{
+    var dlg = new ClaudeDo.Ui.Views.Conflicts.ConflictResolverView { DataContext = resolverVm };
+    await dlg.ShowDialog(this);
+};
+```
+
+- [ ] **Step 4: Build the App to verify compilation.**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.App/Program.cs src/ClaudeDo.Ui/ViewModels/IslandsShellViewModel.cs src/ClaudeDo.Ui/Views/MainWindow.axaml.cs
+git commit -m "feat(ui): expose conflict-resolver factory and dialog seam for integrator"
+```
+
+---
+
+## Task 8: Full verification
+
+- [ ] **Step 1: Build both head projects.**
+
+Run:
+```bash
+dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+```
+Expected: both Build succeeded, 0 errors/warnings.
+
+- [ ] **Step 2: Run the full relevant test suites.**
+
+Run:
+```bash
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
+```
+Expected: all PASS.
+
+- [ ] **Step 3: Flag visual verification.** The resolver dialog cannot be opened end-to-end until the integrator wires Layer A/B's `RequestConflictResolution(taskId, target)` → `IslandsShellViewModel.RequestConflictResolutionAsync`. Report this as a visual-verification gap for the user/integrator: open a real conflicting merge, confirm hunks render, Accept buttons populate the merged box, Resolve & continue closes on success, Abort restores the tree.
+
+- [ ] **Step 4: Leave the branch for the orchestrator.** Do NOT push, do NOT merge to main.

docs/superpowers/plans/2026-06-05-merge-cockpit-layer-b.md

@@ -0,0 +1,837 @@
+# Layer B — Multi-Worktree Merge Cockpit Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Turn the worktrees-overview modal into a batch-merge cockpit (multi-select N worktrees → one target branch → "Merge all" with skip-and-continue conflict collection), and migrate `WorktreeModalView`'s bespoke inline diff onto the canonical `DiffLinesView`.
+
+**Architecture:** The cockpit VM keeps depending on the concrete `WorkerClient` (the overview/cleanup/state methods live only on `WorkerClient`, not `IWorkerClient`). The batch loop is extracted into a delegate-driven method `MergeSelectedAsync(Func<...> mergeFn)` so it is unit-testable with a fake merge function and a never-connected `WorkerClient`. Clean merges (`Status=="merged"`) update the row; conflicts (`Status=="conflict"`, which `MergeTaskAsync` already auto-aborts) are collected into a `ConflictRows` list whose rows expose a `Resolve` button wired to an inert `RequestConflictResolution(taskId, targetBranch)` seam. The diff migration replaces the right-pane `ItemsControl` in `WorktreeModalView` with `DiffLinesView`, feeding it `DiffLineViewModel`s produced by `UnifiedDiffParser`, and deletes the now-dead `WorktreeDiffLineViewModel`/`WorktreeDiffLineKind`.
+
+**Tech Stack:** .NET 8, Avalonia 12, CommunityToolkit.Mvvm source generators, xUnit. Build UI with `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`; run `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release`.
+
+**Frozen contracts reused (do NOT modify):**
+- `WorkerClient.MergeTaskAsync(string taskId, string targetBranch, bool removeWorktree, string commitMessage) -> Task<MergeResultDto>`
+- `WorkerClient.GetMergeTargetsAsync(string taskId) -> Task<MergeTargetsDto?>` (`MergeTargetsDto(string DefaultBranch, IReadOnlyList<string> LocalBranches)`)
+- `MergeResultDto(string Status, IReadOnlyList<string> ConflictFiles, string? ErrorMessage)` — `Status` is `"merged" | "conflict" | "blocked" | <other>`
+- `WorkerClient.GetWorktreesOverviewAsync`, `CleanupFinishedWorktreesAsync`, `SetWorktreeStateAsync`, `ForceRemoveWorktreeAsync`
+- `GitService.GetFileDiffAsync(worktreePath, baseCommit?, relativePath)` returns a `git diff` blob including the `diff --git` header (so `UnifiedDiffParser.Parse` handles it)
+- `DiffLinesView` (`Lines` styled property, `IEnumerable?`), `DiffLineViewModel`, `DiffFileViewModel`, `UnifiedDiffParser.Parse` / `.Flatten`
+
+**Do NOT touch:** any worker-side files (`WorkerHub`, `TaskMergeService`, `GitService`), `IWorkerClient.cs` / `WorkerClient.cs`, `WorkConsole.axaml`, `DetailsIslandViewModel.cs`, and do not create any `ConflictResolver` UI or reference any `ConflictResolver` type.
+
+---
+
+## File Structure
+
+- `src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs` — **modify.** Add `BatchMergeOutcome` enum; add `IsChecked`/`MergeOutcome` (+ derived) to the row VM; add `MergeTargets`, `SelectedTarget`, `SelectedCount`, `IsMerging`, `BatchProgress`, `ConflictRows`, the `RequestConflictResolution` seam, `MergeSelectedAsync`, `MergeAllCommand`, `ResolveConflictCommand`, `ToggleSelectAllCommand`, target loading, and per-row check subscription. Keep all existing context-menu commands/wiring intact.
+- `src/ClaudeDo.Ui/Views/Modals/WorktreesOverviewModalView.axaml` — **modify.** Add a per-row checkbox + outcome badge, a target `ComboBox` + "Merge all" button + progress text in the toolbar, and a "Needs resolution" panel listing `ConflictRows` with `Resolve` buttons.
+- `src/ClaudeDo.Ui/ViewModels/Modals/WorktreeModalViewModel.cs` — **modify.** Replace `SelectedFileDiffLines` element type with `DiffLineViewModel` produced via `UnifiedDiffParser`; delete `WorktreeDiffLineKind` and `WorktreeDiffLineViewModel`.
+- `src/ClaudeDo.Ui/Views/Modals/WorktreeModalView.axaml` — **modify.** Replace the right-pane `ItemsControl` with `ctl:DiffLinesView`; drop the `DiffLineKindToBrushConverter` resource.
+- `src/ClaudeDo.Localization/locales/en.json` + `de.json` — **modify.** Add new `modals.worktreesOverview.*` and `vm.worktreesOverview.*` keys (keep parity).
+- `tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs` — **create.** Unit tests for `MergeSelectedAsync` skip-and-continue, conflict collection, progress, selection gating, and the resolve seam.
+
+No `IWorkerClient` change → no test-fake updates needed.
+
+---
+
+## Task 1: Row-level batch state (outcome enum + row VM fields)
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs`
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs`:
+
+```csharp
+using ClaudeDo.Data.Models;
+using ClaudeDo.Ui.ViewModels.Modals;
+using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
+using Xunit;
+
+namespace ClaudeDo.Ui.Tests.ViewModels;
+
+public class WorktreesOverviewBatchMergeTests
+{
+    private static WorktreeOverviewRowViewModel ActiveRow(string id) => new()
+    {
+        TaskId = id,
+        TaskTitle = $"Task {id}",
+        TaskStatus = TaskStatus.WaitingForReview,
+        State = WorktreeState.Active,
+    };
+
+    [Fact]
+    public void Row_outcome_helpers_reflect_state()
+    {
+        var row = ActiveRow("a");
+        Assert.Equal(BatchMergeOutcome.None, row.MergeOutcome);
+        Assert.False(row.IsConflict);
+
+        row.MergeOutcome = BatchMergeOutcome.Conflict;
+        Assert.True(row.IsConflict);
+
+        row.MergeOutcome = BatchMergeOutcome.Merged;
+        Assert.False(row.IsConflict);
+    }
+}
+```
+
+- [ ] **Step 2: Run test to verify it fails**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter WorktreesOverviewBatchMergeTests`
+Expected: FAIL — `BatchMergeOutcome` and `MergeOutcome`/`IsConflict` do not exist (compile error).
+
+- [ ] **Step 3: Add the enum and row fields**
+
+In `WorktreesOverviewModalViewModel.cs`, add the enum just above `WorktreeOverviewRowViewModel`:
+
+```csharp
+public enum BatchMergeOutcome { None, Merging, Merged, Conflict, Blocked, Failed }
+```
+
+Inside `WorktreeOverviewRowViewModel`, add after the existing `_isSelected` field:
+
+```csharp
+    [ObservableProperty] private bool _isChecked;
+    [ObservableProperty]
+    [NotifyPropertyChangedFor(nameof(IsConflict))]
+    [NotifyPropertyChangedFor(nameof(HasOutcome))]
+    private BatchMergeOutcome _mergeOutcome;
+
+    public bool IsConflict => MergeOutcome == BatchMergeOutcome.Conflict;
+    public bool HasOutcome => MergeOutcome != BatchMergeOutcome.None;
+```
+
+- [ ] **Step 4: Run test to verify it passes**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter WorktreesOverviewBatchMergeTests`
+Expected: PASS (1 test).
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs
+git commit -m "feat(ui): add batch-merge row state to worktrees cockpit VM"
+```
+
+---
+
+## Task 2: Batch orchestration (`MergeSelectedAsync` skip-and-continue)
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs`
+
+- [ ] **Step 1: Write the failing tests**
+
+Append to `WorktreesOverviewBatchMergeTests.cs`. The helper builds a VM with a never-connected `WorkerClient` (the loop never touches it) and seeds `Rows` directly:
+
+```csharp
+    private static WorktreesOverviewModalViewModel NewVm() =>
+        new(new ClaudeDo.Ui.Services.WorkerClient("http://127.0.0.1:1/hub"), () => null!);
+
+    private static MergeResultDto Merged() => new("merged", System.Array.Empty<string>(), null);
+    private static MergeResultDto Conflict() => new("conflict", new[] { "f.cs" }, null);
+    private static MergeResultDto Blocked() => new("blocked", System.Array.Empty<string>(), "blocked");
+
+    [Fact]
+    public async System.Threading.Tasks.Task MergeSelected_only_processes_checked_active_rows()
+    {
+        var vm = NewVm();
+        var a = ActiveRow("a"); a.IsChecked = true;
+        var b = ActiveRow("b"); b.IsChecked = false;          // unchecked -> skipped
+        var c = ActiveRow("c"); c.IsChecked = true; c.State = WorktreeState.Merged; // not active -> skipped
+        vm.Rows.Add(a); vm.Rows.Add(b); vm.Rows.Add(c);
+        vm.SelectedTarget = "main";
+
+        var seen = new System.Collections.Generic.List<string>();
+        await vm.MergeSelectedAsync((id, target, remove, msg) =>
+        {
+            seen.Add(id);
+            Assert.Equal("main", target);
+            Assert.False(remove);                              // removeWorktree must be false
+            return System.Threading.Tasks.Task.FromResult(Merged());
+        });
+
+        Assert.Equal(new[] { "a" }, seen);
+        Assert.Equal(BatchMergeOutcome.Merged, a.MergeOutcome);
+        Assert.False(a.IsChecked);                             // cleared after merge
+    }
+
+    [Fact]
+    public async System.Threading.Tasks.Task MergeSelected_continues_past_conflict_and_collects_it()
+    {
+        var vm = NewVm();
+        var a = ActiveRow("a"); a.IsChecked = true;
+        var b = ActiveRow("b"); b.IsChecked = true;
+        var c = ActiveRow("c"); c.IsChecked = true;
+        vm.Rows.Add(a); vm.Rows.Add(b); vm.Rows.Add(c);
+        vm.SelectedTarget = "main";
+
+        await vm.MergeSelectedAsync((id, target, remove, msg) =>
+            System.Threading.Tasks.Task.FromResult(id == "b" ? Conflict() : Merged()));
+
+        Assert.Equal(BatchMergeOutcome.Merged, a.MergeOutcome);
+        Assert.Equal(BatchMergeOutcome.Conflict, b.MergeOutcome);
+        Assert.Equal(BatchMergeOutcome.Merged, c.MergeOutcome);   // continued past the conflict
+        Assert.Contains(b, vm.ConflictRows);
+        Assert.Single(vm.ConflictRows);
+    }
+
+    [Fact]
+    public async System.Threading.Tasks.Task MergeSelected_maps_blocked_and_exception_to_failure_outcomes()
+    {
+        var vm = NewVm();
+        var a = ActiveRow("a"); a.IsChecked = true;
+        var b = ActiveRow("b"); b.IsChecked = true;
+        vm.Rows.Add(a); vm.Rows.Add(b);
+        vm.SelectedTarget = "main";
+
+        await vm.MergeSelectedAsync((id, target, remove, msg) => id == "a"
+            ? System.Threading.Tasks.Task.FromResult(Blocked())
+            : throw new System.InvalidOperationException("boom"));
+
+        Assert.Equal(BatchMergeOutcome.Blocked, a.MergeOutcome);
+        Assert.Equal(BatchMergeOutcome.Failed, b.MergeOutcome);
+        Assert.Empty(vm.ConflictRows);
+        Assert.False(vm.IsMerging);
+    }
+
+    [Fact]
+    public async System.Threading.Tasks.Task MergeSelected_noop_when_no_target()
+    {
+        var vm = NewVm();
+        var a = ActiveRow("a"); a.IsChecked = true;
+        vm.Rows.Add(a);
+        vm.SelectedTarget = null;
+
+        var called = false;
+        await vm.MergeSelectedAsync((id, t, r, m) => { called = true; return System.Threading.Tasks.Task.FromResult(Merged()); });
+
+        Assert.False(called);
+        Assert.Equal(BatchMergeOutcome.None, a.MergeOutcome);
+    }
+```
+
+- [ ] **Step 2: Run tests to verify they fail**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter WorktreesOverviewBatchMergeTests`
+Expected: FAIL — `MergeSelectedAsync`, `ConflictRows`, `IsMerging`, `SelectedTarget` do not exist (compile error).
+
+- [ ] **Step 3: Implement the orchestration + cockpit fields**
+
+In `WorktreesOverviewModalViewModel.cs`, add these `using`s if missing: `using ClaudeDo.Ui.Services;` (already present). Add fields/properties to `WorktreesOverviewModalViewModel` (after the existing `_selectedRow` field):
+
+```csharp
+    [ObservableProperty][NotifyCanExecuteChangedFor(nameof(MergeAllCommand))] private string? _selectedTarget;
+    [ObservableProperty][NotifyCanExecuteChangedFor(nameof(MergeAllCommand))] private int _selectedCount;
+    [ObservableProperty][NotifyCanExecuteChangedFor(nameof(MergeAllCommand))] private bool _isMerging;
+    [ObservableProperty] private string? _batchProgress;
+
+    public ObservableCollection<string> MergeTargets { get; } = new();
+    public ObservableCollection<WorktreeOverviewRowViewModel> ConflictRows { get; } = new();
+
+    /// Inert seam wired by the integrator to Layer C's resolver at merge time. (taskId, targetBranch)
+    public Func<string, string, Task>? RequestConflictResolution { get; set; }
+```
+
+Add a helper to enumerate rows regardless of grouped/flat mode, plus the orchestration method:
+
+```csharp
+    public IEnumerable<WorktreeOverviewRowViewModel> AllRows =>
+        IsGlobal ? Groups.SelectMany(g => g.Rows) : Rows;
+
+    public async Task MergeSelectedAsync(
+        Func<string, string, bool, string, Task<MergeResultDto>> mergeFn,
+        CancellationToken ct = default)
+    {
+        var target = SelectedTarget;
+        if (string.IsNullOrWhiteSpace(target)) return;
+
+        var selected = AllRows.Where(r => r.IsChecked && r.IsActive).ToList();
+        if (selected.Count == 0) return;
+
+        IsMerging = true;
+        ConflictRows.Clear();
+        var done = 0;
+        try
+        {
+            foreach (var row in selected)
+            {
+                ct.ThrowIfCancellationRequested();
+                row.MergeOutcome = BatchMergeOutcome.Merging;
+                BatchProgress = Loc.T("vm.worktreesOverview.batchProgress", ++done, selected.Count);
+
+                MergeResultDto result;
+                try
+                {
+                    result = await mergeFn(row.TaskId, target!, false,
+                        Loc.T("vm.merge.commitMessage", row.TaskTitle));
+                }
+                catch
+                {
+                    row.MergeOutcome = BatchMergeOutcome.Failed;
+                    continue;
+                }
+
+                switch (result.Status)
+                {
+                    case "merged":
+                        row.MergeOutcome = BatchMergeOutcome.Merged;
+                        row.State = WorktreeState.Merged;
+                        row.IsChecked = false;
+                        break;
+                    case "conflict":
+                        row.MergeOutcome = BatchMergeOutcome.Conflict;
+                        ConflictRows.Add(row);
+                        break;
+                    case "blocked":
+                        row.MergeOutcome = BatchMergeOutcome.Blocked;
+                        break;
+                    default:
+                        row.MergeOutcome = BatchMergeOutcome.Failed;
+                        break;
+                }
+            }
+            BatchProgress = Loc.T("vm.worktreesOverview.batchDone",
+                selected.Count(r => r.MergeOutcome == BatchMergeOutcome.Merged), ConflictRows.Count);
+        }
+        finally
+        {
+            IsMerging = false;
+        }
+    }
+```
+
+> Note: `Loc.T` keys are added in Task 5; they resolve to the key name (harmless) until then, so tests pass now.
+
+- [ ] **Step 4: Run tests to verify they pass**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter WorktreesOverviewBatchMergeTests`
+Expected: PASS (5 tests).
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs
+git commit -m "feat(ui): add skip-and-continue batch merge orchestration"
+```
+
+---
+
+## Task 3: Selection tracking, target loading, commands + resolve seam
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs`
+
+- [ ] **Step 1: Write the failing tests**
+
+Append to `WorktreesOverviewBatchMergeTests.cs`:
+
+```csharp
+    [Fact]
+    public void SelectedCount_tracks_checked_active_rows()
+    {
+        var vm = NewVm();
+        var a = ActiveRow("a");
+        var b = ActiveRow("b");
+        var merged = ActiveRow("c"); merged.State = WorktreeState.Merged;
+        vm.AddRowForTest(a); vm.AddRowForTest(b); vm.AddRowForTest(merged);
+
+        Assert.Equal(0, vm.SelectedCount);
+        a.IsChecked = true;
+        Assert.Equal(1, vm.SelectedCount);
+        b.IsChecked = true;
+        merged.IsChecked = true;                 // not active -> not counted
+        Assert.Equal(2, vm.SelectedCount);
+        a.IsChecked = false;
+        Assert.Equal(1, vm.SelectedCount);
+    }
+
+    [Fact]
+    public void ResolveConflict_invokes_seam_with_task_and_target()
+    {
+        var vm = NewVm();
+        vm.SelectedTarget = "release";
+        var row = ActiveRow("x"); row.MergeOutcome = BatchMergeOutcome.Conflict;
+
+        (string Task, string Target)? captured = null;
+        vm.RequestConflictResolution = (taskId, target) => { captured = (taskId, target); return System.Threading.Tasks.Task.CompletedTask; };
+
+        vm.ResolveConflictCommand.Execute(row);
+
+        Assert.Equal(("x", "release"), captured);
+    }
+
+    [Fact]
+    public void MergeAll_canExecute_requires_target_selection_and_idle()
+    {
+        var vm = NewVm();
+        var a = ActiveRow("a");
+        vm.AddRowForTest(a);
+
+        Assert.False(vm.MergeAllCommand.CanExecute(null));   // no selection, no target
+        a.IsChecked = true;
+        Assert.False(vm.MergeAllCommand.CanExecute(null));   // still no target
+        vm.SelectedTarget = "main";
+        Assert.True(vm.MergeAllCommand.CanExecute(null));
+        vm.IsMerging = true;
+        Assert.False(vm.MergeAllCommand.CanExecute(null));   // busy
+    }
+```
+
+- [ ] **Step 2: Run tests to verify they fail**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter WorktreesOverviewBatchMergeTests`
+Expected: FAIL — `AddRowForTest`, `ResolveConflictCommand`, `MergeAllCommand` do not exist (compile error).
+
+- [ ] **Step 3: Implement subscription, commands, target loading**
+
+In `WorktreesOverviewModalViewModel.cs`:
+
+(a) Add a row-hook that recomputes `SelectedCount` when a row's `IsChecked` changes, and a test seam to add a hooked row. Add these methods to the class:
+
+```csharp
+    private void HookRow(WorktreeOverviewRowViewModel row)
+    {
+        row.PropertyChanged += (_, e) =>
+        {
+            if (e.PropertyName is nameof(WorktreeOverviewRowViewModel.IsChecked)
+                               or nameof(WorktreeOverviewRowViewModel.State))
+                RecomputeSelected();
+        };
+    }
+
+    private void RecomputeSelected() =>
+        SelectedCount = AllRows.Count(r => r.IsChecked && r.IsActive);
+
+    // Test seam: adds a row to the flat list with selection tracking wired up.
+    internal void AddRowForTest(WorktreeOverviewRowViewModel row)
+    {
+        HookRow(row);
+        Rows.Add(row);
+    }
+```
+
+(b) In `LoadAsync`, call `HookRow(row)` everywhere a row is added. Replace the two add sites:
+
+In the grouped branch, change `foreach (var row in grp) group.Rows.Add(row);` to:
+
+```csharp
+                    foreach (var row in grp) { HookRow(row); group.Rows.Add(row); }
+```
+
+In the flat branch, change `foreach (var row in ordered) Rows.Add(row);` to:
+
+```csharp
+                foreach (var row in ordered) { HookRow(row); Rows.Add(row); }
+```
+
+Also, at the start of `LoadAsync` after `IsBusy = true;`, reset batch UI state and (re)load merge targets at the end of the `try`:
+
+After `Rows.Clear(); Groups.Clear();` add:
+
+```csharp
+            ConflictRows.Clear();
+            SelectedCount = 0;
+            BatchProgress = null;
+```
+
+At the very end of the `try` block (after the if/else that fills rows/groups) add:
+
+```csharp
+            await LoadMergeTargetsAsync();
+```
+
+(c) Add target loading. The branch list is repo-level, so query it from the first active row:
+
+```csharp
+    private async Task LoadMergeTargetsAsync()
+    {
+        var anchor = AllRows.FirstOrDefault(r => r.IsActive);
+        if (anchor is null) { MergeTargets.Clear(); SelectedTarget = null; return; }
+        try
+        {
+            var targets = await _worker.GetMergeTargetsAsync(anchor.TaskId);
+            MergeTargets.Clear();
+            if (targets is null) { SelectedTarget = null; return; }
+            foreach (var b in targets.LocalBranches) MergeTargets.Add(b);
+            SelectedTarget = MergeTargets.Contains(targets.DefaultBranch)
+                ? targets.DefaultBranch
+                : MergeTargets.FirstOrDefault();
+        }
+        catch { MergeTargets.Clear(); SelectedTarget = null; }
+    }
+```
+
+(d) Add the commands:
+
+```csharp
+    private bool CanMergeAll() => !IsMerging && SelectedCount > 0 && !string.IsNullOrWhiteSpace(SelectedTarget);
+
+    [RelayCommand(CanExecute = nameof(CanMergeAll))]
+    private Task MergeAll() => MergeSelectedAsync(_worker.MergeTaskAsync);
+
+    [RelayCommand]
+    private void ResolveConflict(WorktreeOverviewRowViewModel? row)
+    {
+        if (row is null) return;
+        RequestConflictResolution?.Invoke(row.TaskId, SelectedTarget ?? "");
+    }
+
+    [RelayCommand]
+    private void ToggleSelectAll()
+    {
+        var actives = AllRows.Where(r => r.IsActive).ToList();
+        var allChecked = actives.Count > 0 && actives.All(r => r.IsChecked);
+        foreach (var r in actives) r.IsChecked = !allChecked;
+    }
+```
+
+- [ ] **Step 4: Run tests to verify they pass**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter WorktreesOverviewBatchMergeTests`
+Expected: PASS (8 tests total in this file).
+
+- [ ] **Step 5: Build the app project to confirm the VM compiles against generated commands**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs tests/ClaudeDo.Ui.Tests/ViewModels/WorktreesOverviewBatchMergeTests.cs
+git commit -m "feat(ui): wire batch selection, target loading and resolve seam"
+```
+
+---
+
+## Task 4: Cockpit view — checkboxes, target picker, Merge all, conflicts panel
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/Views/Modals/WorktreesOverviewModalView.axaml`
+
+This task is AXAML only (no logic) → no new unit test; flag for visual verification.
+
+- [ ] **Step 1: Add the batch toolbar controls**
+
+In `WorktreesOverviewModalView.axaml`, replace the toolbar `StackPanel` (currently containing Refresh, Cleanup finished, StatusMessage) with one that adds select-all, the target picker, the Merge-all button and progress text. Replace the inner `<StackPanel Orientation="Horizontal" Spacing="8">...</StackPanel>` of the toolbar `Border` with:
+
+```xml
+        <StackPanel Orientation="Horizontal" Spacing="8">
+          <Button Classes="btn" Content="{loc:Tr modals.worktreesOverview.refresh}" Command="{Binding RefreshCommand}" IsEnabled="{Binding !IsBusy}"/>
+          <Button Classes="btn" Content="{loc:Tr modals.worktreesOverview.cleanupFinished}" Command="{Binding CleanupFinishedCommand}" IsEnabled="{Binding !IsBusy}"/>
+          <Button Classes="btn" Content="{loc:Tr modals.worktreesOverview.selectAll}" Command="{Binding ToggleSelectAllCommand}"/>
+          <Border Width="1" Background="{DynamicResource LineBrush}" Margin="4,2"/>
+          <TextBlock Text="{loc:Tr modals.worktreesOverview.targetLabel}" VerticalAlignment="Center" Foreground="{DynamicResource TextDimBrush}"/>
+          <ComboBox MinWidth="160"
+                    ItemsSource="{Binding MergeTargets}"
+                    SelectedItem="{Binding SelectedTarget, Mode=TwoWay}"/>
+          <Button Classes="btn accent"
+                  Content="{loc:Tr modals.worktreesOverview.mergeAll}"
+                  Command="{Binding MergeAllCommand}"/>
+          <TextBlock Text="{Binding SelectedCount, StringFormat='{}{0} selected'}"
+                     VerticalAlignment="Center" Foreground="{DynamicResource TextDimBrush}"/>
+          <TextBlock Text="{Binding BatchProgress}" VerticalAlignment="Center" Margin="8,0,0,0"
+                     Foreground="{DynamicResource TextDimBrush}"/>
+          <TextBlock Text="{Binding StatusMessage}" VerticalAlignment="Center" Margin="8,0,0,0"
+                     Foreground="{DynamicResource TextDimBrush}"/>
+        </StackPanel>
+```
+
+- [ ] **Step 2: Add a checkbox + outcome badge to the row template**
+
+In the `WorktreeRowTemplate` `DataTemplate`, change the row `Grid` to add a leading checkbox column and a trailing outcome column. Replace the `<Grid ColumnDefinitions="*,90,80,80">...</Grid>` (the whole grid, lines for Task/State/Diff/Age) with:
+
+```xml
+        <Grid ColumnDefinitions="Auto,*,90,90,80,80">
+          <CheckBox Grid.Column="0" VerticalAlignment="Center" Margin="0,0,8,0"
+                    IsChecked="{Binding IsChecked, Mode=TwoWay}"
+                    IsEnabled="{Binding IsActive}"
+                    IsVisible="{Binding IsActive}"/>
+          <StackPanel Grid.Column="1" Orientation="Vertical" Spacing="2">
+            <TextBlock Classes="title" Text="{Binding TaskTitle}"/>
+            <StackPanel Orientation="Horizontal" Spacing="4">
+              <TextBlock Classes="meta" Text="{Binding TaskStatus}"/>
+              <TextBlock Classes="meta" Text="•"
+                         IsVisible="{Binding !PathExistsOnDisk}"/>
+              <TextBlock Classes="meta" Text="{loc:Tr modals.worktreesOverview.phantom}" Foreground="{DynamicResource StatusErrorBrush}"
+                         IsVisible="{Binding !PathExistsOnDisk}"
+                         ToolTip.Tip="{loc:Tr modals.worktreesOverview.phantomTooltip}"/>
+            </StackPanel>
+          </StackPanel>
+          <TextBlock Grid.Column="2" Classes="meta" VerticalAlignment="Center"
+                     Text="{Binding MergeOutcome}"
+                     IsVisible="{Binding HasOutcome}"/>
+          <Border Grid.Column="3" CornerRadius="3" Padding="6,2" VerticalAlignment="Center"
+                  Background="{Binding State, Converter={StaticResource WorktreeStateColor}}">
+            <TextBlock Classes="meta" Text="{Binding State}" Foreground="{DynamicResource TextBrush}"
+                       HorizontalAlignment="Center"/>
+          </Border>
+          <TextBlock Grid.Column="4" Classes="meta" Text="{Binding DiffStat}" VerticalAlignment="Center"/>
+          <TextBlock Grid.Column="5" Classes="meta" Text="{Binding AgeText}" VerticalAlignment="Center"/>
+        </Grid>
+```
+
+Then update the column-header `Grid` (the one with `ColumnDefinitions="*,90,80,80"` near the ScrollViewer top) to match the new column layout:
+
+```xml
+          <Grid ColumnDefinitions="Auto,*,90,90,80,80" Margin="12,0,12,4">
+            <TextBlock Grid.Column="1" Classes="eyebrow" Text="{loc:Tr modals.worktreesOverview.columnTask}"/>
+            <TextBlock Grid.Column="2" Classes="eyebrow" Text="{loc:Tr modals.worktreesOverview.columnOutcome}"/>
+            <TextBlock Grid.Column="3" Classes="eyebrow" Text="{loc:Tr modals.worktreesOverview.columnState}"/>
+            <TextBlock Grid.Column="4" Classes="eyebrow" Text="{loc:Tr modals.worktreesOverview.columnDiff}"/>
+            <TextBlock Grid.Column="5" Classes="eyebrow" Text="{loc:Tr modals.worktreesOverview.columnAge}"/>
+          </Grid>
+```
+
+- [ ] **Step 3: Add the "Needs resolution" panel**
+
+Inside the content `ScrollViewer`'s root `StackPanel`, at the very top (before the column-header `Grid`), add a conflicts panel that only shows when there are conflicts:
+
+```xml
+          <Border IsVisible="{Binding ConflictRows.Count}"
+                  Background="{DynamicResource ErrorTintBrush}"
+                  BorderBrush="{DynamicResource StatusErrorBrush}"
+                  BorderThickness="1" CornerRadius="6" Padding="12,8" Margin="0,0,0,12">
+            <StackPanel Spacing="6">
+              <TextBlock Classes="eyebrow" Text="{loc:Tr modals.worktreesOverview.needsResolution}"/>
+              <ItemsControl ItemsSource="{Binding ConflictRows}">
+                <ItemsControl.ItemTemplate>
+                  <DataTemplate x:DataType="vm:WorktreeOverviewRowViewModel">
+                    <Grid ColumnDefinitions="*,Auto" Margin="0,2">
+                      <TextBlock Grid.Column="0" Classes="meta" VerticalAlignment="Center"
+                                 Text="{Binding TaskTitle}"/>
+                      <Button Grid.Column="1" Classes="btn"
+                              Content="{loc:Tr modals.worktreesOverview.resolve}"
+                              Command="{Binding $parent[Window].((vm:WorktreesOverviewModalViewModel)DataContext).ResolveConflictCommand}"
+                              CommandParameter="{Binding}"/>
+                    </Grid>
+                  </DataTemplate>
+                </ItemsControl.ItemTemplate>
+              </ItemsControl>
+            </StackPanel>
+          </Border>
+```
+
+> `IsVisible="{Binding ConflictRows.Count}"` uses Avalonia's int→bool coercion (0 = false). If the build flags this, change to a value converter already present, but int→bool is supported.
+
+- [ ] **Step 4: Build the app to verify the AXAML compiles**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded (compiled bindings resolve against the new VM members).
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/Views/Modals/WorktreesOverviewModalView.axaml
+git commit -m "feat(ui): batch-merge cockpit view with checkboxes and conflicts panel"
+```
+
+---
+
+## Task 5: Localization keys (en + de parity)
+
+**Files:**
+- Modify: `src/ClaudeDo.Localization/locales/en.json`
+- Modify: `src/ClaudeDo.Localization/locales/de.json`
+
+- [ ] **Step 1: Add the new keys to `en.json`**
+
+Under `modals.worktreesOverview`, add:
+
+```json
+      "columnOutcome": "RESULT",
+      "selectAll": "Select all",
+      "targetLabel": "Target",
+      "mergeAll": "Merge all",
+      "needsResolution": "NEEDS RESOLUTION",
+      "resolve": "Resolve"
+```
+
+Under `vm.worktreesOverview`, add:
+
+```json
+      "batchProgress": "Merging {0}/{1}…",
+      "batchDone": "Merged {0}, {1} need resolution."
+```
+
+- [ ] **Step 2: Add the matching keys to `de.json`**
+
+Under `modals.worktreesOverview`:
+
+```json
+      "columnOutcome": "ERGEBNIS",
+      "selectAll": "Alle auswählen",
+      "targetLabel": "Ziel",
+      "mergeAll": "Alle mergen",
+      "needsResolution": "ZU LÖSEN",
+      "resolve": "Lösen"
+```
+
+Under `vm.worktreesOverview`:
+
+```json
+      "batchProgress": "Merge {0}/{1}…",
+      "batchDone": "{0} gemergt, {1} zu lösen."
+```
+
+- [ ] **Step 3: Run the localization parity test**
+
+Run: `dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release`
+Expected: PASS (en/de key parity holds).
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add src/ClaudeDo.Localization/locales/en.json src/ClaudeDo.Localization/locales/de.json
+git commit -m "feat(i18n): add batch-merge cockpit strings (en/de)"
+```
+
+---
+
+## Task 6: Migrate `WorktreeModalView` diff onto `DiffLinesView`
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Modals/WorktreeModalViewModel.cs`
+- Modify: `src/ClaudeDo.Ui/Views/Modals/WorktreeModalView.axaml`
+
+- [ ] **Step 1: Switch the VM to the canonical diff model**
+
+In `WorktreeModalViewModel.cs`:
+
+(a) Delete the now-dead types at the top of the file:
+
+```csharp
+public enum WorktreeDiffLineKind { Header, Hunk, Added, Removed, Context }
+
+public sealed partial class WorktreeDiffLineViewModel : ViewModelBase
+{
+    public required string Text { get; init; }
+    public required WorktreeDiffLineKind Kind { get; init; }
+}
+```
+
+(b) Change the collection declaration from:
+
+```csharp
+    public ObservableCollection<WorktreeDiffLineViewModel> SelectedFileDiffLines { get; } = new();
+```
+
+to:
+
+```csharp
+    public ObservableCollection<DiffLineViewModel> SelectedFileDiffLines { get; } = new();
+```
+
+(c) Replace the body of `LoadFileDiffAsync` (the `foreach (var line in diff.Split('\n'))` block) so it parses via `UnifiedDiffParser`. The method becomes:
+
+```csharp
+    private async Task LoadFileDiffAsync(WorktreeNodeViewModel? node)
+    {
+        SelectedFileDiffLines.Clear();
+
+        if (node is null || node.IsDirectory || string.IsNullOrEmpty(node.RelativePath))
+            return;
+
+        string diff;
+        try
+        {
+            diff = await _git.GetFileDiffAsync(WorktreePath, BaseCommit, node.RelativePath);
+        }
+        catch
+        {
+            return;
+        }
+
+        foreach (var line in UnifiedDiffParser.Flatten(UnifiedDiffParser.Parse(diff)))
+            SelectedFileDiffLines.Add(line);
+    }
+```
+
+(`DiffLineViewModel`, `DiffFileViewModel`, and `UnifiedDiffParser` are all in the same `ClaudeDo.Ui.ViewModels.Modals` namespace, so no new `using` is required.)
+
+- [ ] **Step 2: Build to confirm the VM compiles and nothing else referenced the deleted types**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded. (If a compile error names `WorktreeDiffLineViewModel`/`WorktreeDiffLineKind` outside this file or the view, that reference must be migrated too — there should be none besides `WorktreeModalView.axaml`, handled next.)
+
+- [ ] **Step 3: Swap the view's inline diff for `DiffLinesView`**
+
+In `WorktreeModalView.axaml`:
+
+(a) Remove the now-unused converter resource. Delete:
+
+```xml
+  <Window.Resources>
+    <converters:DiffLineKindToBrushConverter x:Key="DiffLineKindToBrush"/>
+  </Window.Resources>
+```
+
+(b) Replace the right-pane `ScrollViewer`'s `ItemsControl` (the `SelectableTextBlock` template bound to `SelectedFileDiffLines`) with the canonical control. Replace:
+
+```xml
+          <ItemsControl ItemsSource="{Binding SelectedFileDiffLines}">
+            <ItemsControl.ItemTemplate>
+              <DataTemplate DataType="vm:WorktreeDiffLineViewModel">
+                <SelectableTextBlock Text="{Binding Text}"
+                                     FontFamily="{DynamicResource MonoFont}"
+                                     FontSize="{StaticResource FontSizeMono}"
+                                     Foreground="{Binding Kind, Converter={StaticResource DiffLineKindToBrush}}"
+                                     TextWrapping="NoWrap"/>
+              </DataTemplate>
+            </ItemsControl.ItemTemplate>
+          </ItemsControl>
+```
+
+with:
+
+```xml
+          <ctl:DiffLinesView Lines="{Binding SelectedFileDiffLines}"/>
+```
+
+(The `xmlns:ctl="using:ClaudeDo.Ui.Views.Controls"` namespace is already declared at the top of this file.)
+
+- [ ] **Step 4: Build the app to verify the AXAML compiles**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Modals/WorktreeModalViewModel.cs src/ClaudeDo.Ui/Views/Modals/WorktreeModalView.axaml
+git commit -m "refactor(ui): render worktree modal diff via canonical DiffLinesView"
+```
+
+---
+
+## Task 7: Full build + test sweep
+
+**Files:** none (verification only).
+
+- [ ] **Step 1: Build the whole app**
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: Build succeeded, 0 errors.
+
+- [ ] **Step 2: Run the UI + localization test projects**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release`
+Then: `dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release`
+Expected: PASS (all green, including the 8 new batch-merge tests).
+
+- [ ] **Step 3: Flag visual-verification gaps**
+
+The cockpit toolbar/checkbox/conflicts-panel layout and the migrated `WorktreeModalView` diff rendering are AXAML changes that cannot be verified headlessly. Report to the user that these need a visual pass (run the app, open the worktrees overview, select several worktrees, pick a target, "Merge all", and open a worktree diff).
+
+---
+
+## Self-Review Notes
+
+- **Spec coverage:** batch-merge cockpit (Tasks 1–4), skip-and-continue + conflict collection (Task 2), single target picker (Tasks 3–4), Resolve → `RequestConflictResolution(taskId, targetBranch)` seam left unwired (Tasks 3–4), `WorktreeModalView` diff migration to `DiffLinesView` (Task 6), no worker files touched, no `IWorkerClient` change, locales in parity (Task 5). ✔
+- **No ConflictResolver reference:** the seam is a bare `Func<string,string,Task>?`; no Layer C type is named. ✔
+- **Type consistency:** `BatchMergeOutcome`, `MergeOutcome`, `IsConflict`, `HasOutcome`, `MergeSelectedAsync`, `ConflictRows`, `SelectedTarget`, `SelectedCount`, `IsMerging`, `BatchProgress`, `RequestConflictResolution`, `MergeAllCommand`, `ResolveConflictCommand`, `ToggleSelectAllCommand`, `AddRowForTest`, `AllRows` are used consistently across tasks. ✔

docs/superpowers/plans/2026-06-09-per-task-model-override-plan.md

@@ -0,0 +1,55 @@
+# Plan: Per-task model override via MCP + cheapest-model prompt guidance
+
+Spec: `docs/superpowers/specs/2026-06-09-per-task-model-override-design.md`
+
+TDD, one focused commit per task. Build with `-c Release` per project; run
+`ClaudeDo.Worker.Tests` (and `Data.Tests` if touched).
+
+## Task 1 — ModelRegistry: cost ordering + alias validation
+
+- Add `ByCostAscending = ["haiku","sonnet","opus"]`.
+- Add `string? NormalizeAlias(string? model)`: trim; null/blank → null;
+  case-insensitive match against `Aliases` → canonical lowercase; else throw
+  `ArgumentException($"Unknown model '{model}'. Allowed: {join(Aliases)}.")`.
+- Tests (Data.Tests): "sonnet"/"OPUS"/" haiku " → normalized; ""/null/"  " →
+  null; "gpt4" → throws.
+
+## Task 2 — CreateChildAsync accepts model
+
+- `TaskRepository.CreateChildAsync`: add `string? model = null` (before the
+  trailing `CancellationToken ct = default`); set
+  `child.Model = ModelRegistry.NormalizeAlias(model)`.
+- Update the two existing callers to compile (named pass-through added in
+  Tasks 3–4; keep default null here).
+
+## Task 3 — Planning + improvement MCP tools forward model
+
+- `PlanningMcpService.CreateChildTask`: add `string? model` param after
+  `commitType`; pass to `CreateChildAsync`. Extend `[Description]` to document
+  the model arg (haiku/sonnet/opus; cheapest capable).
+- `TaskRunMcpService.SuggestImprovement`: add `string? model` param after
+  `description`; pass to `CreateChildAsync`. Extend `[Description]`.
+- Tests: each tool persists the model; invalid value throws.
+
+## Task 4 — External AddTask forwards model
+
+- `ExternalMcpService.AddTask`: add `string? model = null` param (before the
+  trailing `CancellationToken`); `entity.Model = ModelRegistry.NormalizeAlias(model)`.
+  Extend `[Description]`.
+- Test: AddTask persists model; invalid value rejected.
+
+## Task 5 — Prompt guidance
+
+- `PromptFiles.PlanningSystemDefault`: add a short paragraph — assign each
+  subtask the cheapest model that does it well, with ordering haiku < sonnet <
+  opus and the heuristic; pass it as `CreateChildTask(model=...)`.
+- `PromptFiles.SystemDefault` Out-of-scope section: when filing via
+  `SuggestImprovement`, pass the cheapest capable `model`.
+- `PromptFiles.ImprovementChildDefault`: one-line minimality reminder.
+- No test (static prompt text); verify build only.
+
+## Task 6 — Verify
+
+- Build App + Worker `-c Release`; run Worker.Tests + Data.Tests.
+- Update `ClaudeDo.Worker/CLAUDE.md` (ConfigMcpTools/creation-tool notes) and
+  `ClaudeDo.Data/CLAUDE.md` (ModelRegistry) if needed.

docs/superpowers/plans/2026-06-09-unify-parent-task-model-plan.md

@@ -0,0 +1,90 @@
+# Plan — Unify the parent-task model
+
+Spec: `docs/superpowers/specs/2026-06-09-unify-parent-task-model-design.md`
+
+Subagents: `sonnet`. Stage files explicitly by path (never `git add -A`). TDD.
+Build with `-c Release` per project. Commit per task (Conventional Commits).
+
+## Task 1 — Single parent-advance path
+
+- Rename `TaskStateService.TryAdvanceImprovementParentAsync` → `TryAdvanceParentAsync`.
+- Make it advance **any** `WaitingForChildren` parent → `WaitingForReview` when all
+  children are terminal, and advance a parent with **zero** children straight to
+  `WaitingForReview`.
+- In `OnChildTerminalAsync`: drop the `TryCompleteParentAsync` call; keep
+  `_chain.OnChildFinishedAsync`; call the renamed advance method for all parents.
+- Tests: extend `WaitingForChildrenLifecycleTests` — (a) improvement parent still
+  advances; (b) a `WaitingForChildren` parent whose children are a *sequential chain*
+  advances only after the last one is terminal; (c) zero-children parent advances.
+
+## Task 2 — Delete `TryCompleteParentAsync`
+
+- Remove `TaskRepository.TryCompleteParentAsync` (`TaskRepository.cs:477-502`) and
+  any remaining references.
+- Update `src/ClaudeDo.Data/CLAUDE.md` (drop it from the TaskRepository helper list).
+- Build Data + Worker; fix references.
+
+## Task 3 — Planning finalize enters `WaitingForChildren`
+
+- `TaskStateService.FinalizePlanningAsync`: in the same `ExecuteUpdateAsync`, set
+  `Status = WaitingForChildren` alongside `PlanningPhase = Finalized` /
+  `PlanningFinalizedAt`.
+- Verify `PlanningSessionManager.FinalizeAsync` ordering: finalize (→ WaitingForChildren)
+  **before** `SetupChainAsync` enqueues child[0]. Adjust only if ordering is wrong.
+- Tests: finalizing a planning parent with N children leaves it `WaitingForChildren`;
+  after the chain completes it is `WaitingForReview` (not `Done`); a planning parent
+  with zero finalized children lands in `WaitingForReview`.
+
+## Task 4 — Approve merges the whole unit
+
+**Decision: full UX consolidation.** Approve becomes the single entry for reviewing
+*and* merging any task; the separate planning-merge views are folded into the review
+panel. The `PlanningMergeOrchestrator` (which already merges the unit + sets the
+parent `Done` for both planning and improvement, with conflict continue/abort) is
+reused as the engine; only its *entry/UI* moves.
+
+Backend:
+- `WorkerHub.ApproveReview`: for a parent that **has children**, drive
+  `PlanningMergeOrchestrator.StartAsync` (event-based: `PlanningMergeStarted` /
+  `PlanningSubtaskMerged` / `PlanningMergeConflict` / `PlanningMergeAborted` /
+  `PlanningCompleted`) instead of the one-shot `ApproveAndMergeAsync`. Childless tasks
+  keep `ApproveAndMergeAsync`. Conflict resolution still goes through
+  `ContinuePlanningMerge` / `AbortPlanningMerge`.
+- Keep the orchestrator, `ContinuePlanningMerge`, `AbortPlanningMerge`,
+  `GetPlanningAggregate`, `BuildPlanningIntegrationBranch`. Remove the now-redundant
+  standalone `MergeAllPlanning` hub method (approve is the entry).
+- (Optional cleanup) route the orchestrator's `FinalizeParentDoneAsync` through
+  `TaskStateService` so `Status` writes stay centralized; low priority.
+
+UI (Avalonia, MVVM — visual-verification gaps, flag for user):
+- The review panel (`DetailsIslandViewModel` / its view) is the single approve+merge
+  surface. For a child-bearing parent in `WaitingForReview`, approve shows the
+  unit-merge progress + per-subtask state, the aggregate/integration diff preview, and
+  conflict continue/abort — all inline in the review panel.
+- Remove the separate planning-merge view(s)/commands and the standalone "Merge all"
+  button; re-wire their `PlanningMerge*` event handlers into the review panel VM.
+- Sync `IWorkerClient` + hand-rolled test fakes in both UI/Worker test projects.
+
+Tests: approving a parent with two `Done` children merges both then sets `Done`; a
+conflicting second child surfaces the conflict and pauses (continue/abort) without
+losing the parent's `WaitingForReview`/merge state.
+
+## Task 5 — Cancellable `WaitingForChildren` parent
+
+- Add `TaskStatus.WaitingForChildren` to the `CancelAsync` guard.
+- Test: a parent in `WaitingForChildren` can be cancelled.
+
+## Task 6 — Docs
+
+- `src/ClaudeDo.Worker/CLAUDE.md`: add `WaitingForChildren` to the Status table +
+  transition diagram; document the unified parent flow and approve-merges-unit;
+  remove `MergeAllPlanning` from the Hub method list.
+- `src/ClaudeDo.Data/CLAUDE.md`: add `WaitingForChildren` to the TaskEntity status list.
+- Root `CLAUDE.md`: update the "Task status flow" convention line.
+
+## Verify
+
+- `dotnet test` for Worker.Tests + Data.Tests (`-c Release`).
+- UI flows (planning finalize → review → approve-merge; improvement parent;
+  retired MergeAllPlanning button) are **visual-verification gaps** — flag for the
+  user to run the app; do not claim they work from tests alone.

docs/superpowers/plans/2026-06-10-online-inbox.md

@@ -0,0 +1,72 @@
+# Online Inbox — implementation plan
+
+Date: 2026-06-10
+Spec: `docs/superpowers/specs/2026-06-10-online-inbox-design.md`
+Contract: `docs/online-inbox-api-contract.md`
+
+TDD, one commit per task, Conventional Commits. Build with `-c Release` per CLAUDE.md.
+
+## Phase 1 — Worker sync engine (buildable now, no Zitadel package needed)
+
+### Task 1 — Config
+- Add `OnlineInboxConfig` + nested `ZitadelClientConfig` records.
+- Add `online_inbox` (`OnlineInbox`) property to `WorkerConfig`; default `enabled=false`.
+- `Load` leaves it untouched when absent (defaults = disabled).
+- Test: missing section → disabled defaults; populated section round-trips.
+
+### Task 2 — DTOs + Idle-backlog helper
+- `Online/Dtos.cs`: `RemoteList(Id, Name)`, `RemoteTask(Id, ListId, Title, Description, CreatedAt)`,
+  `MirrorTask(Id, ListId, Title, Description)`.
+- `Online/OnlineBacklog.cs`: `static Task<List<MirrorTask>> CurrentAsync(TaskRepository/ctx)` +
+  the filter predicate (Idle, no parent, PlanningPhase None, BlockedBy null).
+- Test the filter against real SQLite seeded with mixed tasks.
+
+### Task 3 — Auth abstraction + token store
+- `Online/Interfaces/IOnlineAuthProvider.cs`.
+- `Online/OnlineTokenStore.cs`: DPAPI CurrentUser persistence at `~/.todo-app/online-inbox.token`;
+  `Save(refreshToken)`, `Read()`, `Clear()`. (Windows-only encryption; thin + guarded.)
+- A trivial `StaticTokenAuthProvider` (returns a configured token or null) for tests + as the
+  temporary default until Zitadel is wired.
+- Test: token store round-trip (Windows); static provider returns/omits token.
+
+### Task 4 — API client
+- `Online/IOnlineInboxApi.cs` + `Online/OnlineInboxApiClient.cs` (typed `HttpClient`).
+- Attaches `Authorization: Bearer` from `IOnlineAuthProvider`; refuses non-HTTPS non-loopback
+  base URLs; throws a typed `OnlineInboxException` on non-2xx.
+- Test with a stubbed `HttpMessageHandler`: each method hits the right path/verb/body; 401
+  surfaces; bearer attached.
+
+### Task 5 — Sync service
+- `Online/OnlineSyncService.cs` (`BackgroundService`) implementing the §5 reconcile loop.
+- DI: register only when `enabled`; resolve repos per-cycle via a scope.
+- Per-cycle try/catch + structured logging; skip when no token; unknown-list skip.
+- Test against a **fake `IOnlineInboxApi`** + real SQLite: pull→import→flag creates local Idle
+  tasks; mirror payload == Idle backlog; lists pushed; unknown list skipped & not flagged;
+  disabled/no-token = no api calls.
+
+### Task 6 — Wire-up + docs
+- Register the stack in `Program.cs` behind the enabled flag.
+- Update `src/ClaudeDo.Worker/CLAUDE.md` (new `Online/` area) and `src/ClaudeDo.Worker/Config`
+  notes. Add `online_inbox` to the config section.
+
+## Phase 2 — UI + real auth (AFTER the VPS reports client config)
+
+### Task 7 — Hub + config plumbing
+- Hub: `GetOnlineInboxConfig` / `SetOnlineInboxConfig` / `SetOnlineInboxAuth(refreshToken)` /
+  `ClearOnlineInboxAuth`. Update `IWorkerClient` + `WorkerClient` + test fakes (both test
+  projects — see the IWorkerClient-fakes memory).
+
+### Task 8 — Settings UI
+- "Online Inbox" section in `SettingsModalViewModel`: enable toggle, base URL, Sign in/out,
+  status. Localized keys in en.json + de.json (parity).
+- Visual verification = manual (flag it).
+
+### Task 9 — ZitadelAuthProvider
+- Add the Zitadel package reference; implement `ZitadelAuthProvider` (refresh-token → access
+  token, cached to expiry) using the reported authority/client-id/flow.
+- Swap it in for `StaticTokenAuthProvider` in DI when enabled.
+- Manual smoke against the live VPS API (tracked, not an automated test).
+
+## Notes
+- No real network / no real Zitadel / no real Claude in any automated test.
+- Stage files by explicit path in subagents; sonnet model; build+test+commit by the orchestrator.

docs/superpowers/plans/2026-06-19-feature-unification-plan.md

@@ -0,0 +1,104 @@
+# Feature unification — phased plan
+
+Date: 2026-06-19
+Design: `docs/superpowers/specs/2026-06-19-feature-unification-design.md`
+
+Six slices, sequenced cheapest/lowest-risk first. Each ends green
+(`dotnet build -c Release` + the touched test project) and is independently
+committable. Phases 0–1 are detailed here; 2–5 are scoped, and each gets its own
+`docs/superpowers/plans/2026-06-19-unify-<slice>.md` when picked up (per the
+2026-06-05 layer-A/B/C convention). Build per-csproj (`-c Release`) — `.slnx` needs
+.NET 9 and a running Worker locks `Debug`.
+
+---
+
+## Phase 0 — Groundwork (Bucket C). No UX change.
+
+**0a. Delete the dead hunks conflict API (C1).**
+- Remove `TaskMergeService.GetConflictsAsync` + the `MergeConflicts`/`ConflictFileContent` records it returns (`src/ClaudeDo.Worker/Lifecycle/TaskMergeService.cs:250`) if unused elsewhere.
+- Remove `WorkerHub.GetMergeConflicts` (`src/ClaudeDo.Worker/Hub/WorkerHub.cs:378`) + `MergeConflictsDto`/`ConflictFileDto`/`ConflictHunkDto` if unused.
+- Remove `WorkerClient`'s `"GetMergeConflicts"` invoke (`src/ClaudeDo.Ui/Services/WorkerClient.cs:276`) + the `IWorkerClient` member + every fake override (`tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs`, `TasksIslandViewModelPlanningTests.cs`, others — grep `GetMergeConflicts`).
+- Delete `TaskMergeServiceTests.cs:672` `GetConflictsAsync_AfterConflictMerge_ReturnsOursAndTheirs`.
+- Verify with grep first: `GetConflictsAsync` and `GetMergeConflicts` have **no** callers outside this chain + tests.
+- Acceptance: Worker + Ui build; Worker.Tests + Ui.Tests green; `GetMergeConflictDocuments` path untouched.
+
+**0b. Single task-creation path (C2).**
+- Identify the path MCP `ExternalMcpService.AddTask` uses; expose a thin creation method (repository or a small `TaskCreationService`) that applies the same defaults (ListId, SortOrder, CreatedAt).
+- Re-point `TasksIslandViewModel.AddAsync` at it instead of `db.Tasks.Add` direct EF.
+- Acceptance: quick-add still works; one creation path; Ui.Tests + Worker.Tests green.
+
+**0c. Prune stale worktrees (C3).**
+- `git worktree list`; remove the orphaned `.claude/worktrees/*` entries (confirm each is unwanted with Mika before `git worktree remove`).
+- Acceptance: only intended worktrees remain; no tracked files change.
+
+> C4 (naming alignment) intentionally NOT in this phase — see design.
+
+---
+
+## Phase 1 — DialogService (B3–B5). Low–medium.
+
+**Goal:** one `IDialogService` replaces the scattered `Show*` Func seams and the
+duplicate open-commands.
+
+- New `IDialogService` (Ui/Services) with typed methods: `OpenListSettings(ListNavItemViewModel)`, `OpenRepoImport()`, `OpenWorktreesOverview(string? listId)`, `OpenWeeklyReport()`, `OpenAbout()`, `OpenWorkerConnectionHelp()`. Implementation owns the factories + `ModalShell`/TCS wiring currently in `MainWindow.axaml.cs` + `IslandsShellViewModel.cs:59-71`.
+- Inject it into `ListsIslandViewModel`, `TasksIslandViewModel`, `IslandsShellViewModel`. Collapse the three List-Settings doors (Lists context menu, Tasks header, shell bridge `IslandsShellViewModel.cs:190-194`) to one `dialogs.OpenListSettings(row)` call; same for Repo Import (2→1) and Worktrees Overview (2→1, keep the `listId?` param for global-vs-per-list).
+- Keep `ModalShell`/TCS dialog pattern; this only centralizes *opening*.
+- Update fakes/ctors per the IWorkerClient-fakes hazard (ctor changes ripple to Ui.Tests).
+- Acceptance: every dialog opens via one method; no duplicate open-commands; Ui.Tests green; visual gap flagged (open each dialog from each former door).
+
+---
+
+## Phase 2 — MergeCoordinator (B1). Medium.
+
+**Goal:** delete the five `RequestConflictResolution` seams; one coordinator.
+
+- New `IMergeCoordinator` (Ui) `MergeAsync(taskId, targetBranch)` = the body of `IslandsShellViewModel.RequestConflictResolutionAsync` (`:49`) plus the "open MergeModal → on conflict open resolver" flow currently split across `MergeModalViewModel:108` and `DiffModalViewModel:103`.
+- Remove the `Func<string,string,Task>? RequestConflictResolution` from `WorktreesOverviewModalViewModel:83`, `DiffModalViewModel:75`, `MergeModalViewModel:33`, `MergeSectionViewModel:51`, and the `DetailsIslandViewModel:347` delegate; inject the coordinator instead.
+- Re-point doors: review Approve, Diff Merge button, WorktreesOverview single + batch (`:331`), Details merge section.
+- Update seam tests (`WorktreesOverviewBatchMergeTests.cs:145`, `DetailsIslandConflictSeamTests.cs:84`) to assert via the coordinator.
+- Acceptance: one merge entry API; resolver still opens for single-task AND planning conflict; Ui.Tests green; visual gap flagged (force a conflict from Approve and from the Diff Merge button).
+
+---
+
+## Phase 3 — WorktreeActions (A3). Medium.
+
+**Goal:** one per-task worktree-actions VM reused by overview rows + Details.
+
+- New `WorktreeActionsViewModel(taskId)` with Merge/Diff/Discard/Keep/ForceRemove over `IWorkerClient` (uses the Phase-2 coordinator for Merge, the Phase-5 viewer for Diff — until then, current calls).
+- `WorktreesOverviewModalViewModel` rows compose one each; `MergeSectionViewModel` hosts one for the active task. Remove the duplicated commands.
+- Acceptance: both surfaces drive the same VM; Ui.Tests green; visual gap flagged.
+
+---
+
+## Phase 4 — AgentConfigEditor (A2). Medium.
+
+**Goal:** one config editor for Global | List | Task scope.
+
+- New `AgentConfigEditorViewModel(scope)` over `InheritanceResolver` exposing Model/SystemPrompt/AgentPath/MaxTurns + reset commands + `InheritedBadge` state; persists via the scope's hub method (`UpdateListConfig` / `UpdateTaskAgentSettings` / app settings).
+- Embed in `SettingsModalViewModel`, `ListSettingsModalViewModel`, and the Details `AgentSettingsSectionViewModel` host; delete the duplicated field/reset logic.
+- Acceptance: identical editor in all three scopes; Localization parity; Ui.Tests green; visual gap flagged.
+
+---
+
+## Phase 5 — DiffViewer (A1 + B2). High; last.
+
+**Goal:** one diff component replaces DiffModal + WorktreeModal + PlanningDiff.
+
+- New `DiffViewerViewModel` with `DiffSource` enum/abstraction (`DirtyWorktree | BranchVsBase | CommitRange | PlanningAggregate | IntegrationBranch`) and an optional file-tree pane (port `WorktreeModal`'s tree + Avalonia-12 selection workaround); reuse `UnifiedDiffParser` + `DiffLinesView`; keep PlanningDiff's combined-mode toggle as a source switch.
+- Re-point all B2 doors to open it with the right source. Remove the three old VMs/views.
+- Update `DiffModalViewModelTests`, `PlanningDiffViewModelTests`.
+- Acceptance: every diff door opens the one viewer; whole-unified AND file-tree layouts work; Ui.Tests green; visual gap flagged (worktree-dirty, post-merge commit-range, planning per-subtask + integration).
+
+---
+
+## Sequencing rationale
+
+0 (delete/no-UX) → 1 (isolated, unblocks nothing but cheap) → 2 (coordinator; 3 & 5
+lean on it for Merge/Diff) → 3 → 4 (independent) → 5 (biggest, most UX-sensitive,
+benefits from 2's coordinator). Stop after any phase and the app is shippable.
+
+## Per-phase commits
+
+Conventional Commits, one per phase (or per sub-step in Phase 0): e.g.
+`refactor(merge): single MergeCoordinator replaces 5 conflict seams`. Stage by path
+(never `git add -A` — concurrent sessions). Commit the spec + this plan first.

docs/superpowers/plans/2026-06-19-rider-merge-editor.md

@@ -0,0 +1,92 @@
+# Plan: Rider-style 3-pane merge editor
+
+Spec: `docs/superpowers/specs/2026-06-19-rider-merge-editor-design.md`
+
+TDD, one focused commit per task (Conventional Commits, `feat(merge): …`).
+Build with `-c Release` per project (a running Worker locks `Debug`).
+Run `ClaudeDo.Ui.Tests` (and `Localization.Tests` for Task 6). No real `claude` CLI in tests.
+Stage ONLY the files each task touches, by explicit path (parallel sessions leave WIP).
+Backend + seam stay unchanged. Implementer/reviewer subagents use **sonnet**.
+
+## Task 1 — VM: active-file model + 3-pane reconstruction + readout
+
+`ConflictResolverViewModel` / `ConflictModels.cs`, additive (seam untouched).
+
+- Add `ActiveFile` (`MergeFile?`), `SelectFileCommand(MergeFile)`, default to first file
+  after load. Keep `Files`, `Current`/`CurrentIndex`/`Next`/`Previous` (focused conflict
+  for the header arrows), `CanContinue`, binary guard, planning routing — all unchanged.
+- Add computed, per `ActiveFile`:
+  - `ActiveOursText`   = concat(stable.Text | conflict.Ours)
+  - `ActiveTheirsText` = concat(stable.Text | conflict.Theirs)
+  - `ActiveResultText` = concat(stable.Text | conflict.Resolution ?? conflict.Ours)
+  - `ActiveConflicts`  = ordered descriptors (block + segment index) for the view.
+- `PositionText` → `"{conflicts} conflicts · {resolved} resolved"` for the active file;
+  keep `CanContinue` = every file resolved AND no binary.
+- Switching files raises a change event the view listens to (reuse/extend
+  `CurrentChanged` → e.g. `ActiveFileChanged`).
+- Tests (Ui.Tests): reconstruction text for ours/theirs/result (result seeds unresolved
+  with Ours); resolving a block updates `ActiveResultText` + readout; switching files
+  preserves each block's `Resolution`; `CanContinue` blocks until all files resolved;
+  binary file still blocks. Keep all existing tests green.
+
+## Task 2 — View: 3-pane AXAML shell + document assembly + synced scroll
+
+`Views/Conflicts/ConflictResolverView.axaml(.cs)`. Visual — verified by running.
+
+- Replace AXAML: ModalShell host kept; header row (◀/▶ focus arrows bound to
+  Previous/Next, file switcher `ItemsControl`/`ComboBox` over `Files` bound to
+  `SelectFileCommand`, right-aligned `PositionText`); `Grid ColumnDefinitions="*,*,*"`
+  of three bordered panes with headers **Ours · current (merge target)** /
+  **Result** / **Theirs · incoming (task)** (drop Base); footer Continue
+  (`IsEnabled=CanContinue`) / Abort; binary banner (kept); `Escape`→Abort (kept).
+- Code-behind: build three `TextDocument`s from `ActiveFile` segments, recording each
+  conflict's start line + line count per document; install TextMate per pane by file
+  extension; rebuild on `ActiveFileChanged`; Ours/Theirs `IsReadOnly=true`.
+- Proportional synced vertical scroll across the three panes (re-entrancy guard).
+- Push Result edits back to the active block `Resolution` (refined in Task 4).
+
+## Task 3 — Result pane: read-only stable, editable conflicts
+
+`ConflictResolverView.axaml.cs` + a small `IReadOnlySectionProvider` helper.
+
+- Track each conflict's result span in a `TextSegmentCollection<…>` over the Result
+  document (anchors auto-adjust on edit).
+- `IReadOnlySectionProvider`: `CanInsert` only strictly inside a conflict span;
+  `GetDeletableSegments` intersects with conflict spans only. Stable text becomes
+  immutable; conflict regions stay editable.
+- Editing inside a conflict span writes the span text back to the block `Resolution`
+  and flips it resolved (updates readout + `CanContinue`).
+
+## Task 4 — Color blocks (IBackgroundRenderer) + accept overlay
+
+`ConflictResolverView.axaml.cs` + renderer/overlay helpers.
+
+- `IBackgroundRenderer` per pane: unresolved conflict = red (Blood tint), resolved =
+  green/muted, Ours side = Moss tint, Theirs side = Accent tint — driven by recorded
+  spans + block `IsResolved`.
+- Between-pane overlay Canvas (Ours|Result and Result|Theirs): `›` accept-ours / `‹`
+  accept-theirs + `✕` dismiss per conflict, positioned at the block's `TextView` visual
+  top, recomputed on scroll/resize. Click → `block.AcceptOurs/AcceptTheirs` and replace
+  the tracked Result span; resolved blocks recolor.
+
+## Task 5 — Polish: readout, focus arrows scroll-to-conflict, resolved styling
+
+- ◀/▶ arrows move `Current` and scroll all three panes to that conflict.
+- `M conflicts · K resolved` live readout; Continue tooltip/hint when blocked.
+- Resolved conflict recolors and drops its accept overlay; unresolved stays red.
+  (Fold into Task 4 if small.)
+
+## Task 6 — Localization + tokens
+
+- Add `conflictResolver.*` keys (pane headers, readout, accept tooltips, hints) to
+  `locales/en.json` AND `locales/de.json` (keep key parity).
+- Add Tokens.axaml color tokens only if a needed conflict/resolved shade is missing.
+- Run Localization.Tests (parity) + a quick scan for hard-coded strings in the view.
+
+## Task 7 — Verify
+
+- Build `ClaudeDo.App` + `ClaudeDo.Ui` `-c Release`; run `Ui.Tests` + `Localization.Tests`.
+- Update `src/ClaudeDo.Ui/CLAUDE.md` (Planning/Conflicts paragraph → new 3-pane editor).
+- **Visual verification gap (flag to Mika):** run the app, trigger a real conflict
+  (single-task approve + planning unit-merge) and confirm panes/colors/accept/scroll/
+  gating/binary render correctly — cannot be asserted in tests.

docs/superpowers/plans/2026-06-19-unify-agent-config.md

@@ -0,0 +1,131 @@
+# Phase 4 — AgentConfigEditor (A2)
+
+Date: 2026-06-23 (picked up after reordering Phase 3 ↔ 4)
+Umbrella: `docs/superpowers/plans/2026-06-19-feature-unification-plan.md`
+Design: `docs/superpowers/specs/2026-06-19-feature-unification-design.md` (A2)
+
+## Reordering note
+
+Phase 3 (WorktreeActions) was deferred. Its premise — overview rows and the Details
+merge section each owning duplicate worktree commands — only half-holds: Details has
+no Discard/Keep/ForceRemove, and the two Diff doors open different VMs (`WorktreeModal`
+vs `DiffModal`) that only Phase 5 unifies. So Phase 3's clean form depends on Phase 5
+(Diff) and a fuller MergeCoordinator (Merge); doing it now would build throwaway
+per-surface delegates. **Phase 3 is folded into Phase 5.** Phase 4 (independent, clean
+dedup) runs now.
+
+## Scope decision: List + Task only (global left as-is)
+
+The design names three scopes (Global | List | Task). Verified against the tree on
+2026-06-23, only **List and Task genuinely duplicate**:
+
+- **List** (`ListSettingsModalViewModel`, "AGENT" section): Model / MaxTurns /
+  SystemPrompt / AgentFile, each with `InheritedBadge` + `↺` reset; 2-tier
+  (list→global) badges computed with inline logic (does **not** use the existing
+  `InheritanceResolver.ResolveList` — which is currently dead code); explicit Save.
+- **Task** (`AgentSettingsSectionViewModel`, TaskHeaderBar gear flyout): same four
+  fields; 3-tier (task→list→global) badges via `InheritanceResolver.Resolve`;
+  `EffectiveMaxTurns` + `EffectiveSystemPromptHint`; `IsRunning` gate; debounced
+  auto-save.
+
+**Global** (`GeneralSettingsTabViewModel`, Settings → General) is the root: no
+inheritance, no badges, no agent file, no reset — three plain controls (model combo,
+max-turns numeric, instructions textbox) plus a global-only PermissionMode, interleaved
+with unrelated settings (Language, parallelism, report paths, standup weekday) and
+saved batched into one `AppSettingsDto` via the modal Save. Embedding the shared editor
+there buys ~3 plain fields at the cost of a degenerate no-badges/no-agent/no-reset mode
+plus surgery on the settings save path and a relayout of the most settings-dense view.
+**Not worth it — global stays as-is.** (Confirmed with Mika 2026-06-23.)
+
+The real maintenance hazard is the **VM logic** (two copies of badge/reset/inheritance
+that already drifted), and the **view** (3 of 4 field blocks are pixel-identical). Both
+collapse cleanly for List+Task.
+
+## Target
+
+One `AgentConfigEditorViewModel` + one `AgentConfigEditor` UserControl, instantiated
+per surface with a scope. The two host VMs keep only their non-agent concerns and host
+the editor as a child.
+
+### `ViewModels/Agent/AgentConfigEditorViewModel.cs` (new)
+
+- `enum AgentConfigScope { List, Task }`
+- ctor `(IWorkerClient worker, AgentConfigScope scope)`
+- Unified bindable surface (single names both views bind to):
+  `Model` (string?), `MaxTurns` (decimal?), `SystemPrompt` (string),
+  `SelectedAgent` (AgentInfo?); `ModelOptions`, `Agents`;
+  `ModelBadge`/`TurnsBadge`/`AgentBadge`, `ModelInheritedHint`/`TurnsInheritedHint`,
+  `EffectiveSystemPromptHint`; `EffectiveMaxTurns` (int), `IsRunning`/`IsEnabled`.
+- Reset commands: `ResetModel`, `ResetTurns`, `ResetAgent`, `ResetAll`.
+- Badges via `InheritanceResolver`: scope==Task → `Resolve(own, list, global)`;
+  scope==List → `ResolveList(own, global)` (adopts the dead method). One `BadgeFor`
+  helper covers both (List scope never yields the `List` source).
+- Load: `LoadForListAsync(listId)` and `LoadForTaskAsync(TaskEntity entity)` — both
+  pull agents + app-settings (global defaults); Task also pulls the list tier +
+  `EffectiveSystemPromptHint`. Localizer-change re-badges (port the `Loc.LanguageChanged`
+  handler + `IDisposable`).
+- Save: `SaveAsync()` is scope-aware — List builds `UpdateListConfigDto` →
+  `UpdateListConfigAsync`; Task builds `UpdateTaskAgentSettingsDto` →
+  `UpdateTaskAgentSettingsAsync`. Task scope also auto-saves debounced (300ms) on field
+  changes; List does not (the modal Save button calls `SaveAsync`). `SaveAsync` is
+  directly callable (tests bypass the debounce).
+- Task-only `Clear()` + `TaskId`.
+
+### `Views/Controls/AgentConfigEditor.axaml` (+ .axaml.cs) (new)
+
+- `x:DataType` = `AgentConfigEditorViewModel`; host sets `DataContext="{Binding Agent}"`.
+- The four field blocks (model/turns/systemprompt/agent) with `InheritedBadge` + `↺`
+  reset, lifted verbatim from the existing two views (they already match). Agent combo
+  shows Name + Description (both scopes; harmless for task). `EffectiveSystemPromptHint`
+  line gated on non-empty (hides for List).
+- `StyledProperty<bool> ShowAgentBrowse` (default false). True → render the Browse
+  button + path line; the browse file-picker code-behind lives here (moved from
+  `ListSettingsModalView`).
+- Shared localization namespace `settings.agentEditor.*` (model/maxTurns/systemPrompt/
+  agentFile/promptPrepended). Reset tooltip reuses `settings.inherit.resetToInherited`.
+
+### Re-point hosts
+
+- `ListSettingsModalViewModel`: drop the agent fields/badges/resets/option-lists; add
+  `public AgentConfigEditorViewModel Agent { get; }` (scope=List). `LoadAsync` →
+  `Agent.LoadForListAsync(listId)`. `SaveAsync` keeps `UpdateListAsync` (name/dir) and
+  adds `await Agent.SaveAsync()`. Keep working-dir browse (`BrowseClicked`).
+- `ListSettingsModalView.axaml`: replace the AGENT section body with
+  `<ctl:AgentConfigEditor DataContext="{Binding Agent}" ShowAgentBrowse="True"/>`; the
+  section-header "Reset agent settings" button binds `Agent.ResetAllCommand`. Remove the
+  agent browse code-behind (moved into the control).
+- `DetailsIslandViewModel`: `AgentSettings` becomes `AgentConfigEditorViewModel`
+  (scope=Task). Preserve the call sites: ctor, `EffectiveMaxTurns`→`TurnsText`
+  PropertyChanged hook, `IsRunning` push, `Dispose`, `Clear`, `TaskId`,
+  `LoadForTaskAsync(entity, ct)`.
+- `TaskHeaderBar.axaml`: replace the flyout field blocks with
+  `<ctl:AgentConfigEditor DataContext="{Binding AgentSettings}"/>` (ShowAgentBrowse=false).
+  Keep the gear button + heading.
+- Delete `AgentSettingsSectionViewModel.cs`.
+
+## Tests
+
+- New `tests/ClaudeDo.Ui.Tests/ViewModels/AgentConfigEditorViewModelTests.cs`:
+  - List scope: badges resolve override-vs-global; resets clear; `SaveAsync` builds the
+    right `UpdateListConfigDto` (via `StubWorkerClient`).
+  - Task scope: badges resolve override/list/global; `EffectiveMaxTurns`/
+    `EffectiveSystemPromptHint` from list tier; resets clear; `SaveAsync` builds the right
+    `UpdateTaskAgentSettingsDto`.
+- `InheritanceResolverTests` unchanged (resolver untouched).
+- Existing DetailsIsland* tests must stay green (they construct the VM but don't name the
+  moved members).
+
+## Acceptance
+
+- `dotnet build -c Release` clean for Ui (+ App).
+- `Ui.Tests` + `Localization.Tests` green.
+- One editor VM + one control drive both List and Task; duplicated field/badge/reset
+  logic deleted; `ResolveList` now has a real caller.
+- Visual gap flagged: open List Settings → Agent, and a task's gear flyout — verify
+  badges, ↺ resets, reset-all, agent browse (list only), system-prompt hint (task), and
+  that list Save persists + task auto-saves.
+
+## Commit
+
+`refactor(agent-config): single AgentConfigEditor for list + task scopes`. Stage by
+path. Commit this plan with it.

docs/superpowers/plans/2026-06-19-unify-diff-viewer.md

@@ -0,0 +1,111 @@
+# Phase 5 — DiffViewer (A1 + B2)
+
+Date: 2026-06-23
+Umbrella: `docs/superpowers/plans/2026-06-19-feature-unification-plan.md`
+Design: `docs/superpowers/specs/2026-06-19-feature-unification-design.md` (A1, B2)
+
+## Goal
+
+One diff component replaces the three parallel read-only diff windows:
+`DiffModalViewModel`/View, `WorktreeModalViewModel`/View, `PlanningDiffViewModel`/View.
+**Merge editor (`ConflictResolverViewModel`) is untouched** — per the design's hard
+decision; the viewer only *opens* it on conflict via the existing Merge flow.
+
+All three are already master-detail: **left nav pane + right `DiffLinesView`**. They
+differ only in left-pane content, chrome, and data source — so they collapse into one
+shell with a source mode.
+
+## Decisions (Mika, 2026-06-23)
+
+- **File nav = file-tree** (folder-grouped), not a flat list. Port `WorktreeModal`'s tree
+  + the Avalonia-12 `TreeView.SelectionChanged` workaround. Carry per-file status + +adds/
+  −dels into the tree rows (from the parsed `DiffFileViewModel`).
+- Planning keeps its **subtask-list + combined-mode toggle**; the branch source keeps its
+  **Merge** button.
+
+## Target
+
+### Shared types → `ViewModels/Modals/DiffModels.cs` (new, same namespace)
+
+Move out of the to-be-deleted VMs so `UnifiedDiffParser`/`DiffLinesView` keep compiling:
+`DiffLineKind`, `DiffFileStatus`, `DiffLineViewModel`, `DiffFileViewModel` (from
+`DiffModalViewModel.cs`), `SubtaskDiffRow` (from `PlanningDiffViewModel.cs`). Add new
+`DiffTreeNodeViewModel` (dir/file node; file leaves hold their `DiffFileViewModel`).
+
+### `DiffViewerViewModel` (`ViewModels/Modals/DiffViewerViewModel.cs`, new)
+
+ctor `(GitService git, IWorkerClient worker)`. A `DiffViewerMode { Files, Planning }`.
+
+- **File sources** (replaces DiffModal + WorktreeModal): config props `WorktreePath`,
+  `BaseRef`, `HeadCommit`, `FromCommitRange`, `TaskId`, `TaskTitle` + `ShowMergeModal`/
+  `ResolveMergeVm` delegates. `LoadAsync` pulls the whole diff via GitService
+  (`GetCommitRangeDiffAsync` | `GetBranchDiffAsync` | `GetDiffAsync`), parses with
+  `UnifiedDiffParser.Parse`, builds `FileTree`. `SelectedNode` (leaf) → `SelectedFile`
+  (header + binary/empty placeholders + `Lines`). Commit-range null-guard → "no longer
+  available" (preserve DiffModal behavior). `MergeCommand` (CanMerge = TaskId +
+  delegates) opens the MergeModal, closes on merged/routed (verbatim from DiffModal).
+- **Planning source** (replaces PlanningDiff): config `PlanningTaskId`, `TargetBranch`.
+  `LoadAsync` pulls `GetPlanningAggregateAsync` → `Subtasks`; `SelectedSubtask` →
+  `DisplayedDiff`; `IsCombinedMode` toggle → `BuildPlanningIntegrationBranchAsync`
+  (success → combined diff; conflict → `CombinedWarning` with subtask + file count;
+  null → hub-error warning). `DisplayedDiff` → flattened `DiffLines` (right pane).
+- Shared: `StatusMessage`, `CloseAction`, `CloseCommand`.
+
+### `DiffViewerView` (`Views/Modals/DiffViewerView.axaml` + `.cs`, new)
+
+`ModalShell`-based window. Left pane: `TreeView` (Files mode) or subtask `ListBox`
+(Planning mode), toggled by mode. Right pane: the DiffModal file pane (header + binary/
+empty/no-changes placeholders + `DiffLinesView Lines="SelectedFile.Lines"`) in Files mode,
+or `DiffLinesView Lines="DiffLines"` in Planning mode. Toolbar: combined toggle + warning
++ loading (Planning). Footer: Merge button (Files mode, CanMerge). Code-behind: `CloseAction`,
+the `TreeView.SelectionChanged` → `SelectedNode` workaround, dir-row tap-to-expand.
+
+### Re-point the 3 doors → one viewer
+
+- **`MergeSectionViewModel`**: `OpenDiffAsync` builds a Files-mode `DiffViewerViewModel`
+  (+ ShowMergeModal/ResolveMergeVm) and calls a single `ShowDiffViewer` delegate;
+  `ReviewCombinedDiffAsync` builds a Planning-mode one and calls the *same* delegate.
+  Replaces `ShowDiffModal` + `ShowPlanningDiffModal` with one `Func<DiffViewerViewModel,Task>
+  ShowDiffViewer`; keeps `ShowMergeModal`. (Resolve the VM via `_services`.)
+- **`DetailsIslandView.axaml.cs`**: replace the two `ShowDiffModal`/`ShowPlanningDiffModal`
+  wirings (→ `DiffModalView`/`PlanningDiffView`) with one `ShowDiffViewer` (→ `DiffViewerView`).
+  Keep `ShowMergeModal`.
+- **`WorktreesOverviewModalViewModel`**: `ShowDiff` builds a Files-mode viewer (worktree path
+  + base). Change `_diffVmFactory` from `Func<WorktreeModalViewModel>` to
+  `Func<DiffViewerViewModel>`; `ShowDiffAction` stays `Action<DiffViewerViewModel>`.
+- **`WindowDialogService.cs`**: `ShowDiffAction` → `new DiffViewerView` + `LoadAsync` + show.
+- **`Program.cs`**: register `DiffViewerViewModel` (transient) + `Func<DiffViewerViewModel>`;
+  drop the `WorktreeModalViewModel` registration.
+
+### Delete
+
+`DiffModalViewModel.cs`, `WorktreeModalViewModel.cs`, `PlanningDiffViewModel.cs`,
+`DiffModalView.axaml(.cs)`, `WorktreeModalView.axaml(.cs)`, `PlanningDiffView.axaml(.cs)`.
+
+### Localization
+
+Reuse existing keys in the merged view (`modals.diff.*` for the file pane, `planning.diff.*`
+for the planning toolbar). Prune clearly-orphaned `modals.worktree.*` if trivial; keep en/de
+parity.
+
+## Tests
+
+Replace `DiffModalViewModelTests` + `PlanningDiffViewModelTests` with
+`DiffViewerViewModelTests` preserving the behaviors: commit-range null-guard → unavailable;
+planning init populates + selects first; subtask select → DisplayedDiff; combined toggle
+success/conflict/null. `WorktreesOverviewBatchMergeTests` compiles unchanged (`() => null!`
+satisfies the new Func type). `UnifiedDiffParserTests` unchanged.
+
+## Acceptance
+
+- `dotnet build -c Release` clean (App); `Ui.Tests` + `Localization.Tests` green.
+- One viewer reached from all 3 doors; old VMs/views deleted; merge editor untouched.
+- Visual gap flagged: Details "Open Diff" (dirty + post-merge commit-range), Worktrees-
+  Overview "Show Diff" (tree), Details "Review Combined Diff" (subtasks + combined toggle),
+  and the Merge button still opens the merge form / resolver on conflict.
+
+## Commit
+
+`refactor(diff): single DiffViewer replaces DiffModal + WorktreeModal + PlanningDiff`.
+Stage by path (exclude concurrent peers' files). Then Phase 3 (WorktreeActions) follows as
+its own slice, reusing this viewer.

docs/superpowers/plans/2026-06-23-worker-log-footer-overlay.md

@@ -0,0 +1,32 @@
+# Plan — Worker log → footer + Log Visualizer overlay
+
+Design: `docs/superpowers/specs/2026-06-23-worker-log-footer-overlay-design.md`. Build on `main`, TDD, commit per task (Conventional Commits, explicit paths — shared worktree). Build `-c Release`.
+
+## Task 1 — `LogRingBuffer` (Worker) + tests
+- `src/ClaudeDo.Worker/Logging/WorkerLogRecord.cs` — `record WorkerLogRecord(string Message, WorkerLogLevel Level, DateTime TimestampUtc)`.
+- `src/ClaudeDo.Worker/Logging/LogRingBuffer.cs` — thread-safe, `TimeSpan window` + int cap; `Append(record)`, `Snapshot()`. Uses an injected clock func (`Func<DateTime>`) for testability (default `() => DateTime.UtcNow`).
+- Tests: age eviction, cap eviction, snapshot order. **No `DateTime.UtcNow` in tests — drive the clock.**
+
+## Task 2 — `BroadcastLogSink` (Worker) + tests
+- `src/ClaudeDo.Worker/Logging/BroadcastLogSink.cs : ILogEventSink` — level map, render (+exception first line), append-all-levels, broadcast Warn/Err via deferred `HubBroadcaster` (`Attach`), dedupe window (const 120s), loop-guard (skip SignalR `SourceContext` for broadcast; swallow broadcast exceptions). Inject clock func.
+- Broadcaster is an abstraction the test can fake: depend on a tiny `Func<string,WorkerLogLevel,DateTime,Task>?` set by `Attach`, OR on `HubBroadcaster` directly (it's a sealed class — prefer a delegate to keep the test pure). Use a delegate.
+- Tests: all levels buffered; only Warn/Err invoke the broadcast delegate; dedupe suppresses 2nd identical within window but still buffers; exception rendering; SignalR-source event buffered but not broadcast.
+
+## Task 3 — wire into `Program.cs` + `WorkerHub.GetRecentLogs`
+- `Program.cs`: create `LogRingBuffer` + `BroadcastLogSink` locals before build; `.WriteTo.Sink(broadcastSink)`; `AddSingleton(logBuffer)`; after build `broadcastSink.Attach((m,l,t) => broadcaster.WorkerLog(m,l,t))` using resolved `HubBroadcaster`.
+- `WorkerHub`: inject `LogRingBuffer`; `public IReadOnlyList<WorkerLogRecordDto> GetRecentLogs()` → snapshot mapped to DTO. Add `WorkerLogRecordDto` (Hub or shared). Update `WorkerHub` ctor → check hub-construction call sites/tests.
+- Build Worker `-c Release`; run Worker.Tests (filtered to new + hub).
+
+## Task 4 — `IWorkerClient.GetRecentLogsAsync` + WorkerClient + fakes
+- `IWorkerClient` + `WorkerClient` impl (`_hub.InvokeAsync<List<WorkerLogEntry>>("GetRecentLogs", ct)`).
+- Update fakes: `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs`, Worker.Tests UiVm fake(s) → return `Array.Empty<WorkerLogEntry>()`.
+- Build Ui + Worker.Tests.
+
+## Task 5 — `LogVisualizerViewModel` + View + dialog wiring + tests
+- VM (Modals/), View (Modals/, ModalShell), `IDialogService.ShowLogVisualizerAsync` + `WindowDialogService` impl.
+- `IslandsShellViewModel.OpenLogVisualizerCommand` (resolves VM, loads, shows). Make footer worker-log line a clickable Button → command.
+- Localization `vm.logVisualizer` en+de.
+- Tests: VM load/populate/filter. Build App `-c Release`; Ui.Tests + Localization.Tests.
+
+## Task 6 — verify + docs
+- Full relevant test pass. Update `src/ClaudeDo.Ui/CLAUDE.md` (overlay VM/view, footer click) + `src/ClaudeDo.Worker/CLAUDE.md` (Logging/ folder, sink, GetRecentLogs, WorkerLog now carries Serilog Warn/Err). Note visual-verification gap (overlay render) for the user.

docs/superpowers/plans/2026-06-25-interactive-ask-user.md

@@ -0,0 +1,56 @@
+# Plan — Interactive "Answer Claude's Questions"
+
+Spec: `docs/superpowers/specs/2026-06-25-interactive-ask-user-design.md`
+
+Implement on the shared main tree. Commit explicit paths per task (never `git add -A`).
+Build with `-c Release` (running Worker locks Debug). No real-Claude tests.
+
+## Task 1 — PendingQuestionRegistry (worker, new file)
+- `src/ClaudeDo.Worker/Runner/PendingQuestionRegistry.cs`: singleton; `record PendingQuestion(TaskId, QuestionId, Question)`.
+  - `(string QuestionId, Task<string> Answer) Register(taskId, question)` — overwrites any stale entry, `RunContinuationsAsynchronously`.
+  - `bool TryAnswer(taskId, questionId, answer)`; `PendingQuestion? Get(taskId)`; `void Remove(taskId, questionId)`.
+- Test: `tests/ClaudeDo.Worker.Tests/Runner/PendingQuestionRegistryTests.cs` — register→answer resolves the task; wrong questionId no-ops; Get reflects state; second Register overwrites.
+
+## Task 2 — AskUser MCP tool (worker)
+- `TaskRunMcpService.cs`: inject `PendingQuestionRegistry`; add
+  `[McpServerTool] async Task<string> AskUser(string question, CancellationToken ct)`:
+  - caller id from `_ctx.Current.CallerTaskId`; register; broadcast `TaskQuestionAsked`.
+  - await answer via `Task<string>.WaitAsync` with a 3-min linked-CTS; on timeout return the fallback string; on request-cancel rethrow.
+  - `finally`: `Remove` + broadcast `TaskQuestionResolved`.
+  - `[Description]`: when to use (only when a wrong guess is costly/irreversible; otherwise proceed).
+- Test: `tests/ClaudeDo.Worker.Tests/Runner/AskUserToolTests.cs` — answer path returns the answer; timeout path returns fallback (inject a short timeout or a seam) with a fake broadcaster + stub context accessor.
+
+## Task 3 — Wire MCP for all runs + timeout env (worker)
+- `TaskRunner.RunAsync`: move MCP-identity setup out of the `standalone` gate so every run gets `claudedo_run`; `AllowedTools` = `mcp__claudedo_run__AskUser` always, append `,mcp__claudedo_run__SuggestImprovement` when standalone. Keep token cleanup in `finally`.
+- `ClaudeProcess.cs`: `psi.Environment["MCP_TOOL_TIMEOUT"] = "200000";`.
+- System prompt file (PromptKind.System default): add one guidance line about `AskUser`.
+
+## Task 4 — Hub + Broadcaster (worker)
+- `HubBroadcaster.cs`: `TaskQuestionAsked(taskId, questionId, question)`, `TaskQuestionResolved(taskId, questionId)`.
+- `WorkerHub.cs`: inject registry; `bool AnswerTaskQuestion(taskId, questionId, answer)`; `PendingQuestionDto? GetPendingQuestion(taskId)`; `record PendingQuestionDto(...)`.
+- `Program.cs`: register `PendingQuestionRegistry` as singleton.
+
+## Task 5 — UI client (IWorkerClient/WorkerClient + fakes)
+- `IWorkerClient`: `Task AnswerTaskQuestionAsync(taskId, questionId, answer)`, `Task<PendingQuestionDto?> GetPendingQuestionAsync(taskId)`, events `Action<string,string,string>? TaskQuestionAskedEvent`, `Action<string,string>? TaskQuestionResolvedEvent`; UI DTO record.
+- `WorkerClient`: implement invokes + `On<...>` handlers raising the events.
+- Update hand-rolled `IWorkerClient` fakes in Ui.Tests (and Worker.Tests if present).
+
+## Task 6 — TaskMonitorViewModel (hot file)
+- Subscribe both events (filter by `_subscribedTaskId`); dispose handlers.
+- Props: `PendingQuestionId`, `PendingQuestion`, `HasPendingQuestion`, `AnswerDraft`, `IsWaitingForInput`.
+- `SubmitAnswerCommand` (CanExecute: non-empty draft + HasPendingQuestion) → `AnswerTaskQuestionAsync`; clear draft.
+- Clear pending on `TaskFinished` for this task and in `Reset()`.
+- Test: `TaskMonitorViewModelTests` — asked event surfaces question; submit invokes client + clears; resolved/finished clears.
+
+## Task 7 — Hydrate on attach (MissionControlViewModel)
+- In `HydrateAsync`, after `ApplyState`, call `GetPendingQuestionAsync(taskId)`; if present, set the monitor's pending question (re-attach case).
+
+## Task 8 — View banner (hot file, additive)
+- `MonitorPaneView.axaml`: a `Border DockPanel.Dock="Top"` above `SessionTerminalView`, `IsVisible="{Binding HasPendingQuestion}"`, showing the question text, a `TextBox` bound to `AnswerDraft` (Enter submits), and a Send `Button` → `SubmitAnswerCommand`. Mirror the roadblock-banner styling.
+
+## Task 9 — Localization
+- `en.json` + `de.json`: `missionControl.question.title`, `.placeholder`, `.send`. Keep parity (Localization.Tests).
+
+## Task 10 — Build + test + verify
+- `dotnet build` App + Worker `-c Release`; run Worker.Tests, Ui.Tests, Localization.Tests.
+- Self-review diffs. Flag the two manual verification gaps to Mika. Do not push.

docs/superpowers/plans/2026-06-25-mission-control.md

@@ -0,0 +1,98 @@
+# Plan — Mission Control (multi-task live monitoring)
+
+Spec: `docs/superpowers/specs/2026-06-25-mission-control-design.md`
+
+Execution: subagent-driven, **sonnet** model, TDD where a test is meaningful, build + test before
+each commit, one Conventional Commit per task. Stage files explicitly by path (never `git add -A`).
+**No duplication** — every task reuses the assets named in the spec's reuse map.
+
+---
+
+## Phase 1 — Extract the reusable monitor core (no behavior change)
+
+### Task 1.1 — Move `LogLineViewModel` + `LogKind` to their own file
+- Cut `LogKind` enum and `LogLineViewModel` from `DetailsIslandViewModel.cs` into
+  `ViewModels/Islands/LogLineViewModel.cs` (same namespace). No logic change.
+- Build `ClaudeDo.App`; run Ui.Tests. Commit: `refactor(ui): split LogLineViewModel into own file`.
+
+### Task 1.2 — Create `TaskMonitorViewModel` owning the streaming/status/outcome core
+- New `ViewModels/Islands/TaskMonitorViewModel.cs`. Move from `DetailsIslandViewModel`:
+  `Log`, `_subscribedTaskId`, `_formatter`, `_claudeBuf`, `OnTaskMessage`, `AppendStdoutLine`,
+  `FlushClaudeBuffer`, `ReplayLogFileAsync`, `ExpandUserPath`; `AgentState` + all `Is*` flags +
+  `OnAgentStateChanged`; `StatusToStateKey` / `FinishedStatusToStateKey`; `SessionOutcome` /
+  `Roadblocks` + `ApplyOutcome` + `RoadblockMarker`; the worker `TaskMessage/Started/Finished/Updated`
+  subscriptions for the streaming concern; `Title`/`TaskIdBadge`/`Model`/`TurnsText`/`TokensFormatted`/
+  diff text/elapsed; `BlockingReason` (+visible flag) from `BlockedByTaskId`/review/children/roadblocks.
+- Ctor takes `IDbContextFactory<ClaudeDoDbContext>`, `IWorkerClient`. `Attach(taskId)` /
+  `AttachAsync(entity)` to (re)bind + replay; `IDisposable` unsubscribes (mirror existing Dispose).
+- Unit test (Ui.Tests): feed `[stdout]`/`[claude]`/`[tool]` lines via the worker fake → `Log`
+  accumulates correctly; `TaskFinished` flips `AgentState`; `ApplyOutcome` splits the roadblock marker.
+  Reuse the existing IWorkerClient fake (see `iworkerclient_fakes_sync`).
+- Build + test. Commit: `feat(ui): extract TaskMonitorViewModel streaming core`.
+
+### Task 1.3 — `DetailsIslandViewModel` delegates to `Monitor`
+- Add `public TaskMonitorViewModel Monitor { get; }`; construct it; route `Bind`/`BindAsync` to
+  `Monitor.Attach`. Remove the moved members; keep subtasks/attachments/editing/merge/review/child
+  outcomes/notes/prep intact. Dispose `Monitor`.
+- Repoint `WorkConsole.axaml` Output-tab bindings (`Log`, `IsRunning/IsDone/IsFailed`,
+  `SessionOutcome`, `TurnsText`, `DiffAddText`/`DiffDelText`, `Model`) to `Monitor.*`. Leave
+  review/merge/session bindings unchanged.
+- Build + test. **Manual visual pass: Details pane behaves exactly as before** (flag for Mika).
+  Commit: `refactor(ui): route DetailsIsland streaming through Monitor`.
+
+---
+
+## Phase 2 — Mission Control window
+
+### Task 2.1 — `MissionControlViewModel`
+- New `ViewModels/MissionControlViewModel.cs`: `ObservableCollection<TaskMonitorViewModel> Monitors`
+  keyed by id; seed from `GetActive()`; add on `TaskStarted`, flip-state-and-keep on `TaskFinished`;
+  `ClearFinished` command; `ColumnCount`/layout signal from `Monitors.Count`; least-active collapse.
+  `IDisposable` disposes all monitors. Inject `IDbContextFactory`, `IWorkerClient`, `IServiceProvider`.
+- Register `AddSingleton<MissionControlViewModel>` in `App/Program.cs`.
+- Unit test: simulate two `TaskStarted` → two monitors; `TaskFinished` keeps the pane; `ColumnCount`
+  matches count. Commit: `feat(ui): add MissionControlViewModel`.
+
+### Task 2.2 — `RevealTaskAsync` navigation on the shell
+- Add `IslandsShellViewModel.RevealTaskAsync(taskId)` (resolve list → select → await load → select row).
+- Wire `TaskMonitorViewModel.OpenInApp` to it (via an `Action<string>?` set by the shell, like the
+  existing `CloseDetail`/`DeleteFromList` hooks — no new DI cycle).
+- Unit test for the select-by-id path. Commit: `feat(ui): reveal a task by id from anywhere`.
+
+### Task 2.3 — `MonitorPaneView` (reuses `SessionTerminalView`)
+- New `Views/MissionControl/MonitorPaneView.axaml(.cs)`: header (title/chip/tok/turn/elapsed),
+  blocking banner (`live-chip`/`terminal`/error-tint classes from IslandStyles — reuse), body =
+  `<SessionTerminalView Entries="{Binding Log}" ... />`, footer (Open in app / Detach / Cancel).
+  `x:DataType=TaskMonitorViewModel`. No new console control. Add `missionControl.*` en+de keys.
+- Build + Localization.Tests. Commit: `feat(ui): add MonitorPaneView`.
+
+### Task 2.4 — `MissionControlView` grid + `MissionControlWindow`
+- `MissionControlView.axaml`: `ItemsControl`/`UniformGrid` of `MonitorPaneView` driven by `ColumnCount`,
+  horizontal scroll fallback, header with `ClearFinished` (+ optional QuickAdd, deferrable).
+- `MissionControlWindow.axaml(.cs)`: hosts the view; lazy-create + hide-on-close.
+- Build. Commit: `feat(ui): add MissionControl window + grid`.
+
+### Task 2.5 — Launch button + lifetime
+- Title-bar toggle button in `MainWindow.axaml` → shell command that shows/focuses the window
+  (created lazily, owns the singleton VM).
+- Set `desktop.ShutdownMode = OnMainWindowClose` in `App.OnFrameworkInitializationCompleted`.
+- Build. **Manual visual pass** (flag for Mika): open with 2+ running tasks; main window still adds
+  tasks; blocking banner; Open-in-app. Commit: `feat(ui): open Mission Control from the title bar`.
+
+---
+
+## Phase 3 — Per-pane detach (lowest priority)
+
+### Task 3.1 — `TaskMonitorWindow` + detach/re-dock
+- `Views/MissionControl/TaskMonitorWindow.axaml(.cs)` hosting `MonitorPaneView`; `Detach` removes the
+  monitor from the grid and shows it in the window (optional always-on-top); close re-docks.
+- Build. Manual visual pass. Commit: `feat(ui): detach a monitor into its own window`.
+
+---
+
+## Cross-cutting checklist (every task)
+- Stage by explicit path; sonnet subagents; reuse per the spec's map — no new console/streaming/insert path.
+- en.json + de.json parity for any new string (Localization.Tests).
+- If `IWorkerClient`/ctor signatures change, update the hand-rolled fakes in **both** test projects.
+- Build `ClaudeDo.App` (`-c Release` if Worker is running) before marking a task done.
+- Never push without asking.

docs/superpowers/plans/2026-06-26-in-app-interactive-sessions.md

@@ -0,0 +1,101 @@
+# Plan — In-App Interactive Sessions
+
+Spec: `docs/superpowers/specs/2026-06-26-in-app-interactive-sessions-design.md`
+
+Implement on the shared main tree. Commit explicit paths per task (never `git add -A`).
+Build with `-c Release` (running Worker locks Debug). No real-Claude tests — fake the
+process stream. Sonnet subagents. Autonomous `TaskRunner`/`ClaudeProcess` path stays untouched.
+
+## Task 1 — StreamingClaudeSession (worker, new file)
+- `Runner/StreamingClaudeSession.cs`: persistent `claude` process. Ctor takes resolved args,
+  working dir, seeded first prompt, a line callback, `WorkerConfig`. Reuse the
+  `ProcessStartInfo` shape + `MCP_TOOL_TIMEOUT="200000"` from `ClaudeProcess`.
+  - Keeps stdin open; sends the first prompt as a user-message JSON line (escape via
+    `JsonSerializer`).
+  - stdout/stderr read tasks → line callback; parse `result` events to track `IsTurnInFlight`.
+  - `SendUserMessageAsync(text, ct)` — enqueue/write a user-message JSON line; if
+    `IsTurnInFlight`, also `InterruptAsync`.
+  - `InterruptAsync(ct)` — write the control-protocol interrupt line; best-effort (swallow +
+    log on failure → queue fallback applies).
+  - `StopAsync` / `DisposeAsync` — close stdin, kill the tree, await exit.
+  - Injectable stream seam so a fake can drive it without a real `claude` binary.
+- Test: `StreamingClaudeSessionTests` (fake stream) — first message emitted; `result` flips
+  `IsTurnInFlight` off; a sent message produces a second turn; mid-turn send calls interrupt
+  then delivers; interrupt throw → delivered at natural turn end; stop kills.
+
+## Task 2 — LiveSessionRegistry (worker, new file)
+- `Runner/LiveSessionRegistry.cs`: singleton; `Register(taskId, StreamingClaudeSession)`,
+  `bool TryGet(taskId, out session)`, `Unregister(taskId)`, `Task StopAsync(taskId)`.
+- Test: register→get; unregister; second register stops+replaces; missing get returns false.
+
+## Task 3 — InteractiveSessionService (worker, new file)
+- `Planning/InteractiveSessionService.cs`: inject `IDbContextFactory`, `WorkerConfig`,
+  `ClaudeArgsBuilder` (or build args inline), `HubBroadcaster`, `LiveSessionRegistry`.
+  - `StartAsync(taskId, ct)`: resolve list working dir + seeded prompt (reuse the body of
+    `PlanningSessionManager.OpenInteractiveAsync` + `BuildInteractivePrompt`); build interactive
+    args (`--model PlanningAlias --permission-mode auto` + streaming flags); spawn the session
+    with a callback that does `HubBroadcaster.TaskMessage(taskId, "[stdout] " + line)`;
+    register; broadcast `InteractiveSessionStarted`. Reject if one is already live for the task.
+  - `SendAsync(taskId, text, ct)` → registry `TryGet` → `SendUserMessageAsync`.
+  - `StopAsync(taskId, ct)` → registry stop + `InteractiveSessionEnded`.
+- Move `OpenInteractiveAsync`/`BuildInteractivePrompt` out of `PlanningSessionManager` if it
+  reads cleaner (or call into it). Remove the `InteractiveLaunchContext` terminal coupling.
+- Test: `InteractiveSessionServiceTests` (fake session factory + fake broadcaster) — start
+  resolves dir, seeds prompt, registers, broadcasts started; missing working dir throws;
+  send routes; stop broadcasts ended.
+
+## Task 4 — Remove terminal interactive path (worker)
+- `Planning/Interfaces/ITerminalLauncher.cs` + `WindowsTerminalLauncher.cs`: delete
+  `LaunchInteractiveAsync`; remove `InteractiveLaunchContext` from `PlanningSessionContext.cs`.
+  Keep planning start/resume launches.
+- Fix any references; ensure the planning launcher tests still build.
+
+## Task 5 — Hub + Broadcaster + DI (worker)
+- `Hub/WorkerHub.cs`: re-point `OpenInteractiveTerminalAsync` to
+  `InteractiveSessionService.StartAsync` (drop `_launcher.LaunchInteractiveAsync`); add
+  `Task SendInteractiveMessage(taskId, text)`, `Task StopInteractiveSession(taskId)`
+  (+ optional `InterruptInteractiveSession`).
+- `Hub/HubBroadcaster.cs`: `InteractiveSessionStarted(taskId)`, `InteractiveSessionEnded(taskId)`.
+- `Program.cs`: register `LiveSessionRegistry` + `InteractiveSessionService` singletons.
+- Test: `WorkerHub` send routes to a fake service; start invokes the service.
+
+## Task 6 — UI client + fakes (ui)
+- `Services/Interfaces/IWorkerClient.cs` + `WorkerClient.cs`: `SendInteractiveMessageAsync(
+  taskId, text)`, `StopInteractiveSessionAsync(taskId)` (+ optional interrupt); events
+  `Action<string>? InteractiveSessionStartedEvent`, `InteractiveSessionEndedEvent` with
+  `On<...>` handlers. `OpenInteractiveTerminalAsync` keeps name/signature.
+- Update hand-rolled `IWorkerClient` fakes in **both** Ui.Tests and Worker.Tests.
+
+## Task 7 — StreamLineFormatter user bubble (ui)
+- Render `type:"user"` NDJSON events as `LogKind.User` (add the kind if missing).
+- Test: a `user` event yields a `LogKind.User` `LogLineViewModel` with the text.
+
+## Task 8 — Shared composer state on the session VMs (ui, hot files)
+- Add to `TaskMonitorViewModel` and `DetailsIslandViewModel` (factor a shared helper —
+  `InteractiveComposer` — to avoid duplication): `ComposerDraft`, `IsInteractiveLive`
+  (toggled by `InteractiveSessionStarted/Ended` for the subscribed task),
+  `SubmitComposerCommand` (CanExecute: non-empty draft && (`HasPendingQuestion` ||
+  `IsInteractiveLive`)). Route: pending question → existing `AnswerTaskQuestionAsync`; else →
+  `SendInteractiveMessageAsync`. Clear draft on submit; clear `IsInteractiveLive` on ended.
+- `MissionControlViewModel`: `EnsureMonitor(taskId)` on `InteractiveSessionStarted`.
+- Test: composer enabled while interactive-live; submit routes (chat vs answer) + clears;
+  ended clears live state.
+
+## Task 9 — SessionTerminalView composer (ui)
+- `Views/Islands/SessionTerminalView.axaml(.cs)`: optional composer docked bottom (styled
+  props `IsComposerVisible`, `ComposerText`, `SubmitCommand`, `ComposerPlaceholder`); TextBox
+  (Enter submits) + Send button. Reuse existing tokens (no inline values).
+- Bind it in `MonitorPaneView.axaml` and `DetailsIslandView.axaml` to each VM's composer
+  state. Fold the existing AskUser banner into the composer's "answering" state if it reads
+  cleaner; otherwise leave the banner and add the composer below.
+
+## Task 10 — Localization
+- `en.json` + `de.json`: `interactive.composer.placeholder`, `.send`, `.stop`, plus any
+  "session ended" notice. Keep parity (Localization.Tests).
+
+## Task 11 — Build + test + verify
+- Build App + Worker `-c Release`; run Worker.Tests, Ui.Tests, Localization.Tests.
+- Self-review diffs. **Manual smoke (real CLI) — flag to Mika:** (a) Run interactively opens
+  an in-app chat (no terminal) and streams; (b) sending a message mid-turn interrupts +
+  redirects; (c) stop kills the process; (d) session shows in both task detail and Mission
+  Control. Do not push.

docs/superpowers/plans/2026-07-03-session-skills.md

@@ -0,0 +1,94 @@
+# Session Skills — Implementation Plan
+
+Spec: `docs/superpowers/specs/2026-07-03-session-skills-design.md`
+Approach: subagent-driven TDD (sonnet), build + test + commit per task, stage files by
+path (never `git add -A`).
+
+**Pre-flight (do first, before building anything):** manual smoke test — drop a skill
+into a scratch worktree's `.claude/skills/` and run `claude -p` to confirm cwd skills are
+discovered in headless mode. The whole feature rests on this. If it fails, stop and
+redesign around `CLAUDE_CONFIG_DIR`.
+
+---
+
+## Task 1 — Data layer: columns + registry table + migration
+
+- Add nullable `SessionSkills` (string, JSON array) to `TaskEntity`, `ListConfigEntity`,
+  `AppSettingsEntity`; map `session_skills` columns in their `*Configuration.cs`.
+- New `SessionSkillEntity` (`name` PK, `source_url`, `pinned_ref`, `subpath`,
+  `description`, `added_at`) — one row per skill; a multi-skill repo writes N rows sharing
+  `source_url`/`pinned_ref` — + configuration + `session_skills` table.
+- New `SessionSkillRepository` (async, CancellationToken): `ListAsync`, `GetAsync(name)`,
+  `UpsertAsync`, `DeleteAsync(name)`, `DeleteBySourceAsync(url)`, `ListBySourceAsync(url)`.
+- EF migration `AddSessionSkills` (columns + table).
+- **Tests (Data.Tests):** repository CRUD on real SQLite; JSON column round-trips a
+  name list.
+
+## Task 2 — Registry service (install / update / remove)
+
+- `Skills/SessionSkillRegistry` + `Skills/Interfaces/ISessionSkillRegistry`,
+  `IRepoCloner` (clone abstraction so tests inject a local source dir).
+- `GitRepoCloner` (production) does `git clone` + resolves HEAD SHA.
+- Install: clone → **detect layout** (`skills/*/SKILL.md` bundle → each subskill; else
+  root `SKILL.md` → single; else reject) → per skill parse YAML frontmatter (`name`,
+  `description`), copy its dir **flat** to `~/.todo-app/session-skills/<name>/`, upsert a
+  row with `subpath`. Reject collision with a skill from a different source; reinstalling
+  the same source refreshes.
+- Update(sourceUrl) / Remove(sourceUrl) per spec (act on all of a source's skills).
+- **Tests (Worker.Tests):** install a **multi-skill** fixture (fake cloner, mirrors
+  ponytail's `skills/*/SKILL.md`) → N rows + N flat dirs; install a root-`SKILL.md`
+  fixture → 1 row; neither → rejected; cross-source name collision rejected;
+  remove-by-source deletes all its dirs + rows. **No real network / no real claude CLI.**
+
+## Task 3 — Resolution: union into ClaudeRunConfig
+
+- Add `IReadOnlyList<string> SkillNames` to `ClaudeRunConfig` (default empty).
+- In `TaskRunner.ResolveConfigAsync`: parse each level's `session_skills`, union + dedup,
+  filter to registry-existing names (drop + log missing).
+- **Tests (Worker.Tests):** union across the three levels; dedup; unknown name dropped.
+
+## Task 4 — Seeder
+
+- `Skills/SessionSkillSeeder` + interface. `SeedAsync(cwd, skillNames, isWorktree, ct)`:
+  copy each installed skill dir → `<cwd>/.claude/skills/<name>/`; if worktree, append
+  `/.claude/skills/<name>/` to `git rev-parse --git-path info/exclude` target if absent.
+- Wire into `TaskRunner` after run-dir resolution, before `ClaudeProcess.RunAsync`
+  (both worktree and sandbox paths).
+- **Tests (Worker.Tests):** seeds into real temp dir; idempotent re-seed; worktree
+  exclude line written once and not duplicated; seeded path is git-ignored (real git
+  temp repo → `git status` clean for the seeded dir).
+
+## Task 5 — Hub + DTOs + client
+
+- `WorkerHub`: `GetSessionSkills`, `InstallSessionSkill(url)`, `UpdateSessionSkill(name)`,
+  `RemoveSessionSkill(name)`.
+- New `SessionSkillDto`; extend `AppSettingsDto`, `ListConfigDto`, `UpdateListConfigDto`,
+  `UpdateTaskAgentSettingsDto` with skill-name lists; map in the update handlers.
+- `IWorkerClient` + `WorkerClient` additions.
+- **Update hand-rolled fakes** in Worker.Tests + Ui.Tests (memory
+  `iworkerclient_fakes_sync`).
+- **Tests:** hub method round-trip via existing hub test harness where present.
+
+## Task 6 — UI: registry tab + selectors
+
+- `SessionSkillsSettingsTabViewModel` + a **Skills** tab in `SettingsModalView.axaml`:
+  installed list, Add (URL), Update, Remove, status line. Mirror
+  `FilesSettingsTabViewModel`.
+- Global multi-select in General settings tab → `AppSettings.SessionSkills`.
+- Skills multi-select in shared `AgentConfigEditor` (covers List + Task) with inheritance
+  badge, wired through `AgentConfigEditorViewModel`.
+- Localization: add EN + DE keys in parity (Localization.Tests enforces).
+- **Tests (Ui.Tests / Localization.Tests):** VM load/save of selections; locale parity.
+- **Visual verification is Mika's** — flag the gaps.
+
+## Task 7 — Wiring, build, end-to-end smoke
+
+- DI registration (registry, cloner, seeder) in `Program.cs`.
+- Build all touched projects `-c Release`; run Worker/Data/Ui/Localization test projects.
+- Manual E2E: install ponytail via the UI, enable per-task, run a task, confirm the skill
+  is available to the agent and **not** committed and **not** in interactive sessions.
+
+---
+
+Commit per task with Conventional Commits (`feat(worker|ui|data): …`). Commit the
+spec + plan docs first.

docs/superpowers/plans/2026-07-23-conpty-interactive-sessions.md

@@ -0,0 +1,88 @@
+# Plan — ConPTY Interactive Sessions
+
+Spec: `docs/superpowers/specs/2026-07-23-conpty-interactive-sessions-design.md`
+Date: 2026-07-23
+
+Execution: subagent-driven-development, sonnet model, TDD where meaningful,
+build + test + commit per task. Stage files explicitly by path (never
+`git add -A`). Terminal rendering is visual — flagged for the user's visual pass.
+
+## Task 0 — Spike: embed a ConPTY terminal running `claude`
+
+Not TDD; a throwaway proof. Add a temporary window/view that embeds each
+candidate control and launches `claude` in a known worktree.
+
+- Evaluate **SvcSystems.UI.Terminal** and **Iciclecreek.Avalonia.Terminal**.
+- Acceptance: the real `claude` TUI renders correctly — colors, resize/reflow,
+  and a live permission prompt is usable; input reaches the CLI.
+- Output: pick one library; note the control API (start with cwd/exe/args/env,
+  process-exited event, dispose/kill). Record the decision in the spec.
+- Remove the throwaway harness before Task 1 (or keep as a manual dev sample,
+  not wired into the app).
+
+**Stop for the user's visual verification of the spike before continuing.**
+
+## Task 1 — Worker: interactive launch-spec endpoint
+
+- Add a Worker service/hub method that, given a taskId, prepares the worktree
+  (session-skills seeding, agent files, MCP config, env — reuse the autonomous
+  run prep path) and returns a `LaunchSpec { cwd, exe, args, env }`.
+- Reuse `WindowsTerminalLauncher.BuildResumeCommand` for exe/args.
+- Guards mirror `ResumeTaskInTerminal` (not Running/Queued, persisted SessionId,
+  worktree Active/Kept). Never-run task → spec without `--resume` (fresh start).
+- Tests (Worker.Tests, real SQLite/git): guard cases, spec contents for a
+  resumable task, fresh-start case. No real `claude` in tests.
+
+## Task 2 — Worker: ad-hoc launch-spec
+
+- Method to build a `LaunchSpec` for a free session in a given directory:
+  MCP config + env set up, no task/session-skills seeding.
+- Tests: env/MCP presence, arbitrary cwd.
+
+## Task 3 — UI: terminal host control + view model
+
+- Wrap the chosen library in an app control/view (e.g. `InteractiveTerminalView`
+  + `InteractiveTerminalViewModel`) that starts from a `LaunchSpec` and exposes
+  running/exited state.
+- `IWorkerClient`: add methods to fetch the task and ad-hoc launch specs; wire
+  the SignalR client + hub method.
+- Update hand-rolled `IWorkerClient`/hub fakes in BOTH test projects.
+- Tests: view model starts/stops lifecycle with a fake terminal backend;
+  fake worker returns a spec.
+
+## Task 4 — Command Center: host interactive panes + entry points
+
+- `MonitorPaneView`: autonomous panes keep the streamed log; interactive panes
+  host the terminal control.
+- Entry points: "Open interactive session" from a task (task-based) and a
+  "New session" action (ad-hoc, pick directory).
+- Layout toggle: focus (tabs) ↔ overview (grid); reuse/extend the existing
+  `UniformGrid` column logic for the grid mode.
+- Tests: view-model level (pane kind selection, layout toggle state). Rendering
+  is a visual-pass item.
+
+## Task 5 — Remove the streaming interactive stack
+
+Only after Tasks 1–4 land and the terminal path works.
+
+- Worker: delete `StreamingClaudeSession`, `InteractiveSessionService`,
+  interactive `WorkerHub` methods + broadcast events, DI registrations.
+  Verify `LiveSessionRegistry` / `IdleSessionReaper` usage first; remove only if
+  unreferenced.
+- UI: remove composer bits on `TaskMonitorViewModel`, the composer/queued portion
+  of `SessionTerminalView`, `IWorkerClient` interactive methods.
+- Update fakes and delete now-dead tests. Full build + all test projects green.
+
+## Task 6 — Docs
+
+- Update `docs/open.md` with visual-verification items (spike render, terminal
+  resize/focus, grid vs tabs).
+- Update affected per-project `CLAUDE.md` (Worker interactive removal, UI new
+  terminal host).
+
+## Verification gates
+
+- After Task 0: user visual pass on the spike.
+- After Task 4: user visual pass on Command Center (task + ad-hoc, tabs + grid,
+  permission prompt round-trip).
+- Never claim the terminal UI works without the user running it.

docs/superpowers/plans/2026-07-24-merge-helper.md

@@ -0,0 +1,79 @@
+# Merge Helper — Implementation Plan
+
+Spec: `docs/superpowers/specs/2026-07-24-merge-helper-design.md`
+Approach: subagent-driven (one subagent per task, `sonnet`, TDD, stage files by path — never `git add -A`). Build with `-c Release` per-csproj (a running Worker locks `Debug`). Commit per task, Conventional Commits.
+
+---
+
+## Phase A — Worker MCP conflict tools
+
+Independently useful; merges first. All in `src/ClaudeDo.Worker/External/ExternalMcpService.cs` + tests in `tests/ClaudeDo.Worker.Tests/`.
+
+### A1 — Verify engine surface (spike, no commit)
+Read `TaskMergeService.MergeAsync` / `ContinueMergeAsync` / `AbortMergeAsync` and the hub conflict flow (`WorkerHub.StartConflictMerge`/`ContinueConflictMerge`/`AbortConflictMerge`). Pin down:
+- exact `ContinueMergeAsync` / `AbortMergeAsync` signatures and how in-progress-merge state is located (repo + target branch from task/list, not shared hub state);
+- how the childless approve path (`ApproveAndMergeAsync`) threads `leaveConflictsInTree`.
+Record findings in the task notes; feeds A2/A3.
+
+### A2 — `leaveConflictsInTree` on review_task / merge_task
+- TDD: tests in `Worker.Tests` (real git) — clean merge → Done; conflict + flag → `conflict_in_tree`, markers present, task stays `WaitingForReview`, `repoPath` returned.
+- Add optional param `leaveConflictsInTree = false` to `MergeTask` and `ReviewTask` (approve branch). When true, call the `leaveConflictsInTree:true` engine path and map the conflict result to `{ mergeStatus/merged, conflicts, repoPath }`.
+- Keep default behaviour (abort-on-conflict) byte-identical when the flag is absent/false.
+- Commit: `feat(worker): let review_task/merge_task leave conflicts in tree via MCP`
+
+### A3 — `continue_merge` + `abort_merge` MCP tools
+- TDD: continue after on-disk resolution → committed, task Done, worktree merged; continue with markers remaining → returns conflicts; abort → markers gone, task `WaitingForReview`; both on no-active-merge → clean MCP error; `TaskUpdated` fired.
+- Add `[McpServerTool] continue_merge(taskId)` → `ContinueMergeAsync`; `abort_merge(taskId)` → `AbortMergeAsync`. Locate the merge from the task's repo/target. Emit `TaskUpdated`.
+- **Route both single-task and orchestrated (parent/children) in-progress merges** where locatable from the task (per A1 findings): detect the kind and call the matching engine continue/abort (`TaskMergeService` vs `PlanningMergeOrchestrator.Continue/Abort`). If the orchestrated path can't be located without hub UI state, leave it to the manual fallback (documented in the B1 prompt) and note the gap in `docs/open.md`.
+- Commit: `feat(worker): add continue_merge and abort_merge MCP tools`
+
+---
+
+## Phase B — Worker launch for the merge-helper session
+
+### B1 — Prompt templates
+- Add `PromptKind.MergeHelper` + `PromptKind.MergeHelperInitial` to `ClaudeDo.Data/PromptFiles.cs` (file names `merge-helper-system.md` / `merge-helper-initial.md`, built-in `DefaultFor`, `Render` tokens for the initial brief).
+- System prompt encodes §7 behaviour (per-status algorithm, ask-on-uncertainty, summary format). Merge-state rule: **prefer MCP tools whenever they apply**; hand-merge (Edit + `git commit -- <paths>`) is an accepted fallback only for merges the MCP tools can't reach (§5.3), never a shortcut around them.
+- Initial brief renders a task table `{id,title,status,list,repo}` + scope label.
+- TDD: `PromptFiles` tests — kinds resolve, defaults non-empty, `Render` substitutes brief tokens.
+- Commit: `feat(data): add merge-helper prompt templates`
+
+### B2 — `BuildForMergeHelper` launch spec
+- TDD (`Worker.Tests`): distinct-repo `--add-dir` set computed from selected tasks; correct cwd per scope (per-list repo vs first repo global); brief file written to `~/.todo-app/merge-helper-sessions/<guid>/brief.md`; allowed-tools + `--permission-mode default` + `MCP_TOOL_TIMEOUT` env correct; single-line kickoff points at the brief.
+- Implement `InteractiveLaunchSpecService.BuildForMergeHelper(IReadOnlyList<string> taskIds, MergeHelperScope scope, ct)`. Reuse the planning brief-file/kickoff pattern.
+- Commit: `feat(worker): build merge-helper interactive launch spec`
+
+### B3 — Hub endpoint + client method
+- `WorkerHub.GetMergeHelperLaunchSpec(string[] taskIds, string? listId)`; `IWorkerClient.GetMergeHelperLaunchSpecAsync(...)` + `WorkerClient` impl.
+- Update hand-rolled `IWorkerClient` fakes in **both** test projects (see gotcha memory).
+- Commit: `feat(worker): expose merge-helper launch spec over the hub`
+
+---
+
+## Phase C — UI
+
+### C1 — Selection dialog (View + VM)
+- New `MergeHelperSelectionViewModel` + `MergeHelperSelectionDialog.axaml` (compiled bindings, `TaskCompletionSource<T>` pattern). Checkbox rows (title, status badge, list/repo), grouping in global mode, default ticks per §4, select-all/none, confirm disabled when empty.
+- Candidates via existing `list_tasks`/worker client; filter client-side.
+- TDD (`Ui.Tests`): default-tick logic, empty→confirm-disabled, returns ordered selected IDs + list mapping.
+- Commit: `feat(ui): add merge-helper task selection dialog`
+
+### C2 — Entry points + event plumbing
+- Per-list context-menu item **"Let Claude handle it"** in `ListsIslandView.axaml` (user-list rows) + one global entry in the footer. Bind to `LetClaudeHandleCommand` on `ListsIslandViewModel` (param = `ListNavItemViewModel` or a global sentinel).
+- VM raises `LetClaudeHandleRequested(MergeHelperScope)`; `IslandsShellViewModel` forwards to Mission Control.
+- Commit: `feat(ui): add "Let Claude handle it" entry points`
+
+### C3 — Mission Control wiring
+- `MissionControlViewModel.OpenMergeHelperConPtySessionAsync(scope)`: open selection dialog → on confirm, `GetMergeHelperLaunchSpecAsync` → wrap in `TerminalLaunchDescriptor` → new `ConPtyPaneViewModel` (never deduped) → add to `ConPtySessions`/`Panes`.
+- Commit: `feat(ui): open merge-helper ConPTY tile from selection`
+
+---
+
+## Verify (per task + at the end)
+- Read each subagent diff; build the touched csproj `-c Release`; run the relevant test project.
+- `locales/en.json` + `de.json` parity for any new UI strings (Localization.Tests enforces it).
+- Flag visual-verification gaps (dialog layout, tile) for the user — never claim UI works without a run.
+- End-to-end ConPTY smoke (real Claude) is a manual item in `docs/open.md`.
+
+## Commit docs first
+`docs(merge-helper): spec + implementation plan` (this file + the spec).

docs/superpowers/plans/2026-07-27-list-handler.md

@@ -0,0 +1,938 @@
+# Per-List Task Handler Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Make "Let Claude handle it" list-scoped only, and turn its prompt into a five-phase run — read all tasks, dedupe, enhance, queue, review+merge.
+
+**Architecture:** Four independent commits. Two touch only leaf code (the MCP status tool, the prompt templates). One strips the global UI entry point. The last is an atomic sweep that makes `listId` non-nullable end to end and collapses the launch spec to a single repo — atomic because a half-flipped signature chain leaves nullable warnings scattered across a commit boundary.
+
+**Tech Stack:** .NET 8, xUnit, Avalonia 12, EF Core + SQLite, CommunityToolkit.Mvvm.
+
+**Spec:** `docs/superpowers/specs/2026-07-27-list-handler-design.md`
+
+**Build note:** `dotnet build ClaudeDo.slnx` needs .NET 9 — build individual csproj with `-c Release` (a running Worker locks `Debug` output).
+
+**Staging note:** the checkout is shared with parallel sessions. Always `git add -- <exact paths>` and `git commit -- <exact paths>`. Never `git add -A`, never a bare `git commit`.
+
+---
+
+### Task 1: `update_task_status` accepts `Cancelled`
+
+Dedupe needs to retire an **Idle** duplicate. Today nothing can: `UpdateTaskStatus` allows only
+`Idle`/`Queued`, `cancel_task` only cancels a *running* task, and `review_task(decision="cancel")`
+requires WaitingForReview/Running/Queued. `TaskStateService.CancelAsync` already owns the
+transition and its side effects.
+
+`BatchMcpTools.BatchUpdateTaskStatus` delegates to this same method, so batch cancel comes free.
+
+**Files:**
+- Modify: `src/ClaudeDo.Worker/External/ExternalMcpService.cs:264-300`
+- Test: `tests/ClaudeDo.Worker.Tests/External/ExternalMcpServiceTests.cs`
+
+- [ ] **Step 1: Write the failing tests**
+
+Append inside the `ExternalMcpServiceTests` class. `SeedTaskAsync` does not exist in this class —
+seed inline the way the existing tests do, via `_lists` / `_tasks`.
+
+```csharp
+    private async Task<TaskEntity> SeedPlainTaskAsync(TaskStatus status)
+    {
+        var listId = Guid.NewGuid().ToString();
+        await _lists.AddAsync(new ListEntity { Id = listId, Name = "L", CreatedAt = DateTime.UtcNow });
+        var task = new TaskEntity
+        {
+            Id = Guid.NewGuid().ToString(), ListId = listId, Title = "t",
+            Status = status, CreatedAt = DateTime.UtcNow, CommitType = "chore",
+        };
+        await _tasks.AddAsync(task);
+        return task;
+    }
+
+    [Fact]
+    public async Task UpdateTaskStatus_Cancelled_CancelsAnIdleTask()
+    {
+        var task = await SeedPlainTaskAsync(TaskStatus.Idle);
+        var queue = CreateQueue();
+        var sut = BuildSut(queue);
+
+        var dto = await sut.UpdateTaskStatus(task.Id, "Cancelled", CancellationToken.None);
+
+        Assert.Equal("Cancelled", dto.Status);
+        var loaded = await _tasks.GetByIdAsync(task.Id);
+        Assert.Equal(TaskStatus.Cancelled, loaded!.Status);
+    }
+
+    [Fact]
+    public async Task UpdateTaskStatus_Done_StillRejected()
+    {
+        var task = await SeedPlainTaskAsync(TaskStatus.Idle);
+        var queue = CreateQueue();
+        var sut = BuildSut(queue);
+
+        var ex = await Assert.ThrowsAsync<InvalidOperationException>(
+            () => sut.UpdateTaskStatus(task.Id, "Done", CancellationToken.None));
+        Assert.Contains("not settable externally", ex.Message);
+    }
+```
+
+- [ ] **Step 2: Run the tests to verify they fail**
+
+```bash
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~ExternalMcpServiceTests.UpdateTaskStatus"
+```
+
+Expected: `UpdateTaskStatus_Cancelled_CancelsAnIdleTask` FAILS with
+`Status 'Cancelled' is not settable externally.`; `UpdateTaskStatus_Done_StillRejected` passes.
+
+- [ ] **Step 3: Add the `Cancelled` branch**
+
+In `ExternalMcpService.UpdateTaskStatus`, insert between the `Queued` case and `default`:
+
+```csharp
+            case TaskStatus.Cancelled:
+                var cancelResult = await _state.CancelAsync(taskId, DateTime.UtcNow, cancellationToken);
+                if (!cancelResult.Ok)
+                    throw new InvalidOperationException(cancelResult.Reason ?? "Cannot cancel task.");
+                break;
+```
+
+Then update the `[McpServerTool, Description(...)]` text directly above the method — it currently
+claims only Idle and Queued are permitted. Replace the whole attribute with:
+
+```csharp
+    [McpServerTool, Description(
+        "Update a task's status. Only 'Idle', 'Queued' and 'Cancelled' are permitted externally — " +
+        "use run_task_now for execution control, and review_task to act on a WaitingForReview task. " +
+        "Settable: Idle (reset to editable), Queued (enqueue for execution), " +
+        "Cancelled (retire the task without deleting it; it can be reset to Idle later). " +
+        "Full lifecycle: Idle → Queued → Running → WaitingForReview → Done | Failed | Cancelled.")]
+```
+
+Also fix the `default` branch message, which still points at `cancel_task`:
+
+```csharp
+            default:
+                throw new InvalidOperationException(
+                    $"Status '{target}' is not settable externally. Use run_task_now or review_task.");
+```
+
+- [ ] **Step 4: Run the tests to verify they pass**
+
+```bash
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~ExternalMcpServiceTests"
+```
+
+Expected: all pass.
+
+- [ ] **Step 5: Run the MCP schema test**
+
+`ExternalMcpToolSchemaTests` asserts over tool descriptions and may pin the old text.
+
+```bash
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~ExternalMcpToolSchemaTests"
+```
+
+Expected: PASS. If it fails on the changed description, update the assertion to match the new
+text — do not revert the description.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add -- src/ClaudeDo.Worker/External/ExternalMcpService.cs tests/ClaudeDo.Worker.Tests/External/ExternalMcpServiceTests.cs
+git commit -m "feat(worker): allow update_task_status to set Cancelled" -- src/ClaudeDo.Worker/External/ExternalMcpService.cs tests/ClaudeDo.Worker.Tests/External/ExternalMcpServiceTests.cs
+```
+
+(If Step 5 required a schema-test edit, add that path to both commands too.)
+
+---
+
+### Task 2: Five-phase helper prompt
+
+**Files:**
+- Modify: `src/ClaudeDo.Data/PromptFiles.cs:231-276` (`MergeHelperDefault`, `MergeHelperInitialDefault`)
+- Test: `tests/ClaudeDo.Data.Tests/PromptFilesTests.cs:54-80`
+
+- [ ] **Step 1: Write the failing tests**
+
+Replace the existing `DefaultFor_merge_helper_is_non_empty_and_mentions_the_merge_tools` test with
+the two below, and keep the other merge-helper tests as they are.
+
+```csharp
+    [Fact]
+    public void DefaultFor_merge_helper_covers_all_five_phases()
+    {
+        var d = PromptFiles.DefaultFor(PromptKind.MergeHelper);
+        Assert.False(string.IsNullOrWhiteSpace(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
+    }
+```
+
+- [ ] **Step 2: Run the tests to verify they fail**
+
+```bash
+dotnet test tests/ClaudeDo.Data.Tests/ClaudeDo.Data.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~PromptFilesTests"
+```
+
+Expected: both new tests FAIL (no "Phase 0", no `batch_get_tasks`).
+
+- [ ] **Step 3: Replace `MergeHelperDefault`**
+
+Replace the whole `private const string MergeHelperDefault = """ … """;` block with:
+
+```csharp
+    private const string MergeHelperDefault = """
+        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 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.
+
+        Work the five phases in order. Do not start a phase before the previous one is finished.
+
+        ## 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 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.
+
+        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.
+        - 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.
+        - Ask the user for anything ambiguous, risky, or destructive.
+
+        ## 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.
+        """;
+```
+
+- [ ] **Step 4: Replace `MergeHelperInitialDefault`**
+
+The scope is now always one list with one repo, so the header states it once and the task lines
+drop the constant `list:` / `repo:` fields.
+
+```csharp
+    private const string MergeHelperInitialDefault = """
+        # List handler brief
+
+        Scope: {scope}
+        Repo: {repo}
+
+        Handle the following tasks. Work Phases 0–5 as your instructions describe, asking me whenever you are unsure.
+
+        {tasks}
+
+        When every task is handled, print the summary.
+        """;
+```
+
+- [ ] **Step 5: Add the `{repo}` token test**
+
+`{repo}` is a new token — Task 4 will pass it. Add to `PromptFilesTests`:
+
+```csharp
+    [Fact]
+    public void DefaultFor_merge_helper_initial_has_repo_token()
+    {
+        var d = PromptFiles.DefaultFor(PromptKind.MergeHelperInitial);
+        Assert.Contains("{repo}", d);
+    }
+```
+
+The existing `RenderTemplate_merge_helper_initial_substitutes_scope_and_tasks` test passes only
+`scope` and `tasks`. `RenderTemplate` leaves unknown tokens alone, so its two `Assert.Contains`
+still hold and its `Assert.DoesNotContain("{scope}", outp)` still holds. Leave it unchanged.
+
+- [ ] **Step 6: Run the tests to verify they pass**
+
+```bash
+dotnet test tests/ClaudeDo.Data.Tests/ClaudeDo.Data.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~PromptFilesTests"
+```
+
+Expected: all pass.
+
+- [ ] **Step 7: Commit**
+
+```bash
+git add -- src/ClaudeDo.Data/PromptFiles.cs tests/ClaudeDo.Data.Tests/PromptFilesTests.cs
+git commit -m "feat(data): five-phase list-handler prompt with dedupe and enhance" -- src/ClaudeDo.Data/PromptFiles.cs tests/ClaudeDo.Data.Tests/PromptFilesTests.cs
+```
+
+---
+
+### Task 3: Drop the global entry point and the LIST column
+
+This removes every caller that passes a null `listId`, clearing the way for Task 4's signature
+sweep. Types stay nullable here; only callers and UI go.
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs:103-113`
+- Modify: `src/ClaudeDo.Ui/Views/Islands/ListsIslandView.axaml:184,206-210`
+- Modify: `src/ClaudeDo.Ui/ViewModels/Modals/MergeHelperSelectionModalViewModel.cs:14-53`
+- Modify: `src/ClaudeDo.Ui/Views/Modals/MergeHelperSelectionModal.axaml:41-72`
+- Modify: `src/ClaudeDo.Localization/locales/en.json`, `src/ClaudeDo.Localization/locales/de.json`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/MergeHelperSelectionModalViewModelTests.cs`
+
+- [ ] **Step 1: Update the dialog tests to the list-only API**
+
+`Configure` becomes `Configure(string listId, string listName)` and `IsGlobal` and `ListName` are
+gone. Rewrite the affected tests. `Load_ExcludesTerminalStatuses_AndTicksActionableByDefault`,
+`CanConfirm_FollowsRowSelection` and `Confirm_ReturnsSelectedIds_InRowOrder` all used
+`Configure(null, null)` to see every seeded task — point them at `"L1"` instead, which holds all
+eight seeded statuses (`t-other-list` lives in `L2` and drops out).
+
+Replace the four tests below; leave `Load_NoCandidates_HasTasksFalse_CannotConfirm` untouched.
+
+```csharp
+    [Fact]
+    public async Task Load_ExcludesTerminalStatuses_AndTicksActionableByDefault()
+    {
+        await SeedAllStatusesAsync();
+        var vm = BuildVm();
+        vm.Configure("L1", "Work");
+        await vm.LoadAsync();
+
+        Assert.DoesNotContain(vm.Tasks, t => t.Id is "t-done" or "t-cancelled");
+        Assert.DoesNotContain(vm.Tasks, t => t.Id == "t-other-list");
+        Assert.Equal(6, vm.Tasks.Count);
+
+        Assert.True(vm.Tasks.Single(t => t.Id == "t-idle").IsSelected);
+        Assert.True(vm.Tasks.Single(t => t.Id == "t-queued").IsSelected);
+        Assert.True(vm.Tasks.Single(t => t.Id == "t-review").IsSelected);
+        Assert.True(vm.Tasks.Single(t => t.Id == "t-failed").IsSelected);
+        Assert.False(vm.Tasks.Single(t => t.Id == "t-running").IsSelected);
+        Assert.False(vm.Tasks.Single(t => t.Id == "t-children").IsSelected);
+    }
+
+    [Fact]
+    public async Task Load_PerListScope_FiltersToThatList()
+    {
+        await SeedAllStatusesAsync();
+        var vm = BuildVm();
+        vm.Configure("L2", "Home");
+        await vm.LoadAsync();
+
+        Assert.Single(vm.Tasks);
+        Assert.Equal("t-other-list", vm.Tasks[0].Id);
+        Assert.Contains("Home", vm.ScopeLabel);
+    }
+
+    [Fact]
+    public async Task CanConfirm_FollowsRowSelection()
+    {
+        await SeedAllStatusesAsync();
+        var vm = BuildVm();
+        vm.Configure("L1", "Work");
+        await vm.LoadAsync();
+
+        Assert.True(vm.CanConfirm);
+
+        vm.SelectNoneCommand.Execute(null);
+        Assert.False(vm.CanConfirm);
+        Assert.All(vm.Tasks, t => Assert.False(t.IsSelected));
+
+        vm.Tasks[0].IsSelected = true;      // single row re-enables via PropertyChanged hook
+        Assert.True(vm.CanConfirm);
+
+        vm.SelectAllCommand.Execute(null);
+        Assert.All(vm.Tasks, t => Assert.True(t.IsSelected));
+    }
+
+    [Fact]
+    public async Task Confirm_ReturnsSelectedIds_InRowOrder()
+    {
+        await SeedAllStatusesAsync();
+        var vm = BuildVm();
+        vm.Configure("L1", "Work");
+        await vm.LoadAsync();
+
+        vm.SelectNoneCommand.Execute(null);
+        vm.Tasks.Single(t => t.Id == "t-review").IsSelected = true;
+        vm.Tasks.Single(t => t.Id == "t-idle").IsSelected = true;
+
+        var closed = false;
+        vm.CloseAction = () => closed = true;
+        vm.ConfirmCommand.Execute(null);
+
+        var result = await vm.Result.Task;
+        Assert.NotNull(result);
+        // Row order (SortOrder): t-idle was seeded before t-review.
+        Assert.Equal(new[] { "t-idle", "t-review" }, result);
+        Assert.True(closed);
+    }
+```
+
+Also change `Cancel_ReturnsNull`'s `vm.Configure(null, null);` to `vm.Configure("L1", "Work");`.
+
+- [ ] **Step 2: Run the tests to verify they fail**
+
+```bash
+dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~MergeHelperSelectionModalViewModelTests"
+```
+
+Expected: FAIL — the project does not compile, because `Configure(string, string)` does not exist
+yet and `IsGlobal` was removed from an assertion that still compiles against it. Compilation
+failure is the expected "red" here.
+
+- [ ] **Step 3: Make the dialog VM list-only**
+
+In `MergeHelperSelectionModalViewModel.cs`:
+
+Remove the `ListName` property from `MergeHelperTaskRowViewModel`:
+
+```csharp
+public sealed partial class MergeHelperTaskRowViewModel : ViewModelBase
+{
+    public required string Id { get; init; }
+    public required string Title { get; init; }
+    public required string StatusText { get; init; }
+
+    [ObservableProperty] private bool _isSelected;
+}
+```
+
+Change the field to non-nullable, drop `IsGlobal`, and make `Configure` list-only:
+
+```csharp
+    private string _listId = "";
+```
+
+```csharp
+    [ObservableProperty] private string _scopeLabel = "";
+
+    public bool HasTasks => Tasks.Count > 0;
+```
+
+```csharp
+    public void Configure(string listId, string listName)
+    {
+        _listId = listId;
+        ScopeLabel = Loc.T("modals.mergeHelper.scopeList", listName);
+    }
+```
+
+In `LoadAsync`, the list filter is now unconditional and `ListName` is no longer selected:
+
+```csharp
+        await using var ctx = await _dbFactory.CreateDbContextAsync(ct);
+        var candidates = await ctx.Tasks.AsNoTracking()
+            .Where(t => t.Status != TaskStatus.Done && t.Status != TaskStatus.Cancelled)
+            .Where(t => t.ListId == _listId)
+            .OrderBy(t => t.SortOrder).ThenBy(t => t.CreatedAt)
+            .Select(t => new { t.Id, t.Title, t.Status })
+            .ToListAsync(ct);
+
+        foreach (var c in candidates)
+        {
+            var row = new MergeHelperTaskRowViewModel
+            {
+                Id = c.Id,
+                Title = c.Title,
+                StatusText = c.Status.ToString(),
+                IsSelected = IsTickedByDefault(c.Status),
+            };
+            row.PropertyChanged += OnRowChanged;
+            Tasks.Add(row);
+        }
+```
+
+- [ ] **Step 4: Drop the LIST column from the dialog view**
+
+In `MergeHelperSelectionModal.axaml`, change both `ColumnDefinitions="32,*,120,120"` (lines 41 and
+57) to `ColumnDefinitions="32,*,120"`, and delete the two `Grid.Column="3"` elements — the header
+`TextBlock` bound to `modals.mergeHelper.columnList` (lines 45-46) and the row `TextBlock` bound to
+`ListName` (lines 68-71).
+
+- [ ] **Step 5: Remove the global command and the Broom button**
+
+In `ListsIslandViewModel.cs`, delete the whole `LetClaudeHandleAllAsync` method including its
+`[RelayCommand]` attribute (lines 103-113). Leave `LetClaudeHandleListAsync` and the
+`MergeHelperRequest` record as they are — Task 4 changes those.
+
+In `ListsIslandView.axaml`, revert the button row to two columns:
+
+```xml
+        <!-- New list + import row -->
+        <Grid ColumnDefinitions="*,Auto" Margin="0,4,0,0">
+```
+
+and delete the whole `<Button Grid.Column="2" … LetClaudeHandleAllCommand … />` element
+(lines 206-210) including its `<PathIcon>` child.
+
+- [ ] **Step 6: Remove the three dead localization keys**
+
+Delete from **both** `src/ClaudeDo.Localization/locales/en.json` and
+`src/ClaudeDo.Localization/locales/de.json`:
+
+- `lists.letClaudeAllTip` (and the trailing comma on the preceding key, so the object stays valid JSON)
+- `modals.mergeHelper.scopeAll`
+- `modals.mergeHelper.columnList` (and the trailing comma on the preceding key)
+
+Keep `lists.contextLetClaude` and `modals.mergeHelper.scopeList`.
+
+- [ ] **Step 7: Build and run the tests**
+
+```bash
+dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
+```
+
+Expected: build succeeds, all tests pass. The localization parity test is the one that catches a
+key removed from only one of the two JSON files.
+
+- [ ] **Step 8: Commit**
+
+```bash
+git add -- src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs src/ClaudeDo.Ui/Views/Islands/ListsIslandView.axaml src/ClaudeDo.Ui/ViewModels/Modals/MergeHelperSelectionModalViewModel.cs src/ClaudeDo.Ui/Views/Modals/MergeHelperSelectionModal.axaml src/ClaudeDo.Localization/locales/en.json src/ClaudeDo.Localization/locales/de.json tests/ClaudeDo.Ui.Tests/ViewModels/MergeHelperSelectionModalViewModelTests.cs
+git commit -m "refactor(ui): scope \"Let Claude handle it\" to a single list" -- src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs src/ClaudeDo.Ui/Views/Islands/ListsIslandView.axaml src/ClaudeDo.Ui/ViewModels/Modals/MergeHelperSelectionModalViewModel.cs src/ClaudeDo.Ui/Views/Modals/MergeHelperSelectionModal.axaml src/ClaudeDo.Localization/locales/en.json src/ClaudeDo.Localization/locales/de.json tests/ClaudeDo.Ui.Tests/ViewModels/MergeHelperSelectionModalViewModelTests.cs
+```
+
+---
+
+### Task 4: Non-nullable `listId` and a single-repo launch spec
+
+One atomic commit across Worker and Ui. Splitting it would leave one side passing `string?` into a
+`string` parameter — nullable warnings strewn across a commit boundary, and a launch spec that
+still carries a dead multi-repo path.
+
+**Files:**
+- Modify: `src/ClaudeDo.Worker/Runner/Interfaces/IInteractiveLaunchSpecService.cs:36`
+- Modify: `src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs:166-253`
+- Modify: `src/ClaudeDo.Worker/Hub/WorkerHub.cs:682-687`
+- Modify: `src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs:90`
+- Modify: `src/ClaudeDo.Ui/Services/WorkerClient.cs:525-526`
+- Modify: `src/ClaudeDo.Ui/ViewModels/MissionControlViewModel.cs:325-357`
+- Modify: `src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs:20`
+- Modify: `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs:103`
+- Modify: `tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs:78`
+- Test: `tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs:363-472`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/MissionControlViewModelTests.cs:409-463`
+
+- [ ] **Step 1: Rewrite the launch-spec tests**
+
+In `InteractiveLaunchSpecServiceTests.cs`, replace the four merge-helper `[Fact]`s (from
+`BuildForMergeHelperAsync_EmptyTaskIds_ThrowsInvalidOperation` through
+`BuildForMergeHelperAsync_WithListId_UsesListWorkingDirAsCwdAndListScope`) with these five. Keep
+the `_mergeHelperSessionDirs` field and `TrackSessionDir` helper above them exactly as they are.
+
+```csharp
+    [Fact]
+    public async Task BuildForMergeHelperAsync_EmptyTaskIds_ThrowsInvalidOperation()
+    {
+        var listId = await SeedListAsync(workingDir: _tempDir);
+        var svc = BuildService();
+        await Assert.ThrowsAsync<InvalidOperationException>(
+            () => svc.BuildForMergeHelperAsync(Array.Empty<string>(), listId, CancellationToken.None));
+    }
+
+    [Fact]
+    public async Task BuildForMergeHelperAsync_ListWithoutExistingWorkingDir_ThrowsInvalidOperation()
+    {
+        var listId = await SeedListAsync(workingDir: Path.Combine(_tempDir, "gone"));
+        var taskId = Guid.NewGuid().ToString();
+        await SeedTaskAsync(taskId, listId, TaskStatus.WaitingForReview);
+
+        var svc = BuildService();
+        var ex = await Assert.ThrowsAsync<InvalidOperationException>(
+            () => svc.BuildForMergeHelperAsync(new[] { taskId }, listId, CancellationToken.None));
+        Assert.Contains("working directory", ex.Message);
+    }
+
+    [Fact]
+    public async Task BuildForMergeHelperAsync_UnknownList_Throws()
+    {
+        var listId = await SeedListAsync(workingDir: _tempDir);
+        var taskId = Guid.NewGuid().ToString();
+        await SeedTaskAsync(taskId, listId, TaskStatus.Idle);
+
+        var svc = BuildService();
+        await Assert.ThrowsAsync<KeyNotFoundException>(
+            () => svc.BuildForMergeHelperAsync(new[] { taskId }, "no-such-list", CancellationToken.None));
+    }
+
+    [Fact]
+    public async Task BuildForMergeHelperAsync_BuildsListScopedSpecWithSingleRepo()
+    {
+        var repo = Path.Combine(_tempDir, "repoOnly");
+        Directory.CreateDirectory(repo);
+
+        var listId = await SeedListAsync(workingDir: repo, name: "Alpha");
+        var t1 = Guid.NewGuid().ToString();
+        var t2 = Guid.NewGuid().ToString();
+        await SeedTaskAsync(t1, listId, TaskStatus.WaitingForReview, title: "First task");
+        await SeedTaskAsync(t2, listId, TaskStatus.Idle, title: "Second task");
+
+        var svc = BuildService();
+        var spec = await svc.BuildForMergeHelperAsync(new[] { t1, t2 }, listId, CancellationToken.None);
+        var sessionDir = TrackSessionDir(spec);
+
+        Assert.Equal(repo, spec.Cwd);
+        Assert.Equal(_claudeStubPath, spec.Exe);
+
+        var args = spec.Args.ToList();
+
+        var pmIdx = args.IndexOf("--permission-mode");
+        Assert.True(pmIdx >= 0);
+        Assert.Equal("default", args[pmIdx + 1]);
+
+        var atIdx = args.IndexOf("--allowedTools");
+        Assert.Equal("mcp__claudedo__*,Read,Grep,Glob,Edit,Bash,WebFetch,WebSearch,Skill", args[atIdx + 1]);
+
+        // --add-dir: session dir + the list's single repo dir
+        var addIdx = args.IndexOf("--add-dir");
+        var appendIdx = args.IndexOf("--append-system-prompt-file");
+        var addDirs = args.GetRange(addIdx + 1, appendIdx - addIdx - 1);
+        Assert.Equal(new[] { sessionDir, repo }, addDirs);
+
+        var systemPromptPath = args[appendIdx + 1];
+        Assert.Equal(Path.Combine(sessionDir, "system-prompt.md"), systemPromptPath);
+        Assert.True(File.Exists(systemPromptPath));
+
+        // kickoff is the LAST arg (positional), single line, points at brief.md
+        var kickoff = args[^1];
+        var briefPath = Path.Combine(sessionDir, "brief.md");
+        Assert.Contains(briefPath, kickoff);
+        Assert.DoesNotContain('\n', kickoff);
+
+        Assert.Equal("200000", spec.Env["MCP_TOOL_TIMEOUT"]);
+    }
+
+    [Fact]
+    public async Task BuildForMergeHelperAsync_BriefNamesListRepoAndEveryTask()
+    {
+        var repo = Path.Combine(_tempDir, "repoBrief");
+        Directory.CreateDirectory(repo);
+
+        var listId = await SeedListAsync(workingDir: repo, name: "Alpha");
+        var t1 = Guid.NewGuid().ToString();
+        var t2 = Guid.NewGuid().ToString();
+        await SeedTaskAsync(t1, listId, TaskStatus.WaitingForReview, title: "First task");
+        await SeedTaskAsync(t2, listId, TaskStatus.Idle, title: "Second task");
+
+        var svc = BuildService();
+        var spec = await svc.BuildForMergeHelperAsync(new[] { t1, t2 }, listId, CancellationToken.None);
+        var sessionDir = TrackSessionDir(spec);
+
+        var brief = File.ReadAllText(Path.Combine(sessionDir, "brief.md"));
+        Assert.Contains("Scope: List: Alpha", brief);
+        Assert.Contains($"Repo: {repo}", brief);
+        Assert.Contains("First task", brief);
+        Assert.Contains("Second task", brief);
+        Assert.Contains(t1, brief);
+        Assert.Contains(t2, brief);
+    }
+```
+
+- [ ] **Step 2: Run the launch-spec tests to verify they fail**
+
+```bash
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~InteractiveLaunchSpecServiceTests.BuildForMergeHelper"
+```
+
+Expected: FAIL. `BuildForMergeHelperAsync_UnknownList_Throws` fails because the current code
+resolves the repo from the tasks and never validates the list; the brief test fails on the missing
+`Repo:` line.
+
+- [ ] **Step 3: Rewrite `BuildForMergeHelperAsync`**
+
+Replace the method body (`InteractiveLaunchSpecService.cs:166-253`) with:
+
+```csharp
+    public async Task<LaunchSpec> BuildForMergeHelperAsync(IReadOnlyList<string> taskIds, string listId, CancellationToken ct)
+    {
+        if (taskIds.Count == 0)
+            throw new InvalidOperationException("No tasks selected for the list handler.");
+
+        await using var ctx = await _dbFactory.CreateDbContextAsync(ct);
+        var taskRepo = new TaskRepository(ctx);
+        var listRepo = new ListRepository(ctx);
+
+        var list = await listRepo.GetByIdAsync(listId, ct)
+            ?? throw new KeyNotFoundException($"List not found: {listId}");
+
+        var repoDir = list.WorkingDir;
+        if (string.IsNullOrEmpty(repoDir) || !Directory.Exists(repoDir))
+            throw new InvalidOperationException($"list '{list.Name}' has no existing working directory");
+
+        var briefLines = new List<string>();
+        foreach (var id in taskIds)
+        {
+            var task = await taskRepo.GetByIdAsync(id, ct)
+                ?? throw new KeyNotFoundException($"Task not found: {id}");
+            briefLines.Add($"- [{task.Status}] {task.Title} (id: {task.Id})");
+        }
+
+        var sessionDir = Path.Combine(Paths.AppDataRoot(), "merge-helper-sessions", Guid.NewGuid().ToString());
+        Directory.CreateDirectory(sessionDir);
+
+        var systemPromptPath = Path.Combine(sessionDir, "system-prompt.md");
+        await File.WriteAllTextAsync(systemPromptPath, PromptFiles.ReadOrDefault(PromptKind.MergeHelper), ct);
+
+        var briefPath = Path.Combine(sessionDir, "brief.md");
+        await File.WriteAllTextAsync(briefPath, PromptFiles.Render(PromptKind.MergeHelperInitial,
+            new Dictionary<string, string>
+            {
+                ["scope"] = $"List: {list.Name}",
+                ["repo"] = repoDir,
+                ["tasks"] = string.Join("\n", briefLines),
+            }), ct);
+
+        var resolvedClaude = WindowsTerminalLauncher.Resolve(_claudePath)
+            ?? throw new InvalidOperationException($"claude executable not found: {_claudePath}");
+
+        // Mirrors WindowsTerminalLauncher.BuildPlanningStartArgs ordering: variadic flags
+        // (--allowedTools, --add-dir) first, then a single-value flag, then the single-line
+        // positional kickoff LAST — a multi-line positional prompt truncates at the first
+        // newline, so the full multi-line brief travels via the file exposed through --add-dir.
+        var args = new List<string>
+        {
+            "--permission-mode", "default",
+            "--allowedTools", MergeHelperAllowedTools,
+            "--add-dir", sessionDir, repoDir,
+            "--append-system-prompt-file", systemPromptPath,
+            $"Read the file {briefPath} first. It lists the tasks you must handle and their status. " +
+            "After reading it, begin the session as your instructions describe.",
+        };
+
+        var env = new Dictionary<string, string>
+        {
+            ["MCP_TOOL_TIMEOUT"] = "200000",
+        };
+
+        return new LaunchSpec(cwd: repoDir, resolvedClaude, args, env);
+    }
+```
+
+- [ ] **Step 4: Flip the interface and hub signatures**
+
+`src/ClaudeDo.Worker/Runner/Interfaces/IInteractiveLaunchSpecService.cs:36`:
+
+```csharp
+    Task<LaunchSpec> BuildForMergeHelperAsync(IReadOnlyList<string> taskIds, string listId, CancellationToken ct);
+```
+
+`src/ClaudeDo.Worker/Hub/WorkerHub.cs:682`:
+
+```csharp
+    public Task<LaunchSpec> GetMergeHelperLaunchSpec(string[] taskIds, string listId) => HubGuard(() =>
+```
+
+(leave the method body as it is).
+
+- [ ] **Step 5: Run the Worker tests**
+
+```bash
+dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release \
+  --filter "FullyQualifiedName~InteractiveLaunchSpecServiceTests"
+```
+
+Expected: build succeeds, all pass. `TasksIslandViewModelPlanningTests.cs:78` holds a fake
+implementing `IWorkerClient` — its signature is flipped in Step 7; if the Worker.Tests build fails
+there, do Step 7 first and re-run.
+
+- [ ] **Step 6: Update the Mission Control tests**
+
+In `MissionControlViewModelTests.cs`, the four `OpenMergeHelperConPtySessionAsync` calls pass
+`null` as the list id. Replace `null` with `"L1"` on lines 421, 435, 436 and 461, and change the
+`ThrowingMergeHelperLaunchSpecWorker` override signature at line 411 to:
+
+```csharp
+        public override Task<LaunchSpec> GetMergeHelperLaunchSpecAsync(IReadOnlyList<string> taskIds, string listId, CancellationToken ct = default)
+```
+
+The list-title lookup in `OpenMergeHelperConPtySessionAsync` is wrapped in a `try/catch` and falls
+back to the plain title, so an unseeded `"L1"` is harmless.
+
+- [ ] **Step 7: Flip the UI signatures**
+
+`src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs:90`:
+
+```csharp
+    Task<LaunchSpec> GetMergeHelperLaunchSpecAsync(IReadOnlyList<string> taskIds, string listId, CancellationToken ct = default);
+```
+
+`src/ClaudeDo.Ui/Services/WorkerClient.cs:525`:
+
+```csharp
+    public async Task<LaunchSpec> GetMergeHelperLaunchSpecAsync(IReadOnlyList<string> taskIds, string listId, CancellationToken ct = default)
+        => await _hub.InvokeAsync<LaunchSpec>("GetMergeHelperLaunchSpec", taskIds, listId, ct);
+```
+
+`tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs:103` and
+`tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs:78` — same parameter change
+(`string? listId` → `string listId`), bodies unchanged.
+
+`src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs:20`:
+
+```csharp
+/// <summary>Confirmed handler run: the scope list and the ordered selected task ids.</summary>
+public sealed record MergeHelperRequest(string ListId, IReadOnlyList<string> TaskIds);
+```
+
+`src/ClaudeDo.Ui/ViewModels/MissionControlViewModel.cs:325-341` — the `listId is not null` guard is
+now dead:
+
+```csharp
+    // List-handler session over a hand-picked set of tasks ("Let Claude handle it").
+    // Ad-hoc style: no owning task, never deduped — every run opens a fresh pane.
+    public async System.Threading.Tasks.Task OpenMergeHelperConPtySessionAsync(string listId, IReadOnlyList<string> taskIds)
+    {
+        if (taskIds is not { Count: > 0 }) return;
+
+        var title = Loc.T("missionControl.mergeHelperTitle");
+        try
+        {
+            await using var ctx = await _dbFactory.CreateDbContextAsync();
+            var list = await ctx.Lists.AsNoTracking().FirstOrDefaultAsync(l => l.Id == listId);
+            if (list?.Name is { Length: > 0 } name) title = $"{title} — {name}";
+        }
+        catch { /* best-effort title lookup */ }
+```
+
+Leave the rest of the method (the `try` block that fetches the spec and adds the pane) unchanged.
+
+- [ ] **Step 8: Build everything and run the full suite**
+
+```bash
+dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Data.Tests/ClaudeDo.Data.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
+```
+
+Expected: both builds succeed with no `CS8600`/`CS8604` nullability warnings on the touched files,
+and every test passes.
+
+- [ ] **Step 9: Commit**
+
+```bash
+git add -- src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs src/ClaudeDo.Worker/Runner/Interfaces/IInteractiveLaunchSpecService.cs src/ClaudeDo.Worker/Hub/WorkerHub.cs src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs src/ClaudeDo.Ui/Services/WorkerClient.cs src/ClaudeDo.Ui/ViewModels/MissionControlViewModel.cs src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs tests/ClaudeDo.Ui.Tests/ViewModels/MissionControlViewModelTests.cs tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs
+git commit -m "refactor(worker): make the list-handler launch spec single-list and single-repo" -- src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs src/ClaudeDo.Worker/Runner/Interfaces/IInteractiveLaunchSpecService.cs src/ClaudeDo.Worker/Hub/WorkerHub.cs src/ClaudeDo.Ui/Services/Interfaces/IWorkerClient.cs src/ClaudeDo.Ui/Services/WorkerClient.cs src/ClaudeDo.Ui/ViewModels/MissionControlViewModel.cs src/ClaudeDo.Ui/ViewModels/Islands/ListsIslandViewModel.cs tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs tests/ClaudeDo.Ui.Tests/ViewModels/MissionControlViewModelTests.cs tests/ClaudeDo.Worker.Tests/UiVm/TasksIslandViewModelPlanningTests.cs tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs
+```
+
+---
+
+### Task 5: Update the project docs
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/CLAUDE.md`
+- Modify: `src/ClaudeDo.Worker/CLAUDE.md`
+- Modify: `docs/open.md`
+
+- [ ] **Step 1: Check what the CLAUDE.md files claim**
+
+```bash
+grep -n "merge.helper\|Let Claude handle\|MergeHelper" src/ClaudeDo.Ui/CLAUDE.md src/ClaudeDo.Worker/CLAUDE.md docs/open.md
+```
+
+- [ ] **Step 2: Correct any stale claim**
+
+Where those files describe the merge helper as having a global scope, or describe the prompt as
+run-and-merge only, update them to: list-scoped only, single repo, five phases (read, dedupe,
+enhance, queue, review+merge). Note in `src/ClaudeDo.Worker/CLAUDE.md` that
+`update_task_status` now also accepts `Cancelled`. Do not restructure the files beyond that.
+
+- [ ] **Step 3: Add the open verification items**
+
+Append to the open-items section of `docs/open.md`:
+
+```markdown
+- **List handler (2026-07-27)** — visual pass: the Broom button is gone from the lists footer,
+  the context-menu item appears only on lists with a working dir, and the selection dialog has no
+  LIST column. Plus a real-Claude smoke run of the five phases (dedupe questions, enhancements
+  landing in task descriptions, queued execution, merges).
+```
+
+- [ ] **Step 4: Commit**
+
+```bash
+git add -- src/ClaudeDo.Ui/CLAUDE.md src/ClaudeDo.Worker/CLAUDE.md docs/open.md
+git commit -m "docs: describe the list-scoped five-phase handler" -- src/ClaudeDo.Ui/CLAUDE.md src/ClaudeDo.Worker/CLAUDE.md docs/open.md
+```
+
+---
+
+## Verification left to the user
+
+None of this can be confirmed from tests alone:
+
+- The lists footer no longer shows the Broom button, and the row context menu still offers
+  "Let Claude handle it" for lists with a working dir.
+- The selection dialog shows TASK and STATUS only, and the scope line reads `List: <name>`.
+- A real ConPTY run: Phase 1 asks about duplicates, Phase 2's enhancements are visible in the task
+  descriptions afterwards, Phase 3 reports the slot count and the tasks execute, Phase 4 merges or
+  hands off to conflict resolution.

docs/superpowers/plans/2026-08-07-handler-run-links.md

@@ -0,0 +1,939 @@
+# Handler-Run Links Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** A "Let Claude handle it" run records which tasks it processed, shows them as a list on the handler task's detail pane, and wears a HANDLER badge instead of MANUAL.
+
+**Architecture:** One new nullable column `TaskEntity.HandlerTaskId` (1:n, last run wins) stamped at handler-task creation from the selection the UI already passes down. The badge is a display-only computed property on `TaskRowViewModel`, driven by the existing `HandlerBaseCommit`. The panel reuses `ChildOutcomeRowViewModel` and the existing refresh path.
+
+**Tech Stack:** .NET 8, EF Core (SQLite), Avalonia 12 + CommunityToolkit.Mvvm, xUnit.
+
+**Spec:** `docs/superpowers/specs/2026-08-07-handler-run-links-design.md`
+
+---
+
+## File Structure
+
+**Modified:**
+- `src/ClaudeDo.Data/Models/TaskEntity.cs` — new `HandlerTaskId` property
+- `src/ClaudeDo.Data/Configuration/TaskEntityConfiguration.cs` — column mapping + index
+- `src/ClaudeDo.Data/Repositories/TaskRepository.cs` — `SetHandlerTaskIdAsync`
+- `src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs` — stamp after creating the handler task
+- `src/ClaudeDo.Ui/ViewModels/Islands/TaskRowViewModel.cs` — `HandlerBaseCommit`, `IsHandlerRun`, `HandlerBadge`, `ManualBadge` precedence
+- `src/ClaudeDo.Ui/Views/Islands/TaskRowView.axaml` — HANDLER badge border
+- `src/ClaudeDo.Ui/Design/IslandStyles.axaml` — `HandlerBadgeBrush` + `Border.badge.handler`
+- `src/ClaudeDo.Localization/locales/en.json` + `de.json` — `tasks.badgeHandler`, `tasks.handlerTip`
+- `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs` — `HandledTasks` collection, loader, clear, refresh
+- `src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml` — HANDLED TASKS panel
+- `src/ClaudeDo.Data/CLAUDE.md`, `src/ClaudeDo.Ui/CLAUDE.md`, `docs/explore-notes/conpty-sessions.md` — docs
+
+**Created:**
+- `src/ClaudeDo.Data/Migrations/<timestamp>_AddHandlerTaskId.cs` (+ Designer, + snapshot update) — generated
+- `tests/ClaudeDo.Worker.Tests/Repositories/TaskRepositoryHandlerLinkTests.cs`
+- `tests/ClaudeDo.Ui.Tests/ViewModels/TaskRowViewModelHandlerBadgeTests.cs`
+- `tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandHandledTasksTests.cs`
+
+---
+
+## Task 1: Data — `HandlerTaskId` column and migration
+
+**Files:**
+- Modify: `src/ClaudeDo.Data/Models/TaskEntity.cs:60-61`
+- Modify: `src/ClaudeDo.Data/Configuration/TaskEntityConfiguration.cs:96-97` and `:127-131`
+- Create: `src/ClaudeDo.Data/Migrations/<timestamp>_AddHandlerTaskId.cs` (generated)
+
+- [ ] **Step 1: Add the property**
+
+In `src/ClaudeDo.Data/Models/TaskEntity.cs`, directly after the existing `HandlerHeadCommit` line (`public string? HandlerHeadCommit { get; set; }`), add:
+
+```csharp
+
+    // Id of the "list handler" run task that processed this task ("Let Claude handle it").
+    // 1:n and last-run-wins -- a second handler run over the same task overwrites it. Deliberately
+    // NOT ParentTaskId: that is the planning-child relation and drives the indented tree rendering.
+    // No FK: a deleted handler task must not cascade into the tasks it merely touched.
+    public string? HandlerTaskId { get; set; }
+```
+
+- [ ] **Step 2: Map the column and index it**
+
+In `src/ClaudeDo.Data/Configuration/TaskEntityConfiguration.cs`, after the line
+`builder.Property(t => t.HandlerHeadCommit).HasColumnName("handler_head_commit");` add:
+
+```csharp
+        builder.Property(t => t.HandlerTaskId).HasColumnName("handler_task_id");
+```
+
+At the end of `Configure`, after the line
+`builder.HasIndex(t => t.BlockedByTaskId).HasDatabaseName("idx_tasks_blocked_by");` add:
+
+```csharp
+        builder.HasIndex(t => t.HandlerTaskId).HasDatabaseName("idx_tasks_handler_task_id");
+```
+
+Do **not** add a `HasOne`/`HasForeignKey` relationship — the column is intentionally FK-less.
+
+- [ ] **Step 3: Generate the migration**
+
+Run from the repo root:
+
+```bash
+dotnet ef migrations add AddHandlerTaskId --project src/ClaudeDo.Data/ClaudeDo.Data.csproj --startup-project src/ClaudeDo.Worker/ClaudeDo.Worker.csproj
+```
+
+Expected: creates `src/ClaudeDo.Data/Migrations/<timestamp>_AddHandlerTaskId.cs` + `.Designer.cs` and updates `ClaudeDoDbContextModelSnapshot.cs`. The `Up` method must contain exactly one `AddColumn<string>(name: "handler_task_id", table: "tasks", nullable: true)` and one `CreateIndex(name: "idx_tasks_handler_task_id", table: "tasks", column: "handler_task_id")`. If it contains anything else, another agent's uncommitted model change leaked in — delete the migration, coordinate, retry.
+
+If `dotnet ef` is unavailable, hand-author the migration + Designer mirroring
+`src/ClaudeDo.Data/Migrations/20260806111454_AddInteractiveSessionId.cs`, and add
+`Property<string>("HandlerTaskId").HasColumnType("TEXT").HasColumnName("handler_task_id");`
+plus the index to the `TaskEntity` builder in `ClaudeDoDbContextModelSnapshot.cs`.
+
+- [ ] **Step 4: Build**
+
+Run: `dotnet build src/ClaudeDo.Data/ClaudeDo.Data.csproj -c Release`
+Expected: `Build succeeded`, 0 errors.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Data/Models/TaskEntity.cs src/ClaudeDo.Data/Configuration/TaskEntityConfiguration.cs src/ClaudeDo.Data/Migrations
+git commit -- src/ClaudeDo.Data/Models/TaskEntity.cs src/ClaudeDo.Data/Configuration/TaskEntityConfiguration.cs src/ClaudeDo.Data/Migrations -m "feat(data): add handler_task_id to link handled tasks to their handler run"
+```
+
+⚠️ Always commit with explicit paths (`git commit -- <paths>`), never a bare `git commit` — the
+main checkout is shared with concurrent sessions.
+
+---
+
+## Task 2: Data — `SetHandlerTaskIdAsync` repository method
+
+**Files:**
+- Modify: `src/ClaudeDo.Data/Repositories/TaskRepository.cs` (after `SetHandlerHeadCommitAsync`, currently `:394-403`)
+- Test: `tests/ClaudeDo.Worker.Tests/Repositories/TaskRepositoryHandlerLinkTests.cs` (create)
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ClaudeDo.Worker.Tests/Repositories/TaskRepositoryHandlerLinkTests.cs`:
+
+```csharp
+using ClaudeDo.Data;
+using ClaudeDo.Data.Models;
+using ClaudeDo.Data.Repositories;
+using ClaudeDo.Worker.Tests.Infrastructure;
+using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
+
+namespace ClaudeDo.Worker.Tests.Repositories;
+
+/// Covers the handler-run link: SetHandlerTaskIdAsync stamps the tasks a "Let Claude handle it"
+/// run processed, so the handler task's detail pane can list them after the run.
+public sealed class TaskRepositoryHandlerLinkTests : IDisposable
+{
+    private readonly DbFixture _db = new();
+    private readonly ClaudeDoDbContext _ctx;
+    private readonly TaskRepository _tasks;
+    private readonly ListRepository _lists;
+
+    public TaskRepositoryHandlerLinkTests()
+    {
+        _ctx = _db.CreateContext();
+        _tasks = new TaskRepository(_ctx);
+        _lists = new ListRepository(_ctx);
+    }
+
+    public void Dispose()
+    {
+        _ctx.Dispose();
+        _db.Dispose();
+    }
+
+    private async Task<string> CreateListAsync()
+    {
+        var listId = Guid.NewGuid().ToString();
+        await _lists.AddAsync(new ListEntity
+        {
+            Id = listId,
+            Name = "Test List",
+            CreatedAt = DateTime.UtcNow,
+        });
+        return listId;
+    }
+
+    private async Task<string> AddTaskAsync(string listId)
+    {
+        var id = Guid.NewGuid().ToString();
+        await _tasks.AddAsync(new TaskEntity
+        {
+            Id = id,
+            ListId = listId,
+            Title = "T",
+            Status = TaskStatus.Idle,
+            CreatedAt = DateTime.UtcNow,
+        });
+        return id;
+    }
+
+    [Fact]
+    public async Task SetHandlerTaskIdAsync_StampsAllGivenTasks()
+    {
+        var listId = await CreateListAsync();
+        var a = await AddTaskAsync(listId);
+        var b = await AddTaskAsync(listId);
+        var handlerId = await AddTaskAsync(listId);
+
+        var affected = await _tasks.SetHandlerTaskIdAsync(new[] { a, b }, handlerId);
+
+        Assert.Equal(2, affected);
+        Assert.Equal(handlerId, (await _tasks.GetByIdAsync(a))!.HandlerTaskId);
+        Assert.Equal(handlerId, (await _tasks.GetByIdAsync(b))!.HandlerTaskId);
+        Assert.Null((await _tasks.GetByIdAsync(handlerId))!.HandlerTaskId);
+    }
+
+    [Fact]
+    public async Task SetHandlerTaskIdAsync_IgnoresUnknownIds()
+    {
+        var listId = await CreateListAsync();
+        var a = await AddTaskAsync(listId);
+        var handlerId = await AddTaskAsync(listId);
+
+        var affected = await _tasks.SetHandlerTaskIdAsync(
+            new[] { a, "does-not-exist" }, handlerId);
+
+        Assert.Equal(1, affected);
+        Assert.Equal(handlerId, (await _tasks.GetByIdAsync(a))!.HandlerTaskId);
+    }
+
+    [Fact]
+    public async Task SetHandlerTaskIdAsync_SecondRunOverwrites()
+    {
+        var listId = await CreateListAsync();
+        var a = await AddTaskAsync(listId);
+        var firstHandler = await AddTaskAsync(listId);
+        var secondHandler = await AddTaskAsync(listId);
+
+        await _tasks.SetHandlerTaskIdAsync(new[] { a }, firstHandler);
+        await _tasks.SetHandlerTaskIdAsync(new[] { a }, secondHandler);
+
+        Assert.Equal(secondHandler, (await _tasks.GetByIdAsync(a))!.HandlerTaskId);
+    }
+
+    [Fact]
+    public async Task SetHandlerTaskIdAsync_EmptyList_IsNoOp()
+    {
+        var listId = await CreateListAsync();
+        var handlerId = await AddTaskAsync(listId);
+
+        var affected = await _tasks.SetHandlerTaskIdAsync(Array.Empty<string>(), handlerId);
+
+        Assert.Equal(0, affected);
+    }
+}
+```
+
+- [ ] **Step 2: Run the tests to verify they fail**
+
+Run: `dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --filter "FullyQualifiedName~TaskRepositoryHandlerLinkTests"`
+Expected: compile error — `TaskRepository` does not contain a definition for `SetHandlerTaskIdAsync`.
+
+- [ ] **Step 3: Implement the method**
+
+In `src/ClaudeDo.Data/Repositories/TaskRepository.cs`, directly after `SetHandlerHeadCommitAsync`, add:
+
+```csharp
+    // Links the tasks a "list handler" run processed back to the handler's own task, so the
+    // handler's detail pane can list them after the run. Stamped from the user's selection at
+    // creation time -- that way tasks the handler later cancels as duplicates stay visible.
+    // Unknown ids are silently skipped. Returns the number of rows actually stamped.
+    public async Task<int> SetHandlerTaskIdAsync(
+        IReadOnlyList<string> taskIds,
+        string handlerTaskId,
+        CancellationToken ct = default)
+    {
+        if (taskIds.Count == 0) return 0;
+
+        var ids = taskIds.Where(id => id != handlerTaskId).Distinct().ToList();
+        if (ids.Count == 0) return 0;
+
+        return await _context.Tasks
+            .Where(t => ids.Contains(t.Id))
+            .ExecuteUpdateAsync(s => s
+                .SetProperty(t => t.HandlerTaskId, handlerTaskId), ct);
+    }
+```
+
+- [ ] **Step 4: Run the tests to verify they pass**
+
+Run: `dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --filter "FullyQualifiedName~TaskRepositoryHandlerLinkTests"`
+Expected: `Passed! - Failed: 0, Passed: 4`.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Data/Repositories/TaskRepository.cs tests/ClaudeDo.Worker.Tests/Repositories/TaskRepositoryHandlerLinkTests.cs
+git commit -- src/ClaudeDo.Data/Repositories/TaskRepository.cs tests/ClaudeDo.Worker.Tests/Repositories/TaskRepositoryHandlerLinkTests.cs -m "feat(data): add SetHandlerTaskIdAsync to stamp handled tasks"
+```
+
+---
+
+## Task 3: Worker — stamp the selection when the handler task is created
+
+**Files:**
+- Modify: `src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs:409-450`
+- Test: `tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs` (append a `[Fact]` in the `── CreateMergeHelperTaskAsync ──` region, currently starting at `:747`)
+
+Note: `CreateMergeHelperTaskAsync` already receives `IReadOnlyList<string> taskIds` — the UI →
+`IWorkerClient` → `WorkerHub` chain needs **no** change.
+
+- [ ] **Step 1: Write the failing test**
+
+Append to `tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs` inside the same test class, after the existing `CreateMergeHelperTaskAsync_CreatesIdleManualTask_StampsHandlerBaseCommit` test:
+
+```csharp
+    [Fact]
+    public async Task CreateMergeHelperTaskAsync_StampsHandlerTaskIdOnSelectedTasks()
+    {
+        if (!GitAvailable) { Assert.True(true, "git not available -- skipping"); return; }
+
+        var repo = CreateRepo();
+        var listId = await SeedListAsync(workingDir: repo.RepoDir, name: "Alpha");
+        var t1 = Guid.NewGuid().ToString();
+        var t2 = Guid.NewGuid().ToString();
+        await SeedTaskAsync(t1, listId, TaskStatus.WaitingForReview, title: "First task");
+        await SeedTaskAsync(t2, listId, TaskStatus.Idle, title: "Second task");
+
+        var svc = BuildService();
+        var handlerId = await svc.CreateMergeHelperTaskAsync(
+            new[] { t1, t2 }, listId, "List handler: Alpha", "Tasks handled by this run:", CancellationToken.None);
+
+        using var readCtx = _db.CreateContext();
+        var tasks = new TaskRepository(readCtx);
+        Assert.Equal(handlerId, (await tasks.GetByIdAsync(t1))!.HandlerTaskId);
+        Assert.Equal(handlerId, (await tasks.GetByIdAsync(t2))!.HandlerTaskId);
+        // The handler never links to itself.
+        Assert.Null((await tasks.GetByIdAsync(handlerId))!.HandlerTaskId);
+    }
+```
+
+- [ ] **Step 2: Run the test to verify it fails**
+
+Run: `dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --filter "FullyQualifiedName~CreateMergeHelperTaskAsync_StampsHandlerTaskIdOnSelectedTasks"`
+Expected: FAIL — `Assert.Equal() Failure: Values differ … Actual: null`.
+
+- [ ] **Step 3: Stamp the selection**
+
+In `src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs`, in `CreateMergeHelperTaskAsync`, replace:
+
+```csharp
+        await taskRepo.AddAsync(handlerTask, ct);
+
+        return handlerTask.Id;
+```
+
+with:
+
+```csharp
+        await taskRepo.AddAsync(handlerTask, ct);
+
+        // Link the selection back to this run BEFORE the session starts: the handler cancels
+        // duplicates in phase 1, and those still belong in the "what was this run supposed to do"
+        // list. Stamping later (e.g. at handoff) would lose them.
+        await taskRepo.SetHandlerTaskIdAsync(taskIds, handlerTask.Id, ct);
+
+        return handlerTask.Id;
+```
+
+- [ ] **Step 4: Run the test to verify it passes**
+
+Run: `dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release --filter "FullyQualifiedName~CreateMergeHelperTaskAsync"`
+Expected: `Passed! - Failed: 0` (all five `CreateMergeHelperTaskAsync` tests).
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs
+git commit -- src/ClaudeDo.Worker/Runner/InteractiveLaunchSpecService.cs tests/ClaudeDo.Worker.Tests/Runner/InteractiveLaunchSpecServiceTests.cs -m "feat(handler): link the selected tasks to the handler run task"
+```
+
+---
+
+## Task 4: Ui — HANDLER badge instead of MANUAL
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Islands/TaskRowViewModel.cs:40,51,234-240,308-329`
+- Modify: `src/ClaudeDo.Ui/Views/Islands/TaskRowView.axaml:141-144`
+- Modify: `src/ClaudeDo.Ui/Design/IslandStyles.axaml:114-118` and `:987-990`
+- Modify: `src/ClaudeDo.Localization/locales/en.json:163-164`, `src/ClaudeDo.Localization/locales/de.json:163-164`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/TaskRowViewModelHandlerBadgeTests.cs` (create)
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ClaudeDo.Ui.Tests/ViewModels/TaskRowViewModelHandlerBadgeTests.cs`:
+
+```csharp
+using ClaudeDo.Data.Models;
+using ClaudeDo.Ui.ViewModels.Islands;
+using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
+
+namespace ClaudeDo.Ui.Tests.ViewModels;
+
+/// A "list handler" host task is IsManual=true so automation skips it, but MANUAL reads wrong on
+/// it -- the HANDLER badge must win and MANUAL must disappear.
+public class TaskRowViewModelHandlerBadgeTests
+{
+    [Fact]
+    public void HandlerTask_ShowsHandlerBadge_AndSuppressesManualBadge()
+    {
+        var row = new TaskRowViewModel { Id = "t1" };
+        row.IsManual = true;
+        row.HandlerBaseCommit = "base123";
+
+        Assert.True(row.IsHandlerRun);
+        Assert.NotNull(row.HandlerBadge);
+        Assert.Null(row.ManualBadge);
+    }
+
+    [Fact]
+    public void PlainManualTask_StillShowsManualBadge()
+    {
+        var row = new TaskRowViewModel { Id = "t2" };
+        row.IsManual = true;
+
+        Assert.False(row.IsHandlerRun);
+        Assert.Null(row.HandlerBadge);
+        Assert.NotNull(row.ManualBadge);
+    }
+
+    [Fact]
+    public void UpdateFromEntity_MirrorsHandlerBaseCommit()
+    {
+        var row = new TaskRowViewModel { Id = "t3" };
+        row.UpdateFromEntity(new TaskEntity
+        {
+            Id = "t3",
+            ListId = "l1",
+            Title = "List handler: Alpha",
+            Status = TaskStatus.Idle,
+            IsManual = true,
+            HandlerBaseCommit = "base123",
+            CreatedAt = DateTime.UtcNow,
+        });
+
+        Assert.Equal("base123", row.HandlerBaseCommit);
+        Assert.True(row.IsHandlerRun);
+    }
+}
+```
+
+- [ ] **Step 2: Run the test to verify it fails**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter "FullyQualifiedName~TaskRowViewModelHandlerBadgeTests"`
+Expected: compile error — `TaskRowViewModel` has no `HandlerBaseCommit` / `IsHandlerRun` / `HandlerBadge`.
+
+- [ ] **Step 3: Add the properties**
+
+In `src/ClaudeDo.Ui/ViewModels/Islands/TaskRowViewModel.cs`, after the `_isManual` field
+declaration (`[ObservableProperty] private bool _isManual;`), add:
+
+```csharp
+    // Mirror of TaskEntity.HandlerBaseCommit -- non-null marks this row as a "list handler" run
+    // host task ("Let Claude handle it"), which wears HANDLER instead of MANUAL.
+    [ObservableProperty] private string? _handlerBaseCommit;
+```
+
+Replace the `ManualBadge` line (currently `public string? ManualBadge => IsManual ? Loc.T("tasks.badgeManual") : null;`) with:
+
+```csharp
+    public bool IsHandlerRun => !string.IsNullOrEmpty(HandlerBaseCommit);
+
+    public string? HandlerBadge => IsHandlerRun ? Loc.T("tasks.badgeHandler") : null;
+
+    // HANDLER outranks MANUAL: a handler host task is IsManual only so automation skips it, and
+    // "MANUAL" would read as a hand-written reminder. The two badges never show together.
+    public bool ShowManualBadge => IsManual && !IsHandlerRun;
+
+    public string? ManualBadge => ShowManualBadge ? Loc.T("tasks.badgeManual") : null;
+```
+
+Add a change hook next to the existing `OnIsManualChanged` partial method:
+
+```csharp
+    partial void OnHandlerBaseCommitChanged(string? value)
+    {
+        OnPropertyChanged(nameof(IsHandlerRun));
+        OnPropertyChanged(nameof(HandlerBadge));
+        OnPropertyChanged(nameof(ShowManualBadge));
+        OnPropertyChanged(nameof(ManualBadge));
+    }
+```
+
+Inside the existing `OnIsManualChanged`, next to the existing `OnPropertyChanged(nameof(ManualBadge));` line, add:
+
+```csharp
+        OnPropertyChanged(nameof(ShowManualBadge));
+```
+
+In `UpdateFromEntity`, after the line `IsManual          = t.IsManual;` add:
+
+```csharp
+        HandlerBaseCommit = t.HandlerBaseCommit;
+```
+
+Also add `HandlerBadge` to `RefreshLocalized`, next to the existing `PlanningBadge` line:
+
+```csharp
+        OnPropertyChanged(nameof(HandlerBadge));
+        OnPropertyChanged(nameof(ManualBadge));
+```
+
+- [ ] **Step 4: Add the locale keys**
+
+In `src/ClaudeDo.Localization/locales/en.json`, after `"manualTip": ...` (line 164) add:
+
+```json
+    "badgeHandler": "HANDLER",
+    "handlerTip": "Handler run — see the tasks it processed in the detail pane",
+```
+
+In `src/ClaudeDo.Localization/locales/de.json`, after `"manualTip": ...` (line 164) add:
+
+```json
+    "badgeHandler": "HANDLER",
+    "handlerTip": "Handler-Run — die bearbeiteten Tasks stehen im Detailbereich",
+```
+
+- [ ] **Step 5: Add the badge style and brush**
+
+In `src/ClaudeDo.Ui/Design/IslandStyles.axaml`, after the line
+`<SolidColorBrush x:Key="ManualBadgeBrush"   Color="{StaticResource TextFaintColor}"/>` add:
+
+```xml
+    <SolidColorBrush x:Key="HandlerBadgeBrush" Color="{StaticResource PeatSoftColor}"/>
+```
+
+After the existing `Border.badge.manual` style block add:
+
+```xml
+  <!-- handler → peat: a "Let Claude handle it" run host, not a hand-written reminder -->
+  <Style Selector="Border.badge.handler">
+    <Setter Property="Background" Value="{DynamicResource HandlerBadgeBrush}"/>
+  </Style>
+```
+
+- [ ] **Step 6: Render the badge**
+
+In `src/ClaudeDo.Ui/Views/Islands/TaskRowView.axaml`, replace the manual badge block (lines 141-144):
+
+```xml
+              <Border Classes="badge manual" IsVisible="{Binding IsManual}"
+                      ToolTip.Tip="{loc:Tr tasks.manualTip}">
+                <TextBlock Text="{Binding ManualBadge}"/>
+              </Border>
+```
+
+with:
+
+```xml
+              <Border Classes="badge manual" IsVisible="{Binding ShowManualBadge}"
+                      ToolTip.Tip="{loc:Tr tasks.manualTip}">
+                <TextBlock Text="{Binding ManualBadge}"/>
+              </Border>
+              <Border Classes="badge handler" IsVisible="{Binding IsHandlerRun}"
+                      ToolTip.Tip="{loc:Tr tasks.handlerTip}">
+                <TextBlock Text="{Binding HandlerBadge}"/>
+              </Border>
+```
+
+Only the `IsVisible` binding changed on the manual border (`IsManual` → `ShowManualBadge`); the
+handler border is new. No converter is needed — `ShowManualBadge` is already a `bool`.
+
+- [ ] **Step 7: Run tests to verify they pass**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter "FullyQualifiedName~TaskRowViewModelHandlerBadgeTests"`
+Expected: `Passed! - Failed: 0, Passed: 3`.
+
+Run: `dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release`
+Expected: `Passed! - Failed: 0` (en/de key parity).
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: `Build succeeded` — this compiles the AXAML.
+
+- [ ] **Step 8: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Islands/TaskRowViewModel.cs src/ClaudeDo.Ui/Views/Islands/TaskRowView.axaml src/ClaudeDo.Ui/Design/IslandStyles.axaml src/ClaudeDo.Localization/locales/en.json src/ClaudeDo.Localization/locales/de.json tests/ClaudeDo.Ui.Tests/ViewModels/TaskRowViewModelHandlerBadgeTests.cs
+git commit -- src/ClaudeDo.Ui/ViewModels/Islands/TaskRowViewModel.cs src/ClaudeDo.Ui/Views/Islands/TaskRowView.axaml src/ClaudeDo.Ui/Design/IslandStyles.axaml src/ClaudeDo.Localization/locales/en.json src/ClaudeDo.Localization/locales/de.json tests/ClaudeDo.Ui.Tests/ViewModels/TaskRowViewModelHandlerBadgeTests.cs -m "feat(ui): show a HANDLER badge on list-handler run tasks"
+```
+
+---
+
+## Task 5: Ui — "HANDLED TASKS" panel on the handler's detail pane
+
+**Files:**
+- Modify: `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs:248-255`, `:581-584`, `:685`, `:814-833`
+- Modify: `src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml:414-434`
+- Test: `tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandHandledTasksTests.cs` (create)
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandHandledTasksTests.cs`:
+
+```csharp
+using ClaudeDo.Data;
+using ClaudeDo.Data.Models;
+using ClaudeDo.Ui.Services;
+using ClaudeDo.Ui.ViewModels.Islands;
+using Microsoft.EntityFrameworkCore;
+using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
+
+namespace ClaudeDo.Ui.Tests.ViewModels;
+
+/// Covers the handler-run link: binding a "list handler" host task lists every task stamped with
+/// its id, including ones the handler cancelled as duplicates.
+public class DetailsIslandHandledTasksTests : IDisposable
+{
+    private readonly string _dbPath;
+
+    public DetailsIslandHandledTasksTests()
+    {
+        _dbPath = Path.Combine(Path.GetTempPath(), $"claudedo_details_handled_test_{Guid.NewGuid():N}.db");
+        using var ctx = NewContext();
+        ctx.Database.EnsureCreated();
+    }
+
+    public void Dispose()
+    {
+        try { File.Delete(_dbPath); } catch { }
+        try { File.Delete(_dbPath + "-wal"); } catch { }
+        try { File.Delete(_dbPath + "-shm"); } catch { }
+    }
+
+    private ClaudeDoDbContext NewContext()
+    {
+        var opts = new DbContextOptionsBuilder<ClaudeDoDbContext>()
+            .UseSqlite($"Data Source={_dbPath}")
+            .Options;
+        return new ClaudeDoDbContext(opts);
+    }
+
+    private sealed class TestDbFactory : IDbContextFactory<ClaudeDoDbContext>
+    {
+        private readonly Func<ClaudeDoDbContext> _create;
+        public TestDbFactory(Func<ClaudeDoDbContext> create) => _create = create;
+        public ClaudeDoDbContext CreateDbContext() => _create();
+    }
+
+    private sealed class NullServiceProvider : IServiceProvider
+    {
+        public object? GetService(Type serviceType) => null;
+    }
+
+    private sealed class StubNotesApi : ClaudeDo.Ui.Services.Interfaces.INotesApi
+    {
+        public Task<List<DailyNoteDto>> ListAsync(DateOnly day) =>
+            Task.FromResult(new List<DailyNoteDto>());
+        public Task<DailyNoteDto?> AddAsync(DateOnly day, string text) =>
+            Task.FromResult<DailyNoteDto?>(null);
+        public Task UpdateAsync(string id, string text) => Task.CompletedTask;
+        public Task DeleteAsync(string id) => Task.CompletedTask;
+    }
+
+    private sealed class FakeWorkerClient : StubWorkerClient
+    {
+        public override bool IsConnected => true;
+    }
+
+    private DetailsIslandViewModel BuildVm()
+    {
+        var factory = new TestDbFactory(NewContext);
+        return new DetailsIslandViewModel(
+            factory, new FakeWorkerClient(), new NullServiceProvider(), new StubNotesApi(), new MergeCoordinator());
+    }
+
+    [Fact]
+    public async Task Bind_HandlerTask_ListsHandledTasksWithTheirStatus()
+    {
+        const string listId = "list-1";
+        const string handlerId = "handler-task-1";
+
+        await using (var ctx = NewContext())
+        {
+            ctx.Lists.Add(new ListEntity { Id = listId, Name = "L", WorkingDir = @"C:\repo", CreatedAt = DateTime.UtcNow });
+            ctx.Tasks.Add(new TaskEntity
+            {
+                Id = handlerId, ListId = listId, Title = "List handler: L",
+                Status = TaskStatus.WaitingForReview, IsManual = true,
+                HandlerBaseCommit = "base123", HandlerHeadCommit = "head456",
+                CreatedAt = DateTime.UtcNow,
+            });
+            ctx.Tasks.Add(new TaskEntity
+            {
+                Id = "done-1", ListId = listId, Title = "Merged task",
+                Status = TaskStatus.Done, HandlerTaskId = handlerId,
+                SortOrder = 0, CreatedAt = DateTime.UtcNow,
+            });
+            ctx.Tasks.Add(new TaskEntity
+            {
+                Id = "dupe-1", ListId = listId, Title = "Duplicate the handler cancelled",
+                Status = TaskStatus.Cancelled, HandlerTaskId = handlerId,
+                SortOrder = 1, CreatedAt = DateTime.UtcNow,
+            });
+            ctx.Tasks.Add(new TaskEntity
+            {
+                Id = "unrelated-1", ListId = listId, Title = "Not part of the run",
+                Status = TaskStatus.Idle, CreatedAt = DateTime.UtcNow,
+            });
+            await ctx.SaveChangesAsync();
+        }
+
+        var vm = BuildVm();
+        vm.Bind(new TaskRowViewModel { Id = handlerId, Status = TaskStatus.WaitingForReview });
+
+        var deadline = DateTime.UtcNow.AddSeconds(5);
+        while (DateTime.UtcNow < deadline && vm.HandledTasks.Count == 0)
+            await Task.Delay(20);
+
+        Assert.Equal(2, vm.HandledTasks.Count);
+        Assert.True(vm.HasHandledTasks);
+        Assert.Equal("Merged task", vm.HandledTasks[0].Title);
+        Assert.Equal(TaskStatus.Done, vm.HandledTasks[0].Status);
+        Assert.Equal(TaskStatus.Cancelled, vm.HandledTasks[1].Status);
+        Assert.DoesNotContain(vm.HandledTasks, r => r.Id == "unrelated-1");
+    }
+
+    [Fact]
+    public async Task Bind_PlainTask_HasNoHandledTasks()
+    {
+        const string listId = "list-1";
+        const string taskId = "plain-1";
+
+        await using (var ctx = NewContext())
+        {
+            ctx.Lists.Add(new ListEntity { Id = listId, Name = "L", CreatedAt = DateTime.UtcNow });
+            ctx.Tasks.Add(new TaskEntity
+            {
+                Id = taskId, ListId = listId, Title = "Plain",
+                Status = TaskStatus.Idle, CreatedAt = DateTime.UtcNow,
+            });
+            await ctx.SaveChangesAsync();
+        }
+
+        var vm = BuildVm();
+        vm.Bind(new TaskRowViewModel { Id = taskId, Status = TaskStatus.Idle });
+        await Task.Delay(300);
+
+        Assert.Empty(vm.HandledTasks);
+        Assert.False(vm.HasHandledTasks);
+    }
+}
+```
+
+- [ ] **Step 2: Run the tests to verify they fail**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter "FullyQualifiedName~DetailsIslandHandledTasksTests"`
+Expected: compile error — `DetailsIslandViewModel` has no `HandledTasks` / `HasHandledTasks`.
+
+- [ ] **Step 3: Add the collection**
+
+In `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs`, after the line
+`public ObservableCollection<ChildOutcomeRowViewModel> ChildOutcomes { get; } = new();` add:
+
+```csharp
+    // Tasks a "list handler" run processed ("Let Claude handle it"), linked via
+    // TaskEntity.HandlerTaskId. Separate from ChildOutcomes on purpose: that collection is the
+    // planning/improvement parent's children and feeds the merge card's combined diff, which a
+    // handler run must not touch (it commits straight to the list's working dir).
+    public ObservableCollection<ChildOutcomeRowViewModel> HandledTasks { get; } = new();
+```
+
+After the line `public bool HasChildOutcomes => ChildOutcomes.Count > 0;` add:
+
+```csharp
+    public bool HasHandledTasks => HandledTasks.Count > 0;
+```
+
+- [ ] **Step 4: Clear it on rebind**
+
+In the same file, in the rebind reset block, after the line `ChildOutcomes.Clear();` add:
+
+```csharp
+        HandledTasks.Clear();
+```
+
+and after `OnPropertyChanged(nameof(HasChildOutcomes));` in that same block add:
+
+```csharp
+        OnPropertyChanged(nameof(HasHandledTasks));
+```
+
+- [ ] **Step 5: Load it on bind**
+
+In the same file, directly after the line `await LoadChildOutcomesAsync(row.Id, ct);` add:
+
+```csharp
+            await LoadHandledTasksAsync(row.Id, ct);
+```
+
+Then add the loader immediately after the closing brace of `LoadChildOutcomesAsync`:
+
+```csharp
+    // Tasks stamped with this handler run's id. Ordered like the task list itself so the panel
+    // reads in the same order the user picked them.
+    private async System.Threading.Tasks.Task LoadHandledTasksAsync(string handlerTaskId, CancellationToken ct)
+    {
+        try
+        {
+            await using var ctx = await _dbFactory.CreateDbContextAsync(ct);
+            var handled = await ctx.Tasks
+                .AsNoTracking()
+                .Include(t => t.Worktree)
+                .Where(t => t.HandlerTaskId == handlerTaskId)
+                .OrderBy(t => t.SortOrder).ThenBy(t => t.CreatedAt)
+                .ToListAsync(ct);
+            ct.ThrowIfCancellationRequested();
+            if (handled.Count == 0) return;
+
+            HandledTasks.Clear();
+            foreach (var h in handled)
+                HandledTasks.Add(new ChildOutcomeRowViewModel
+                {
+                    Id = h.Id,
+                    Title = h.Title,
+                    Status = h.Status,
+                    RoadblockCount = h.RoadblockCount,
+                    WorktreeState = h.Worktree?.State ?? ClaudeDo.Data.Models.WorktreeState.Active,
+                });
+            OnPropertyChanged(nameof(HasHandledTasks));
+        }
+        catch (OperationCanceledException) { }
+        catch { /* best-effort */ }
+    }
+```
+
+- [ ] **Step 6: Keep the rows live**
+
+In the same file, in `RefreshChildOutcomeAsync`, replace:
+
+```csharp
+        var row = ChildOutcomes.FirstOrDefault(c => c.Id == childTaskId);
+        if (row is null) return;
+```
+
+with:
+
+```csharp
+        // The same refresh serves both lists: a planning parent's children and a handler run's
+        // handled tasks. Only one of them can hold a given id.
+        var row = ChildOutcomes.FirstOrDefault(c => c.Id == childTaskId)
+                  ?? HandledTasks.FirstOrDefault(c => c.Id == childTaskId);
+        if (row is null) return;
+```
+
+- [ ] **Step 7: Render the panel**
+
+In `src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml`, directly after the closing
+`</StackPanel>` of the existing `<!-- Child outcomes -->` block, add:
+
+```xml
+            <!-- Handled tasks (list handler run) -->
+            <StackPanel Spacing="6" IsVisible="{Binding HasHandledTasks}">
+              <TextBlock Classes="section-label" Text="HANDLED TASKS" />
+              <ItemsControl ItemsSource="{Binding HandledTasks}">
+                <ItemsControl.ItemTemplate>
+                  <DataTemplate x:DataType="vm:ChildOutcomeRowViewModel">
+                    <Grid ColumnDefinitions="*,Auto,Auto" Margin="0,2">
+                      <TextBlock Grid.Column="0" Text="{Binding Title}"
+                                 TextTrimming="CharacterEllipsis"
+                                 VerticalAlignment="Center" />
+                      <TextBlock Grid.Column="1" Text="{Binding RoadblockText}"
+                                 IsVisible="{Binding HasRoadblock}"
+                                 Foreground="#E0A030"
+                                 Margin="8,0" VerticalAlignment="Center" />
+                      <TextBlock Grid.Column="2" Text="{Binding StatusLabel}"
+                                 Opacity="0.75" VerticalAlignment="Center" />
+                    </Grid>
+                  </DataTemplate>
+                </ItemsControl.ItemTemplate>
+              </ItemsControl>
+            </StackPanel>
+```
+
+- [ ] **Step 8: Run the tests to verify they pass**
+
+Run: `dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release --filter "FullyQualifiedName~DetailsIslandHandledTasksTests"`
+Expected: `Passed! - Failed: 0, Passed: 2`.
+
+Run: `dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release`
+Expected: `Build succeeded`.
+
+- [ ] **Step 9: Commit**
+
+```bash
+git add src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandHandledTasksTests.cs
+git commit -- src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs src/ClaudeDo.Ui/Views/Islands/Detail/WorkConsole.axaml tests/ClaudeDo.Ui.Tests/ViewModels/DetailsIslandHandledTasksTests.cs -m "feat(ui): list the tasks a handler run processed on its detail pane"
+```
+
+---
+
+## Task 6: Full verification and docs
+
+**Files:**
+- Modify: `src/ClaudeDo.Data/CLAUDE.md` (TaskEntity field list)
+- Modify: `src/ClaudeDo.Ui/CLAUDE.md` (TaskRowViewModel + DetailsIslandViewModel bullets)
+- Modify: `docs/explore-notes/conpty-sessions.md` (list handler → host task section)
+
+- [ ] **Step 1: Run every affected test project**
+
+```bash
+dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Data.Tests/ClaudeDo.Data.Tests.csproj -c Release
+dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
+```
+
+Expected: `Failed: 0` in all four. If a hand-rolled fake in a test project fails to compile,
+it is one of the known `IWorkerClient`/ViewModel-ctor fakes — update it; do not skip the test.
+
+- [ ] **Step 2: Update `src/ClaudeDo.Data/CLAUDE.md`**
+
+In the `TaskEntity` bullet, append `HandlerTaskId` to the field enumeration (after
+`HandlerBaseCommit / HandlerHeadCommit`), and add a sub-bullet under the existing
+`HandlerBaseCommit`/`HandlerHeadCommit` sub-bullet:
+
+```markdown
+  - `HandlerTaskId` = back-link from a task to the **list handler run** that processed it (1:n, last run wins, no FK). Stamped from the user's selection when the handler task is created, so tasks the handler later cancels as duplicates stay listed. Deliberately not `ParentTaskId` — that is the planning-child relation and drives the indented tree.
+```
+
+- [ ] **Step 3: Update `src/ClaudeDo.Ui/CLAUDE.md`**
+
+In the `DetailsIslandViewModel` bullet, after the `ChildOutcomes` mention, add
+`, plus `HandledTasks` (tasks a list-handler run processed, via `HandlerTaskId`)`.
+
+In the `TaskRowViewModel` sentence, after the `IsManual` clause, add
+`, `IsHandlerRun` (→ HANDLER badge, which outranks MANUAL)`.
+
+- [ ] **Step 4: Update `docs/explore-notes/conpty-sessions.md`**
+
+In the "The host task and its commit range" section, add after the existing description:
+
+```markdown
+`CreateMergeHelperTaskAsync` also stamps `TaskEntity.HandlerTaskId` on every selected task
+(`TaskRepository.SetHandlerTaskIdAsync`) before the session starts, so the handler task's detail
+pane can list what the run was meant to process — including tasks phase 1 cancels as duplicates.
+The handler never links to itself.
+```
+
+Bump that note's "verified against" commit line to the current HEAD.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add src/ClaudeDo.Data/CLAUDE.md src/ClaudeDo.Ui/CLAUDE.md docs/explore-notes/conpty-sessions.md
+git commit -- src/ClaudeDo.Data/CLAUDE.md src/ClaudeDo.Ui/CLAUDE.md docs/explore-notes/conpty-sessions.md -m "docs(handler): document the handler-run task link"
+```
+
+- [ ] **Step 6: Report the visual-verification gap**
+
+The build and tests cannot confirm any of this renders correctly. Explicitly hand these to Mika:
+
+1. HANDLER badge colour and legibility on a handler task row (light **and** dark theme), and that MANUAL is gone from that row while still present on a normal manual reminder.
+2. The HANDLED TASKS panel on the handler task's Session tab: position relative to OUTCOMES, spacing, and behaviour with ~20 handled tasks (scroll).
+3. That a real "Let Claude handle it" run over a multi-task selection produces a populated panel after the run, including a phase-1-cancelled duplicate.

docs/superpowers/plans/2026-08-11-operation-feedback.md

@@ -0,0 +1,515 @@
+# Feedback für langlaufende Operationen — Vorgaben für die Umsetzung
+
+> **Dieses Dokument ist absichtlich kein Task-Skript.** Es enthält die Vorgaben pro Gruppe.
+> Die konkreten Tasks schreibt der **Merge-Helper je Gruppe** beim Ausführen — er kennt dann
+> den tatsächlichen Codestand. Was hier steht, ist bindend; was hier nicht steht, entscheidet
+> er. Checkboxen stehen auf Paketebene, damit der Fortschritt sichtbar bleibt.
+
+**Design:** `docs/superpowers/specs/2026-08-11-operation-feedback-design.md` — dort stehen die
+Belege (Datei:Zeile) und die Begründungen. Dieses Dokument wiederholt sie nicht.
+
+**Ziel:** Jede Operation, die länger als ~300 ms dauern kann, zeigt an, dass sie läuft, was sie
+tut und wie lange sie schon läuft — über **einen** Mechanismus statt pro Fall neu gebaut.
+
+---
+
+## Ausführungsmodell
+
+```
+P0 (Fundament)  ──  muss ALLEIN und ZUERST landen
+   │
+   ├── Gruppe A  UI-Stille      Merge-Helper 1
+   ├── Gruppe B  UI-Freeze      Merge-Helper 2
+   └── Gruppe C  Worker-Stille  Merge-Helper 3
+
+Gruppe D  MCP-Stille  Merge-Helper 4  ──  unabhängig von P0, kann sofort starten
+```
+
+**Ein Merge-Helper pro Gruppe.** Nach P0 laufen A, B, C und D parallel. Jede Gruppe hält sich
+strikt an ihr Datei-Eigentum — das ist die einzige Absicherung gegen gegenseitiges
+Überschreiben, weil alle im gemeinsamen `main`-Checkout arbeiten.
+
+### Datei-Eigentum (bindend)
+
+| Gruppe | Besitzt exklusiv | Darf **nicht** anfassen |
+|---|---|---|
+| **P0** | `Ui/Services/OperationStatus.cs` (neu), `Ui/Views/Controls/OperationIndicator.axaml(.cs)` (neu), **beide `locales/*.json`**, `Ui/Services/WorkerClient.cs` (nur Timing-Hook) | alles andere |
+| **A** | Island-VMs, Modal-VMs, deren AXAML, `Ui/Services/UpdateCheckService.cs` | `locales/*`, `WorkerClient`, `IWorkerClient`, Worker-Projekt |
+| **B** | `Ui/ViewModels/Modals/DiffViewerViewModel.cs`, `Ui/Views/Controls/DiffTextView.axaml.cs` | `locales/*`, Island-VMs, Worker-Projekt |
+| **C** | `Worker/Hub/HubBroadcaster.cs`, `Worker/Hub/WorkerHub.cs`, `Ui/Services/WorkerClient.cs`, `IWorkerClient.cs`, `StubWorkerClient.cs`, `Worker/Lifecycle/*Recovery.cs`, `Worker/Runner/WorktreeManager.cs`, `Worker/Worktrees/WorktreeMaintenanceService.cs` | `locales/*`, Island-VMs, `Worker/External/*` |
+| **D** | `Worker/External/*McpTools.cs`, `Worker/External/ExternalMcpService.cs`, `Worker/Lifecycle/TaskMergeService.cs` (nur die Progress-Schleife) | `locales/*`, alles im Ui-Projekt |
+
+**Locale-Regel:** Nur P0 schreibt in `en.json`/`de.json`. Braucht eine Gruppe doch einen Key,
+den P0 nicht vorgesehen hat: als **letzte** Änderung des Pakets anhängen und im Merge-Helper
+als bekannte Konfliktstelle behandeln. Nie mitten in der Gruppe.
+
+---
+
+## Vorgaben für den Merge-Helper selbst
+
+Gilt für alle vier Gruppen:
+
+- **Agent-Modell:** `sonnet` für Implementierer und Reviewer. Nie haiku, nie opus, nie Fable.
+- **`maxTurns` explizit auf 200 setzen.** `model_presets` ist NULL, sonst bekommt ein
+  sonnet-Task 30 Turns und stirbt mit „exited with code 1 and no result".
+- **`serializeOnFileOverlap` auf der Gruppenliste einschalten.** Innerhalb einer Gruppe
+  fassen mehrere Pakete dieselben Dateien an.
+- **Bauen:** `dotnet build ClaudeDo.slnx` schlägt auf .NET 8 fehl. Einzelprojekte mit
+  `-c Release` bauen (ein laufender Worker sperrt `Debug`):
+  ```
+  dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
+  dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
+  ```
+- **Testen — pro Gruppe die relevanten Projekte:**
+  ```
+  A, B   dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
+         dotnet test tests/ClaudeDo.Localization.Tests/... -c Release   (nur wenn Keys berührt)
+  C      Ui.Tests + ClaudeDo.Worker.Tests  (Worker.Tests enthält auch UiVm-Tests)
+  D      dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
+  P0     Ui.Tests + Localization.Tests
+  ```
+  Fällt ein Test innerhalb der Verify-Kette, erst die Suite **allein** laufen lassen — die
+  `Ui.Tests` haben eine bekannte reihenfolgen-abhängige Flakiness, die nichts mit dem Merge zu
+  tun hat.
+- **Nie `git add -A`.** Immer explizit nach Pfad stagen und `git commit -- <pfade>` — der
+  `main`-Checkout ist von parallelen Sessions geteilt, ein blankes Commit fegt fremde WIP mit.
+- **Nach dem Batch-Merge `main` selbst prüfen.** Approve baut und testet nicht. Neun grüne
+  Branches haben `main` schon zweimal zerlegt, davon einmal durch eine Test-Kollision, die ein
+  reiner src-Build nicht sieht. Also: Build **und** die betroffenen Testprojekte.
+- **Vor Approve prüfen, ob der Branch überhaupt etwas enthält** (`changedFileCount`). Ein
+  blockierter Task wird sonst `Done` mit leerem Branch.
+- **Keine EF-Migration** in diesem Vorhaben. Parallele Migrationen aus Geschwister-Branches
+  löschen sich beim SQLite-Table-Rebuild gegenseitig die Spalten, und die Tests bemerken es
+  nicht (`EnsureCreated`).
+- **Keine Tests, die die echte `claude`-CLI starten.**
+- **Visuelle Prüfung ist nicht durch Tests ersetzbar.** Jedes Paket in A und B endet mit einer
+  offenen visuellen Prüfung für den Nutzer. Nie behaupten, die UI funktioniere.
+
+---
+
+## P0 — Fundament
+
+- [x] **P0-1 — `OperationStatus` + `OperationIndicator` + Locale-Keys**
+- [x] **P0-2 — Timing-Hook für die Messung**
+- [x] **P0-3 — Regel in den CLAUDE.md-Dateien**
+
+> **Stand 2026-08-17.** P0, A (außer A5), B, C1 und D sind gemergt; der visuelle Pass über A und B
+> ist durch, ohne Fund. Nachtrag zu P0-2: der Timing-Sink liegt seit dem Release-Vorlauf hinter
+> `CLAUDEDO_OP_TIMING=1` und ist **standardmäßig aus** — die 63 `InvokeTimedAsync`-Call-Sites
+> bleiben bewusst stehen. Offen: C2–C5.
+
+**Vorbedingung:** keine. Muss allein landen, bevor A/B/C starten.
+
+### Der Vertrag (bindend — 19 Pakete hängen daran)
+
+`src/ClaudeDo.Ui/Services/OperationStatus.cs`, eine `ObservableObject`-Klasse:
+
+| Member | Verhalten |
+|---|---|
+| `bool IsRunning` | **sofort** `true` bei `Begin`. Treibt `CanExecute`, verhindert Doppelklick |
+| `bool ShowIndicator` | erst nach **300 ms** `true`. Kein Flackern bei schnellen Calls |
+| `string? Label` | lokalisierter Text |
+| `string Elapsed` | `mm:ss`, **lokal getickt** |
+| `bool IsStalled` | `true` nach **60 s ohne `Report`** |
+| `IDisposable Begin(string label)` | startet; `Dispose` beendet **auch im Exception-Fall** |
+| `void Report(string label)` | überschreibt `Label` mid-flight, setzt die Stall-Uhr zurück |
+
+**Nachbesserung 1 (bindend):** `IsStalled` bemisst sich an der Zeit **seit dem letzten
+`Report`**, nicht an der Gesamtdauer. Ein regulär mehrminütiges Verify-Gate darf sich nicht
+selbst als hängend melden. Eine Operation ohne jeden `Report` gilt nach 60 s als stalled — das
+ist genau der Fall, der heute wie ein Absturz aussieht.
+
+Benutzung im ViewModel:
+
+```csharp
+using var op = Approve.Begin(Loc.T("ops.merge.merging"));
+var result = await _worker.ApproveReviewAsync(...);
+```
+
+### Weitere Vorgaben
+
+- **Zeitquelle injizierbar** über `TimeProvider` (in .NET 8 vorhanden). **Kein statischer
+  `DispatcherTimer`** — geteilter statischer State ist die Ursache der reihenfolgen-abhängigen
+  Flakiness in den `Ui.Tests`. Timer-Callbacks kommen vom Threadpool und müssen auf den
+  Dispatcher gepostet werden.
+- **Mehrere `OperationStatus` pro VM sind erwünscht.** `WorktreesOverviewModalViewModel`
+  braucht getrennte für Refresh, Cleanup und Merge — sonst blockiert ein laufender Refresh die
+  Cleanup-Anzeige.
+- **`OperationStatus` transportiert keine Fehler.** Fehlerbehandlung bleibt unverändert über
+  `ShowErrorAsync` / `ErrorReported` / `FlashFooterError`.
+- **`OperationIndicator`** nutzt `Ellipse.spinner` aus `Design/IslandStyles.axaml` (14×14,
+  Accent, 0.9 s Rotation) plus Label und Elapsed. Ohne dieses Control wird die
+  Spinner-StackPanel aus `MergeModalView.axaml` acht Mal von Hand nachgebaut. Werte aus
+  `Tokens.axaml` verwenden, keine Inline-Zahlen.
+- **Locale-Keys:** neuer Top-Level-Namespace `ops` in `en.json` und `de.json`, Parität wird von
+  `Localization.Tests` erzwungen. P0 legt die Keys für **A und C** vorab an — abgeleitet aus den
+  Paketlisten unten.
+
+**Nachbesserung 3 (bindend):** **Gruppe D braucht keine Locale-Keys.**
+MCP-Progress-Meldungen gehen an Agenten, nicht an den Nutzer, und bleiben englische
+Klartext-Strings.
+
+### P0-2: Messung an genau einer Stelle
+
+Zwei Hooks, nicht zwanzig:
+1. In `WorkerClient` jeden Hub-Invoke mit Dauer loggen.
+2. Im DB-Pfad der Islands dasselbe.
+
+Ein Tag Nutzung liefert eine sortierte Liste echter Ausreißer. **A5 und C werten sie aus**,
+statt zu raten. Bild 2 und 4 brauchen keine Messung.
+
+Faustregel für den Zweifelsfall: instrumentiert wird, was git aufruft, Netz nutzt, einen
+Prozess startet, oder O(n) über unbegrenzt viele DB-Zeilen läuft. Einzelzeilen-Reads nicht.
+
+### Definition of Done für P0
+
+`OperationStatus` hat Unit-Tests mit einem Fake-`TimeProvider` für: 300-ms-Grace, 60-s-Stall
+**ab letztem Report**, Elapsed-Formatierung, `Dispose` nach Exception, `Report` überschreibt
+Label und setzt die Stall-Uhr zurück. `Localization.Tests` grün. Kein VM ist umgestellt — P0
+liefert nur das Werkzeug.
+
+### Task-Entwürfe (grob)
+
+**P0-1 · `OperationStatus` + `OperationIndicator` + `ops`-Locale-Keys**
+Baue das Primitive nach dem Vertrag oben, dazu das Anzeige-Control und den neuen
+Locale-Namespace `ops` in beiden Sprachdateien. Keys für Gruppe A und C vorab anlegen, für D
+keine. Zeitquelle über `TimeProvider`, kein statischer Timer.
+*Dateien:* `Ui/Services/OperationStatus.cs` (neu), `Ui/Views/Controls/OperationIndicator.axaml(.cs)` (neu), `Localization/locales/{en,de}.json`, `tests/ClaudeDo.Ui.Tests/`
+*Fertig wenn:* Unit-Tests für Grace, Stall-ab-Report, Elapsed, Dispose-nach-Exception, Report-Reset. Localization.Tests grün. Kein ViewModel angefasst.
+
+**P0-2 · Timing-Hook für die Messung**
+Zwei Hooks: Dauer jedes Hub-Invokes in `WorkerClient`, Dauer des DB-Pfads der Islands. Ziel
+sind auswertbare Zahlen, keine Anzeige. Ausgabe so, dass sie nach einem Tag Nutzung sortierbar
+ist.
+*Dateien:* `Ui/Services/WorkerClient.cs`, der gemeinsame DB-Zugriffspfad der Island-VMs
+*Fertig wenn:* Beide Hooks aktiv, Overhead vernachlässigbar, das Format ist dokumentiert.
+
+**P0-3 · Feedback-Regel in den CLAUDE.md-Dateien**
+`src/ClaudeDo.Ui/CLAUDE.md`: jeder `IWorkerClient`-Call in einem `[RelayCommand]` läuft durch
+eine `OperationStatus`, Anzeige über `OperationIndicator`. `src/ClaudeDo.Worker/CLAUDE.md`: ein
+MCP-Tool, das über ~5 s laufen kann, reportet Progress.
+*Fertig wenn:* Beide Regeln stehen, jeweils mit einem Satz Begründung.
+
+---
+
+## Gruppe A — Bild 1: UI-Stille
+
+- [x] **A1 — Detail-Pane** ⚠️ *der gemeldete Fall*
+- [x] **A2 — WorktreesOverview**
+- [x] **A3 — Settings-Tabs** — ohne OnlineInbox-SignIn, siehe Nachzügler unten
+- [x] **A4 — Reports und Planning-UI** — ohne die beiden Planning-Calls im `DiffViewerViewModel`
+- [x] ~~**A5 — Island-DB-Pfade nach Messdaten**~~ — **abgesagt** (2026-08-13): kein DB-Pfad über
+  500 ms (höchster p95 372 ms), die Ausreißer saßen alle auf der Hub-Seite. Wie vorgesehen
+  geschlossen, ohne Code.
+
+**Nachzügler (kein Task):** drei Locale-Keys aus P0 sind ungenutzt geblieben —
+`ops.onlineInbox.signingIn` (A3), `ops.planning.buildingIntegrationBranch` und
+`ops.planning.loadingAggregate` (A4). Die beiden Planning-Calls liegen in
+`DiffViewerViewModel.cs`, einer Datei aus Gruppe B, die A4 nicht anfassen durfte.
+
+**Vorbedingung:** P0 gemergt.
+
+### Vorgaben
+
+- **A1 zuerst.** `DetailsIslandViewModel.ApproveReviewAsync` ist der gemeldete Schmerz. Dazu im
+  selben Paket: `SubmitForReviewAsync`, `RejectReviewAsync`, `ParkReviewAsync` und
+  `MergeSectionViewModel.PreviewMergeAsync`.
+- **A1 abonniert `IWorkerClient.MergeProgressEvent`**, um das Label mid-flight von „merging" auf
+  „verifying" zu schärfen. Das Event existiert seit `cad0582`.
+
+  **Nachbesserung 2 (bindend):** A verlässt sich darauf, dass dieses Event **bestehen bleibt**.
+  C1 baut den generischen Kanal darunter, muss `MergeProgressEvent` aber als dünnen Forwarder
+  erhalten. Andernfalls müsste C `DetailsIslandViewModel` ändern — eine Datei aus Gruppe A —
+  und die Parallelität wäre zerstört. **A darf keinen anderen Kanal verwenden.**
+- **Abo nur für die Dauer des Calls.** Der Worker broadcastet an alle Clients; ein dauerhaft
+  registriertes VM bekommt Events für fremde Tasks. `MergeModalViewModel` macht es richtig
+  vor: `+=` im `try`, `-=` im `finally`, plus `if (taskId != TaskId) return;`.
+- **A2:** `IsBusy` existiert dort schon, schaltet aber nur `IsEnabled`. Die Anzeige fehlt
+  komplett. Betrifft Refresh, Cleanup, Reset, ForceRemove und Batch-Merge — Batch-Merge
+  zusätzlich mit Zeilen-Status, weil dort N Tasks sequenziell durchlaufen.
+- **A3:** SessionSkill-Install ist ein `git clone` — der offensichtlichste Kandidat. Dazu
+  Update/Restore-Defaults, OnlineInbox-SignIn, RepoImport-Scan, Update-Check.
+- **A4:** GenerateWeekReport, RunDailyPrepNow, BuildPlanningIntegrationBranch,
+  GetPlanningAggregate, Finalize/QueuePlanningSubtasks. `DiffViewerViewModel.IsLoadingCombined`
+  existiert bereits und bleibt — nicht doppeln.
+- **A5 erst nach Auswertung von P0-2.** Nur Stellen umstellen, die die Messung als Ausreißer
+  zeigt. Kein Umstellen auf Verdacht.
+- **`DetailsIslandViewModel` ist groß.** Nicht umstrukturieren, nur die Commands anfassen.
+- **Bereits saubere Flächen nicht anfassen:** `MergeModalViewModel`,
+  `ConflictResolverViewModel`, `DiffViewerViewModel.IsLoadingCombined`,
+  `UsageMonitorModalViewModel`.
+
+### Definition of Done pro Paket
+
+Jeder umgestellte Command: `IsRunning` während des Laufs gesetzt, `CanExecute` gesperrt,
+Zustand nach einer Exception zurückgesetzt — als Test in `ClaudeDo.Ui.Tests`. Kein
+handgebauter Spinner, immer `OperationIndicator`. **Visuelle Prüfung offen und explizit
+benannt** (Grace-Periode und Layout kann kein Test bestätigen).
+
+### Task-Entwürfe (grob)
+
+**A1 · Detail-Pane: Approve, Submit, Reject, Park, Preview** ⚠️ *der gemeldete Fall*
+Fünf Commands im Detail-Pane bekommen je eine `OperationStatus` und einen `OperationIndicator`
+neben dem auslösenden Button. Approve abonniert zusätzlich `MergeProgressEvent` **nur für die
+Dauer des Calls** und filtert auf die eigene TaskId, um das Label von „merging" auf „verifying"
+zu schärfen. `DetailsIslandViewModel` nicht umstrukturieren.
+*Dateien:* `Ui/ViewModels/Islands/DetailsIslandViewModel.cs`, `MergeSectionViewModel.cs`, `Ui/Views/Islands/Detail/*`
+*Fertig wenn:* Approve zeigt während des Verify-Gates Phase und Elapsed, Button ist gesperrt, Zustand nach Fehler zurückgesetzt. Visuelle Prüfung offen.
+
+**A2 · WorktreesOverview: Anzeige für alle fünf Aktionen**
+`IsBusy` existiert, schaltet aber nur `IsEnabled`. Getrennte `OperationStatus` für Refresh,
+Cleanup, Reset, ForceRemove und Batch-Merge — der Batch-Merge zusätzlich mit Zeilen-Status, weil
+er N Tasks sequenziell durchläuft.
+*Dateien:* `Ui/ViewModels/Modals/WorktreesOverviewModalViewModel.cs`, `Ui/Views/Modals/WorktreesOverviewModalView.axaml`
+*Fertig wenn:* Jede der fünf Aktionen zeigt sichtbar, dass sie läuft; ein laufender Refresh blockiert die Cleanup-Anzeige nicht. Visuelle Prüfung offen.
+
+**A3 · Settings-Tabs: Skill-Install, Restore-Defaults, OnlineInbox, RepoImport, Update-Check**
+Fünf Flächen, bei denen `IsBusy` heute nur den Button sperrt. Der Skill-Install ist ein
+`git clone` und der offensichtlichste Kandidat.
+*Dateien:* `Ui/ViewModels/Modals/Settings/*`, `Ui/ViewModels/Modals/RepoImportModalViewModel.cs`, `Ui/Services/UpdateCheckService.cs`, `Ui/Views/Modals/SettingsModalView.axaml`
+*Fertig wenn:* Alle fünf zeigen Aktivität; der Skill-Install zeigt zusätzlich, dass geklont wird. Visuelle Prüfung offen.
+
+**A4 · Reports und Planning-UI**
+GenerateWeekReport, RunDailyPrepNow, BuildPlanningIntegrationBranch, GetPlanningAggregate,
+Finalize/QueuePlanningSubtasks. `DiffViewerViewModel.IsLoadingCombined` existiert bereits und
+bleibt unangetastet.
+*Dateien:* `Ui/ViewModels/Modals/WeeklyReportModalViewModel.cs`, Planning-Pfade in `DetailsIslandViewModel`/`TasksIslandViewModel`, zugehörige AXAML
+*Fertig wenn:* Report-Generierung und Planning-Integration zeigen Aktivität; kein Doppel-Indikator im Combined-Diff. Visuelle Prüfung offen.
+
+**A5 · Island-DB-Pfade nach Messdaten**
+**Erst die Zahlen aus P0-2 auswerten**, dann nur die Ausreißer umstellen. Kandidaten:
+`ClearCompleted`, Drag-Reorder über viele Zeilen, Laden großer Listen. Nichts auf Verdacht.
+*Dateien:* nach Messergebnis
+*Fertig wenn:* Die Auswertung ist im Task dokumentiert, und jede umgestellte Stelle ist durch eine Messung begründet. Wenn nichts über der Schwelle liegt: Task mit Begründung schließen, nichts bauen.
+
+---
+
+## Gruppe B — Bild 2: UI-Freeze
+
+- [x] **B1 — `UnifiedDiffParser.Parse` auslagern**
+- [x] **B2 — `DiffAlignment.Build` Grenze**
+- [x] **B3 — Guard-Test gegen Dispatcher-Blockade**
+
+**Vorbedingung:** P0 gemergt (für den Indikator in B1).
+
+### Vorgaben
+
+- **Reihenfolge ist zwingend: erst auslagern, dann anzeigen.** Ein Spinner auf einem
+  blockierten UI-Thread wird nicht gezeichnet. B1 verschiebt `UnifiedDiffParser.Parse` nach
+  `Task.Run` und setzt danach den Indikator.
+- **`UnifiedDiffParser` ist statisch und rein** — thread-safe, `Task.Run` ist unkritisch. Das
+  Zurückschreiben der Ergebnisse in Observable-Collections muss auf dem UI-Thread passieren.
+- **B2 braucht eine Entscheidung, die der Merge-Helper trifft:** `DiffAlignment.Build` läuft in
+  `DiffTextView.axaml.cs` — in einem Control, nicht in einem VM. Entweder Grenze („ab N Zeilen
+  auslagern") oder inkrementeller Aufbau. Die Wahl gehört ins Paket, nicht hierher; die
+  Vorgabe ist nur: **eine sichtbare Grenze definieren, keine unbegrenzte Synchron-Arbeit.**
+- **AvaloniaEdit-Fallen** (belegt, nicht neu ausprobieren): `this.TryGetResource` in einem
+  Control findet Brushes aus `Tokens.axaml` **nie** und scheitert lautlos; Brushes und Typeface
+  nicht im Konstruktor auflösen. `ScrollToVerticalOffset` ist in v12 ein No-op — schreiben über
+  `ScrollViewer.Offset`, lesen über `TextView.ScrollOffsetChanged`.
+- Gemeinsames Editor-Boilerplate gehört in `Views/Controls/DiffEditorSetup.cs`, nicht ein
+  drittes Mal kopiert.
+
+### Definition of Done
+
+B3 ist der einzige Test im Vorhaben, der Blockade prüft: großes Diff-Fixture, Nachweis, dass
+der Dispatcher weiter Nachrichten verarbeitet. Visuelle Prüfung offen (Verhalten bei großem
+Diff, Indikator während des Parsens).
+
+### Task-Entwürfe (grob)
+
+**B1 · `UnifiedDiffParser.Parse` vom UI-Thread nehmen**
+Beide Aufrufstellen im `DiffViewerViewModel` nach `Task.Run` verschieben, danach den
+`OperationIndicator` setzen. Reihenfolge ist zwingend: erst auslagern, dann anzeigen — ein
+Spinner auf einem blockierten Dispatcher wird nicht gezeichnet. Das Zurückschreiben in
+Observable-Collections muss auf dem UI-Thread passieren.
+*Dateien:* `Ui/ViewModels/Modals/DiffViewerViewModel.cs`
+*Fertig wenn:* Kein synchroner Parse mehr im VM, Indikator während des Parsens sichtbar. Visuelle Prüfung mit einem großen Diff offen.
+
+**B2 · `DiffAlignment.Build` — Grenze gegen unbegrenzte Synchron-Arbeit**
+`Build` läuft in einem Control, nicht in einem VM. Der ausführende Agent entscheidet zwischen
+Auslagern ab einer Zeilenzahl und inkrementellem Aufbau — die Vorgabe ist nur: **eine
+sichtbare, begründete Grenze**. AvaloniaEdit-Fallen aus dem Vorgaben-Abschnitt beachten
+(`TryGetResource` scheitert lautlos, `ScrollToVerticalOffset` ist ein No-op).
+*Dateien:* `Ui/Views/Controls/DiffTextView.axaml.cs`, gemeinsames Boilerplate nach `DiffEditorSetup.cs`
+*Fertig wenn:* Die gewählte Grenze ist im Code kommentiert und begründet; große Diffs blockieren nicht mehr unbegrenzt. Visuelle Prüfung offen.
+
+**B3 · Guard-Test: großer Diff blockiert den Dispatcher nicht**
+Headless-Test mit großem Diff-Fixture, der nachweist, dass der Dispatcher während Parse und
+Build weiter Nachrichten verarbeitet. Der einzige Blockade-Test im Vorhaben — soll auch
+zukünftige Regressionen fangen.
+*Dateien:* `tests/ClaudeDo.Ui.Tests/`, Fixture im Testprojekt
+*Fertig wenn:* Der Test fällt gegen den Stand **vor** B1/B2 und ist danach grün.
+
+---
+
+## Gruppe C — Bild 3: Worker-Stille
+
+- [x] **C1 — generischer `OperationProgress`-Kanal**
+- [ ] **C2 — Startup-Recovery sichtbar**
+- [ ] **C3 — Worktree-Anlage sichtbar**
+- [ ] **C4 — Rebase-after-Merge und WorktreeMaintenance**
+- [ ] **C5 — periodische Dienste**
+
+> **Einzige offene Gruppe.** C2–C5 sind unblockiert (C1 ist gemergt). Woran man den Reststand
+> erkennt: die vier Keys `ops.worker.startupRecovery`, `.creatingWorktree`, `.rebasingAfterMerge`
+> und `.maintainingWorktrees` liegen ungenutzt in beiden Sprachdateien.
+
+**Vorbedingung:** P0 gemergt. Die Abhängigkeit zur Parallelsession ist mit `cad0582`
+aufgelöst.
+
+### Vorgaben
+
+- **Der Kanal:**
+  ```
+  OperationProgress(string opKey, string phase, int current, int total)
+  ```
+  `opKey` = TaskId bei task-gebundenen Operationen, sonst ein stabiler String
+  (`"worktree-cleanup"`, `"startup-recovery"`, `"planning-integration:<taskId>"`).
+- **Kein Elapsed auf der Leitung.** Das UI tickt lokal. Die heutige Implementierung lässt den
+  Worker alle 30 s ticken — damit zeigt sie die ersten 30 Sekunden nur „merging". C1 stellt das
+  um.
+- **`MergeProgressEvent` bleibt als Forwarder** (siehe Nachbesserung 2 unter Gruppe A). Vier
+  Zeilen. Entfernen erst, wenn A und C beide gemergt sind — nicht in dieser Gruppe.
+- **`current`/`total` wird als Text gezeigt, nie als Prozentbalken.** Die meisten Operationen
+  haben kein sinnvolles Total.
+- **C3 zuerst prüfen, nicht bauen:**
+  `docs/superpowers/specs/2026-08-07-ui-reaktivitaet-und-listen-performance-design.md` führt
+  `WorktreeManager.cs:103` als DB-Write-ohne-Broadcast. Ob das inzwischen geschlossen ist,
+  gehört geprüft, bevor es doppelt behoben wird.
+- **C5 ist der wackeligste Punkt im Design.** Periodische Dienste (Usage, OnlineSync, Prime,
+  Queue) dürfen **nur Aktivität und Fehler** melden, keinen Tick-Strom. Wenn der Merge-Helper
+  beim Umsetzen zum Schluss kommt, dass C5 nur Rauschen erzeugt: **weglassen und begründen**,
+  statt es durchzuziehen.
+- **Test-Fakes wachsen mit.** Ein neues Event auf `IWorkerClient`/`WorkerHub` bricht
+  handgeschriebene Fakes in **beiden** Testprojekten — `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs`
+  und die UiVm-Tests unter `tests/ClaudeDo.Worker.Tests/`.
+- **Broadcast-Sparsamkeit:** vor einem „fehlenden Broadcast" immer den Aufrufer prüfen. Im
+  08-07-Spec war ein gemeldetes Loch in Wahrheit schon vom Aufrufer abgedeckt, und der Fix
+  wäre ein Duplikat gewesen.
+
+### Definition of Done
+
+Progress-Callbacks in `ClaudeDo.Worker.Tests` mit einem Fake gezählt — keine echten Timeouts,
+keine echte CLI. UI-Seite: die Anzeige beim Worker-Start ersetzt „reconnecting" durch die
+laufende Recovery-Phase. Visuelle Prüfung offen.
+
+### Task-Entwürfe (grob)
+
+**C1 · Generischer `OperationProgress`-Kanal, `MergeProgress` darauf umstellen**
+Neues Hub-Event `OperationProgress(opKey, phase, current, total)`, ohne Elapsed auf der Leitung.
+Der Merge-Pfad sendet darüber. **`MergeProgressEvent` bleibt als vierzeiliger Forwarder** —
+Gruppe A hängt daran und darf nicht angefasst werden. Fakes in beiden Testprojekten mitziehen.
+*Dateien:* `Worker/Hub/HubBroadcaster.cs`, `Worker/Hub/WorkerHub.cs`, `Ui/Services/WorkerClient.cs`, `IWorkerClient.cs`, `tests/ClaudeDo.Ui.Tests/StubWorkerClient.cs`, UiVm-Fakes in `Worker.Tests`
+*Fertig wenn:* Merge-Phasen laufen über den neuen Kanal, das UI tickt Elapsed lokal, `MergeProgressEvent` funktioniert unverändert weiter, beide Testprojekte grün.
+
+**C2 · Worker-Startup-Recovery sichtbar machen**
+Die sechs Recovery-Services beim Worker-Start melden Phase und `i/n` über den Kanal
+(`opKey = "startup-recovery"`). Das UI ersetzt „reconnecting" durch die laufende Phase.
+*Dateien:* `Worker/Lifecycle/*Recovery.cs`, Anzeige im `IslandsShellViewModel`-Umfeld
+*Fertig wenn:* Beim Worker-Start ist sichtbar, welche Recovery läuft. Visuelle Prüfung offen.
+
+**C3 · Worktree-Anlage beim Task-Start sichtbar machen**
+**Zuerst prüfen**, ob der im 08-07-Spec gemeldete Broadcast-Gap in `WorktreeManager` inzwischen
+geschlossen ist — nicht doppelt beheben. Danach die stille Lücke zwischen `Queued` und erster
+Ausgabe an der Task-Zeile sichtbar machen.
+*Dateien:* `Worker/Runner/WorktreeManager.cs`, Task-Row-Anzeige
+*Fertig wenn:* Das Prüfergebnis steht im Task; die Anlage-Phase ist an der Zeile sichtbar. Visuelle Prüfung offen.
+
+**C4 · Rebase-after-Merge und WorktreeMaintenance in den Kanal**
+`RebaseOthersAfterMergeAsync` läuft heute innerhalb des Merge-Calls **nach** dem
+Phasen-Broadcast und ist damit vollständig unsichtbar. Dazu der Hintergrunddienst über alle
+Worktrees, mit `i/n`.
+*Dateien:* `Worker/Lifecycle/TaskMergeService.cs` (Rebase-Abschnitt), `Worker/Worktrees/WorktreeMaintenanceService.cs`
+*Fertig wenn:* Beide melden Fortschritt; ein Merge zeigt nach dem Verify-Gate die Rebase-Phase statt Stille.
+
+**C5 · Periodische Dienste — optional, Abbruch erlaubt**
+Usage, OnlineSync, Prime, Queue sollen **nur Aktivität und Fehler** melden, keinen Tick-Strom.
+Der wackeligste Punkt im Design: kommt der ausführende Agent zum Schluss, dass das nur
+Anzeige-Rauschen erzeugt, **weglassen und begründen** statt durchziehen.
+*Dateien:* `Worker/Usage/`, `Worker/Online/`, `Worker/Prime/`, `Worker/Queue/`
+*Fertig wenn:* Entweder sparsame Meldungen ohne Rauschen — oder eine begründete Absage im Task.
+
+---
+
+## Gruppe D — Bild 4: MCP-Stille
+
+- [x] **D1 — `ProgressReporter` extrahieren**
+- [x] **D2 — die `batch_*`-Tools** — es sind **sieben**, nicht acht (die Achterzahl unten war ein
+  Zählfehler beim Schreiben des Plans)
+- [x] **D3 — Worktree- und Diff-Tools** — drei davon; `batch_cleanup_task_worktrees` lief über D2
+- [x] **D4 — Rest und Doku-Regel** — fand zwei echte Lücken, die D1–D3 offen gelassen hatten:
+  `continue_merge` reichte sein Progress-Token nicht ins Post-Merge-Verify-Gate, und der
+  Unit-Merge-Drain im `PlanningMergeOrchestrator` verlor es nach dem ersten Tick. Dazu
+  `list_worktrees`.
+
+**Vorbedingung:** keine. Kann sofort starten, parallel zu P0.
+
+### Vorgaben
+
+- **Warum das zählt:** ohne Progress bricht der MCP-Client bei Stille nach 300 s ab, während
+  der Worker weiterarbeitet. Das ist die dokumentierte Ursache dafür, dass ein Merge zwar
+  durchläuft, den Task aber nie auf `Done` bringt und Abhängige dauerhaft blockiert.
+- **D1:** `TaskMergeService.RunReportingProgressAsync` ist die einzige existierende
+  Progress-Schleife. Als eigenständige Klasse extrahieren, plus ein Overload für
+  Element-Fortschritt (`i/n`). Nicht kopieren — extrahieren, damit es eine Implementierung
+  bleibt.
+- **`TaskMergeService` ist die einzige Datei, die D mit C teilt.** D fasst dort ausschließlich
+  die Progress-Schleife an. Wenn beide Gruppen gleichzeitig laufen, ist das die Stelle, die der
+  Merge-Helper im Auge behalten muss.
+- **Keine Locale-Keys** (Nachbesserung 3). Englische Klartext-Strings.
+- **Zielumfang:** die 7 `batch_*`-Tools mit `i/n`, dann `cleanup_task_worktree`,
+  `batch_cleanup_task_worktrees`, `get_task_diff`, `preview_merge_set`. Bereits versorgt und
+  nicht anzufassen: die 5 Tools in `ExternalMcpService` mit `IProgress`, `TaskWaitMcpTools`,
+  `merge_task`/`review_task`.
+- **D4 schreibt die Regel ins Worker-`CLAUDE.md`:** ein MCP-Tool, das über ~5 s laufen kann,
+  reportet Progress. Ohne die Regel wiederholt sich das Muster beim nächsten Tool.
+
+### Definition of Done
+
+Für jedes umgestellte Tool ein Test in `ClaudeDo.Worker.Tests`, der mit einem Fake-`IProgress`
+zählt, dass Meldungen kommen — bei `batch_*` mindestens eine pro Element. Keine visuelle
+Prüfung nötig, diese Gruppe hat keine UI.
+
+### Task-Entwürfe (grob)
+
+**D1 · `ProgressReporter` extrahieren**
+`TaskMergeService.RunReportingProgressAsync` als eigenständige Klasse herauslösen, plus einen
+Overload für Element-Fortschritt (`i/n`). **Extrahieren, nicht kopieren** — es soll eine
+Implementierung bleiben. Dies ist die einzige Datei, die D mit C teilt; nur die Progress-Schleife
+anfassen.
+*Dateien:* `Worker/Lifecycle/TaskMergeService.cs`, neue Klasse im Worker-Projekt
+*Fertig wenn:* Der Merge-Pfad nutzt die extrahierte Klasse, Verhalten unverändert, bestehende Merge-Tests grün.
+
+**D2 · Die sieben `batch_*`-Tools mit Element-Fortschritt**
+Jedes `batch_*`-Tool reportet pro verarbeitetem Element. Grund: ohne Meldung bricht der
+MCP-Client nach 300 s Stille ab, während der Worker weiterläuft — genau der Mechanismus, der
+einen Merge durchlaufen lässt, den Task aber nie auf `Done` bringt.
+*Dateien:* `Worker/External/BatchMcpTools.cs`
+*Fertig wenn:* Pro Tool ein Test mit Fake-`IProgress`, der mindestens eine Meldung je Element zählt. Englische Klartext-Strings, keine Locale-Keys.
+
+**D3 · Worktree- und Diff-Tools mit Progress**
+`cleanup_task_worktree`, `batch_cleanup_task_worktrees`, `get_task_diff`, `preview_merge_set`.
+Bereits versorgt und **nicht** anzufassen: die fünf Tools mit `IProgress` in
+`ExternalMcpService`, `TaskWaitMcpTools`, `merge_task`, `review_task`.
+*Dateien:* die betroffenen `Worker/External/*McpTools.cs`, `ExternalMcpService.cs`
+*Fertig wenn:* Jedes der vier Tools meldet Fortschritt, mit Test.
+
+**D4 · Restliche Long-Runner und die Regel im Worker-`CLAUDE.md`**
+Verbleibende Tools durchgehen, die über ~5 s laufen können, und die Regel festschreiben: ein
+MCP-Tool über ~5 s reportet Progress. Ohne die Regel wiederholt sich das Muster beim nächsten
+Tool.
+*Dateien:* restliche `Worker/External/*McpTools.cs`, `src/ClaudeDo.Worker/CLAUDE.md`
+*Fertig wenn:* Die Regel steht mit Begründung; die durchgegangenen Tools sind im Task aufgelistet — auch die, die bewusst nichts bekommen.
+
+---
+
+## Was nach allen vier Gruppen offen bleibt
+
+- ~~**Visuelle Prüfung** für alle Pakete in A und B~~ — **am 2026-08-17 durch**, ohne Fund
+  (Worktrees-Übersicht, Settings/Skill-Install, WeeklyReport, großer Diff, Detail-Pane-Approve).
+- ~~**Auswertung von P0-2**~~ — am 2026-08-13 ausgewertet, siehe A5.
+- **`MergeProgressEvent`-Forwarder entfernen**, sobald A und C beide gemergt sind. Ein
+  Aufräum-Task, kein Paket.
+- **Bewusst nicht gebaut:** Cancel, Footer-Anzeige für laufende Operationen, Prozentbalken,
+  Änderungen am Installer (der hat bereits eine vollständige Progress-Pipeline).

docs/superpowers/specs/2026-06-05-git-merge-review-rework-design.md

@@ -0,0 +1,197 @@
+# Git Tab / Merge & Review Rework — Design
+
+Date: 2026-06-05
+Status: Approved
+
+## Goal
+
+Make handling merges and reviews as simple as possible in the Terminal component's
+Git tab, and rework the diff viewers and worktree modals along the way. The work is
+split into three layers built across separate sessions, with a shared foundation that
+is built and pushed first so the parallel sessions branch from frozen contracts.
+
+The user mostly trusts task output but wants the diff one click away for important
+work, and wants to land several independently-queued worktrees without per-task
+hopping or hand-resolving conflicts in an external editor.
+
+## Layers
+
+- **Layer A — Review/merge cockpit** (this session). Single-task review + merge UX in
+  the Git tab; consolidate the four diff renderers into one `DiffView`.
+- **Layer B — Multi-worktree merge cockpit** (parallel session). Batch-merge N
+  worktrees into one target, skip-and-continue, conflicts collected for resolution.
+- **Layer C — Inline conflict resolver** (parallel session). VSCode-style inline hunk
+  resolver plus the worker-side conflict plumbing it needs.
+
+They stack: A defines the single-task flow, B reuses it for many tasks, both funnel
+conflicts into C.
+
+## Shared foundation (built & pushed this session, before B/C branch)
+
+Everything B and C depend on lands first on `main`. B and C branch from that commit.
+
+### 1. One diff model + one `DiffView` control
+
+Today there are four diff renderers and two parallel diff models:
+
+- `DiffLinesView.axaml` (used by `DiffModalView`)
+- the inline diff `ItemsControl` in `WorktreeModalView.axaml`
+- `PlanningDiffView.axaml`
+- their backing models: `DiffFileViewModel`/`DiffLineViewModel` (+ `UnifiedDiffParser`)
+  vs `WorktreeNodeViewModel`/`WorktreeDiffLineViewModel`
+
+Collapse into a single canonical diff model + parser + a `DiffView` UserControl. All
+diff rendering across the app goes through `DiffView`.
+
+- Model: `DiffFileViewModel { Path, AddCount, DelCount, Lines }`,
+  `DiffLineViewModel { OldNo, NewNo, Kind (Add|Del|Ctx|File|Hunk), Text }`.
+- Parser: one static `UnifiedDiffParser.Parse(rawUnifiedDiff)` returning the model.
+- `DiffView` exposes a `Files` styled property (file list + selected-file lines), or a
+  simpler `Lines` property for single-file use — Layer A decides the exact surface
+  while building it, but the type names above are frozen so B and C can bind to them.
+
+### 2. Frozen worker conflict contract
+
+Added to `IWorkerClient` (and `WorkerClient` with stub bodies that throw
+`NotSupportedException`) plus new DTOs, so A and B compile against the interface while
+C provides the real worker-side implementation.
+
+```csharp
+// IWorkerClient additions (signatures frozen this session)
+Task<MergeResultDto>            StartConflictMergeAsync(string taskId, string targetBranch);
+Task<MergeConflictsDto>         GetMergeConflictsAsync(string taskId);
+Task                            WriteConflictResolutionAsync(string taskId, string path, string resolvedContent);
+Task<MergeResultDto>            ContinueMergeAsync(string taskId);
+Task                            AbortMergeAsync(string taskId);
+```
+
+- `StartConflictMergeAsync` performs the merge with `leaveConflictsInTree: true` (the
+  worker already supports this flag — used today by the planning orchestrator) and
+  returns `MergeResultDto` with `Status="conflict"` and the conflict file list, leaving
+  `.git/MERGE_HEAD` in place in the list's `WorkingDir`.
+- `GetMergeConflictsAsync` returns each conflicted file with ours/theirs/base content,
+  read via `git show :2:<path>` (ours), `:3:<path>` (theirs), `:1:<path>` (base).
+- `WriteConflictResolutionAsync` writes resolved content to the file in `WorkingDir`
+  and `git add`s it.
+- `ContinueMergeAsync` wraps the existing `TaskMergeService.ContinueMergeAsync`
+  (`git add -A` → re-check `git diff --name-only --diff-filter=U` → `git commit`).
+- `AbortMergeAsync` wraps the existing `TaskMergeService.AbortMergeAsync`
+  (`git merge --abort`).
+
+New DTOs (defined in the worker hub DTO file, mirrored client-side):
+
+```csharp
+public record MergeConflictsDto(string TaskId, IReadOnlyList<ConflictFileDto> Files);
+public record ConflictFileDto(string Path, IReadOnlyList<ConflictHunkDto> Hunks);
+public record ConflictHunkDto(string Ours, string Theirs, string? Base);
+```
+
+Existing DTOs reused unchanged: `MergeResultDto(Status, ConflictFiles, ErrorMessage)`,
+`MergePreviewDto`, `MergeTargetsDto`.
+
+### 3. Conflict data model (UI)
+
+`ConflictFile { Path, Hunks[] }`, `ConflictHunk { Ours, Theirs, Base, Resolution }`.
+Shaped so a future 3-way merge pane needs no model change (Layer C is the inline
+resolver now; the model leaves room for 3-way later).
+
+### 4. Integration seams (delegates, wired by the integrator at merge)
+
+A's and B's cockpits hold a `RequestConflictResolution(string taskId)` callback (an
+`Action<string>` or `Func<string, Task>`). They never reference Layer C's resolver
+types. The integrator connects these callbacks to C's `ConflictResolverViewModel`
+factory when merging the three branches together.
+
+## Parallel boundaries (verified disjoint)
+
+| Area | A (this session) | B (parallel) | C (parallel) |
+|---|---|---|---|
+| `DiffView` + diff model/parser | builds | reuses | reuses |
+| `WorkConsole.axaml` / `DetailsIslandViewModel` | owns | — | — |
+| `DiffModalView` + `PlanningDiffView` | migrates to `DiffView` | — | — |
+| `WorktreesOverviewModalView/VM` + `WorktreeModalView` | — | owns | — |
+| `WorkerHub` / `TaskMergeService` / `GitService` | — | — | owns |
+| New `ConflictResolverView/VM` + conflict UI model | — | — | owns |
+| `IWorkerClient` / `WorkerClient` | adds frozen stubs + DTOs | reuses `MergeTaskAsync` | fills stub bodies |
+| Test fakes (`IWorkerClient`) in both test projects | adds new no-op methods | — | makes them functional if needed |
+
+The only file C and A both touch is `WorkerClient.cs` (C replaces the stub bodies A
+wrote). Contained; reconciled at integration. Everything else is disjoint.
+
+## Layer A — review/merge cockpit (this session)
+
+- The Git tab becomes the single Approve + merge surface. `Approve` and the merge
+  target / preview / diff flow together as one block (no separate REVIEW vs
+  MERGE & WORKTREE sections).
+- `Continue` (reject → requeue with feedback) and `Reset` (reject → idle) **stay** in
+  the Output tab footer — unchanged.
+- The diff is shown via the unified `DiffView` opened as a modal from the cockpit. No
+  inline diff recap in the tab (the island is too small).
+- On a single-task **Approve that conflicts**: instead of today's auto-abort, call
+  `StartConflictMergeAsync` and fire `RequestConflictResolution(taskId)`. This leaves
+  the main checkout mid-merge until the user resolves or aborts (behavior change,
+  intended). The callback is inert until Layer C is merged; the integrator wires it.
+- Migrate `DiffModalView` and `PlanningDiffView` onto the new `DiffView`.
+
+### Behavior change accepted
+
+Today `MergeTask`/`ApproveReview` use `leaveConflictsInTree: false` (auto-abort on
+conflict). Under this design, an Approve that conflicts leaves the merge in progress
+and opens the resolver. The mid-merge guard (`IsMidMergeAsync`) still prevents a second
+concurrent merge.
+
+## Layer B — multi-worktree merge cockpit (parallel)
+
+- Rework `WorktreesOverviewModalView`/`WorktreesOverviewModalViewModel` into a
+  batch-merge cockpit: list mergeable worktrees, select N, choose one target branch
+  (single target — 99% of the time everything goes to the same branch), "Merge all".
+- **Skip-and-continue**: client-side loop calling the existing
+  `MergeTaskAsync(taskId, target, removeWorktree, msg)` per selected task. Clean merges
+  apply; conflicting ones are collected (existing `MergeTaskAsync` auto-aborts on
+  conflict, leaving the tree clean) into a "needs resolution" list with live progress.
+- Each conflict row exposes a **Resolve** action → `RequestConflictResolution(taskId)`
+  (wired to Layer C at integration).
+- Per-task diff via the shared `DiffView`; migrate `WorktreeModalView`'s inline diff
+  onto it.
+- B touches no worker files — keeps it parallel-safe.
+
+## Layer C — inline conflict resolver (parallel)
+
+### Worker side
+
+Implement the five frozen contract methods:
+
+- Add hub methods `StartConflictMerge`, `GetMergeConflicts`, `WriteConflictResolution`,
+  `ContinueMerge`, `AbortMerge` in `WorkerHub`.
+- `StartConflictMerge` calls the existing `TaskMergeService.MergeAsync` overload with
+  `leaveConflictsInTree: true`.
+- `ContinueMerge` / `AbortMerge` wrap the existing `TaskMergeService.ContinueMergeAsync`
+  / `AbortMergeAsync` (currently service-level only, not hub-exposed).
+- `GetMergeConflicts` reads ours/theirs/base per conflicted file via
+  `git show :2:/:3:/:1:`; add the `GitService` helpers needed.
+- `WriteConflictResolution` writes the resolved content to `WorkingDir` and stages it.
+- Fill the `WorkerClient` stub bodies (real SignalR `InvokeAsync` calls).
+- Update the hand-rolled `IWorkerClient` fakes in both test projects.
+
+### UI
+
+- New `ConflictResolverView` + `ConflictResolverViewModel`. 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.
+- When every file's hunks are resolved → `ContinueMergeAsync(taskId)` → `MergeResultDto`
+  (`merged` closes the resolver; `conflict` means not fully resolved, stay open).
+- `AbortMergeAsync(taskId)` cancels and aborts the merge.
+- Expose a factory (`Func<string, ConflictResolverViewModel>`) the integrator wires to
+  A's and B's `RequestConflictResolution` callbacks.
+
+## Build / test
+
+`.slnx` needs .NET 9; on .NET 8 build individual csproj with `-c Release` (a running
+Worker locks `Debug`). Run the relevant test projects. No tests that spawn the real
+`claude` CLI. Keep `en.json`/`de.json` localization keys in parity.
+
+## Out of scope
+
+- Full 3-way synchronized merge editor (model leaves room; not built now).
+- Per-task differing merge targets in the batch (single target only).
+- Any CI/PR tooling (direct push-to-main workflow).

docs/superpowers/specs/2026-06-09-per-task-model-override-design.md

@@ -0,0 +1,80 @@
+# Per-task model override via MCP + cheapest-model prompt guidance
+
+Date: 2026-06-09
+
+## Goal
+
+Let Claude pick the model for each task it generates (planning subtasks,
+improvement follow-ups, external task creation) directly at creation time via
+MCP, and instruct Claude — in the relevant prompts — to choose the *cheapest*
+model that can do the job well.
+
+## Background
+
+- `TaskEntity.Model` (nullable) already exists and is resolved
+  task → list-config → global default in `TaskRunner.ResolveConfigAsync`, then
+  passed to the CLI as `--model` by `ClaudeArgsBuilder`.
+- Today the model can only be set *after* creation via `set_task_config`
+  (`ConfigMcpTools.SetTaskConfig`). The creation tools (`CreateChildTask`,
+  `SuggestImprovement`, `AddTask`) accept no model, so assigning one is a
+  two-call dance.
+- `ModelRegistry.Aliases = ["sonnet","opus","haiku"]`; no cost ordering or
+  validation helper exists.
+
+No schema change is required — only plumbing a `model` argument through the
+creation paths plus prompt edits.
+
+## Decisions
+
+- **Validation:** strict alias-only. `model` must be one of haiku/sonnet/opus
+  (case-insensitive); blank/null means "inherit" (no override); anything else
+  throws an MCP error so Claude self-corrects immediately rather than the task
+  failing later at CLI runtime.
+- **`AddSubtask` is out of scope:** it creates a `SubtaskEntity` (a checklist
+  step), which is never independently executed — a model there is a no-op.
+- **Improvement-child prompt:** the child's model is fixed at filing time and
+  it cannot re-pick, so only a one-line "this is an intentionally small/cheap
+  unit — stay minimal" reminder is added. The real model-choice instruction
+  lives in the main system prompt's SuggestImprovement guidance.
+
+## Cost ordering & heuristic (single source: `ModelRegistry.ByCostAscending`)
+
+`haiku < sonnet < opus`
+
+- **haiku** — trivial/mechanical: doc tweaks, simple renames, small localized edits.
+- **sonnet** — normal coding work (default).
+- **opus** — complex architecture, cross-cutting changes, hard debugging.
+
+## Changes
+
+1. **`ClaudeDo.Data/Models/ModelRegistry.cs`**
+   - `ByCostAscending = ["haiku","sonnet","opus"]`.
+   - `string? NormalizeAlias(string? model)` — trim; null/blank → null;
+     case-insensitive match → canonical lowercase alias; else throw
+     `ArgumentException` with the allowed list.
+
+2. **`TaskRepository.CreateChildAsync`** — add optional `string? model = null`;
+   set `child.Model = ModelRegistry.NormalizeAlias(model)`. Single choke-point
+   for both child-creation MCP tools.
+
+3. **MCP creation tools** (add `model` param, document in `[Description]`):
+   - `PlanningMcpService.CreateChildTask` → forward to `CreateChildAsync`.
+   - `TaskRunMcpService.SuggestImprovement` → forward to `CreateChildAsync`.
+   - `ExternalMcpService.AddTask` → `NormalizeAlias` then set `entity.Model`.
+
+4. **Prompts (`PromptFiles.cs`)**
+   - `PlanningSystemDefault` — instruct the planner to pass each
+     `CreateChildTask` the cheapest capable model (with the ordering/heuristic).
+   - `SystemDefault` (Out-of-scope improvements) — when filing via
+     `SuggestImprovement`, pass the cheapest capable `model`.
+   - `ImprovementChildDefault` — one-line minimality reminder.
+
+5. **Tests** (no real CLI):
+   - `NormalizeAlias`: valid aliases (any case), blank/null → null, unknown → throws.
+   - `CreateChildTask` / `SuggestImprovement` / `AddTask` persist the model;
+     invalid model is rejected.
+
+## Out of scope
+
+- No DB migration. No locale changes (prompts and MCP descriptions are not
+  localized). No UI changes (existing per-task model display already covers it).

docs/superpowers/specs/2026-06-09-unify-parent-task-model-design.md

@@ -0,0 +1,148 @@
+# Unify the parent-task model (planning · improvement · normal)
+
+**Date:** 2026-06-09
+**Status:** Approved-pending-implementation
+
+## Problem
+
+ClaudeDo has three ways a task produces and waits on work, grown as separate
+mechanisms that represent the *same shape* — "a task runs, may emit children,
+and once it + its children are terminal it surfaces for review":
+
+| | children authored | scheduling | parent flow today | merge of children |
+|---|---|---|---|---|
+| **Normal** | none | — | `Running → WaitingForReview → Done` | own worktree on approve |
+| **Improvement** | autonomously *during* run (`suggest_improvement`) | parallel (no blockers) | `Running → WaitingForChildren → WaitingForReview → Done` | separate `MergeAllPlanning` |
+| **Planning** | interactively *before* run (planning session) | sequential chain (`BlockedByTaskId`) | `Idle →(Active→Finalized)→ Done` (skips review) | separate `MergeAllPlanning` |
+
+The incidental divergence we want to remove:
+
+1. **Two "parent is waiting on children" representations** — improvement uses
+   `Status=WaitingForChildren`; planning uses `PlanningPhase=Finalized` with the
+   parent's `Status` jumping `Idle → Done`, never passing through the waiting/review
+   states at all.
+2. **Two parent-advance methods** doing the same job —
+   `TaskRepository.TryCompleteParentAsync` (planning → `Done`, no review) vs
+   `TaskStateService.TryAdvanceImprovementParentAsync` (improvement → `WaitingForReview`).
+3. **A separate merge action** — `MergeAllPlanning` / `PlanningMergeOrchestrator`
+   merges children, decoupled from the parent's `approve`. Approving a parent and
+   merging its unit are two clicks.
+
+What is **genuinely unique and kept**: `PlanningPhase.Active` — the interactive,
+human-in-the-loop authoring gate where children are drafted and cannot run until
+finalize. Improvement has no equivalent. The two *authoring* entry points
+(`PlanningMcpService.CreateChildTask` vs `TaskRunMcpService.SuggestImprovement`)
+also stay distinct — they already share `CreateChildAsync`; unifying the authoring
+UX is explicitly out of scope.
+
+## Decisions (locked)
+
+- **All parents get review.** A planning parent now surfaces in `WaitingForReview`
+  after its children finish, instead of auto-completing to `Done`.
+- **Approve merges the whole unit — full UX consolidation.** Approve is the single
+  entry for reviewing *and* merging any task. For a parent with children it drives the
+  existing `PlanningMergeOrchestrator` (unit merge + parent→`Done` + conflict
+  continue/abort, all already implemented); the standalone "Merge All" button is
+  removed and the orchestrator's conflict dialog + combined-diff preview are reused
+  in-place. Childless tasks keep `ApproveAndMergeAsync`.
+- **Scope = state model + code paths.** Internal refactor; authoring UX and child
+  base-commit resolution are unchanged.
+
+## Target model
+
+**One parent-with-children lifecycle, used by every parent regardless of how its
+children were authored:**
+
+```
+                          ┌─ (no children) ──────────────┐
+Idle → Queued → Running ──┤                              ├→ WaitingForReview → Done
+                          └─ (has/spawns children) ─┐    │      (approve =
+                                                    │    │       merge unit)
+                                WaitingForChildren ─┘    │
+                                       │                 │
+                          (all children terminal) ───────┘
+```
+
+Planning parent (never runs as an agent — it runs an interactive session):
+
+```
+Idle (PlanningPhase None)
+  →[StartPlanning]      Idle (PlanningPhase Active)        ← authoring gate (KEPT)
+  →[FinalizePlanning]   WaitingForChildren (Finalized)     ← children chain runs
+  →[all children terminal]  WaitingForReview
+  →[approve]            merge unit → Done
+```
+
+Children (planning **and** improvement) keep going straight to `Done` with no
+individual review; they accumulate on their branches and merge as a unit when the
+parent is approved.
+
+### State machine after the change
+
+- `WaitingForChildren` is the **single** "parent waiting on children" state, used by
+  both planning and improvement parents.
+- `WaitingForReview` is reached by every parent before `Done`.
+- `PlanningPhase`: `None | Active | Finalized` — unchanged; `Active` remains the
+  authoring gate, `Finalized` marks "was a planning parent" and is set together with
+  `Status=WaitingForChildren`.
+
+## Code changes
+
+1. **Single parent-advance path.** Rename
+   `TaskStateService.TryAdvanceImprovementParentAsync` →
+   `TryAdvanceParentAsync`; it already only checks `Status==WaitingForChildren` +
+   "all children terminal" → `WaitingForReview` (with the failed/cancelled
+   annotation on `Result`). It becomes the only path for both systems.
+   - Handle **zero children**: a finalized planning parent with no children must go
+     straight to `WaitingForReview` (today `TryComplete`/`TryAdvance` both `return`
+     on `Count == 0`).
+
+2. **Delete `TaskRepository.TryCompleteParentAsync`** (`TaskRepository.cs:477`) and
+   its invocation in `TaskStateService.OnChildTerminalAsync`. Planning parents now
+   advance via `TryAdvanceParentAsync` to `WaitingForReview` instead of `Done`.
+   - Keep `_chain.OnChildFinishedAsync` (inter-child unblock — planning-only effect).
+
+3. **`FinalizePlanningAsync`** (`TaskStateService.cs:289`) sets the parent
+   `Status = WaitingForChildren` in the same update that sets
+   `PlanningPhase = Finalized`. This happens before `SetupChainAsync` enqueues
+   child[0], so the parent is in `WaitingForChildren` before any child can finish.
+
+4. **Approve merges the unit.** `WorkerHub.ApproveReview` (and the MCP
+   `ReviewTask` approve path): when the approved task has children, run
+   `PlanningMergeOrchestrator` (parent worktree if `Active` + each `Done` child in
+   order), then transition the parent to `Done`. On a child merge conflict, the
+   parent stays in `WaitingForReview` (mirrors current single-task approve-conflict
+   behavior). Retire the `MergeAllPlanning` Hub method + UI button.
+
+5. **Allow cancelling a `WaitingForChildren` parent.** Add `WaitingForChildren` to
+   the `CancelAsync` guard so a parent waiting on children can be cancelled (today it
+   cannot — minor gap).
+
+6. **Docs.** Fix the `WaitingForChildren`-missing drift in
+   `src/ClaudeDo.Data/CLAUDE.md` and `src/ClaudeDo.Worker/CLAUDE.md`, and update the
+   transition diagram + the root `CLAUDE.md` status-flow line to the unified model.
+
+## Out of scope (unchanged)
+
+- Authoring UX: planning session vs `suggest_improvement` stay as two distinct
+  entry points (both already call `CreateChildAsync`).
+- `WorktreeManager.ResolveBaseCommitAsync` base-commit divergence (planning children
+  branch from list HEAD; improvement children from parent head) — left as-is.
+- Sequential-vs-parallel scheduling — already shared infrastructure
+  (`BlockedByTaskId`); planning chains, improvement doesn't. No change.
+
+## Risks / edge cases
+
+- **Ordering on finalize** — parent must be `WaitingForChildren` before the first
+  child can reach terminal. Guaranteed by setting it inside `FinalizePlanningAsync`,
+  which runs before `SetupChainAsync`.
+- **Zero-children planning parent** — must advance to `WaitingForReview`, not stick
+  in `WaitingForChildren`. Explicit branch in `TryAdvanceParentAsync` /
+  `FinalizePlanningAsync`.
+- **Failed/cancelled children** — parent still advances to `WaitingForReview` with
+  the existing `⚠ Children: N failed, M cancelled` annotation; no wedge.
+- **Approve-merge conflict** — keep parent in `WaitingForReview`; surface the
+  conflicting child like the current merge-conflict path.
+- **Existing rows** — planning parents currently sitting at `Idle`+`Finalized` with
+  live children: behavior change is forward-only (new finalizes use the new flow);
+  no migration needed since `Status`/`PlanningPhase` columns already exist.

docs/superpowers/specs/2026-06-10-online-inbox-design.md

@@ -0,0 +1,142 @@
+# Online Inbox — desktop-side design
+
+Date: 2026-06-10
+Status: approved, implementing
+Related: `docs/online-inbox-api-contract.md` (the API both ends share)
+
+## Goal
+
+Let the owner add task ideas and view their Idle backlog from a phone/browser. The desktop
+ClaudeDo opts in to an online service, syncs its list catalog + Idle backlog up, and pulls
+web-created tasks down as local `Idle` tasks. Execution stays 100% local.
+
+This spec covers only the **desktop side** (this repo). The API + web client are built
+VPS-side against the shared contract.
+
+## Non-goals
+
+- No remote execution; the Worker still runs everything locally.
+- No syncing of any task state other than the `Idle` mirror.
+- No multi-user. Single Zitadel user = the owner.
+- Web client is create + read only.
+
+## Opt-in & where things live
+
+- **Off by default.** When disabled: zero network, zero auth — byte-for-byte today's
+  behaviour. Auth only matters once enabled.
+- Sync runs in the **Worker** (it owns the DB and already hosts `BackgroundService`s). The
+  opt-in config and the stored refresh token live in `worker.config.json`-adjacent state.
+- Interactive Zitadel login happens in the **UI** (browser flow), which hands the resulting
+  refresh token to the Worker over SignalR; the Worker persists it (DPAPI) and uses it for
+  headless token refresh during polling.
+
+## Config (`WorkerConfig`, new `online_inbox` section)
+
+```jsonc
+"online_inbox": {
+  "enabled": false,
+  "api_base_url": "",            // e.g. https://inbox.claudedo.kuns.dev
+  "poll_interval_seconds": 60,
+  "zitadel": {
+    "authority": "",            // issuer URL  (from VPS report)
+    "client_id": "",
+    "scopes": "openid offline_access"   // offline_access → refresh token
+  }
+}
+```
+
+The refresh token is NOT stored in this file. It lives encrypted via
+`System.Security.Cryptography.ProtectedData` (DPAPI, CurrentUser) at
+`~/.todo-app/online-inbox.token` and is read/written only by the Worker.
+
+## Components (Worker, new `Online/` folder)
+
+```
+Worker/Online/
+  OnlineInboxConfig.cs        — the config record (bound from WorkerConfig.OnlineInbox)
+  Dtos.cs                     — RemoteList, RemoteTask, MirrorTask DTOs (match the contract)
+  IOnlineInboxApi.cs          — typed client surface (one method per endpoint)
+  OnlineInboxApiClient.cs     — HttpClient impl; attaches bearer via IOnlineAuthProvider
+  Interfaces/IOnlineAuthProvider.cs — Task<string?> GetAccessTokenAsync(ct)
+  ZitadelAuthProvider.cs      — concrete (PENDING: needs the Zitadel package + client config)
+  OnlineTokenStore.cs         — DPAPI-backed refresh-token persistence
+  OnlineSyncService.cs        — BackgroundService: the reconcile loop (§contract 5)
+  OnlineBacklog.cs            — static helper: the Idle-backlog query/filter (§contract 2)
+```
+
+### `IOnlineInboxApi`
+```
+Task PutListsAsync(IReadOnlyList<RemoteList> lists, ct)
+Task<IReadOnlyList<RemoteTask>> GetUnimportedTasksAsync(ct)   // GET /tasks?imported=false
+Task MarkImportedAsync(string id, ct)                          // POST /tasks/{id}/imported
+Task PutMirrorAsync(IReadOnlyList<MirrorTask> tasks, ct)       // PUT /tasks/mirror
+```
+(The desktop never calls `POST /tasks`, `GET /lists`, or `GET /lists/{id}/tasks` — those are
+web-only.)
+
+### `IOnlineAuthProvider`
+Single method `Task<string?> GetAccessTokenAsync(CancellationToken)` returning a bearer token
+(refreshing transparently), or `null` if not logged in / refresh failed. Abstracting it lets
+us:
+- ship and test the sync engine now with a fake provider,
+- wire the real `ZitadelAuthProvider` once the VPS reports authority/client-id and we add the
+  Zitadel package reference.
+
+`ZitadelAuthProvider` reads the refresh token from `OnlineTokenStore`, exchanges it for an
+access token, caches the access token until near expiry. **Marked with a
+`// TODO(online-inbox)` until the flow is wired.**
+
+> **Auth correction (2026-06-10):** the `KunsZitadel` nuget package is a *server-side*
+> resource-server helper (`AddKunsZitadel` → `JwtBearer` token *validation*). It belongs on
+> the VPS API, NOT the desktop. The desktop must *acquire* tokens, so `ZitadelAuthProvider`
+> uses a client OIDC flow — `IdentityModel.OidcClient` (auth-code + PKCE, loopback redirect)
+> or the device-authorization grant — against Zitadel's OIDC endpoints, then persists the
+> refresh token via `OnlineTokenStore`.
+
+### `OnlineSyncService` (the loop)
+- Hosted only when `online_inbox.enabled == true` (guarded at registration).
+- Every `poll_interval_seconds`: create a DI scope, resolve `TaskRepository` + `ListRepository`
+  (same pattern as the External MCP app), run the §5 reconcile loop.
+- Skips a cycle (logs at debug) if `GetAccessTokenAsync` returns null (not logged in).
+- All failures are caught per-cycle and logged; never crashes the Worker. Network errors back
+  off to the next interval.
+- Import safety: a pulled task whose `listId` has no local list is skipped + logged (not
+  imported), and NOT marked imported, so it retries once the list exists. Imported tasks land
+  as `Status=Idle, CreatedBy="online"` — they never auto-run; the user queues them locally.
+
+## UI (later increment, after VPS report)
+
+- Settings modal → new "Online Inbox" section: enable toggle, API base URL, **Sign in /
+  Sign out** (Zitadel browser/device flow via the OIDC client lib), connection status.
+- Login produces a refresh token; UI sends it to the Worker via a new hub method
+  `SetOnlineInboxAuth(refreshToken)` → Worker writes it through `OnlineTokenStore`.
+- Config read/write via hub methods `GetOnlineInboxConfig` / `SetOnlineInboxConfig`
+  (mirrors the existing `GetAppSettings`/`UpdateAppSettings` pattern).
+- Visual verification is a manual step (flagged — never claimed working without a run).
+
+## Security
+
+- Disabled → no network, no token read.
+- Bearer attached only over HTTPS `api_base_url`; refuse `http://` non-loopback base URLs.
+- Refresh token encrypted at rest (DPAPI CurrentUser). Never logged.
+- Imported tasks are `Idle` only — no auto-execution path from the web.
+
+## Testing
+
+- `OnlineSyncService` reconcile logic tested against a **fake `IOnlineInboxApi`** + real
+  SQLite (Worker.Tests style): pull→import→flag, mirror set = Idle backlog, list catalog push,
+  unknown-list skip, disabled = no calls, not-logged-in = skipped cycle.
+- `OnlineBacklog` filter tested directly (excludes children/planning/blocked/non-Idle).
+- **No real network and no real Zitadel** in tests — fake the api + auth provider. (Consistent
+  with the no-real-Claude-in-tests rule.)
+- DPAPI token store: round-trip test is Windows-only; guard or keep as a thin wrapper.
+
+## Open items (need the VPS report)
+
+- Exact Zitadel authority/issuer, client id, scopes, and **which grant the Zitadel app is
+  registered for** (auth-code+PKCE with which loopback redirect URI, or device-code). This
+  drives the desktop OIDC client implementation.
+- Final API base URL.
+- Desktop client OIDC library decision: `IdentityModel.OidcClient` (recommended) vs
+  hand-rolled device-code. (`KunsZitadel` is server-side only — see the auth correction
+  above; it's for the VPS API.)

docs/superpowers/specs/2026-06-19-feature-unification-design.md

@@ -0,0 +1,91 @@
+# Feature unification — one component per feature
+
+Date: 2026-06-19
+
+## Goal
+
+ClaudeDo grew organically; several features now exist as parallel implementations
+or are reachable through many hand-wired entry points. This design maps the
+duplication and defines a target where **each feature is one component**, reached
+through one path, with dead code removed.
+
+## Method
+
+Mapped via five parallel exploration agents (merge/conflict, review→merge,
+diff+worktree, task create/edit, UI entry-point inventory), then verified the
+load-bearing claims by grep/read before writing this. Every file:line below was
+confirmed against the working tree on 2026-06-19.
+
+## Key finding: it is NOT three merge engines
+
+There is **one** merge engine (`TaskMergeService`), wrapped **once** for multi-child
+units (`PlanningMergeOrchestrator`), with **one** conflict resolver (the Rider
+3-pane). `Worker/CLAUDE.md` already records "there is no separate 'Merge all' entry —
+approve is the single review+merge action." What *looks* like 2–3 merge features is
+**entry-point sprawl** in the UI plus **one dead hunks-API** left over from the
+Layer-C rework. So unification is mostly UI plumbing + deletion, not re-architecting
+the engine.
+
+## Findings — three buckets
+
+### Bucket A — genuine duplication (parallel implementations of one job)
+
+| # | Feature | Duplicated components | Shared already |
+|---|---|---|---|
+| A1 | Diff viewing | `DiffModalViewModel` (worktree + commit-range), `WorktreeModalViewModel` (file-tree + per-file), `PlanningDiffViewModel` (per-subtask + integration) | `UnifiedDiffParser`, `DiffLinesView` (good) |
+| A2 | Agent-config editing | `ListSettingsModalViewModel` (list scope), `AgentSettingsSectionViewModel` (task scope); global lives in `SettingsModalViewModel` | `InheritanceResolver`, `InheritedBadge` (good) |
+| A3 | Worktree actions | `WorktreesOverviewModalViewModel` per-row cmds (Merge/Discard/Keep/ForceRemove/ShowDiff/Jump) vs `MergeSectionViewModel` (Merge/OpenDiff) | same `IWorkerClient` calls |
+| A4 | Merge display | ~~`AgentStripView` re-displays `MergeSectionViewModel` state~~ — resolved 2026-08-06: `AgentStripView` was dead (never bound after the task-detail redesign); deleted instead of unified | — |
+
+### Bucket B — entry-point sprawl (one backend, many hand-wired doors)
+
+| # | Feature | Doors | Evidence |
+|---|---|---|---|
+| B1 | Conflict-resolution seam | 5 copies of `Func<string,string,Task>? RequestConflictResolution` | `WorktreesOverviewModalViewModel.cs:83`, `DiffModalViewModel.cs:75`, `MergeModalViewModel.cs:33`, `MergeSectionViewModel.cs:51`, `DetailsIslandViewModel.cs:347` (delegates). Threaded through `MainWindow.axaml.cs:81`, `IslandsShellViewModel.cs:49/202`, `DiffModalViewModel.cs:103`, `MergeSectionViewModel.cs:159` |
+| B2 | Diff (open) | 3–4 | MergeSection "Open Diff", TaskHeaderBar "Review Merged Diff", WorktreesOverview "Show Diff", Planning "Review Combined" |
+| B3 | List Settings dialog | 2 (was 3 — Lists context menu entry removed 2026-08-06) | Tasks header button, double-click on a list row, shell bridge `IslandsShellViewModel.cs:190-194` |
+| B4 | Worktrees Overview | 2–3 | Repos menu (global), Lists context menu (per-list) |
+| B5 | Repo Import | 2 | Repos menu, Lists footer button |
+
+The conflict-resolution *target* is already single-point (`IslandsShellViewModel.RequestConflictResolutionAsync`, line 49). What is duplicated is the **seam plumbing**: five VMs each own the Func and it is threaded by hand.
+
+### Bucket C — dead / leftover
+
+| # | Item | Evidence |
+|---|---|---|
+| C1 | Dead hunks conflict API | `TaskMergeService.GetConflictsAsync` (`Lifecycle/TaskMergeService.cs:250`) ← `WorkerHub.GetMergeConflicts` (`Hub/WorkerHub.cs:378`) ← `WorkerClient` `"GetMergeConflicts"` (`Services/WorkerClient.cs:276`) ← `IWorkerClient`. Live resolver uses `GetMergeConflictDocuments` (`WorkerHub.cs:389`). Only `TaskMergeServiceTests.cs:672` still references the old one. |
+| C2 | Two task-creation paths | UI quick-add `TasksIslandViewModel.AddAsync` writes EF directly (`db.Tasks.Add`); MCP `ExternalMcpService.AddTask` is the service path. They can drift. |
+| C3 | Stale worktrees | `.claude/worktrees/feat+planning-sessions-ui/…` carries old copies of `DiffModalViewModel`/`ListSettingsModalViewModel`/`WorktreeModalViewModel`; layer-c resolver leftovers. Worktree hygiene, not main code. |
+| C4 | Naming drift (deferred) | Hub `StartConflictMerge`/`ContinueConflictMerge`/`AbortConflictMerge` (`WorkerHub.cs:367/405/414`) vs service `MergeAsync`/`ContinueMergeAsync`/`AbortMergeAsync`. **Documented as intentional** at `Worker/CLAUDE.md:153`. |
+
+## Targets — one component per feature
+
+1. **MergeCoordinator (B1).** Replace the five `RequestConflictResolution` Func seams with one injected coordinator exposing `MergeAsync(taskId, targetBranch)` that owns the "merge → on-conflict open resolver" sequence. Every door (review Approve, Diff Merge button, WorktreesOverview single + batch, Details merge section) calls it. The single resolution point (`IslandsShellViewModel.RequestConflictResolutionAsync`) becomes the coordinator's body.
+2. **DiffViewer (A1 + B2).** One `DiffViewerViewModel` + view with a `DiffSource` abstraction (`DirtyWorktree | BranchVsBase | CommitRange | PlanningAggregate | IntegrationBranch`) and an optional file-tree pane. Replaces `DiffModal` + `WorktreeModal` + `PlanningDiff` shells; keeps `UnifiedDiffParser`/`DiffLinesView`. All B2 doors open it with a different source.
+3. **WorktreeActions (A3).** One `WorktreeActionsViewModel` for a single task's worktree (merge/diff/discard/keep/force-remove), reused by both the overview rows and the Details merge section instead of each owning copies.
+4. **AgentConfigEditor (A2).** One editor component parameterized by scope (`Global | List | Task`) over `InheritanceResolver`, embedded in Settings, List Settings, and the Details panel. Collapses the duplicated property set + reset commands + badges.
+5. **DialogService (B3–B5).** Consolidate the per-modal `Show*` Func seams (`IslandsShellViewModel.cs:59-71`) into one `IDialogService` with typed open methods (`OpenListSettings(list)`, `OpenRepoImport()`, `OpenWorktreesOverview(listId?)`…). Menu, context menu, and footer all call the same method; duplicate command definitions across `ListsIsland`/shell collapse to one.
+6. **Single task-creation path (C2).** Route UI quick-add through the same creation path MCP `AddTask` uses (repository/service), so both honor the same invariants.
+
+Plus **C1** (delete dead hunks API + its test) and **C3** (prune stale worktrees) as groundwork. **C4** naming alignment is **deferred** — it is documented-intentional and would churn the hub + `WorkerClient` + every `IWorkerClient` fake (see the "fakes to sync" hazard) for cosmetic gain.
+
+## Decisions
+
+- **Phased, each phase ships green.** Six independently buildable/committable slices; cheapest and lowest-risk first (see the plan). No big-bang.
+- **One plan file per slice.** Matching the 2026-06-05 layer-A/B/C convention, each slice gets its own `docs/superpowers/plans/2026-06-19-unify-<slice>.md` authored when it is picked up. This umbrella plan sequences them and details Phase 0–1.
+- **DiffViewer (A1) is last.** Highest effort and most UX-sensitive (file-tree vs whole-unified are different layouts); deferring it lets the cheaper wins land first and de-risks the big one.
+- **Keep the merge engine and the resolver seam contract.** `TaskMergeService`, `PlanningMergeOrchestrator`, `ConflictResolverViewModel` ctor/`OpenAsync`/`OpenForPlanningAsync`/`CloseRequested` are unchanged — unification is above them.
+- **Naming alignment deferred, not done** (rationale above).
+
+## Out of scope / deferred
+
+- Hub/service merge-method renaming (C4).
+- Subtask deletion in the UI (a missing feature surfaced during mapping, not a duplicate).
+- Any DB migration, worker engine change, or push.
+
+## Acceptance (per phase)
+
+Each phase: `dotnet build -c Release` clean for touched projects; the relevant test
+project green; locales in parity (Localization.Tests) where keys change; the feature
+reachable through its single new path with the old doors removed or delegating. UI
+phases (2–5) flag a visual-verification gap for Mika to confirm in the running app.

docs/superpowers/specs/2026-06-19-rider-merge-editor-design.md

@@ -0,0 +1,132 @@
+# Rider-style 3-pane merge editor (conflict resolver redesign)
+
+Date: 2026-06-19
+
+## Goal
+
+Replace ClaudeDo's current conflict resolver (3 read-only columns Base|Ours|Theirs,
+one conflict at a time, accept buttons + editable result below) with a JetBrains
+Rider-style **3-pane merge editor**:
+
+- LEFT = **Ours** (read-only) · current branch / merge target
+- MIDDLE = **Result** (editable) · the merged file being assembled
+- RIGHT = **Theirs** (read-only) · incoming task branch
+
+Whole file per pane (not one conflict at a time), color-coded conflict blocks,
+inline per-hunk accept controls (`›` accept a side into the result, `✕` dismiss),
+a `M conflicts · K resolved` readout, synced scrolling, Continue gated until every
+conflict is resolved, Abort, and a binary-file guard. Visual reference: the
+attached "Merge Revisions" screenshot.
+
+## Background
+
+- Avalonia 12 desktop app; the conflict editor already uses **AvaloniaEdit 12.0.0**
+  + `AvaloniaEdit.TextMate` (theme `StyleInclude` in `src/ClaudeDo.App/App.axaml`).
+- **Backend is kept unchanged.** `WorkerHub.GetMergeConflictDocuments(taskId)` returns
+  each conflicted file as ordered `MergeSegment`s: *stable* text (git's already
+  auto-merged content) interleaved with *conflict* blocks carrying `Ours/Base/Theirs`.
+  `StartConflictMerge` / `WriteConflictResolution` / `Continue[Planning]ConflictMerge` /
+  `Abort[Planning]ConflictMerge` and their `IWorkerClient` mirrors stay as-is.
+  `ConflictMarkerParser` (Data) already produces the segments. **ours = merge target
+  (current branch); theirs = incoming task branch.** Merges are LOCAL-only (no push).
+- **Seam kept unchanged** so single-task AND planning conflict paths keep working:
+  `IslandsShellViewModel.ConflictResolverFactory` + `ShowConflictResolver`
+  (wired in `MainWindow.axaml.cs`), VM ctor `(IWorkerClient, taskId)`,
+  `OpenAsync(targetBranch)`, `OpenForPlanningAsync(parentId, subtaskId)`, `CloseRequested`.
+  The planning-path WIP currently uncommitted in the tree (`OpenForPlanningAsync`,
+  `_conflictTaskId`, `LoadDocumentsAsync`) is part of this seam and is preserved.
+
+### Key insight: the segments already line the panes up
+
+Because every conflicted file is split into *stable* (identical on both sides, git
+auto-merged) and *conflict* (divergent) segments, reconstructing three documents —
+
+- **Ours**   = Σ over segments of (stable.Text | conflict.Ours)
+- **Theirs**  = Σ over segments of (stable.Text | conflict.Theirs)
+- **Result**  = Σ over segments of (stable.Text | conflict.Resolution ?? conflict.Ours)
+
+— yields three documents that are byte-identical in their stable regions and differ
+only inside conflict blocks. So the panes align line-for-line for free, and a real
+client-side 3-way diff is **not** needed for the core feature.
+
+## Decisions
+
+- **Data source = segment-based (no backend change, no DiffPlex).** The worker already
+  applied git's auto-merge; only conflicts remain actionable. The screenshot's
+  "N changes" (non-conflicting hunks shown as separately flippable) are already merged
+  and have nothing to accept, so the readout is **`M conflicts · K resolved`**. True
+  "N changes" parity (raw `:1/:2/:3` blobs + DiffPlex 3-way) is an explicit later
+  add-on that does not touch the seam — see *Out of scope / fast-follow*.
+- **One file at a time + file switcher.** Like Rider's title bar ("Merge Revisions for
+  …file"). When more than one file conflicts, a compact switcher selects the active
+  file; Continue still requires *all* files resolved. (Replaces today's cross-file
+  flattened one-at-a-time navigation as the primary model.)
+- **Result-pane editing model.** The middle document is the merged file. Stable text is
+  read-only via `IReadOnlySectionProvider`; only conflict regions are editable. Each
+  conflict's result span is tracked in a `TextSegmentCollection` (anchors auto-adjust on
+  edit). Accepting `›`(ours)/`‹`(theirs) replaces that span; editing inside it or
+  accepting flips the block to **resolved**. Unresolved regions are seeded with the Ours
+  text and painted red until acted on.
+- **Accept controls = overlay between panes** (not an AvaloniaEdit margin). A thin Canvas
+  overlay between Ours|Result and Result|Theirs hosts `›`/`✕` (and `‹`) per conflict,
+  positioned at each block's visual Y (recomputed on scroll/resize). This matches the
+  screenshot's between-pane gutters and avoids the lack of a built-in right-side margin.
+- **Synced scroll = proportional (Green).** Mirror each pane's vertical scroll offset to
+  the other two with a re-entrancy guard. Aligned/virtual-space scroll + bezier connector
+  curves are a deferred stretch.
+- **Seam + existing VM tests preserved.** Keep `MergeConflictBlock` with its
+  `AcceptOurs/Theirs/Both/Base` commands and `MergeFile.Compose`; keep
+  `Current`/`CurrentIndex`/`Next`/`Previous` repurposed as the focused-conflict the top
+  arrows jump to. New state (active file, readout) is additive.
+
+## Architecture
+
+### ViewModel (`ConflictResolverViewModel`, `ConflictModels.cs`)
+
+Unchanged seam: ctor, `OpenAsync`, `OpenForPlanningAsync`, `CloseRequested`,
+`Continue`/`Abort` (incl. planning routing), `CanContinue` gating, binary guard.
+
+Additive:
+- `ActiveFile` (`MergeFile`) + the switcher list (`Files`) + `SelectFileCommand`.
+- Per-active-file reconstruction exposed for the view and for tests:
+  `ActiveOursText`, `ActiveTheirsText`, `ActiveResultText` (result seeds unresolved =
+  Ours), plus an ordered list of conflict descriptors (the block + its segment index)
+  so the view can compute offsets/spans as it assembles each document.
+- Readout `PositionText` → `"{M} conflicts · {K} resolved"` (active file and/or total);
+  `CanContinue` stays "all files resolved AND no binary".
+- On switching files, block `Resolution` persists (state lives on `MergeConflictBlock`),
+  so progress survives navigation; the view rebuilds documents from the active file.
+
+### View (`Views/Conflicts/ConflictResolverView.axaml` + `.cs`)
+
+- AXAML: ModalShell host (kept), header (prev/next arrows, file switcher, readout),
+  `Grid` of three bordered panes with headers, two between-pane overlay Canvases,
+  footer (Continue/Abort), binary banner, `Escape`→Abort. Drop the Base column.
+- Code-behind builds three `TextDocument`s from `ActiveFile`'s segments, recording each
+  conflict's line span per document; installs TextMate by file extension on all three;
+  rebuilds on file switch; pushes result-pane edits back into the active block's
+  `Resolution` and flips resolved.
+- `IReadOnlySectionProvider` on the Result `TextArea` (stable = read-only, conflicts =
+  editable) backed by a `TextSegmentCollection` of the conflict result-spans.
+- One `IBackgroundRenderer` per pane painting unresolved-conflict (red), resolved
+  (green/muted), and ours/theirs side tints, driven by the recorded spans + block state.
+- Overlay accept controls positioned at each block's `TextView` visual top; click →
+  `block.AcceptOurs/AcceptTheirs` and the code-behind replaces the tracked result span.
+- Proportional synced vertical scroll across the three panes.
+
+### Localization / tokens
+
+- New `conflictResolver.*` keys (pane headers, readout, accept tooltips) in
+  `en.json` + `de.json` (parity enforced by Localization.Tests).
+- Block colors from `Tokens.axaml` (reuse Blood/Moss/Accent tints; add tokens only if a
+  needed shade is missing).
+
+## Out of scope / fast-follow (not in this plan)
+
+- **Raw 3-way diff "N changes" parity (Option B):** a new worker method returning raw
+  `:1/:2/:3` blobs per conflicted file + DiffPlex client-side 3-way diff so
+  non-conflicting changes also appear as accept-able hunks. Seam-preserving; later.
+- **Intra-conflict word/line highlighting** (Rider's "Highlight words") via a line
+  transformer.
+- **Bezier connector curves + aligned / virtual-space synced scroll** (Red stretch).
+- No DB migration, no backend/seam changes, no push.

docs/superpowers/specs/2026-06-23-worker-log-footer-overlay-design.md

@@ -0,0 +1,49 @@
+# Worker log → footer auto-route + Log Visualizer overlay
+
+**Date:** 2026-06-23
+**Status:** approved (design forks resolved with user)
+
+## Goal
+
+1. Auto-route **all Worker WARN/ERROR** Serilog events to the footer status strip (today only ~10 hand-curated business events reach it).
+2. Make the footer log line **clickable** → opens a **Log Visualizer overlay** showing the **last 30 min** of logs at **all levels**, color-coded.
+3. **Dedupe/rate-limit** the footer so repeating warnings (e.g. the current 60s OIDC-discovery failure) don't strobe.
+
+## Decisions (locked)
+
+- **Overlay source:** Worker-side **in-memory ring buffer** (30-min window, all levels), fetched via a hub call. No log-file parsing.
+- **Levels:** overlay shows INF/WRN/ERR; footer flashes **WARN/ERROR only**.
+- **Footer noise:** per-message dedupe within a rate-limit window (suppress the footer broadcast for an identical message seen recently; the event is still buffered for the overlay).
+
+## Architecture
+
+### Worker
+
+- **`LogRingBuffer`** (singleton, `Logging/`): thread-safe, time-bounded (`TimeSpan` window, default 30 min) + hard cap (e.g. 5000) ring of `WorkerLogRecord(Message, Level, TimestampUtc)`. Evicts on append by age + cap. `Snapshot()` returns newest-last.
+- **`BroadcastLogSink : Serilog.Core.ILogEventSink`** (`Logging/`): for every `LogEvent` —
+  - map level: Verbose/Debug/Information→`Info`, Warning→`Warn`, Error/Fatal→`Error`;
+  - render `msg = evt.RenderMessage()` (+ `": {ex.GetType().Name}: {ex.Message}"` first-line if `evt.Exception != null`);
+  - append to `LogRingBuffer` (all levels);
+  - if `Warn|Error` **and** not rate-limited: fire-and-forget `HubBroadcaster.WorkerLog(msg, level, evt.Timestamp.UtcDateTime)`.
+  - **Loop guard:** wrap the broadcast in try/catch and swallow; skip broadcasting events whose `SourceContext` is SignalR/connections plumbing (still buffered). Broadcasting must never itself log.
+  - **Dedupe/rate-limit:** dict `message → lastBroadcastUtc`; suppress footer broadcast if `now - last < RateLimitWindow` (const, 120 s). Periodic prune of the dict.
+- **DI wiring (chicken-egg):** `LogRingBuffer` + `BroadcastLogSink` are created as locals in `Program.cs` *before* `builder.Build()`, captured into `UseSerilog(... .WriteTo.Sink(broadcastSink))`, and registered as singletons. `HubBroadcaster` doesn't exist until post-build, so the sink starts detached; after `builder.Build()` we call `broadcastSink.Attach(app.Services.GetRequiredService<HubBroadcaster>())`. Buffering works from process start; broadcasting begins once attached.
+- **Hub:** `WorkerHub.GetRecentLogs() -> IReadOnlyList<WorkerLogRecordDto>` reads `LogRingBuffer.Snapshot()`. (Read-only, no auth beyond existing hub.)
+
+### UI
+
+- **IWorkerClient / WorkerClient:** add `Task<IReadOnlyList<WorkerLogEntry>> GetRecentLogsAsync(CancellationToken ct = default)`. ⚠ Update hand-rolled fakes in **both** test projects (StubWorkerClient + Worker.Tests UiVm fake).
+- **Footer:** wrap the worker-log `TextBlock` so it's clickable (Button, transparent) → `IslandsShellViewModel.OpenLogVisualizerCommand`. Existing `OnWorkerLogReceived` already routes the (now more numerous) `WorkerLog` broadcasts to the strip — **no change needed** for footer routing itself.
+- **`LogVisualizerViewModel`** (Modals/): on open, `GetRecentLogsAsync()` → `ObservableCollection<LogLineViewModel>` (msg, level→brush, HH:mm:ss). A level filter (All / Warn+Err) and a Refresh command. MVP = snapshot on open + Refresh; live-tail is a later nicety.
+- **`LogVisualizerView`** (Modals/): `ModalShell`-based dialog (consistent with other modals), shown via `IDialogService.ShowLogVisualizerAsync(vm)`. Small, scrollable, monospaced, color-coded lines.
+- **Localization:** new `vm.logVisualizer` (+ any view keys) in **en.json + de.json** (parity test enforces).
+
+## Out of scope / follow-ups
+
+- Live-tail while the overlay is open (snapshot + Refresh for MVP).
+- The **OIDC-discovery-every-60s failure** is a *separate* bug (Online Inbox enabled, `auth.kuns.dev` SSL fails). Dedupe tames the footer symptom; the root cause is tracked separately.
+
+## Tests
+
+- Worker: `LogRingBufferTests` (age + cap eviction, snapshot order), `BroadcastLogSinkTests` (level mapping; all levels buffered; only Warn/Err broadcast; dedupe suppresses repeat broadcast within window but still buffers; exception rendering; loop-guard source filter).
+- UI: `LogVisualizerViewModelTests` (loads from worker, populates, filter). Footer-click wiring smoke.

docs/superpowers/specs/2026-06-25-interactive-ask-user-design.md

@@ -0,0 +1,102 @@
+# Interactive "Answer Claude's Questions" — Design
+
+**Date:** 2026-06-25
+**Status:** Approved (brainstormed with Mika)
+
+## Goal
+
+Let the user answer a question Claude raises *mid-run* from inside Mission Control,
+without leaving the autonomous-execution model. Not a chat panel, not a terminal, not
+proactive steering — only: *Claude surfaces a question → the user types an answer → the
+run continues with that answer in context.*
+
+User decisions (brainstorm):
+- Scope: "I mostly want to answer his questions if he surfaces any."
+- Trigger: **any running task** may ask, with a **3-minute** answer window.
+
+## Why not the alternatives
+
+- **Embedded terminal / PTY** — would destroy the NDJSON contract the whole worker
+  pipeline depends on (StreamAnalyzer, token accounting, auto-commit, status flow) and
+  needs a terminal-emulator control Avalonia doesn't have. Rejected.
+- **Streaming-stdin (`--input-format stream-json`)** — right tool for a free-form chat,
+  overkill here. Rejected for v1.
+- **`--resume` per-turn** — already exists; not live (cold process per turn).
+
+## Mechanism
+
+The in-task MCP already blocks the `claude -p` process while a tool call is in flight.
+That blocking *is* the pause. Add one in-task MCP tool, `AskUser(question)`:
+
+1. The tool resolves the caller task id, registers a pending question + a
+   `TaskCompletionSource<string>` in a singleton `PendingQuestionRegistry`, and
+   broadcasts `TaskQuestionAsked(taskId, questionId, question)`.
+2. Mission Control surfaces the question with an input box.
+3. The user answers → `WorkerHub.AnswerTaskQuestion` resolves the TCS → the tool
+   returns the answer as its result → Claude continues.
+4. No answer within **3 minutes** → the tool returns *"No response received within 3
+   minutes — proceed using your best judgment."* and the run carries on autonomously.
+
+### Key facts that make this work
+
+- **No persisted status change.** The task is still genuinely `Running` (process alive,
+  blocked mid-tool-call). "Waiting for input" is **ephemeral**: in-memory registry +
+  live SignalR events + a UI overlay. No `TaskStatus` enum value, no `TaskStateService`
+  transition, **no EF migration**. If the worker dies mid-wait, `StaleTaskRecovery`
+  flips the orphaned `Running` row to `Failed` like any interrupted run.
+- **`MCP_TOOL_TIMEOUT` must be raised.** Claude Code caps HTTP MCP tool calls at **60 s**
+  by default. The `claudedo_run` MCP is HTTP, so `ClaudeProcess` must set
+  `MCP_TOOL_TIMEOUT=200000` (≈3 min + margin) on the spawned process or the 3-min window
+  is silently truncated to 60 s.
+- **MCP wired for all runs.** Today `TaskRunner` only mints the run MCP for standalone
+  top-level tasks (for `SuggestImprovement`). To satisfy "any running task," move the
+  MCP-identity setup out of that gate so every `RunAsync` gets `claudedo_run`.
+  `AllowedTools` always includes `mcp__claudedo_run__AskUser`; `SuggestImprovement` stays
+  gated to improvement-eligible (standalone) runs.
+
+## Surface changes
+
+**Worker (mostly new files):**
+- `Runner/PendingQuestionRegistry.cs` (new, singleton) — `Register`, `TryAnswer`, `Get`,
+  `Remove`; one pending question per task.
+- `Runner/TaskRunMcpService.cs` (edit) — add `AskUser` `[McpServerTool]`; inject the
+  registry.
+- `Runner/TaskRunner.cs` (edit) — wire MCP identity for all runs; add `AskUser` to
+  allowed tools.
+- `Runner/ClaudeProcess.cs` (edit) — set `MCP_TOOL_TIMEOUT` env.
+- `Hub/HubBroadcaster.cs` (edit) — `TaskQuestionAsked`, `TaskQuestionResolved`.
+- `Hub/WorkerHub.cs` (edit) — `AnswerTaskQuestion`, `GetPendingQuestion` + DTO.
+- `Program.cs` (edit) — register `PendingQuestionRegistry` singleton.
+- System prompt (edit) — one line telling Claude the tool exists and to use it only when
+  a wrong guess would be costly/irreversible (otherwise proceed).
+
+**UI:**
+- `Services/IWorkerClient.cs` + `WorkerClient.cs` (edit) — `AnswerTaskQuestionAsync`,
+  `GetPendingQuestionAsync`, `TaskQuestionAskedEvent`, `TaskQuestionResolvedEvent`.
+- `ViewModels/Islands/TaskMonitorViewModel.cs` (edit, **hot file**) — pending-question
+  state, `AnswerDraft`, `SubmitAnswerCommand`, clear on finish/resolve.
+- `ViewModels/MissionControlViewModel.cs` (edit) — hydrate pending question on attach.
+- `Views/MissionControl/MonitorPaneView.axaml` (edit, **hot file**) — additive
+  question/answer banner above the terminal.
+- `Localization/locales/en.json` + `de.json` — `missionControl.question.*` keys.
+
+**Tests:** `PendingQuestionRegistry` (answer/timeout/unknown/overwrite), `AskUser` tool
+(answer + timeout fallback, fake broadcaster — no real Claude), `TaskMonitorViewModel`
+(surface/submit/clear). Update IWorkerClient fakes in both test projects.
+
+## Concurrency note
+
+Two files (`TaskMonitorViewModel.cs`, `MonitorPaneView.axaml`) are also being touched by
+a concurrent Mission Control drag-and-drop session on the shared main tree. Keep edits
+additive, commit explicit paths only (never `git add -A`).
+
+## Verification gaps (manual)
+
+1. **Real-Claude smoke test** — confirm a blocking `AskUser` call survives ≥3 min with
+   `MCP_TOOL_TIMEOUT=200000` and that the model actually calls the tool when uncertain.
+2. **Visual** — the question banner + input box in the pane (Mika does the visual pass).
+
+## Non-goals
+
+Free-form chat panel; proactive steering; tool-permission prompts (stays `auto`);
+`ContinueAsync`/resumed runs gaining `AskUser` (deferred follow-up).

docs/superpowers/specs/2026-06-25-mission-control-design.md

@@ -0,0 +1,144 @@
+# Mission Control — multi-task live monitoring
+
+Date: 2026-06-25
+Status: approved (design); implementation not started
+
+## Problem
+
+The UI can observe only **one** running task at a time. `DetailsIslandViewModel` is hard 1:1
+(single `Task`, single `_subscribedTaskId`); selecting another task in the middle pane *replaces*
+what Details shows. Yet the worker runs several tasks concurrently (`MaxParallelExecutions`) and
+already broadcasts every task's live output to all clients keyed by `taskId`. So the user cannot
+watch multiple in-flight sessions, and monitoring blocks normal work (adding tasks, reviewing).
+
+## Goal
+
+Watch several running tasks at once **without** giving up the normal app. Requirements drawn from
+the brainstorm:
+
+- A **live console grid** — multiple full Claude output streams side by side.
+- Each pane also shows **task details, blocking reasons**, and a **navigation helper** to open the
+  monitored task in the main app.
+- Lives in a **separate, always-available window** so the main window stays fully usable (adding
+  tasks must never be blocked). Combines "full window" + "detachable".
+
+## Non-goals
+
+- No worker/SignalR changes. The broadcast layer is already N-capable (`TaskMessage(taskId,line)`,
+  `TaskStarted/Finished/Updated`, `GetActive()`). This is a UI/VM-only feature.
+- No second SignalR connection. The new window shares the existing singleton `IWorkerClient`.
+- No new merge/review engine. Review/merge stays in the main window's Details pane; Mission Control
+  is read-mostly (monitor + cancel + navigate).
+
+## Hard constraint: no duplicated components or features
+
+This feature is an **extract-and-reuse** exercise, not a rebuild. The single biggest risk is
+forking a second live-streaming/parsing/status implementation. The reuse map below is binding.
+
+### Reuse map (what already exists — use it, do not copy it)
+
+| Concern | Existing asset | Location | How Mission Control uses it |
+|---|---|---|---|
+| Live console body (log list, LIVE/DONE/FAILED chip, auto-scroll) | `SessionTerminalView` (StyledProps `Entries`, `Label`, `IsRunning/IsDone/IsFailed`) | `Views/Islands/SessionTerminalView.axaml(.cs)` | Bind a pane's `Entries`→its `Log`, status flags + label. **No new console control.** |
+| Log line model | `LogLineViewModel` + `LogKind` | `ViewModels/Islands/DetailsIslandViewModel.cs` (top) | Shared model — move to its own file so both consumers reference one type. |
+| Live stream parse/replay | `OnTaskMessage` / `AppendStdoutLine` / `FlushClaudeBuffer` / `ReplayLogFileAsync` + `StreamLineFormatter` + `ExpandUserPath` | private in `DetailsIslandViewModel.cs` | **Extract to `TaskMonitorViewModel`** (Phase 1). One streaming engine, two consumers. |
+| Status state machine | `AgentState` + `Is*` flags + `StatusToStateKey` / `FinishedStatusToStateKey` | `DetailsIslandViewModel.cs` | Extract into `TaskMonitorViewModel`. |
+| Outcome / roadblock split | `ApplyOutcome` + `RoadblockMarker` constant | `DetailsIslandViewModel.cs` | Extract into `TaskMonitorViewModel`. |
+| Status chip / terminal styling | `live-chip`, `terminal`, `log-*` style classes | `Design/IslandStyles.axaml` | Reuse the classes as-is. |
+| Add a new task | `TasksIslandViewModel.AddAsync` (`NewTaskTitle`, user-list only, direct `TaskRepository`) | `TasksIslandViewModel.cs:406` | Optional quick-add reuses this path; **must not** introduce a second insert path. |
+| Live task list | `IWorkerClient.GetActive()` + `TaskStarted/Finished` events | worker hub / `WorkerClient` | Populate the grid; add/remove panes. |
+| DI / singletons | `IslandsShellViewModel`, `DetailsIslandViewModel`, `IWorkerClient` all singletons | `App/Program.cs` | Register `MissionControlViewModel` singleton; inject existing singletons. |
+
+## Design
+
+### TaskMonitorViewModel (the reusable core — new, but carved out of DetailsIslandViewModel)
+
+One instance == one monitored task. Owns:
+
+- `Log` (`ObservableCollection<LogLineViewModel>`), the filtered `TaskMessageEvent` subscription
+  (by `taskId`), stdout buffering, and NDJSON replay from disk on attach.
+- `AgentState` + `Is*` flags; `SessionOutcome` / `Roadblocks` (the outcome split).
+- Lightweight display: `Title`, `TaskIdBadge`, `Model`, `TurnsText`, `TokensFormatted`,
+  diff add/del, elapsed.
+- `BlockingReason` (string/visible flag) derived from existing data: `BlockedByTaskId`
+  (planning/child chain), `WaitingForReview` / `WaitingForChildren` status, and roadblock markers.
+- Commands: `OpenInApp`, `Detach`, `Cancel`.
+- `IDisposable` — unsubscribes all worker events (mirror DetailsIslandViewModel.Dispose).
+
+`DetailsIslandViewModel` is refactored to **own one `TaskMonitorViewModel` (`public Monitor`)** and
+delegate streaming/status/outcome to it. Its heavy concerns (subtasks, attachments, editing, merge
+cockpit, review verbs, child outcomes, notes/prep modes) stay put. **Phase 1 must be a no-behavior-
+change refactor** — all existing Ui.Tests stay green.
+
+> Binding-surface decision (Phase 1): repoint `WorkConsole.axaml`'s Output-tab bindings that
+> reference streaming/status (`Log`, `IsRunning/IsDone/IsFailed`, `SessionOutcome`, `TurnsText`,
+> diff text, `Model`) to `Monitor.*`. `x:DataType` stays `DetailsIslandViewModel`; compiled bindings
+> handle the nested path. Review/merge/session bindings are untouched. Prefer repointing over adding
+> ~15 forwarding properties (one source of truth, no boilerplate).
+
+### MissionControlViewModel (new)
+
+- `ObservableCollection<TaskMonitorViewModel> Monitors`, keyed by `taskId`.
+- On open: seed from `GetActive()`. On `TaskStarted`: add a monitor. On `TaskFinished`: keep the
+  pane (so the final output stays readable) but flip its state; a "clear finished" action prunes them.
+- Adaptive layout signal (column count) from `Monitors.Count`:
+  `1→1col, 2→2col, 3–4→2col(2 rows), 5+→fixed-width panes, horizontal scroll`. Least-active panes
+  beyond a threshold collapse to a compact card (title + last line + chip), click to expand — this is
+  the readability fallback so we never render N unreadable slivers.
+- Optional `QuickAdd` (deferred within Phase 2): title + target user-list → the **same** creation
+  path as `TasksIslandViewModel.AddAsync` (shared method, not a copy).
+- Disposes every monitor on window close.
+
+### Windowing (new plumbing — thin)
+
+- `MissionControlWindow` (Avalonia `Window`) hosting `MissionControlView`; DataContext =
+  the singleton `MissionControlViewModel`.
+- No non-modal secondary-window precedent exists (all current dialogs use `ShowDialog(owner)`), so
+  this is genuinely new but small:
+  - Set `desktop.ShutdownMode = OnMainWindowClose` in `App.OnFrameworkInitializationCompleted` so
+    closing Mission Control never quits the app, and closing the main window does.
+  - Open via a **title-bar button in MainWindow** (toggle: show / focus-if-open). The window is
+    created lazily and hidden (not destroyed) on close so its monitors persist cheaply.
+  - Persist size/position (reuse the ui.config.json mechanism if present; otherwise defer).
+
+### MonitorPaneView (new view, reuses SessionTerminalView)
+
+```
+┌─ #142  Refactor auth module ───────── ● running ─┐   header: title, live chip, tok/turn/elapsed
+│  ⏱ 4m12s   ◆ 18.3k tok   ↻ turn 6                 │
+├───────────────────────────────────────────────────┤
+│ ⚠ Blocked: waiting on #141 (planning parent)      │   blocking banner (visible only when blocked)
+├───────────────────────────────────────────────────┤
+│  <SessionTerminalView Entries={Log} .../>          │   the REUSED console
+├───────────────────────────────────────────────────┤
+│  [↗ Open in app]   [⧉ Detach]   [✕ Cancel]        │   footer
+└───────────────────────────────────────────────────┘
+```
+
+### Navigation helper "Open in app" (new shell method)
+
+No select-by-id exists today. Add `IslandsShellViewModel.RevealTaskAsync(taskId)`:
+1. resolve the task's list, set `Lists.SelectedList`; 2. await `Tasks.LoadForList`; 3. find the row in
+`Tasks.Items` by id, set `Tasks.SelectedTask` (→ `Details.Bind`); 4. bring MainWindow to front.
+`TaskMonitorViewModel.OpenInApp` calls this. Single navigation entry point — no duplicate selection logic.
+
+### Detach (Phase 3)
+
+`Detach` moves a `TaskMonitorViewModel` out of the grid into a small `TaskMonitorWindow`
+(reuses `MonitorPaneView`), optionally always-on-top; closing it re-docks. Lowest priority.
+
+## Risks / open items
+
+- **Phase 1 binding repoint** is the main risk: a missed `WorkConsole` binding shows as a blank
+  field, not a build error. Mitigation: Ui.Tests + a manual visual pass on the Details pane.
+- **Localization parity** (Localization.Tests): every new visible string needs en + de keys under a
+  `missionControl.*` namespace.
+- **Quick-add coupling** across windows is the weakest part; kept optional/deferrable.
+- Detached windows = most plumbing, least daily payoff → Phase 3, last.
+
+## Verification
+
+- Build `ClaudeDo.App` + run Ui.Tests / Localization.Tests after each phase.
+- Manual visual pass (cannot be auto-verified): Details pane unchanged after Phase 1; grid populates
+  with 2+ concurrent tasks, blocking banner shows, Open-in-app surfaces the task, adding a task in the
+  main window works while Mission Control is open.

docs/superpowers/specs/2026-06-26-in-app-interactive-sessions-design.md

@@ -0,0 +1,147 @@
+# In-App Interactive Sessions — Design
+
+**Date:** 2026-06-26
+**Status:** Proposed (awaiting approval)
+
+## Goal
+
+Replace the external Windows-Terminal "Run interactively" session with an **in-app
+streaming chat**, rendered in the existing `SessionTerminalView` in **both task detail and
+Mission Control**. Keep everything inside the app — no `wt.exe` pop-out. Autonomous task
+execution is **untouched** (stays one-shot, non-interactive).
+
+## Decisions (brainstorm)
+
+1. **Engine: persistent streaming session.** One `claude` process kept alive with
+   `--input-format stream-json`; user messages pushed over stdin.
+2. **Scope: interactive sessions only.** The autonomous `TaskRunner`/`ClaudeProcess` run
+   loop, review, queue, and worktree machinery are NOT changed.
+3. **Placement: shared `SessionTerminalView`** — the in-app session + composer appear in the
+   task-detail session surface and in the Mission Control monitor pane.
+4. **Full replace.** "Run interactively" now opens the in-app session; the
+   `WindowsTerminalLauncher.LaunchInteractiveAsync` path is removed. **Planning** sessions
+   keep using `wt` (untouched).
+5. **Send semantics: interrupt + redirect** mid-turn (control protocol), with automatic
+   *queue-for-next-turn* fallback if interrupt is unavailable.
+
+## What an interactive session is (unchanged semantics, new transport)
+
+Today (`PlanningSessionManager.OpenInteractiveAsync` + `WindowsTerminalLauncher`):
+`claude --model <PlanningAlias> --permission-mode auto "<task title+description>"` in the
+**list's working dir**, env `MAX_THINKING_TOKENS=20000`, full default toolset, relies on the
+globally-registered `claudedo` MCP. **Ephemeral** — no worktree, no `task_run` record, no
+status change, no review.
+
+We keep all of that. Only the transport changes: instead of a `wt` window, the same
+`claude` invocation runs as a persistent stream-json process owned by the worker, its output
+streamed into the app and its stdin fed from an in-app composer.
+
+> Honest tradeoff: the `wt` terminal gave the full Claude Code TUI (slash-command UX,
+> interactive prompts). An in-app stream-json chat is plainer — type messages, watch streamed
+> output. `--permission-mode auto` means no blocking permission prompts (so headless works),
+> but it is a simpler surface than the real TUI. Accepted per the "full replace" decision.
+
+## The streaming engine
+
+Flags: `--model <PlanningAlias> --permission-mode auto --input-format stream-json
+--output-format stream-json --verbose --replay-user-messages` in the list working dir, env
+`MAX_THINKING_TOKENS=20000`. No `--mcp-config`/`--allowedTools` (interactive uses the global
+MCP + default tools, exactly as today).
+
+- First stdin message = the seeded interactive prompt:
+  `{"type":"user","message":{"role":"user","content":[{"type":"text","text":"…"}]},"parent_tool_use_id":null}\n`
+  (stdin stays open).
+- A stdout read task forwards each NDJSON line to a callback (→ broadcast + the session's log)
+  and detects `result` events (turn boundary; the process then idles for the next message).
+- `SendUserMessageAsync(text)` writes a user-message JSON line; if a turn is in flight, also
+  `InterruptAsync()` (control-protocol interrupt) so Claude pivots immediately. If interrupt
+  is unavailable, the message lands when the current turn ends → automatic queue fallback.
+- **Interrupt is verified working** (spike, 2026-06-26, CLI 2.1.191). Exact shape:
+  `{"type":"control_request","request_id":"<id>","request":{"subtype":"interrupt"}}` — no
+  `initialize` handshake needed; `control_response {"subtype":"success"}` confirms
+  synchronously; the same process then accepts the redirect and runs a fresh turn with
+  context intact.
+- **Interrupt artifact:** the aborted turn emits a `result` with `is_error=true,
+  subtype="error_during_execution"`. The session must treat an interrupt-induced result as
+  *"turn aborted, continue"* (drain the queued redirect), **not** as a session failure.
+  Tolerate the incidental `system:init`/`system:status`/`rate_limit_event`/hook events that
+  also appear in the stream.
+- `--replay-user-messages` echoes each sent message back on stdout as a `user` event, so it
+  rides the existing stream pipeline into the timeline (ordered + confirmed) with no extra
+  broadcast surface.
+- The session ends only when the **user stops it** (kill the process tree) — an interactive
+  session has no auto-finalize and never enters review. No queue slot is involved (it is
+  launched directly, not via the autonomous picker).
+
+## Surface changes
+
+**Worker**
+- `Runner/StreamingClaudeSession.cs` (new) — persistent process + send/interrupt/stop; reuse
+  the `ProcessStartInfo` shape + `MCP_TOOL_TIMEOUT` from `ClaudeProcess`; streams via a line
+  callback; `IsTurnInFlight`. Cancellation kills the tree.
+- `Runner/LiveSessionRegistry.cs` (new, singleton) — `taskId → StreamingClaudeSession`
+  (`Register`/`TryGet`/`Unregister`/`Stop`), mirrors `PendingQuestionRegistry`.
+- `Planning/InteractiveSessionService.cs` (new) — owns interactive lifecycle: `StartAsync(
+  taskId)` resolves the list working dir + seeded prompt (reuse `OpenInteractiveAsync`'s
+  body), spawns the session, registers it, wires output to `HubBroadcaster.TaskMessage`,
+  broadcasts `InteractiveSessionStarted`; `SendAsync(taskId, text)`; `StopAsync(taskId)` →
+  `InteractiveSessionEnded`.
+- `Planning/WindowsTerminalLauncher.cs` + `Planning/Interfaces/ITerminalLauncher.cs` — remove
+  `LaunchInteractiveAsync` (+ `InteractiveLaunchContext`). Planning start/resume stay.
+- `Hub/WorkerHub.cs` — `OpenInteractiveTerminalAsync` re-pointed to
+  `InteractiveSessionService.StartAsync` (no terminal); add `SendInteractiveMessage(taskId,
+  text)`, `StopInteractiveSession(taskId)` (+ optional `InterruptInteractiveSession`).
+- `Hub/HubBroadcaster.cs` — `InteractiveSessionStarted(taskId)`,
+  `InteractiveSessionEnded(taskId)`. Log lines reuse the existing `TaskMessage(taskId, line)`.
+- `Program.cs` — register `LiveSessionRegistry` + `InteractiveSessionService`.
+
+**UI**
+- `Views/Islands/SessionTerminalView.axaml(.cs)` — add an optional composer (styled
+  properties: `IsComposerVisible`, `ComposerText`, `SubmitCommand`, `ComposerPlaceholder`).
+  Both hosts (task detail + Mission Control) get it by binding their VM's composer state.
+- `StreamLineFormatter` — render `type:"user"` NDJSON events as a `LogKind.User` bubble.
+- A small shared composer concept on `TaskMonitorViewModel` **and** `DetailsIslandViewModel`
+  (factor a helper to avoid duplication): `ComposerDraft`, `SubmitComposerCommand`,
+  `IsInteractiveLive` (set by `InteractiveSessionStarted/Ended`). Submit →
+  `SendInteractiveMessageAsync`; clear draft. (If a pending AskUser question exists, the same
+  composer answers it — keep the existing answer route.)
+- `MissionControlViewModel` — `EnsureMonitor(taskId)` on `InteractiveSessionStarted` so the
+  session appears as a monitor; mark it interactive.
+- `Services/Interfaces/IWorkerClient.cs` + `WorkerClient.cs` — `SendInteractiveMessageAsync`,
+  `StopInteractiveSessionAsync` (+ optional interrupt); events
+  `InteractiveSessionStartedEvent`/`InteractiveSessionEndedEvent`. `OpenInteractiveTerminalAsync`
+  keeps its name/signature (now starts the in-app session). Update hand-rolled fakes in **both**
+  test projects (`iworkerclient_fakes_sync`).
+- `TasksIslandViewModel.RunInteractivelyAsync` — unchanged call site; now opens/focuses the
+  in-app session surface instead of a terminal.
+- Localization `interactive.*` / `missionControl.chat.*` (en/de, parity enforced).
+
+**Tests**
+- `StreamingClaudeSessionTests` (fake process stream, no real Claude): first message streams;
+  `result` idles; a sent message starts another turn; mid-turn send calls `InterruptAsync`
+  then delivers; interrupt-failure degrades to queue; stop kills.
+- `LiveSessionRegistryTests` — register/get/unregister/stop.
+- `InteractiveSessionServiceTests` — start resolves working dir + seeds prompt + registers +
+  broadcasts started; send routes to the session; stop broadcasts ended (fake session +
+  broadcaster).
+- `TaskMonitorViewModelTests` / `DetailsIslandViewModelTests` — composer enabled while
+  interactive-live; submit invokes client + clears; `user` line renders; question route still
+  answers.
+
+## Risks / open questions
+
+- **Interrupt protocol shape — RESOLVED** (spike 2026-06-26, see "The streaming engine").
+  Mid-turn interrupt works on CLI 2.1.191 with the documented shape; the queue fallback is a
+  genuine fallback now, not the expected path. Re-verify if the CLI version changes.
+- **Plainer than the TUI** — slash-command/interactive-prompt UX differs (accepted).
+- **Auto-mode editing the list working dir directly** (no worktree) — this is the *existing*
+  interactive behavior, unchanged here.
+- **No real-Claude tests** (project rule) — the live loop is covered only by the fake stream;
+  real interrupt/redirect is a **manual verification gap** to flag.
+
+## Non-goals
+
+- Changing autonomous task execution / review / queue / worktrees.
+- Interactive sessions producing run records, worktrees, or review (stays ephemeral).
+- Worktree isolation for interactive edits; image/attachment messages in the composer.
+- Removing planning's `wt` terminal launch.

docs/superpowers/specs/2026-07-03-session-skills-design.md

@@ -0,0 +1,169 @@
+# Session Skills — Design
+
+**Date:** 2026-07-03
+**Status:** Approved (design), implementation not started
+
+## Problem
+
+Mika wants to give headless task agents a specific Claude skill (e.g.
+[ponytail](https://github.com/DietrichGebert/ponytail)) **without** installing it
+globally in `~/.claude/skills/`, where it would leak into every interactive session.
+Skills should be a first-class, per-level session setting alongside `model`,
+`max_turns`, and `system_prompt` — configurable **global / per-list / per-task** — and
+sourced from a GitHub URL.
+
+## Key facts that shape the design
+
+- The Claude CLI discovers skills from two places: the **global** `~/.claude/skills/`
+  (every session — undesirable here) and the **working directory's** `.claude/skills/`
+  (plus plugins). ClaudeDo fully controls each spawned session's `WorkingDirectory`
+  (`ClaudeProcess.cs:30`), so a skill dropped into the session cwd is scoped to exactly
+  that headless run.
+- **Auto-commit uses `git add -A`** (`WorktreeManager.CommitIfChangedAsync` →
+  `_git.AddAllAsync`, `WorktreeManager.cs:142`). Anything seeded into a worktree's
+  `.claude/skills/` would be committed unless explicitly excluded → the seeder must add
+  the seeded paths to the worktree's `info/exclude`.
+- A skill is not just prompt text: `SKILL.md` may reference scripts that run via Bash.
+  Headless agents run with `--permission-mode auto` (effectively unattended), so a skill
+  pulled from an arbitrary URL is **unattended third-party code execution**. This is why
+  install is a deliberate, pinned, reviewable step — not a live per-run URL fetch.
+
+## Decisions (locked)
+
+1. **Install-and-pin, not live fetch.** A dedicated registry screen installs a skill
+   once: clone the repo, pin to the current commit, store locally. Per-level config then
+   references installed skills **by name** (checkboxes), never a URL.
+2. **Three levels, additive union.** Effective skill set = `global ∪ list ∪ task`.
+   (Unlike `model`/`prompt`, which override — skills add up. Trade-off accepted: an
+   inherited skill can't be switched off for a single task in the MVP.)
+3. **A repo can contribute multiple skills.** Installer detects the layout:
+   - `skills/*/SKILL.md` (plugin bundle) → import **each** subskill flat. This is
+     ponytail: it ships 6 skills (`ponytail`, `-help`, `-review`, `-audit`, `-debt`,
+     `-gain`) under `skills/<name>/SKILL.md` plus `.claude-plugin/`, hooks, commands, an
+     MCP — none of which we consume; we take only the `skills/<name>/` dirs.
+   - root `SKILL.md` → single skill.
+   - neither → reject.
+   The CLI expects `.claude/skills/<name>/SKILL.md` **flat**, so subskills are flattened
+   on install. Selection is **per individual skill name** (enable just `ponytail` +
+   `ponytail-help` if you want, not all six).
+4. **Public repos only** (plain `git clone` over HTTPS, no auth) for MVP.
+
+> **Correction (2026-07-03, from the smoke test):** the original "one repo = one skill
+> at root" MVP was wrong for the very target repo — ponytail is a multi-skill plugin.
+> Decision 3 above replaces it.
+
+## Architecture
+
+### Storage & registry
+
+- Each discovered skill is copied **flat** to `~/.todo-app/session-skills/<name>/` (its
+  own self-contained dir with `SKILL.md` at the root of that dir), so the seeder just
+  copies `<name>/` → cwd.
+- New DB table `session_skills`, one row **per skill** (a multi-skill repo writes N rows
+  sharing `source_url` + `pinned_ref`): `name` (PK), `source_url`, `pinned_ref` (commit
+  SHA), `subpath` (dir within the repo the skill came from, e.g. `skills/ponytail` or
+  `.` for root), `description`, `added_at`. Repo-level ops act on all rows with the same
+  `source_url` (no separate sources table — keep it flat).
+- New worker service `SessionSkillRegistry` (in a new `Skills/` area under the Worker):
+  - `InstallAsync(url)` — clone to temp → **detect layout** (`skills/*/SKILL.md` bundle
+    vs root `SKILL.md`) → for each discovered skill parse frontmatter (`name`,
+    `description`), resolve HEAD SHA as `pinned_ref`, copy its dir flat into place, upsert
+    a row. Returns the list of installed skill names. Name collision (a skill name from a
+    *different* source) → error surfaced to UI; reinstalling the same source updates.
+    Clone is injected (`IRepoCloner`) so tests use a local source dir — **no real network,
+    no real CLI**.
+  - `UpdateAsync(sourceUrl)` — re-clone, re-detect, refresh that source's skills +
+    `pinned_ref`.
+  - `RemoveAsync(sourceUrl)` — delete all its skill dirs + rows.
+  - `ListAsync()` — registry entries for the UI (grouped by source for display).
+
+### Resolution
+
+`TaskRunner.ResolveConfigAsync` (`TaskRunner.cs:488`) already merges
+task → list → global for the other fields. Add:
+
+```
+SkillNames = Union(task.SessionSkills, listConfig?.SessionSkills, global.SessionSkills)
+```
+
+deduped, filtered to names that still exist in the registry (a removed skill is silently
+dropped — logged). Add `IReadOnlyList<string> SkillNames` to `ClaudeRunConfig`
+(`ClaudeArgsBuilder.cs:5`). **No CLI flag is emitted** — skills are seeded on disk, not
+passed as args. `ClaudeArgsBuilder.Build` is unchanged for skills.
+
+Per-level storage: a nullable TEXT column `session_skills` (JSON array of names) on
+`tasks`, `list_config`, and `app_settings`.
+
+### Seeding
+
+New service `SessionSkillSeeder`, called by `TaskRunner` after the working dir is
+resolved and before `ClaudeProcess.RunAsync`:
+
+- For each resolved skill name, copy `~/.todo-app/session-skills/<name>/` →
+  `<cwd>/.claude/skills/<name>/` (overwrite → idempotent for resume/re-run).
+- If the cwd is a git worktree, append `/.claude/skills/<name>/` to the worktree's
+  `info/exclude` (path via `git rev-parse --git-path info/exclude`, so it targets the
+  per-worktree exclude), only if not already present. **Only the seeded subdirs are
+  excluded** — never blanket-exclude `/.claude/`, in case the target project commits its
+  own `.claude/`.
+- Sandbox runs (not a repo) skip the exclude step.
+- No separate cleanup: seeded dirs vanish with the worktree/sandbox.
+
+### allowedTools caveat
+
+`--allowedTools` is only emitted when set (`ClaudeArgsBuilder.cs:80`); normal task runs
+leave it null → all tools allowed → the `Skill` tool is available. If a future per-task
+allowedTools restriction is added, it must include `Skill`. Noted, not handled in MVP.
+
+## UI
+
+Mirror the existing agent-file pattern.
+
+- **Registry screen ("extra mask"):** a new **Skills** tab in the Settings modal
+  (`SettingsModalView.axaml`) with `SessionSkillsSettingsTabViewModel`. **Add** (URL text
+  box → install a repo, which may yield several skills); lists installed skills grouped by
+  source (name, description, source, short ref); **Update** / **Remove** act per source
+  (repo). Status/error line like `FilesSettingsTabViewModel`.
+- **Global selector:** multi-select (checkbox list) of installed skills in the General
+  settings tab → `AppSettings.SessionSkills`.
+- **List + Task selectors:** add a skills multi-select to the shared
+  `AgentConfigEditor` control (`AgentConfigEditor.axaml` /
+  `AgentConfigEditorViewModel.cs`), which is already reused by both List settings and the
+  per-task flyout — one addition covers both levels, with the existing inheritance-badge
+  pattern.
+
+### Hub / client surface
+
+New `WorkerHub` methods + `IWorkerClient` entries (update hand-rolled fakes in both test
+projects — see memory `iworkerclient_fakes_sync`):
+`GetSessionSkills`, `InstallSessionSkill(url)`, `UpdateSessionSkill(sourceUrl)`,
+`RemoveSessionSkill(sourceUrl)`. Extend `AppSettingsDto`, `ListConfigDto`,
+`UpdateListConfigDto`, `UpdateTaskAgentSettingsDto` with the selected skill-name lists.
+New `SessionSkillDto`.
+
+## Edge cases
+
+- **Removed skill still referenced** by a level → dropped at resolve time, logged, no
+  failure.
+- **Name collision on install** → reject with a clear message; offer Update instead.
+- **Repo without root `SKILL.md`** → reject at install.
+- **Target project already has `.claude/skills/`** → additive copy; exclude only our
+  subdirs.
+- **Resume / re-run** reuses the worktree → re-seed overwrites, exclude append is
+  idempotent.
+
+## Verification (must-check, can't be unit-tested)
+
+- **Does `claude -p` actually load and invoke a skill placed in cwd `.claude/skills/`?**
+  **CONFIRMED 2026-07-03.** Mika ran, in a stable terminal, a `claude -p` invocation in a
+  scratch cwd holding `.claude/skills/ponytail*/SKILL.md`; the model invoked the
+  `ponytail-help` skill and returned its exact Lite/Full/Ultra table. Headless mode does
+  surface cwd skills → the whole approach holds; no `CLAUDE_CONFIG_DIR` fallback needed.
+- Seeded skill is **not** committed by the auto-commit step (worktree run).
+- Skill does not appear in a normal interactive session (no global leak).
+
+## Out of scope (MVP)
+
+Private-repo auth; consuming a plugin's *non-skill* parts (hooks, commands, MCP — we take
+only `skills/<name>/`); auto-update & update notifications; per-task *disabling* of an
+inherited skill; surfacing skill invocation in the run log.

docs/superpowers/specs/2026-07-23-conpty-interactive-sessions-design.md

@@ -0,0 +1,171 @@
+# ConPTY Interactive Sessions — Design
+
+Date: 2026-07-23
+Status: Approved (design), implementation not started
+
+## Problem
+
+The current in-app interactive session path streams `stream-json` from a
+`claude` process spawned **in the Worker** and renders it as a chat log with a
+composer. It does not surface permission requests, AskUser questions, and other
+TUI-native interactions well — the rendering is a partial reimplementation of
+what the real Claude Code TUI already does. We want full fidelity for
+interactive work without rebuilding the TUI.
+
+## Decision
+
+**Hybrid execution model:**
+
+- **Autonomous queue tasks** (`Status=Queued`, picked by the queue): unchanged.
+  Headless `stream-json`, full orchestration (status flow, diff, review, merge).
+- **Interactive sessions**: an **embedded ConPTY terminal** running the real
+  `claude` CLI, rendered in the **UI process**. Full TUI fidelity (permission
+  prompts, questions, colors, everything the standalone CLI does). Detached from
+  the review/merge/status machinery — these are a manual cockpit.
+
+This is the third direction for interactive (external `wt` terminal → streaming
+chat → embedded ConPTY). The streaming interactive stack is **removed**, not run
+in parallel — accepted as discarded work in exchange for one interactive path
+and full fidelity.
+
+## Architecture
+
+### Process location
+
+ConPTY terminal controls render in-process and spawn their child (`claude`) as a
+child of the host process. Therefore interactive sessions move **out of the
+Worker and into the UI process**. They no longer flow over SignalR. This mirrors
+the existing `ResumeTaskInTerminal` behavior (launch real `claude`), but embedded
+instead of via external `wt.exe`.
+
+### Worktree preparation (task-based sessions)
+
+Interactive task sessions get the **same worktree preparation as autonomous
+runs**: session-skills seeding, agent files, MCP config, environment. The Worker
+performs the prep and returns a launch spec to the UI:
+
+```
+LaunchSpec {
+  cwd:  string   // worktree path
+  exe:  string   // resolved claude executable / shell
+  args: string[] // e.g. --resume <sessionId>
+  env:  Dictionary<string,string>
+}
+```
+
+The command construction reuses `WindowsTerminalLauncher.BuildResumeArgs`/`Resolve`.
+Guards mirror `ResumeTaskInTerminal` for Running/Queued (rejected). Worktree
+handling (FINAL):
+- Existing Active/Kept worktree + persisted SessionId → `--resume <id>`.
+- No usable worktree but the list has a WorkingDir (git repo) → create a worktree
+  **on demand** via `WorktreeManager.CreateAsync` (the same path autonomous runs
+  use), then a fresh-start spec. This lets never-run tasks be opened interactively.
+- Fresh (non-resume) session → the task's prompt (title + description) is passed
+  as claude's positional prompt so the session starts on the task.
+- No worktree and no WorkingDir → clear error.
+Interactive sessions are detached: ClaudeDo does NOT record their claude session
+id (ConPTY is opaque, no stream-json), so resuming a specific past interactive
+conversation is only via claude's own `--continue`/`--resume` in the worktree dir.
+
+### Free / ad-hoc sessions
+
+In addition to task-based sessions, the user can open an ad-hoc terminal in a
+chosen directory (no task). These also get MCP config + env set up so the
+`claudedo` tools are available, but no per-level session-skills seeding tied to a
+task.
+
+### Terminal host control — RESOLVED by spike (2026-07-23)
+
+**Library: `Iciclecreek.Avalonia.Terminal` 2.0.3** (namespace `Iciclecreek.Terminal`).
+It needs Avalonia >= 12.0.2; the repo is on 12.0.4 → compatible, no bump.
+`SvcSystems.UI.Terminal` (latest) needs Avalonia 12.1+ → rejected.
+
+Visual pass (user, 2026-07-23): the real `claude` TUI renders correctly inside
+the embedded control — Claude Code opened and was usable.
+
+**Binding approach — use the library's own `LaunchProcess()` (FINAL).**
+An initial attempt drove `Porta.Pty` ourselves (own read loop, key tunneling via
+`GenerateKeyInput`/`GenerateCharInput`, manual resize) to bypass
+`LaunchProcess()` and inject a custom `PtyOptions.Environment`. That was a
+mistake: it rendered wrong, lagged, and dropped input. The spike had proven the
+library's own `TerminalControl.LaunchProcess()` pipeline renders correctly, stays
+responsive, and handles input/resize/focus. So `PtyTerminalSession` is a thin
+wrapper (`src/ClaudeDo.Ui/Services/PtyTerminalSession.cs`):
+
+- Set `control.Process = descriptor.Exe`, `control.Args = descriptor.Args`,
+  `control.StartingDirectory = descriptor.Cwd`, then `await control.LaunchProcess()`.
+- Relay the control's own `ProcessExited` event and `Kill()`.
+- `Process=""` stays on the AXAML `TerminalControl` to suppress the library's
+  auto-launch-on-load, so exactly one process starts (our manual launch).
+
+**Environment:** `LaunchProcess()` gives no per-launch env dict, but
+`Porta.Pty.SpawnAsync` inherits the *current process* environment. So apply
+`descriptor.Env` entries via `Environment.SetEnvironmentVariable(key, value)`
+(process scope) before `LaunchProcess()`. The only var needed is
+`MCP_TOOL_TIMEOUT`; session-skills/agent-files/MCP-config are on disk / globally
+registered, independent of env. (The earlier "child gets zero env vars" claim was
+wrong — Porta.Pty seeds from the process env.)
+
+**Sizing gotcha (critical):** the control derives Cols/Rows from
+`arranged-size / character-cell-size`. Without an EXPLICIT monospace font the cell
+metrics are wrong and the child TUI renders into the wrong area. Set
+`FontFamily="Cascadia Mono,Consolas,monospace"`, `FontSize`, `BufferSize`, and
+`HorizontalAlignment/VerticalAlignment=Stretch` on the `TerminalControl` (matching
+the spike) — this is what made rendering correct in the pane.
+
+**Lesson:** do not hand-roll pty/input/render around this control — use its
+`LaunchProcess()` pipeline.
+
+### Command Center layout
+
+- `MonitorPaneView` keeps the streamed log for autonomous tasks.
+- Interactive panes host the terminal control instead of the log+composer.
+- Layout is **toggleable**: focus mode (tabs, one session large) ↔ overview mode
+  (grid, several sessions at once).
+
+## Removals
+
+Worker:
+- `StreamingClaudeSession`, `InteractiveSessionService`
+- `WorkerHub` interactive methods: `OpenInteractiveTerminal`,
+  `SendInteractiveMessage`, `RemoveQueuedInteractiveMessage`,
+  `StopInteractiveSession`, `InterruptInteractiveSession`
+- Broadcast events: `InteractiveSessionStarted/Ended`, `InteractiveQueueChanged`,
+  `InteractiveMessageSent`
+- `IdleSessionReaper` and `LiveSessionRegistry` **iff** unused elsewhere
+  (verify during implementation — do not delete blindly).
+
+UI:
+- Composer on `TaskMonitorViewModel`: `ComposerDraft`, `SubmitComposerCommand`,
+  `InterruptInteractiveCommand`, `StopInteractiveCommand`, `QueuedMessages`,
+  `IsInteractiveLive`.
+- The composer + queued-messages portion of `SessionTerminalView` (the log
+  portion stays for autonomous panes).
+- `IWorkerClient` interactive methods.
+
+## Open items (implementation time)
+
+- Whether `LiveSessionRegistry` is referenced outside the interactive path.
+- Session-id availability for a never-run task (no `--resume` → start fresh).
+
+Resolved: env approach (see Terminal host control — add custom vars on top of the
+inherited process env via `PtyOptions.Environment`); library + binding seam.
+
+## Non-goals
+
+- No screen-scraping of terminal output back into task status/diff/review.
+- No change to the autonomous queue execution path.
+
+## Status (2026-07-23)
+
+Implemented on main (not pushed) and visually verified by the user (rendering,
+input, responsiveness correct after switching to `LaunchProcess()` + setting a
+monospace font). Done: worker launch-spec (task + ad-hoc, on-demand worktree,
+prompt seeding), UI terminal host, Command Center hosting (grid↔tabs), streaming
+stack removed. Permission mode: left to claude's default (not forced), per user.
+
+Deferred: **Avalonia 12.1 upgrade** — blocked, not adopted. 12.1's XAML source
+generator needs Roslyn 4.14 (.NET 9.0.3xx SDK); the repo pins .NET 8 in
+`global.json`, and bumping the SDK floor risks the Gitea Actions release build.
+Staying on Avalonia 12.0.x (Iciclecreek 2.0.3 works there). Revisit only with a
+deliberate SDK-floor decision.

docs/superpowers/specs/2026-07-24-conpty-planning-design.md

@@ -0,0 +1,61 @@
+# ConPTY Planning Sessions — Design (2026-07-24)
+
+**Task:** `5d627df8` — interaktive Planning-Session über embedded ConPTY statt externem `wt`-Fenster.
+
+## Problem
+Planning-Sessions (`StartPlanningSession`/`ResumePlanningSession`) öffnen heute ein externes
+Windows-Terminal (`WindowsTerminalLauncher` → `wt.exe`). Seit ConPTY existiert (embedded
+claude-TUI im UI-Prozess, Command Center), soll die interaktive Planning-Session denselben
+Weg nutzen: konsistente UX, keine externen Fenster.
+
+## Approved decisions (Brainstorm 2026-07-24)
+- **Env-Isolation:** Prozess-global akzeptiert (Sessions werden sequenziell per Klick geöffnet;
+  jedes claude-Child snapshottet Env beim Spawn). Keine Änderung an `PtyTerminalSession`.
+- **wt-Launcher:** Code bleibt; nur das Routing für Planning wird auf ConPTY umgestellt
+  (kein Rip-out von `LaunchPlanningStart/ResumeAsync`).
+- Planning-Kachel im Command Center (Mission Control), wie andere ConPTY-Sessions.
+  Finalize/Discard/Queue-Plan bleiben unverändert auf den bestehenden Buttons.
+
+## Change map
+
+### Worker
+1. `WindowsTerminalLauncher`: Planning-Start-Args in einen bare Builder
+   `BuildPlanningStartArgs(PlanningSessionStartContext) -> IReadOnlyList<string>` herausziehen
+   (analog `BuildResumeArgs`); `BuildPlanningStartCommand` nutzt ihn weiter (wt unverändert).
+   Resume-Args `BuildPlanningResumeArgs(sessionId) = ["--permission-mode","plan","--resume",id]`
+   (bisher inline in `LaunchPlanningResumeAsync`).
+2. `InteractiveLaunchSpecService`: `BuildPlanningStart(PlanningSessionStartContext) -> LaunchSpec`
+   und `BuildPlanningResume(PlanningSessionResumeContext) -> LaunchSpec` — resolve claude,
+   Args aus (1), Env `MAX_THINKING_TOKENS=20000` + `CLAUDEDO_PLANNING_TOKEN=<token>`
+   (+ `MCP_TOOL_TIMEOUT` wie interaktiv), Cwd = ctx.WorkingDir. Nimmt den Kontext (keine
+   Manager-Kopplung).
+3. Hub: `GetPlanningStartLaunchSpec(taskId) -> LaunchSpec` (ruft `_planning.StartAsync`,
+   broadcastet `TaskUpdated`, baut Spec; bei Fehler discard+rethrow wie heute),
+   `GetPlanningResumeLaunchSpec(taskId) -> LaunchSpec` (ruft `_planning.ResumeAsync`).
+
+### UI
+4. `IWorkerClient`/`WorkerClient`: `GetPlanningStartLaunchSpecAsync`/`GetPlanningResumeLaunchSpecAsync`
+   (mirror `GetInteractiveLaunchSpecAsync`).
+5. `MissionControlViewModel`: `OpenPlanningConPtySessionAsync(taskId, resume)` — dedupt nach
+   TaskId, holt die Planning-Spec, baut `TerminalLaunchDescriptor` → `ConPtyPaneViewModel`
+   (Titel „<task> (Planning)").
+6. `TasksIslandViewModel`: `OpenPlanningSessionAsync`/`ResumePlanningSessionAsync` (Resume-Zweig
+   der `UnfinishedPlanningModal`) öffnen die Planning-ConPTY-Kachel via neuem Event
+   `OpenPlanningConPtyRequested(taskId, resume)`, statt `StartPlanningSessionAsync`/wt.
+   `IslandsShellViewModel` verdrahtet das Event → `OpenMissionControl()` +
+   `MissionControl.OpenPlanningConPtySessionAsync`.
+
+### #12 (Nebenbefund)
+MCP-Permission-Prompt trotz `--allowedTools "mcp__claudedo__*"`: im interaktiven ConPTY vom
+User bestätigbar (kein Blocker wie headless). Beim Testen prüfen, ob der Glob den Prompt in
+der aktuellen CLI unterdrückt; falls nicht, allowedTools/`--permission-mode`-Kombi nachziehen.
+
+## Out of scope
+- Entfernen des wt-Codes / `ResumeTaskInTerminal`.
+- Per-Child-Env-Isolation in `PtyTerminalSession`.
+- Änderungen an Finalize/Discard/Queue-Plan-Lifecycle.
+
+## Verification
+- Build Worker + App (`-c Release`), Worker.Tests + Ui.Tests grün.
+- Visual (User): Planning-Start öffnet Command-Center-Kachel mit claude-TUI im Plan-Modus;
+  create_child_task erzeugt Draft-Kinder live; Resume greift die Session; kein wt-Fenster.

docs/superpowers/specs/2026-07-24-merge-helper-design.md

@@ -0,0 +1,182 @@
+# Merge Helper ("Let Claude handle it") — Design
+
+**Status:** Proposed — awaiting approval
+**Date:** 2026-07-24
+**Scope:** Feature — a per-list and global button that opens an **interactive ConPTY Claude session** pre-loaded with a set of user-selected tasks. The session (the "Merge Helper") drives each selected task to completion and merge autonomously via `mcp__claudedo__*` tools, asks the user interactively (in the ConPTY terminal) only when uncertain, resolves merge conflicts itself, and ends with a written summary of everything that changed.
+
+---
+
+## 1. Goal
+
+Collapse the repetitive per-task review→merge clicking into a single "Let Claude handle it" action. The user picks the tasks; an embedded Claude session babysits them — running the ones that still need running, reviewing diffs, merging the clean ones, resolving conflicts, and reporting back — while remaining fully interactive so the user can answer questions mid-run.
+
+This reuses the existing ConPTY infrastructure (UI-process embedded terminal) and the globally-registered `claudedo` MCP server. The only genuinely new worker capability is **MCP-driven conflict resolution** (§5), which today exists only in the UI hub.
+
+---
+
+## 2. Decisions (locked with user, 2026-07-24)
+
+| Question | Decision |
+|---|---|
+| Which tasks does the helper handle? | **Free choice, any status.** User hand-picks; helper acts per-status. |
+| How are tasks selected for a run? | **Checkbox dialog before launch** (candidates listed, user ticks). |
+| Merge authority / review-gate | **Auto-merge; asks interactively on uncertainty.** The app's per-task diff-gate is intentionally bypassed for helper-driven merges. |
+| Conflict handling | **Build MCP conflict tools** so the helper resolves conflicts in the working tree itself, asking only when unsure (Option B). The helper must handle **all** cases including parent/children unit merges; where the MCP path doesn't reach, **manual resolution by hand (Edit + git) is an accepted fallback** (user-confirmed 2026-07-24). |
+
+---
+
+## 3. UX Flow
+
+1. **Entry points**
+   - **Per-list:** context-menu item **"Let Claude handle it"** on each user-list row in `ListsIslandView.axaml` (alongside Settings / Worktrees / Open in Explorer).
+   - **Global:** one entry (footer of the lists island) that spans *all* lists/repos.
+2. Click opens the **Merge Helper selection dialog** (§4): a checkbox list of candidate tasks, grouped by list/repo, pre-filtered to tasks worth acting on but freely overridable.
+3. User ticks tasks → **"Let Claude handle it"** confirm button.
+4. UI asks the worker for a `MergeHelperLaunchSpec`, opens a **ConPTY tile in Mission Control** running the real `claude` TUI with the merge-helper prompt.
+5. The session works through the tasks, printing progress and asking questions inline; the user answers directly in the terminal.
+6. On completion Claude prints a **summary** (merged / skipped / conflicted / follow-ups). The tile stays open for review.
+
+---
+
+## 4. Selection Dialog
+
+New modal `MergeHelperSelectionDialog` (View + VM), built with the existing `TaskCompletionSource<T>` dialog pattern used by other modals.
+
+**Contents:**
+- Title: *"Let Claude handle it"* + subtitle naming the scope ("List: <name>" or "All lists").
+- A scrollable checkbox list of **candidate tasks**. Per row: checkbox, title, status badge, list/repo name (in global mode).
+- Grouping: by list/repo in global mode; flat in per-list mode.
+- Default selection: all **actionable** tasks pre-ticked — actionable = `WaitingForReview`, `Idle`, `Queued`, `Failed` (resettable). `Running` / `WaitingForChildren` shown but unticked (helper will poll them). Terminal `Done`/`Cancelled` excluded from the list entirely.
+- Footer: **"Let Claude handle it"** (disabled when nothing ticked) + **Cancel**. A "select all / none" affordance.
+
+**Candidate source:** `list_tasks` via the existing worker client (per list, or across all lists for global). No new query needed; the VM filters client-side by status.
+
+**Output:** an ordered `IReadOnlyList<string>` of selected task IDs (+ their list/repo mapping), passed to the launch request.
+
+---
+
+## 5. New Worker Capability — MCP Conflict Resolution
+
+Today (verified): `merge_task` / `review_task approve` call `TaskMergeService.MergeAsync(..., leaveConflictsInTree:false)` — on conflict they run `git merge --abort` (clean rollback, no markers) and return `mergeStatus="conflict"`; the task stays `WaitingForReview`. Continue/abort/write-resolution exist **only** on the SignalR hub (Rider merge editor). An MCP agent therefore cannot resolve conflicts. This section adds that.
+
+### 5.1 Approach
+
+Reuse the *exact* engine methods the UI already uses — `TaskMergeService.MergeAsync(leaveConflictsInTree:true)`, `ContinueMergeAsync`, `AbortMergeAsync` — and expose them over MCP. The helper resolves conflict markers on disk (it has filesystem access to the repo checkouts via `--add-dir`, see §6.3) and drives the merge state exclusively through MCP tools so the engine stays authoritative.
+
+### 5.2 MCP surface changes (`ExternalMcpService.cs`)
+
+1. **`review_task` / `merge_task` — new optional param `leaveConflictsInTree: bool = false`.**
+   When `true` and the merge conflicts: leave markers in the checkout instead of aborting, and return
+   `{ mergeStatus: "conflict_in_tree", conflicts: string[], repoPath: string }`
+   where `repoPath` is the checkout holding the markers. Task stays `WaitingForReview`, merge is in progress. Clean-merge behaviour is unchanged, so the helper can always pass `true`.
+
+2. **New tool `continue_merge(taskId)`** → `TaskMergeService.ContinueMergeAsync`.
+   Stages the resolved files and commits the merge; on success the task goes to `Done` and the worktree is marked merged, returning `{ merged: true, mergeCommit }`. If markers remain, returns `{ merged: false, conflicts: string[] }`.
+
+3. **New tool `abort_merge(taskId)`** → `TaskMergeService.AbortMergeAsync`.
+   Aborts the in-progress merge; task stays `WaitingForReview`. Returns `{ aborted: true }`.
+
+**Implementation notes (verify against `TaskMergeService.cs` during the plan):**
+- Confirm the exact signatures of `ContinueMergeAsync` / `AbortMergeAsync` and how in-progress-merge state is keyed. The hub tracks a single active conflict merge; the MCP variants must locate the merge from `taskId` (target branch + repo from the task/list), not shared hub state.
+- Emit the existing `TaskUpdated` event after continue/abort so the UI list re-buckets live.
+- Guard against a repo already mid-merge (`Blocked`) — surface it to the agent rather than clobbering.
+
+### 5.3 Parent/children unit merges
+
+`review_task approve` on a task **with children** drives `PlanningMergeOrchestrator` (a multi-step unit merge with its own continue/abort on the hub). The helper must handle these too. Two paths, tried in order:
+
+1. **MCP (preferred):** `continue_merge` / `abort_merge` detect *which* kind of in-progress merge the task has (single-task `TaskMergeService` vs orchestrated `PlanningMergeOrchestrator`) and route to the matching engine continue/abort. This keeps the orchestrated path engine-mediated over MCP too. Implement if the orchestrator's continue/abort can be located from the task without shared hub UI state (verify in A1).
+2. **Manual fallback (accepted):** where the MCP path genuinely can't reach an in-progress merge, the helper resolves the conflict markers on disk (Read/Edit) and completes the merge by hand (`git add <paths>` + `git commit`, or `git merge --continue`). The user has explicitly accepted hand-merging as a fallback. The system prompt still mandates: **prefer the MCP tools whenever they apply**; only drop to raw git for cases the MCP tools don't cover, and honour the shared-checkout rule (`git commit -- <paths>`, never a bare commit that sweeps peers' index).
+
+---
+
+## 6. Launch — Worker + Wiring
+
+### 6.1 Prompt templates
+
+Add `PromptKind.MergeHelper` (system) and `PromptKind.MergeHelperInitial` (brief) to `ClaudeDo.Data/PromptFiles.cs`, with built-in defaults and `{{token}}` rendering, mirroring `Planning` / `PlanningInitial`.
+
+- **System prompt** (`merge-helper-system.md`): defines the role and the per-status algorithm (§7), the merge/conflict rules, the "ask on uncertainty" posture, and the required final summary format.
+- **Initial brief** (`merge-helper-initial.md`): rendered with the selected tasks — a table of `{id, title, status, list, repo}` plus the scope label. Written to a session-brief file on disk; the positional prompt is a **single-line kickoff** pointing at that file via `--add-dir` (planning pattern — a multi-line positional prompt truncates at the first newline).
+
+### 6.2 Session files
+
+Path: `~/.todo-app/merge-helper-sessions/<sessionId>/` (a fresh GUID per run — these sessions are ephemeral and never resumed):
+- `brief.md` — rendered task list + scope + instructions.
+- No per-session MCP config: the session uses the **globally-registered `claudedo` MCP server** (same as task/ad-hoc sessions), so no token is needed.
+
+Cleanup: prune session dirs older than N days on app start (best-effort; same posture as planning dirs).
+
+### 6.3 Launch spec
+
+New `InteractiveLaunchSpecService.BuildForMergeHelper(selectedTaskIds, scope, ct)` returning a `LaunchSpec`:
+- **Cwd:** per-list → the list's repo working dir; global → the first selected task's repo (any valid repo; the agent works cross-repo via MCP).
+- **`--add-dir`:** the session-brief dir **plus every distinct repo checkout** among the selected tasks (so the agent can read/resolve conflict markers in each repo). Computed from each task's list working dir.
+- **Args:** `--permission-mode default`, `--allowedTools mcp__claudedo__*,Read,Grep,Glob,Edit,Bash,WebFetch,WebSearch,Skill`, `--append-system-prompt-file <merge-helper-system.md>`, `--add-dir ...`, then the single-line kickoff prompt.
+  - `Edit` is required for conflict resolution; `Bash` is allowed for **read-only** git inspection (`git status`/`diff`) — the system prompt mandates that all merge *state changes* go through MCP tools, never raw `git merge/commit`, to keep the engine authoritative and honour the user's rejection of the "raw git" option.
+- **Env:** `MCP_TOOL_TIMEOUT=200000` (as task/ad-hoc sessions set).
+
+### 6.4 Hub + client + Mission Control
+
+- **Hub:** `WorkerHub.GetMergeHelperLaunchSpec(string[] taskIds, string? listId)` → `_launchSpecService.BuildForMergeHelper(...)`. Sibling to `GetAdHocLaunchSpec` / `GetPlanningStartLaunchSpec`.
+- **Client:** `IWorkerClient.GetMergeHelperLaunchSpecAsync(...)` + `WorkerClient` impl.
+- **Mission Control:** `MissionControlViewModel.OpenMergeHelperConPtySessionAsync(spec)` — wraps the spec in a `TerminalLaunchDescriptor`, creates a `ConPtyPaneViewModel` (ad-hoc style, **never deduped** — each run is its own tile), adds it to `ConPtySessions`.
+- **Event plumbing:** `ListsIslandViewModel` raises `LetClaudeHandleRequested(scope)`; `IslandsShellViewModel` forwards to Mission Control, which opens the selection dialog, then (on confirm) fetches the spec and opens the tile.
+
+---
+
+## 7. Helper Behaviour (encoded in the system prompt)
+
+For each selected task, act by status:
+- **Idle / Queued:** `run_task_now`; poll `get_task` until terminal or `WaitingForReview`.
+- **Failed:** `reset_failed_task` then run, *or* ask the user — failures often need a human call; default to asking briefly.
+- **Running / WaitingForChildren:** poll `get_task` until it surfaces for review.
+- **WaitingForReview:** `get_task_diff` (stat first, then full if needed), sanity-check the change against the task's intent, then `review_task approve` with `leaveConflictsInTree:true`.
+  - **Clean →** merged, task Done.
+  - **Conflict (`conflict_in_tree`) →** open the conflicted files under `repoPath` (Read/Edit), resolve the markers guided by both sides' intent, then `continue_merge`. If the resolution is non-obvious or risky, **ask the user in the terminal** before continuing. `abort_merge` if the user declines or it's unsafe.
+- **Parent with children:** clean unit merge proceeds; on conflict, resolve via the MCP tools if they reach the orchestrated merge, else hand-merge the markers and complete it (§5.3) — asking the user first when the resolution is non-obvious.
+
+Cross-cutting rules (in the prompt):
+- Ask the user interactively for anything ambiguous, risky, or destructive — that is the point of the ConPTY session.
+- Never use raw `git merge/commit/reset`; drive all merge state through the MCP tools.
+- Keep a running tally; at the end print a **summary**: per task — final status, merge commit (if any), conflicts resolved, anything skipped, and suggested follow-ups.
+
+---
+
+## 8. Testing
+
+**Automated (`ClaudeDo.Worker.Tests`, real SQLite + real git):**
+- `review_task`/`merge_task` with `leaveConflictsInTree:true`: clean merge → Done; conflicting merge → `conflict_in_tree`, markers present in the checkout, task stays `WaitingForReview`.
+- `continue_merge`: after markers resolved on disk → commits, task Done, worktree merged; with markers still present → returns remaining conflicts.
+- `abort_merge`: in-progress merge aborted, markers gone, task stays `WaitingForReview`.
+- `continue_merge`/`abort_merge` on a task with no in-progress merge → clean MCP error, no clobber.
+- `TaskUpdated` fired after continue/abort.
+- `BuildForMergeHelper`: computes distinct repo `--add-dir` set, correct cwd per scope, brief file rendered with all selected tasks, allowed-tools string correct.
+
+**No real-Claude tests** (per project convention) — the end-to-end ConPTY run is a manual smoke item.
+
+**Manual (add to `docs/open.md`):**
+- ConPTY tile launches with the brief; MCP tools reachable; a clean multi-task run merges all and prints a summary.
+- A seeded conflict is resolved autonomously via `continue_merge`.
+- Interactive question round-trip (helper asks, user answers in terminal).
+- Global (multi-repo) run with `--add-dir` for each repo.
+- Selection dialog: grouping, default ticks, select-all/none, per-list vs global scope.
+
+---
+
+## 9. Phasing
+
+Delivered as one plan with three phases (see the plan doc). Phase A is independently useful and merges first.
+
+- **Phase A — Worker MCP conflict tools** (§5): `leaveConflictsInTree` param + `continue_merge` + `abort_merge` + tests. No UI.
+- **Phase B — Worker launch** (§6.1–6.4 worker side): prompt templates, `BuildForMergeHelper`, hub endpoint, session-file/brief generation, client method. Contract for C locked here.
+- **Phase C — UI**: selection dialog (View+VM), per-list + global entries, event plumbing, `OpenMergeHelperConPtySessionAsync`.
+
+---
+
+## 10. Out of scope (v1)
+
+- Resuming a merge-helper session (`--resume`); sessions are ephemeral.
+- A non-interactive/headless merge-helper (this is deliberately a ConPTY interactive session).
+- Cross-list *batching* semantics beyond "act on each selected task independently."
+- Any change to the existing per-task Approve/diff-gate flow.

docs/superpowers/specs/2026-07-27-list-handler-design.md

@@ -0,0 +1,191 @@
+# "Let Claude handle it" — per-list handler with read / dedupe / enhance / run / merge
+
+Date: 2026-07-27
+Supersedes parts of: `2026-07-24-merge-helper-design.md` (global scope, run-then-merge-only prompt)
+
+## 1. Problem
+
+The merge helper shipped in v2.3.0 with two entry points — a per-list context-menu item and a
+global footer Broom button — and a prompt that only runs and merges the selected tasks.
+
+Two things are wrong with that:
+
+- **The global scope is unwanted.** A run spanning several lists spans several repos, which
+  makes `cwd`, the `--add-dir` set and the merge order ambiguous for no benefit. The user
+  works one list (= one repo) at a time.
+- **The helper starts too late.** It takes the task list as given: it never reads the tasks as
+  a set, so duplicates run twice and produce conflicting worktrees, and vague tasks go into an
+  autonomous run under-specified and come back wrong.
+
+## 2. Goal
+
+One entry point, on a user list. It opens an interactive ConPTY session that takes the selected
+tasks through five phases: read them all, dedupe them, sharpen them for autonomous execution,
+run them, then review and merge each worktree.
+
+Non-goals: no change to the autonomous queue path, no change to the ConPTY tile plumbing,
+no rename of the `MergeHelper*` identifiers (the user-facing label stays "Let Claude handle it").
+
+## 3. Scope becomes list-only
+
+`listId` becomes non-nullable across the whole chain:
+
+| Layer | Change |
+|---|---|
+| `ListsIslandViewModel` | `MergeHelperRequest(string ListId, …)`; `LetClaudeHandleAllAsync` deleted |
+| `IslandsShellViewModel:241` | unchanged (already forwards `req.ListId`) |
+| `MissionControlViewModel:327` | `OpenMergeHelperConPtySessionAsync(string listId, …)` |
+| `IWorkerClient:90` / `WorkerClient:525` | `GetMergeHelperLaunchSpecAsync(taskIds, string listId, ct)` |
+| `WorkerHub:682` | `GetMergeHelperLaunchSpec(string[] taskIds, string listId)` |
+| `IInteractiveLaunchSpecService:36` | `BuildForMergeHelperAsync(taskIds, string listId, ct)` |
+
+Deleted UI surface:
+
+- Broom button `ListsIslandView.axaml:205-210` and `LetClaudeHandleAllCommand`.
+- `IsGlobal` on `MergeHelperSelectionModalViewModel` and the LIST column
+  (`MergeHelperSelectionModal.axaml:71`) — with a single list the column is constant.
+- Localization keys `lists.letClaudeAllTip`, `modals.mergeHelper.scopeAll`,
+  `modals.mergeHelper.columnList` (en + de, parity test enforces both).
+
+`Configure(string listId, string listName)` loses its nullable overload; `ScopeLabel` always
+renders `modals.mergeHelper.scopeList`.
+
+### 3.1 Single repo in the launch spec
+
+`BuildForMergeHelperAsync` currently collects a distinct `repoDirs` set across the selected
+tasks and picks `cwd` per scope. With a list scope every task shares the list's `WorkingDir`,
+so this collapses to:
+
+- Load the list; throw `InvalidOperationException` if it has no existing `WorkingDir`.
+- `cwd` = that directory; `--add-dir` = the session dir + that one directory.
+- The per-task brief line drops the now-constant `list:` and `repo:` fields.
+
+The context-menu item is already hidden when `WorkingDir` is empty, so the throw is a guard,
+not a normal path.
+
+### 3.2 Entry point visibility
+
+The item stays in the list row's context menu, next to "List settings", "Worktrees overview",
+"Open in Explorer" and "Open in Terminal". That is the established place for list-scoped
+actions; a second always-visible button in the row would break the pattern.
+
+## 4. Worker: `Cancelled` becomes externally settable
+
+`ExternalMcpService.UpdateTaskStatus` accepts only `Idle` and `Queued` and throws
+`"Status '{target}' is not settable externally. Use run_task_now or cancel_task."` for the
+rest — but neither escape hatch reaches an **Idle** task: `cancel_task` only cancels a
+*running* task, and `review_task(decision="cancel")` requires WaitingForReview/Running/Queued.
+The dedupe phase needs exactly that: retire an Idle duplicate without destroying it.
+
+Add to the switch:
+
+```csharp
+case TaskStatus.Cancelled:
+    var cancelResult = await _state.CancelAsync(taskId, DateTime.UtcNow, cancellationToken);
+    if (!cancelResult.Ok)
+        throw new InvalidOperationException(cancelResult.Reason ?? "Cannot cancel task.");
+    break;
+```
+
+`TaskStateService.CancelAsync` (`State/TaskStateService.cs:244`) already owns the transition
+and its worktree/parent side effects. The existing error message in `UpdateTaskStatus` already
+lists `Cancelled` as valid, so this also removes a lie. A cancelled task stays visible and can
+be reset to Idle — nothing is lost, unlike `delete_task`.
+
+## 5. The five-phase prompt
+
+`PromptFiles.MergeHelperDefault` is rewritten. The session stays interactive and the helper is
+told to ask whenever unsure — that is the point of a watched ConPTY session.
+
+### Phase 0 — Read
+
+`batch_get_tasks` over every id in the brief before touching anything: title, description,
+status, parent/child links. The helper must hold the whole set in mind before acting on any
+single task.
+
+### Phase 1 — Dedupe
+
+Compare the tasks pairwise for overlap. Emit a table of candidate pairs with the reason each
+pair looks like a duplicate, then **ask per pair**:
+
+- merge → fold the loser's unique content into the survivor via `update_task`, then
+  `update_task_status(loserId, "Cancelled")`;
+- keep both → note why and move on.
+
+Nothing is cancelled without an explicit answer.
+
+### Phase 2 — Enhance
+
+For each surviving task, sharpen title and description for autonomous execution:
+
+- concrete acceptance criteria,
+- the files/areas actually involved — grounded in the repo via Read/Grep/Glob, not guessed,
+- explicit out-of-scope.
+
+Write back with `update_task` (title / description / commitType are the settable fields; it
+refuses while Running, which cannot happen this early). Rules: do not change intent, do not
+invent requirements. A task too vague to sharpen safely gets a question, not a guess.
+
+### Phase 3 — Run
+
+`run_task_now` cannot be used for a batch: `OverrideSlotService.StartInSlot`
+(`Queue/OverrideSlotService.cs:65-70`) holds a single slot and throws `"override slot busy"`
+on the second concurrent call. The queue picker is the only parallel path.
+
+So: read `get_app_settings`, tell the user how many parallel slots are configured
+(`MaxParallelExecutions`, default 1 — `AppSettingsEntity.cs:14`), then
+`update_task_status(id, "Queued")` for every surviving task, then poll `get_task` until each
+has left Queued/Running — `WaitingForReview` on success, `Failed` on error. Announcing the
+slot count up front stops the user wondering why "run them all" executes one at a time.
+
+A task already `Running` or `WaitingForChildren` when the session starts is not re-queued, only
+polled. A task already `WaitingForReview` skips straight to Phase 4.
+
+### Phase 4 — Review and merge
+
+Sequential, in list order. A task that came back `Failed` needs human judgement — ask whether
+to `reset_failed_task` and re-queue it, or skip it. Otherwise, unchanged from the shipped
+prompt: `get_task_diff` (stat first,
+full diff when non-trivial), sanity-check against the task's intent, ask before merging
+anything that looks wrong, then `review_task(taskId, decision="approve",
+leaveConflictsInTree=true)` and the conflict loop (`continue_merge` / `abort_merge`, parent id
+for unit merges, hand-resolution only where MCP cannot reach, always
+`git commit -- <paths>` and never `git add -A` because the checkout is shared).
+
+New in this phase: the prompt states that because Phase 3 branches all fork from the same
+base, **conflicts are the normal case, not an exception** — resolve them rather than bailing
+out of the run.
+
+### Phase 5 — Summary
+
+One line per task: title — dedupe action — enhanced? — final status — merge commit —
+conflicts resolved. Then anything skipped and why, then follow-ups.
+
+### Brief template
+
+`MergeHelperInitialDefault` names the list and repo once in the header and drops the per-task
+`list:`/`repo:` fields, leaving `- [{status}] {title} (id: {id})`. Descriptions stay out of the
+brief; Phase 0 fetches them.
+
+## 6. Testing
+
+| Test | Change |
+|---|---|
+| `MergeHelperSelectionModalViewModelTests` | drop `IsGlobal`, list-scoped `Configure` |
+| `InteractiveLaunchSpecServiceTests` | three `null`-listId cases → non-null; drop the two-repo global-scope test; add "list without WorkingDir throws" |
+| `MissionControlViewModelTests` | four `OpenMergeHelperConPtySessionAsync(null, …)` calls |
+| `StubWorkerClient`, `TasksIslandViewModelPlanningTests` fake | signature |
+| `PromptFilesTests` | assert the five phase markers in the default prompt |
+| `Localization.Tests` | parity after removing three keys |
+| new: `ExternalMcpService` / worker test | `UpdateTaskStatus(id, "Cancelled")` cancels an Idle task; unknown status still throws |
+
+No test spawns the real `claude` CLI — the prompt content is asserted as text, the session
+itself is a manual smoke step.
+
+## 7. Verification left to the user
+
+- The list context menu shows "Let Claude handle it" only for lists with a working dir, and
+  the Broom button is gone from the footer row.
+- The selection dialog has no LIST column and reads "List: <name>".
+- A real ConPTY run: dedupe questions appear, enhancements land in the task descriptions,
+  queued tasks execute, merges complete or hand off to conflict resolution.

docs/superpowers/specs/2026-08-06-planning-chain-fork-base-design.md

@@ -0,0 +1,235 @@
+# Planning-Chain Children: Fork Base Commit (Design Options, No Implementation)
+
+**Date:** 2026-08-06
+**Status:** Options evaluated, recommendation given — decision pending (Mika)
+**Scope:** Analysis only. No production code changed by this document.
+
+## Problem
+
+The planning chain gives **ordering**, not **code inheritance**. `PlanningChainCoordinator.SetupChainAsync`
+(`src/ClaudeDo.Worker/Planning/PlanningChainCoordinator.cs:36-72`) links children via
+`BlockedByTaskId` (child[i] blocks on child[i-1]) so they run one at a time. But each child's
+worktree is still created from **main's current HEAD**, not from the predecessor's branch, so
+child N+1 never sees child N's (unmerged) work.
+
+**Observed failure (unit `44241dcb`, "Installer: Environment-Checks", 2026-08-05):** 7 of 9
+children succeeded; the two that depended on a sibling's output could not:
+
+- `4e196058` ("Claude Help Me" button) — reported: *"the task spec assumes an existing
+  SystemCheckPage/EnvironmentCheckReport/ExecutableResolver, but that code only exists on an
+  unmerged sibling branch (claudedo/06aca9b3...). A fast-forward merge of that branch was
+  attempted ... but was denied twice by the auto-mode permission classifier. No implementation
+  work was done."*
+- `c22cdd06` (Diagnose section) — *"Blocked before implementation could start."*
+
+Both correctly reported `CLAUDEDO_BLOCKED` and committed nothing (`ahead: 0`). A second-order
+symptom of the same root cause: `ExecutableResolver.cs` was independently created **twice**
+(`40272c0b`, `06aca9b3`, near-identical) and collided as an add/add conflict at unit-merge time.
+
+## Ist-Zustand (verified against commit `816f247`, 2026-08-06)
+
+### Where the base commit is chosen
+
+`WorktreeManager.ResolveBaseCommitAsync` — `src/ClaudeDo.Worker/Runner/WorktreeManager.cs:191-207`:
+
+```csharp
+private async Task<string> ResolveBaseCommitAsync(TaskEntity task, string workingDir, CancellationToken ct)
+{
+    if (task.ParentTaskId is not null)
+    {
+        var parent = ...;
+        if (parent is not null && parent.PlanningPhase == PlanningPhase.None)
+        {
+            var parentWt = await new WorktreeRepository(ctx).GetByTaskIdAsync(task.ParentTaskId, ct);
+            var parentHead = parentWt?.HeadCommit ?? parentWt?.BaseCommit;
+            if (parentHead is not null)
+                return parentHead;
+        }
+    }
+    return await _git.RevParseHeadAsync(workingDir, ct);   // planning children land here
+}
+```
+
+**A "don't fork from main" mechanism already exists** — but only for *improvement* children
+(a non-planning parent's own follow-up subtasks), which base off `task.ParentTaskId`'s worktree
+HEAD. The guard `parent.PlanningPhase == PlanningPhase.None` explicitly **excludes** planning
+children: their `ParentTaskId` points at the planning parent (which has no worktree of its own),
+not at a sibling, so this branch never fires for them and they fall through to `RevParseHeadAsync`
+= main HEAD. This is a deliberate exclusion in the existing code, not an oversight — it simply
+never anticipated that a planning child's *predecessor in the chain* (not its parent) might be
+the thing to inherit from.
+
+Called from `WorktreeManager.CreateAsync` (`:35`), invoked by `TaskRunner` (`Runner/TaskRunner.cs:309`)
+at the moment a task transitions to `Running` — i.e. worktree creation happens per-run, not once
+at plan-finalize time.
+
+### Children already run strictly sequentially — this is not a new constraint
+
+`SetupChainAsync` sets `BlockedByTaskId` on every child but the first
+(`Planning/PlanningChainCoordinator.cs:61-69`); the queue picker only claims rows with
+`BlockedByTaskId IS NULL`. `OnChildFinishedAsync` (`:92-120`) unblocks the successor **only**
+after the predecessor reaches `Done` (and cascades cancellation down the chain on
+Failed/Cancelled). `OverrideSlotService.RunNow` (`Queue/OverrideSlotService.cs:32-42`) is the one
+path that bypasses this — it calls `StartRunningAsync` directly with no `BlockedByTaskId` check,
+so a user can manually force a later child to run out of turn.
+
+Net: under the normal (queue-driven) path, by the time child N+1's worktree is created, child N
+is already terminal. Forking N+1 from N's branch tip instead of main's HEAD does **not** introduce
+any new concurrency constraint on the normal path — the sequencing already exists. It only matters
+for the `RunNow` bypass edge case (see Option 1 below).
+
+### The merge side already treats the unit as a sequential chain, twice over
+
+`PlanningMergeOrchestrator.DrainAsync` (`Planning/PlanningMergeOrchestrator.cs:183-229`) merges
+`Done` children into `targetBranch` **one at a time, in `SortOrder`**, via
+`TaskMergeService.MergeAsync`; the first conflict pauses the whole drain
+(`PlanningMergeConflict`, state kept for `ContinueAsync`/`AbortAsync`), and the first
+non-conflict failure **aborts the drain outright** — remaining children are never merged and the
+parent never reaches `Done` (`:208-215`).
+
+`PlanningAggregator.BuildIntegrationBranchAsync` (`Planning/PlanningAggregator.cs:81-126`) — used
+for the pre-approve combined-diff preview — does the same thing again: builds a scratch
+integration branch off `targetBranch` and `MergeNoFfAsync`s each child's branch in, in
+`SortOrder`, stopping at the first conflict.
+
+So **both** the actual unit-merge and its preview already model the child set as an ordered
+sequence where one bad link can stall everything downstream. The only place in the whole pipeline
+that still treats planning children as N independent forks of main is worktree creation.
+
+## Options evaluated
+
+### Option 1 — child forks from the predecessor's branch
+
+Extend `ResolveBaseCommitAsync` (or a planning-specific sibling of it) to also handle planning
+children: look up the chain predecessor via `BlockedByTaskId` (not `ParentTaskId` — that points at
+the planning parent, which has no worktree) and use its `WorktreeEntity.HeadCommit ?? BaseCommit`
+the same way the improvement-child path already does.
+
+**What actually breaks, given the Ist-Zustand above:**
+
+- *Not* a new concurrency constraint (see above) — the chain already serializes execution.
+- *Not* a new "one failure blocks everyone" behavior at merge time — `DrainAsync` already aborts
+  the whole drain on the first non-conflict failure, and the integration-branch preview already
+  stops at the first conflict. Option 1 brings execution-time behavior in line with what merge-time
+  behavior already is, rather than introducing a new failure mode.
+- **Genuinely new:** child N+1's branch now contains N's commits as ancestors. When N is later
+  merged into `targetBranch` with `--no-ff` and N+1 is merged afterward, N+1's diff against N's
+  content is empty (identical trees) — merges cleanly as a no-op for that slice, verified by the
+  same mechanism `DrainAsync` already uses. No new conflict class is introduced; if anything this
+  *removes* one: the `ExecutableResolver.cs` add/add collision would not have occurred, since N+1
+  would start from a tree that already has the file.
+- **Genuinely new edge case:** `OverrideSlotService.RunNow` on a chain member whose predecessor
+  hasn't produced a `WorktreeEntity`/`HeadCommit` yet. Needs an explicit fallback to main HEAD —
+  the same `?? ` pattern the improvement-child branch already uses for a predecessor with no
+  `HeadCommit` (never committed) covers most of this; a predecessor that was never even *run* needs
+  the same fallback-to-`RevParseHeadAsync` the code already falls through to today.
+- **Genuinely new edge case:** a discarded/failed predecessor's worktree row still carries its last
+  `HeadCommit`/`BaseCommit` (the row isn't deleted on discard, only `State` flips) — same as the
+  improvement-child path already tolerates, so no new handling needed there.
+- Children still go straight to `Done` with no individual review (Unified Parent Model), so there
+  is no "reject and rewrite a middle child after a successor already forked from it" scenario to
+  worry about — that action doesn't exist in the current state machine.
+
+**Price:** deeper branch chains (cosmetic — they're squashed away by the sequential merge/prune
+regardless); one new fallback path for the `RunNow` bypass. Meaningfully smaller than it first
+looks, because it extends an existing pattern (improvement children) into a lane whose execution
+and merge sides are *already* sequential — it only fixes the one place that wasn't.
+
+### Option 2 — merge predecessor to main immediately on success, before the successor starts
+
+Keeps children independent worktrees (forked from main-as-it-is-now, updated after each merge),
+but requires a real merge to `main` per child, outside of Approve.
+
+**Breaks:**
+
+- Directly contradicts the documented invariant "**Approve is the single review+merge action**"
+  (`src/ClaudeDo.Worker/CLAUDE.md` → Status Model; `docs/explore-notes/review-merge.md` → "Approve
+  = merge the whole unit"). Unreviewed work would land on `main` automatically, mid-chain, before
+  the parent — or the user — ever sees it.
+- Requires calling `TaskMergeService.MergeAsync` from `OnChildFinishedAsync` (state-transition
+  code), duplicating what `PlanningMergeOrchestrator` already owns, and doing it against a
+  `VerifyCommand`-gated repo N times instead of once — if the gate is configured, a mid-chain
+  verify failure now has to be handled somewhere there's currently no error path for it (parent is
+  still `WaitingForChildren`, not under merge orchestration yet).
+- Unavoidably touches `TaskStateService`/status-transition semantics, which this task's scope
+  explicitly excludes ("Die Status-Logik oder `TaskStateService` anfassen" is out of scope) — this
+  option cannot be implemented without doing exactly that.
+
+**Verdict:** rejected outright — it isn't just costly, it conflicts with a stated architectural
+invariant and this task's own non-goals.
+
+### Option 3 — child may merge the predecessor's branch into its own worktree if it needs to
+
+Least invasive to the base-commit mechanism; delegates the decision to the agent at runtime.
+
+**Breaks:**
+
+- This is *exactly* what the blocked child in the observed incident already tried, and it was
+  denied twice by the auto-mode permission classifier. The real blocker isn't a missing
+  capability, it's that `git merge` trips the classifier's "risky/hard-to-reverse" heuristic
+  regardless of target — even though a merge confined to the task's own isolated worktree (never
+  touching the shared `workingDir`) is materially lower-risk than a merge on a shared checkout.
+  Fixing this option means carving a narrower permission rule (allow `git merge` only inside a
+  path under the task's own worktree root), which is a security-policy change, not a merge-model
+  change.
+- Even with permission granted, it still relies on the agent (a) noticing it's missing a
+  prerequisite, (b) correctly identifying which sibling branch has it, and (c) successfully
+  resolving any conflict that surfaces — three separate failure points per occurrence, decided
+  fresh by an LLM each time rather than encoded once in the pipeline.
+- Doesn't help children that fail *before* they'd even think to look (e.g., a child whose first
+  action is reading a file that doesn't exist yet has no signal to act on).
+
+**Verdict:** possible as a narrow permission-scope fix layered *on top of* Option 1 (so an agent
+that still needs something from further back than its immediate predecessor isn't stuck), but not
+a substitute for it — on its own it reproduces the exact failure mode from the incident, just with
+one fewer denial.
+
+### Option 4 — change nothing; require independent children at planning time
+
+Zero code changes; pushes the constraint into plan quality.
+
+**Breaks:**
+
+- No enforcement exists today (`PlanningSessionManager` doesn't validate structural independence
+  between proposed subtasks), and reliably detecting "child B depends on code child A will write"
+  from a plan draft is itself an unsolved code-review problem — not something a prompt tweak
+  guarantees.
+- A shared-foundation-plus-N-consumers decomposition (exactly the `44241dcb` shape: environment
+  checks feeding two UI consumers) is often the *correct* decomposition, not a planning mistake.
+  Banning it either forces over-merging into one giant child (defeating the purpose of splitting)
+  or requires the planner to reject a structurally sound plan.
+- Reproduces the observed failure verbatim under the same conditions: nothing about this option
+  would have caught `44241dcb` before it shipped two dead children.
+
+**Verdict:** cheapest to write down, but doesn't fix the problem — it relocates it to "the plan
+looked independent but wasn't," which is what already happened.
+
+## Recommendation
+
+**Option 1**, with the `RunNow`-bypass fallback described above, and with Option 3's narrower
+permission-scope fix as an optional follow-up (not a prerequisite) for cases where a child needs
+something from further back in the chain than its immediate predecessor.
+
+**Why:** Option 1 is not a new mechanism — it's closing the one gap in a pattern that already
+exists twice in this codebase: `WorktreeManager.ResolveBaseCommitAsync` already forks improvement
+children from their parent's HEAD instead of main, and both `PlanningMergeOrchestrator.DrainAsync`
+and `PlanningAggregator.BuildIntegrationBranchAsync` already treat the child set as an ordered
+merge sequence where the first failure stalls everything after it. Planning-child worktree
+creation is the outlier, not the rule. Extending the existing predecessor-lookup pattern (keyed
+off `BlockedByTaskId` instead of `ParentTaskId` for this lane) makes the "sees predecessor's work"
+guarantee hold everywhere the chain already implies it, without touching `TaskStateService`, the
+review model, or introducing a merge-time failure mode that doesn't already exist. Options 2 and 4
+either conflict with a stated invariant/this task's own non-goals, or fail to address the incident
+at all; Option 3 alone reproduces the incident's exact failure.
+
+**Price to pay knowingly:** a chain member that never got a chance to run (no `WorktreeEntity` yet)
+needs an explicit main-HEAD fallback when its successor is forced via `RunNow` — a few lines,
+mirroring the null-coalescing fallback the improvement-child path already has. No other new failure
+surface was found.
+
+## Explicitly out of scope (per task)
+
+- Implementing Option 1 or any other option — Mika decides first.
+- Any change to `TaskStateService` or status-transition logic.
+- Changing blocked-child visibility/behavior — that's task `001ee94a`, running in parallel; it only
+  touches MCP visibility, no production code overlap with this document.

docs/superpowers/specs/2026-08-07-diff-side-by-side-design.md

@@ -0,0 +1,225 @@
+# Diff Viewer: Side-by-Side, Syntax Highlighting, Word Diff
+
+Date: 2026-08-07
+Status: approved (design), not implemented
+
+## Problem
+
+The diff viewer renders every change as a flat unified stream. Reading what actually changed
+inside a modified line means mentally aligning a `−` row with a `+` row several rows below it.
+The user reads diffs faster side by side.
+
+Three gaps, all in the same surface:
+
+1. No side-by-side mode.
+2. No syntax highlighting — the merge editor (`ConflictResolverView`) already has it via
+   TextMate, the diff viewer does not.
+3. No intra-line (word) highlighting, so a one-character change looks like a whole-line rewrite.
+
+## Current state
+
+| Concern | Where |
+|---|---|
+| Parsing | `src/ClaudeDo.Ui/ViewModels/Modals/UnifiedDiffParser.cs` → `DiffFileViewModel.Lines` |
+| Models | `src/ClaudeDo.Ui/ViewModels/Modals/DiffModels.cs` (`DiffLineViewModel{Kind,OldNo,NewNo,Text}`, `DiffLineKind{Add,Del,Ctx,File}`) |
+| Rendering | `src/ClaudeDo.Ui/Views/Controls/DiffLinesView.axaml` — non-virtualized `ItemsControl`, one `Border`+`Grid`+4 `TextBlock`s per line, `TextWrapping="NoWrap"` |
+| Host | `src/ClaudeDo.Ui/Views/Modals/DiffViewerView.axaml` — Files mode (line 154, `SelectedFile.Lines`) and Planning mode (line 162, flattened `DiffLines` across all files) |
+| Highlighting reference | `src/ClaudeDo.Ui/Views/Conflicts/ConflictResolverView.axaml.cs:80-83` — `RegistryOptions(ThemeName.DarkPlus)` + `InstallTextMate` + `SetGrammar` by file extension |
+
+`Avalonia.AvaloniaEdit`, `AvaloniaEdit.TextMate` and `TextMateSharp.Grammars` are already
+referenced in `ClaudeDo.Ui.csproj`.
+
+## Decision
+
+Replace `DiffLinesView` with an AvaloniaEdit-based control. TextMate highlighting is bound to
+the `TextEditor` control; it cannot be lifted into `TextBlock` inlines without reimplementing
+the scope→brush layer that `AvaloniaEdit.TextMate` already provides. Building split/wrap/word
+diff on the `TextBlock` model first and swapping the renderer later would be throwaway work.
+
+Side effect worth having: AvaloniaEdit virtualizes, which removes the current non-virtualized
+`ItemsControl` as a scaling limit on large diffs.
+
+Rejected: keeping the `ItemsControl` and hand-rolling highlighting from `TextMateSharp`
+tokenization — same output, materially more code, and a second highlighting path to maintain
+alongside the merge editor's.
+
+## Layout semantics
+
+Left pane is the **old** state, right pane is the **new** state — each side carries the complete
+version of the hunk, not "removals here, additions there".
+
+```
+        LEFT (old)                       RIGHT (new)
+   12  public void Save()            12  public void Save()
+   13      var x = 1;                13      var x = 2;      ← word diff on `1` / `2`
+   14      Log("old");                ·  (filler)
+    ·  (filler)                      14      Log("new");
+   15  }                             15  }
+```
+
+## Components
+
+### 1. `DiffAlignment` (new, pure)
+
+`src/ClaudeDo.Ui/ViewModels/Modals/DiffAlignment.cs`
+
+Turns `IReadOnlyList<DiffLineViewModel>` into a render-ready `AlignedDiff`. No Avalonia types,
+fully unit-testable.
+
+```csharp
+public enum AlignedSide { Ctx, Del, Add, Filler, Gap }
+
+public readonly record struct TextSpan(int Start, int Length);
+
+public sealed record SplitRow(
+    AlignedSide LeftKind,  int? OldNo, string LeftText,  IReadOnlyList<TextSpan> LeftSpans,
+    AlignedSide RightKind, int? NewNo, string RightText, IReadOnlyList<TextSpan> RightSpans);
+
+public sealed record UnifiedRow(
+    AlignedSide Kind, int? OldNo, int? NewNo, string Text, IReadOnlyList<TextSpan> Spans);
+
+public sealed record AlignedDiff(
+    IReadOnlyList<SplitRow> SplitRows,   string LeftText, string RightText,
+    IReadOnlyList<UnifiedRow> UnifiedRows, string UnifiedText);
+```
+
+Row index `i` maps to document line `i + 1` in the corresponding text. That mapping is the
+contract the margin and both renderers depend on.
+
+**Pairing.** Walk the lines. A `Ctx` run emits rows with the same text on both sides. A change
+block (a `Del` run followed by an `Add` run) pairs index-wise up to `min(delCount, addCount)`;
+the overhang gets `Filler` rows on the opposite side.
+
+**Gaps.** The parser drops `@@` headers, so a skipped region shows up as a jump in `OldNo`/`NewNo`
+between consecutive lines. `DiffAlignment` detects that jump and inserts a `Gap` row on both
+sides. The parser is not touched.
+
+**Word diff.** Only for `(Del, Add)` rows that are paired 1:1. Tokenize each side into runs of
+word characters / whitespace / single punctuation, run an LCS over the tokens, and emit the
+changed token runs as character spans per side.
+
+Two guards, both `const` and both covered by tests:
+- Skip when either side exceeds `MaxWordDiffChars = 2000` — LCS cost, and such lines are
+  unreadable as word diffs anyway.
+- Skip when token similarity is below `MinWordDiffSimilarity = 0.5` (common tokens / max token
+  count). Below that the two lines are unrelated rewrites and per-word tinting is noise.
+
+### 2. `DiffTextView` (new control, replaces `DiffLinesView`)
+
+`src/ClaudeDo.Ui/Views/Controls/DiffTextView.axaml` + `.axaml.cs`
+
+Styled properties:
+
+| Property | Type | Meaning |
+|---|---|---|
+| `File` | `DiffFileViewModel?` | Source; the control aligns it and caches the `AlignedDiff` per file instance |
+| `Mode` | `DiffViewMode` (`Unified`\|`Split`) | Layout |
+| `WrapLines` | `bool` | Bound to each editor's `WordWrap` |
+
+Two `TextEditor`s in a two-column grid, both `IsReadOnly=true`, `ShowLineNumbers=false`.
+`Unified` mode collapses the right editor and spans the left one across both columns, feeding
+it `UnifiedText`. `Split` mode shows both, fed `LeftText` / `RightText`.
+
+Per editor:
+- **TextMate**: one shared `RegistryOptions(ThemeName.DarkPlus)`; grammar resolved from
+  `File.Path`'s extension via `GetLanguageByExtension` → `GetScopeByLanguageId` → `SetGrammar`,
+  exactly as `ConflictResolverView.ApplyGrammar` does. No extension match → no grammar, plain text.
+- **`DiffLineNumberMargin : AbstractMargin`** — draws line numbers from the row list. Split: old
+  numbers left, new numbers right. Unified: two number columns in one margin. `Filler` and `Gap`
+  rows draw nothing.
+- **`DiffLineBackgroundRenderer : IBackgroundRenderer`** — full-width tint per visual line by
+  row kind: add / del / filler / gap / ctx.
+- **`WordDiffRenderer : IBackgroundRenderer`** — stronger tint over the changed spans, via
+  `BackgroundGeometryBuilder` at `lineStartOffset + span.Start`.
+
+Both renderers resolve rows through a single `Func<int, RowInfo?>` keyed by document line.
+
+**Highlighting on fragments.** Only hunks are in the document, not whole files, so TextMate's
+line-by-line state can be wrong at a fragment boundary (a line inside a block comment may be
+highlighted as code). Accepted — the same is true of every fragment-based diff viewer.
+
+**Colors.** Line tints stay the existing low-alpha `RunningTintBrush` / `ErrorTintBrush` so
+syntax foregrounds remain legible. The per-line foreground recolor from `DiffLinesView`
+(green/red text) is dropped — syntax colors take over. `Filler` gets a new dim token brush,
+`Gap` renders as a dim `⋯` separator row.
+
+**Scroll sync** (split only), modeled on `ConflictResolverView.HookScrollSync` — find each
+editor's descendant `ScrollViewer`, guard re-entry with a `_syncing` flag:
+- `WrapLines = false`: sync `Offset.Y` directly. Line heights match, so alignment is exact.
+- `WrapLines = true`: line heights diverge. Sync on the first visible document line instead
+  (`ScrollToLine`), which keeps the top of the viewport aligned and lets rows drift downward.
+
+### 3. Host changes
+
+`DiffViewerView.axaml`:
+- Header gains a segmented Unified/Split toggle and a wrap toggle.
+- Files mode: `DiffLinesView Lines="{Binding SelectedFile.Lines}"` → `DiffTextView File="{Binding SelectedFile}"`.
+- Planning mode: the flattened single-stream `DiffLines` view is replaced by an `ItemsControl`
+  over the subtask's parsed files, each item a file header plus its own `DiffTextView`. One
+  editor can only carry one grammar, so per-file editors are required for highlighting to work
+  at all here. `DiffViewerViewModel` exposes the parsed per-file list for the selected subtask;
+  `DiffLines` and `UnifiedDiffParser.Flatten` lose their last consumer and are removed.
+
+`DiffLinesView.axaml` + `.axaml.cs` are deleted once both usages are migrated.
+
+### 4. Persistence
+
+`src/ClaudeDo.Ui/AppSettings.cs` (`~/.todo-app/ui.config.json`) already holds UI-only
+preferences (`Language`, `AccentPreset`) with plain `Load()`/`Save()`. Two properties are added
+there:
+
+```csharp
+public string DiffViewMode { get; set; } = "unified";   // "unified" | "split"
+public bool DiffWrapLines { get; set; }
+```
+
+`DiffViewerViewModel` takes the injected `AppSettings`, seeds its toggles on open and calls
+`Save()` when either changes. No database column, no EF migration, no hub method — a view
+preference does not belong in `AppSettingsEntity`.
+
+### 5. Localization
+
+New keys in both `locales/en.json` and `locales/de.json` (Localization.Tests enforces parity):
+`diff.view.unified`, `diff.view.split`, `diff.view.wrap`.
+
+## Testing
+
+`tests/ClaudeDo.Ui.Tests` — `DiffAlignment` is pure and carries the logic worth testing:
+
+- Context-only diff → identical rows on both sides, no fillers.
+- Equal-size change block → 1:1 pairing, no fillers.
+- Unequal change block (3 del / 5 add) → 3 paired rows + 2 right-side rows with left fillers.
+- Add-only and delete-only blocks → fillers on the opposite side throughout.
+- Non-contiguous line numbers → exactly one `Gap` row inserted.
+- Word diff: single-token change yields one span per side at the right offsets.
+- Word diff skipped above `MaxWordDiffChars` and below `MinWordDiffSimilarity`.
+- Row index ↔ document line mapping holds for both `SplitRows` and `UnifiedRows`.
+- Binary file and empty-content file → empty `AlignedDiff`, no crash.
+
+`AppSettings` round-trip: persisted mode and wrap survive `Save()`/`Load()`.
+
+Rendering (margin, both renderers, scroll sync, TextMate colors) is not unit-testable here and
+is an explicit manual visual pass — see Open items.
+
+## Known limitations
+
+1. **Wrap + split drift.** With wrap on, the two panes align at the top of the viewport but rows
+   drift apart further down. Per-line vertical alignment as VS Code does it is out of scope.
+2. **Fragment highlighting.** See above — highlighting state can be wrong at hunk boundaries.
+3. **Editors per file in Planning mode.** A subtask touching many files instantiates one editor
+   per file. Same cost as viewing those files individually in Files mode; not capped. If it
+   proves slow, the fix is lazy instantiation on expand, not a silent truncation.
+
+## Open items (manual verification)
+
+- Visual pass on both modes: tints legible over DarkPlus syntax colors; line numbers aligned;
+  filler and gap rows readable.
+- Scroll sync with wrap off (exact) and wrap on (top-anchored).
+- Planning mode with a multi-file subtask.
+- Toggle state survives an app restart.
+
+## Docs to update on completion
+
+- `src/ClaudeDo.Ui/CLAUDE.md` — Views/Controls list and the "Diff & Conflicts" section still
+  name `DiffLinesView`.
+- `docs/explore-notes/review-merge.md` — diff stack description + "verified against" commit.

docs/superpowers/specs/2026-08-07-handler-run-links-design.md

@@ -0,0 +1,169 @@
+# Handler-Run: Verknüpfung zu den behandelten Tasks
+
+**Date:** 2026-08-07
+**Status:** Design approved (Mika), implementation pending
+**Verified against:** commit `c792765`
+
+## Problem
+
+Ein "Let Claude handle it"-Run besitzt seit 2026-08-05 einen echten Task (`IsManual=true`,
+`HandlerBaseCommit`/`HandlerHeadCommit`, Diff über Commit-Range). Was fehlt: **welche Tasks der Run
+behandelt hat, ist nirgends persistiert.** Die Auswahl lebt nur in der ConPTY-Session und im
+Transcript; `HandoffMcpTools.HandoffListHandler` (`src/ClaudeDo.Worker/External/HandoffMcpTools.cs:28-45`)
+bekommt `survivingTaskIds` als flüchtige Liste.
+
+Folge: Nachdem ein Run durch ist und der Diff sichtbar wird, lässt sich nicht mehr nachvollziehen,
+*was alles gemacht werden sollte* und *welcher Task was produziert hat*. Duplikate, die der Handler
+in Phase 1 gecancelt hat, verschwinden vollständig aus dem Blickfeld.
+
+Zweitens zeigt der Handler-Task in der Liste das Badge **MANUAL**, weil er `IsManual=true` setzt —
+irreführend, denn es ist kein manueller Reminder.
+
+## Ist-Zustand
+
+### Es gibt kein Task-Kind
+
+`TaskEntity` hat **kein `Kind`/`Type`-Enum**. Task-"Arten" sind heute Feld-Kombinationen:
+
+| Feld | Bedeutung |
+|---|---|
+| `IsManual` | manueller Reminder — Queue/Daily-Prep/Refine überspringen ihn |
+| `ParentTaskId` | Kind einer Planning-/Improvement-Session |
+| `PlanningPhase` | Planning-Parent |
+| `BlockedByTaskId` | Kettenglied, Queue-Picker überspringt es |
+| `HandlerBaseCommit` | worktree-loser List-Handler-Host (`src/ClaudeDo.Data/Models/TaskEntity.cs:60-61`) |
+
+Ein Handler-Task ist also allein durch `HandlerBaseCommit != null` identifiziert.
+
+### `ParentTaskId` ist belegt
+
+`TaskRepository.CreateChildAsync` (`src/ClaudeDo.Data/Repositories/TaskRepository.cs:306`) setzt es
+für Planning-Kinder; `TaskRowViewModel.IsChild`/`ShowAsChild`
+(`src/ClaudeDo.Ui/ViewModels/Islands/TaskRowViewModel.cs:59,66`) hängen daran und rücken die Zeile
+im Baum ein. Ein Recycling für Handler→behandelte Tasks würde die Auswahl optisch unter den Handler
+schieben und mit echten Planning-Kindern kollidieren.
+
+### Badge-Infrastruktur existiert
+
+`TaskRowView.axaml:129-144` rendert DRAFT / PLANNED / PLANNING / MANUAL über
+`Border Classes="badge <variant>"`. Basis-Style und Varianten liegen in
+`src/ClaudeDo.Ui/Design/IslandStyles.axaml:963-990`, die Brushes als theme-fähige Tokens in
+`Tokens.axaml`. Loc-Keys: `tasks.badgeManual`, `tasks.manualTip` (en.json:163-164).
+
+### Kinder-Panel existiert
+
+`DetailsIslandViewModel.LoadChildOutcomesAsync`
+(`src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs:704-748`) lädt
+`Where(t => t.ParentTaskId == parentTaskId)` in `ChildOutcomes` (`:248`) und rendert pro Zeile
+Id/Titel/Status/RoadblockCount/WorktreeState via `ChildOutcomeRowViewModel`; Refresh läuft über
+`TaskUpdated`/`WorktreeUpdated` (`:814-833`).
+
+## Entscheidungen
+
+| Frage | Entscheidung | Begründung |
+|---|---|---|
+| Neues `TaskKind`-Enum? | **Nein** | Es gäbe kein Enum zu erweitern — es wäre das erste überhaupt, inkl. Migration und Rückwirkung auf Queue/Filter/UI. Der Bedarf ist eine Beziehung, kein Typ. |
+| `ParentTaskId` wiederverwenden? | **Nein** | belegt durch Planning-Kinder, kollidiert mit Einrückungs-Logik |
+| 1:n oder n:m? | **1:n**, eine nullable Spalte | Historie "welcher Run hat den Task mal berührt" bringt nichts, wenn ohnehin der letzte Run derjenige ist, dessen Diff man ansieht. Join-Tabelle = doppelter Code für einen Randfall. |
+| Wann stempeln? | **Beim Anlegen des Handler-Tasks** | Die UI kennt die Auswahl bereits. Erfasst auch die Tasks, die der Handler in Phase 1 als Duplikat cancelt — genau das "was sollte alles gemacht werden". Ein Stempeln erst in `handoff_list_handler` würde Dedupe-Verlierer verlieren und bei Abbruch vor Phase 2 gar nichts verknüpfen. |
+| Umfang der Anzeige | **Nur Liste + Endstatus** | Kein Phasen-Protokoll, kein Per-Task-Diff im Panel — der Diff hängt ohnehin am jeweiligen Task. |
+
+## Design
+
+### 1. Daten
+
+Neue nullable Spalte auf `TaskEntity`:
+
+```csharp
+/// <summary>Id des Handler-Task-Runs, der diesen Task behandelt hat (null = keiner).</summary>
+public string? HandlerTaskId { get; set; }
+```
+
+Konfiguration in `TaskEntityConfiguration`: `HasIndex(t => t.HandlerTaskId)`, kein FK-Constraint
+(konsistent mit `BlockedByTaskId`-Handhabung; ein gelöschter Handler-Task soll die behandelten Tasks
+nicht kaskadierend anfassen). EF-Core-Migration `AddHandlerTaskId`.
+
+Ein zweiter Run über dieselben Tasks überschreibt die Zuordnung — gewollt (1:n).
+
+### 2. Schreiben
+
+Die Auswahl wird durchgereicht: UI → `IWorkerClient.CreateMergeHelperTaskAsync` → 
+`WorkerHub.CreateMergeHelperTask` (`src/ClaudeDo.Worker/Hub/WorkerHub.cs:827-838`) →
+`InteractiveLaunchSpecService.CreateMergeHelperTaskAsync`. Nach dem Anlegen des Handler-Tasks setzt
+eine neue Repository-Methode die Zuordnung in einem Batch-Update:
+
+```csharp
+Task<int> SetHandlerTaskIdAsync(IReadOnlyList<string> taskIds, string handlerTaskId, CancellationToken ct);
+```
+
+Der Handler-Task selbst bekommt **kein** `HandlerTaskId` (kein Selbstbezug). Unbekannte Ids werden
+still übersprungen.
+
+### 3. Badge
+
+`TaskRowViewModel`:
+
+```csharp
+public bool IsHandlerRun => !string.IsNullOrEmpty(HandlerBaseCommit);
+public string? HandlerBadge => IsHandlerRun ? Loc.T("tasks.badgeHandler") : null;
+public string? ManualBadge => IsManual && !IsHandlerRun ? Loc.T("tasks.badgeManual") : null;
+```
+
+`HandlerBaseCommit` muss dafür auf das Row-ViewModel und in dessen Mapping aufgenommen werden.
+HANDLER hat Vorrang vor MANUAL — beide Badges nie gleichzeitig.
+
+In `TaskRowView.axaml` analog zu `:141-144` ein `Border Classes="badge handler"` mit
+`ToolTip.Tip="{loc:Tr tasks.handlerTip}"`. In `IslandStyles.axaml` eine `.badge.handler`-Variante
+mit `{DynamicResource HandlerBadgeBrush}`, Token in `Tokens.axaml` für Light und Dark.
+
+Neue Loc-Keys in en.json **und** de.json (Parität ist testgeprüft):
+
+- `tasks.badgeHandler` — "HANDLER" / "HANDLER"
+- `tasks.handlerTip` — "Handler run — lists the tasks it processed" / "Handler-Run — listet die
+  Tasks, die er bearbeitet hat"
+
+### 4. Anzeige
+
+Im Detail-Bereich eines Handler-Tasks eine Liste der behandelten Tasks, parallel zum bestehenden
+Kinder-Panel:
+
+- Neue Collection `HandledTasks` auf `DetailsIslandViewModel`, befüllt von `LoadHandledTasksAsync`
+  mit `Where(t => t.HandlerTaskId == taskId)`, sortiert wie die Kinder-Liste.
+- Zeilen wiederverwenden `ChildOutcomeRowViewModel` (Id, Titel, Status, RoadblockCount,
+  WorktreeState) — keine neue Row-Klasse.
+- Refresh über dieselben `TaskUpdated`-Events wie `ChildOutcomes`; der bestehende
+  `RefreshChildOutcomeAsync`-Pfad (`:814-833`) wird um die zweite Collection erweitert.
+- Sichtbar nur wenn `HandledTasks.Count > 0`.
+- **Keine Klick-Interaktion** — das bestehende `ChildOutcomes`-Template ist eine reine Anzeige
+  (Titel / Roadblock / Status, kein Tapped-Handler). Die neue Liste bleibt identisch; "zum Task
+  springen" wäre neues Verhalten und ist hier nicht enthalten.
+
+### 5. Fehlerfälle
+
+- Handler-Task gelöscht → `HandlerTaskId` der behandelten Tasks zeigt ins Leere; die Tasks bleiben
+  normal nutzbar, das Panel existiert schlicht nicht mehr. Kein Cleanup nötig.
+- Behandelter Task gelöscht → verschwindet aus der Liste (Query läuft live gegen die Tasks).
+- Leere Auswahl → kein Stempeln, Panel bleibt unsichtbar.
+
+## Tests
+
+| Ebene | Test |
+|---|---|
+| Data | `SetHandlerTaskIdAsync` stempelt alle übergebenen Ids, ignoriert unbekannte, überschreibt eine vorhandene Zuordnung |
+| Worker | `CreateMergeHelperTaskAsync` stempelt die übergebene Auswahl und **nicht** den Handler-Task selbst |
+| Ui | `TaskRowViewModel`: HANDLER schlägt MANUAL (`IsManual=true` + `HandlerBaseCommit` gesetzt → nur HANDLER) |
+| Ui | `DetailsIslandViewModel`: `HandledTasks` lädt nach `HandlerTaskId`, aktualisiert sich auf `TaskUpdated` |
+| Localization | Parität en/de — deckt der bestehende Test automatisch ab |
+
+## Bewusst nicht enthalten
+
+- Kein `TaskKind`-Enum.
+- Keine n:m-Historie über mehrere Runs.
+- Kein Phasen-Protokoll (Dedupe-Begründungen, Umformulierungen) — nur das Ergebnis.
+- Kein Per-Task-Diff im Panel; der Diff bleibt am jeweiligen Task.
+- Kein Badge auf den *behandelten* Tasks.
+
+## Offen
+
+- **Sichtprüfung durch Mika:** Badge-Farbe im Light- und Dark-Theme, Position des Panels im
+  Detail-Bereich, Verhalten bei vielen behandelten Tasks (Scroll).

docs/superpowers/specs/2026-08-07-ui-reaktivitaet-und-listen-performance-design.md

@@ -0,0 +1,173 @@
+# UI-Reaktivität und Listen-Performance
+
+**Datum:** 2026-08-07
+**Status:** Design freigegeben, Implementierung offen
+
+## Problem
+
+Zwei Symptome, die als eines gemeldet wurden:
+
+1. **Stale UI.** Ein Task bleibt in der Liste auf `Queued` stehen, obwohl der Worker ihn längst auf `Running` gesetzt hat. Ebenso tauchen extern angelegte Tasks (Online-Inbox, List-Handler) erst nach einem manuellen Neuladen auf. Modals und Overlays zeigen den Stand vom Öffnungszeitpunkt.
+2. **Langsames Laden.** Eine Liste mit ~125 erledigten Tasks braucht 1–2 Sekunden zum Öffnen. Ziel sind Listen mit bis zu ~1000 erledigten Tasks.
+
+## Analyse
+
+### Reaktivität: es fehlt kein Event, es fehlt die Selbstheilung
+
+Der Broadcast-Pfad ist im Grundsatz korrekt: der Worker schreibt in die DB, committet, und sendet danach eine ID über SignalR (`HubBroadcaster`); die UI lädt die Entity frisch nach. WAL-Sichtbarkeit und EF-Change-Tracking wurden als Ursache **ausgeschlossen** — die UI nutzt `IDbContextFactory` mit kurzlebigen Kontexten, und WAL-Reader sehen Commits sofort.
+
+Das eigentliche Problem: **ein einziger verlorener Event ist permanent.** Der einzige Reconcile-Trigger ist heute `ConnectionRestoredEvent`, also ein Verbindungsabbruch. Es gibt drei Wege, auf denen ein Update verloren geht:
+
+| # | Loch | Ort |
+|---|---|---|
+| 1 | Blankes `catch { }` um den gesamten Delta-Pfad. Eine einzige transiente Exception (z.B. `SQLITE_BUSY`) lässt die Zeile dauerhaft auf dem alten Stand — ohne Log, ohne Retry. | `src/ClaudeDo.Ui/ViewModels/Islands/TasksIslandViewModel.cs:224` |
+| 2 | `QueuePicker.ClaimNextAsync` committet `status='running'` sofort. Wirft danach etwas in `RunInSlotAsync` oder im ungeschützten Setup-Block von `TaskRunner.ContinueAsync` (Zeilen 218–238 liegen außerhalb jedes `try`), fängt der Catch das ab und **loggt nur** — kein `FailAsync`, kein Broadcast. DB sagt Running, die UI erfährt es nie. | `src/ClaudeDo.Worker/Queue/QueueService.cs:349-352` |
+| 3 | DB-Writes ohne Broadcast. | `src/ClaudeDo.Worker/Runner/WorktreeManager.cs:103`, `src/ClaudeDo.Worker/Online/OnlineSyncService.cs:131` |
+
+**Korrektur (2026-08-07, bei der Umsetzung gefunden):** `InteractiveLaunchSpecService.cs:447` stand hier ursprünglich als drittes Loch. Das war falsch. Die Service-Methode broadcastet zwar selbst nicht, aber ihr einziger Produktions-Aufrufer `WorkerHub.CreateMergeHelperTask` (`src/ClaudeDo.Worker/Hub/WorkerHub.cs:818`) sendet direkt danach `TaskUpdated` — seit Commit `c07c1f7` vom 2026-08-05, abgesichert durch `MergeHelperTaskHubTests.CreateMergeHelperTask_CreatesIdleManualTask_StampsBaseCommit_Broadcasts`. Der ursprüngliche Befund hatte den DB-Write gesehen, aber den Aufrufer nicht geprüft. Ein Broadcast im Service wäre ein Duplikat gewesen.
+
+Dazu zwei kleinere Befunde:
+
+- **Race im Delta-Pfad.** `OnWorkerTaskUpdated` ist `async void` und hängt an *zwei* Events (`TaskUpdatedEvent` und `WorktreeUpdatedEvent`, `TasksIslandViewModel.cs:117-118`). Der Full-Reload-Zweig ist per `_loadCts` gegen Überholen abgesichert, der Delta-Zweig nicht — ein älterer Read kann einen neueren überschreiben.
+- ~~**Kein Busy-Timeout konfiguriert.**~~ **Widerlegt (2026-08-07, empirisch geprüft).** Die Vermutung war, die blanken Connection-Strings (`src/ClaudeDo.App/Program.cs:95`, `src/ClaudeDo.Worker/Program.cs:61`) ließen einen `SQLITE_BUSY` sofort durchschlagen. Das stimmt nicht: Microsoft.Data.Sqlite 8.0.11 setzt `DefaultTimeout` **von sich aus auf 30 Sekunden**, mit oder ohne das Keyword — gemessen an `SqliteConnectionStringBuilder("Data Source=x.db").DefaultTimeout` → `30`, ebenso `SqliteConnection.DefaultTimeout` und `SqliteCommand.CommandTimeout`. Ein Contention-Test (Writer hält 2s, zweiter Writer parallel) zeigt, dass der zweite wartet und nach ~2030 ms durchkommt, statt zu werfen. Der ursprünglich dafür gemachte Commit `f62dbb9` war ein No-op mit irreführendem Kommentar und wurde mit `ac58679` zurückgenommen. Die tatsächliche Absicherung gegen transiente Lesefehler leistet der Retry im Delta-Pfad, nicht ein Timeout.
+- **`RunCreated` ist ein totes Event.** Wird in `TaskRunner.cs:358` gesendet, hat aber keinen einzigen Abonnenten in der UI.
+
+### Performance: der Engpass ist das Rendering, nicht die Datenbank
+
+SQLite ist hier **nicht** der Engpass, und ein DB-Wechsel würde nichts verbessern. Die Kosten verteilen sich so:
+
+| Posten | bei 125 Zeilen |
+|---|---|
+| SQLite-Read, 125 Zeilen × ~30 Spalten, 2 Joins | < 1 ms |
+| EF-Materialisierung | ~1–5 ms |
+| **Avalonia baut ~8.500 Controls mit Bindings** | **~1.000–1.500 ms** |
+
+Eine `TaskRowView` erzeugt **~68 Controls eager**: ~50 für Struktur und Inhalt plus 18 `MenuItem`-Deklarationen des inline deklarierten ContextMenus (`TaskRowView.axaml:35-85`). Die Liste ist **nicht virtualisiert**: drei `ItemsControl` (Overdue/Open/Completed) liegen in einem gemeinsamen `ScrollViewer` ohne `ItemsPanel`-Override (`TasksIslandView.axaml:100,119,152`). `ItemsControl` nutzt per Default ein normales `StackPanel`, und der gemeinsame `ScrollViewer` gibt allen dreien unbegrenzte Höhe — deshalb würde auch ein bloßes Setzen von `VirtualizingStackPanel` nichts bewirken.
+
+Zeilenhöhe ~68px, verfügbare Listenhöhe auf 2560×1440 ~1250px → **~19 Zeilen gleichzeitig sichtbar**.
+
+| | Controls | geschätzt |
+|---|---|---|
+| heute, 125 Tasks | ~8.500 | 1–2 s |
+| heute, 1000 Tasks | ~68.000 | ~10 s+ |
+| virtualisiert (19 sichtbar + Overscan ≈ 25 Zeilen) | ~1.700 | ~250 ms |
+| + ContextMenu lazy | ~1.250 | ~180 ms |
+
+Entscheidend: die virtualisierten Werte sind **konstant** und gelten für 125 wie für 10.000 Zeilen.
+
+Nebenbefund: `LoadForList` (`TasksIslandViewModel.cs:305-309`) hat **kein `.Where()` vor `ToListAsync()`** — es lädt die komplette `tasks`-Tabelle aller Listen mit zwei Joins und filtert danach in C#. Die vorhandenen Indizes (`idx_tasks_list_id`, `idx_tasks_status`) werden dadurch nie genutzt. Bei der heutigen DB-Größe unkritisch, aber es skaliert mit der DB-Gesamtgröße statt mit der Listengröße.
+
+### Drag & Drop: architektonisch virtualisierungsfähig
+
+Die Task-Liste nutzt **kein** Avalonia-`DragDrop` pro Item, sondern ein eigenes Ghost-Drag:
+
+- Vier Pointer-Handler hängen **zentral** an der `TasksIslandView` (`TasksIslandView.axaml.cs:40-43`, Tunnel-Routing) — keine pro-Zeile registrierten Handler, die beim Container-Recycling leaken könnten.
+- Das Ziel wird per `InputHitTest` live ermittelt (`TasksIslandView.axaml.cs:304-329`) — kein Index-Hack, recycling-sicher.
+- Drop-Hints sind reine ViewModel-Properties (`TaskRowViewModel.cs:25-26`, `DropHintAbove`/`DropHintBelow`).
+- Der Ghost ist ein `RenderTargetBitmap`-Snapshot in einem separaten Topmost-Fenster (`Views/Controls/TaskDragController.cs`), losgelöst vom Visual Tree.
+
+Anzupassen sind:
+
+- `FindNextInSameSection` und `SectionFor` (`TasksIslandViewModel.cs:366-374`, `:622-628`) iterieren per `IndexOf` über die drei UI-Collections. Die flache Master-Collection `Items` existiert bereits (`TasksIslandViewModel.cs:55`) und ist korrekt sortiert — das ist der Grund, warum das Flatten bezahlbar ist.
+- **Auto-Scroll beim Ziehen fehlt komplett.** Fällt heute weniger auf, weil alle Container realisiert sind; bei einer virtualisierten Liste ist es Pflicht.
+- **Bestehender Bug:** Zieht man über eine Gruppengrenze, prüft `ReorderAsync` (`TasksIslandViewModel.cs:560-563`) zwar die Sektion, verschiebt bei ungleichen Sektionen aber nur `Items` ohne anschließendes `Regroup()`. `SortOrder` landet in der DB, die UI zeigt nichts.
+- **Kein Präzedenzfall:** im gesamten `ClaudeDo.Ui`-Projekt existiert kein `VirtualizingStackPanel` und kein `ItemsRepeater`.
+
+### Drag-Optik
+
+Heute laufen zwei Darstellungen derselben Zeile gleichzeitig: der Bitmap-Ghost am Cursor **und** die Originalzeile mit `Opacity 0.55`, `scale(1.03)`, BoxShadow und Accent-Rand (`IslandStyles.axaml:441-446`). `scale(1.03)` ändert kein Layout und überlappt daher die Nachbarzeilen. Das Feedback für das Drop-Ziel ist der ganz normale `:pointerover`-Hover (`IslandStyles.axaml:433-435`, setzt nur `BorderBrush`) — dasselbe Signal wie beim harmlosen Drüberfahren; einen eigenen `drop-target`-Style gibt es nur für die Lists-Island (`Border.list-item.drop-target`). Zusätzlich laufen `BrushTransition` (0.12s) und `ThicknessTransition` auf `Margin` (0.15s) auch während des Drags mit, was die Rückmeldung verschwimmen lässt.
+
+## Verworfene Alternativen
+
+| Alternative | Warum verworfen |
+|---|---|
+| **SQLite ersetzen** | Kein Engpass. Der DB-Read liegt unter 1 ms; die Zeit steckt zu >95% im Aufbau des Visual Tree. Monatelange Arbeit für null messbaren Gewinn. |
+| **Nur Task-Titel laden, Rest lazy beim Öffnen** | Richtige Intuition, falsche Ebene. Spart Bytes aus einer lokalen Datei, die in unter 1 ms gelesen wird. Die 125 Zeilen werden weiterhin als 125 vollständige `TaskRowView` gebaut. Um wirklich zu sparen, müsste das Zeilen-Template entkernt werden — also genau die Chips und Icons entfallen, wegen derer die Liste nützlich ist. Als *Zusatz* (schlanke Projektion für Speicher/Materialisierung) sinnvoll, als Hauptmaßnahme nicht. |
+| **Completed einklappen + „mehr laden"** | Billig und sofort wirksam, aber aufgeklappt mit 1000 Zeilen hängt es wieder. Bleibt als **Fallback**, falls der Virtualisierungs-Spike scheitert. |
+| **Completed archivieren** | Löst das Problem durch Vermeidung; der Wunsch war ausdrücklich, 1000 erledigte Tasks sehen zu können. |
+| **`Revision`-Spalte / Change-Feed** | Strukturell sauber (verlorene Events wären egal, Race gelöst), aber Migration plus Anpassung jedes Schreibpfads. Für eine Single-User-Desktop-App mit lokaler DB Overkill; der Reconcile-Tick erreicht dasselbe Ziel deutlich billiger. Bleibt als Eskalation, falls Phase 3 in der Praxis nicht reicht. |
+| **Nur die Löcher stopfen (ohne Reconcile)** | Behebt die bekannten Fälle, lässt die Architektur „ein verlorener Event = permanent stale" aber intakt. Das nächste Loch kommt mit dem nächsten Feature. |
+
+## Design
+
+### Phase 1 — Reaktivitäts-Löcher schließen
+
+Unabhängig von Phase 2 und 3, kann sofort starten.
+
+| Fix | Ort |
+|---|---|
+| `catch { }` ersetzen durch Log + einmaligen Retry. **Kein** Footer-Error — das ist ein Hintergrund-Refresh, keine Nutzeraktion. | `TasksIslandViewModel.cs:224` |
+| Catch-Block ruft `_state.FailAsync` (das selbst broadcastet), statt nur zu loggen; `OperationCanceledException` bleibt ausgenommen | `QueueService.cs:349-352` |
+| `WorktreeUpdated` nach dem Insert broadcasten | `Runner/WorktreeManager.cs:103` |
+| `TaskUpdated` nach dem Insert broadcasten | `Online/OnlineSyncService.cs:131` |
+| Monotone Sequenznummer pro TaskId im Delta-Pfad; Ergebnisse mit veralteter Sequenz verwerfen | `OnWorkerTaskUpdated` |
+| `RunCreated` ersatzlos entfernen (totes Event ohne Abonnent) | `HubBroadcaster`, `TaskRunner.cs:358` |
+
+Der ungeschützte Setup-Block in `TaskRunner.ContinueAsync` (Zeilen 218–238) wird **nicht** separat umgebaut: sobald `RunInSlotAsync` im Fehlerfall `FailAsync` ruft, ist jede dort geworfene Exception abgedeckt — der Task landet auf `Failed` und der Broadcast erfolgt. Ein zweiter Schutzwall wäre doppelt.
+
+### Phase 2 — Flache virtualisierte Liste
+
+**Datenmodell.** `Regroup()` erzeugt statt drei Collections **eine** `Rows`-Collection vom Union-Typ (`HeaderRow` | `TaskRowViewModel`), abgeleitet aus der bereits vorhandenen flachen `Items`. Gruppenüberschriften werden zu regulären Einträgen:
+
+```
+Rows
+ [0]  HeaderRow   "Überfällig (3)"
+ [1]  TaskRow     …
+ [4]  HeaderRow   "Offen (12)"
+ …
+ [17] HeaderRow   "Erledigt (125)"
+ …
+```
+
+**View.** Eine `ListBox` mit `VirtualizingStackPanel` und einem DataTemplate-Selector (Header / Task) ersetzt die drei `ItemsControl` und den umschließenden `ScrollViewer`.
+
+**Drag.** `FindNextInSameSection`, `SectionFor` und `ReorderAsync` rechnen gegen `Items` statt gegen die UI-Collections. Auto-Scroll beim Ziehen an den Listenrand wird neu gebaut. Der Cross-Section-Reorder-Bug wird im selben Zug behoben, da die Sektionsgrenzen in der flachen Struktur ohnehin explizit modelliert werden müssen.
+
+**Zeilenkosten.** Das ContextMenu wird bei `ContextRequested` im Code-Behind aufgebaut statt als 18 `MenuItem`s pro Template-Instanz.
+
+**Query.** `.Where()` wandert vor `ToListAsync()`, damit die Query mit der Listengröße statt der DB-Gesamtgröße skaliert. Erfordert Umbau von `ITaskListFilter` von In-Memory-Prädikaten (`Matches(TaskEntity)`) auf `IQueryable`-Expressions.
+
+**Drag-Optik (Variante A).** Ghost folgt dem Cursor; die Originalzeile kollabiert zu einer leeren, gestrichelten Lücke, die beim Ziehen an die jeweilige Zielposition mitwandert.
+
+```
+   ┌──────────────────────┐
+   │ Fix login bug        │
+   ├──────────────────────┤
+   │ ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ │ ← leerer Slot, wandert mit
+   ├──────────────────────┤
+   │ Rebase branch        │
+   └──────────────────────┘
+        ┌────────────────┐
+        │ Update deps    │ ← Ghost am Cursor
+        └────────────────┘
+```
+
+Begleitend: `scale(1.03)` und BoxShadow auf der gezogenen Zeile entfallen; der normale `:pointerover`-Hover wird während eines aktiven Drags per `dragging`-Klasse am Container unterdrückt; Transitions sind während des Drags aus.
+
+### Phase 3 — Reconcile-Tick
+
+Setzt Phase 2 voraus: auf einer Liste, die 1–2 s zum Laden braucht, würde ein periodischer Abgleich alles verschlimmern.
+
+Ein Timer (3–5 s) gleicht die **sichtbaren** Rows gegen die lokale SQLite ab und **patcht ausschließlich Properties** — er baut nie Zeilen neu und löst nie einen `LoadForList` aus. Bei einer lokalen DB und wenigen Dutzend sichtbaren Zeilen ist das ein einzelner indizierter Query.
+
+Damit ist jeder verlorene Event nach spätestens einem Tick geheilt, unabhängig davon, wo er fehlte. Derselbe Tick versorgt zusätzlich die langlebigen Overlays: Worktrees-Overview, LogVisualizer und die MergeHelper-Auswahl.
+
+Kurzlebige Modals (Settings, ListSettings, RepoImport, WeeklyReport, ConflictResolver) bleiben bewusst statisch — ein Dialog, der sich unter den Fingern des Nutzers ändert, ist schlechter als einer, der den Stand vom Öffnen zeigt.
+
+## Tests
+
+- **Worker.Tests:** Broadcast-Assertions über einen Fake-Broadcaster auf allen in Phase 1 gefixten Pfaden — insbesondere, dass der Fehlerfall in `RunInSlotAsync` einen Broadcast auslöst.
+- **Ui.Tests:** Der Reconcile-Tick patcht abweichende Properties; ein Ergebnis mit veralteter Sequenznummer wird verworfen; `Regroup()` erzeugt die korrekte `Rows`-Folge inklusive Header-Positionen und -Zählern.
+- **Nicht automatisiert testbar:** Ladezeit und Drag-Optik. Beides erfordert eine manuelle Gegenmessung mit einer großen Liste durch den Nutzer.
+
+Keine Tests, die die echte `claude`-CLI starten.
+
+## Risiken
+
+1. **Kein Virtualisierungs-Präzedenzfall im Projekt.** Das HitTest-basierte Custom-Drag ist theoretisch tragfähig, aber nie gegen recycelte Container verifiziert. **Die erste Aufgabe in Phase 2 ist ein Spike**, kein Umbau: eine virtualisierte Liste mit dem bestehenden Drag, inklusive Recycling während eines aktiven Drags und Auto-Scroll. Scheitert der Spike, ist der Fallback „Completed einklappen + nachladen".
+2. **Variable Zeilenhöhen.** 68 px im Normalfall, 90–110 px bei zweizeiligem Titel oder mehreren Badges. `VirtualizingStackPanel` beherrscht das, aber die Scrollbar springt dabei gern, weil die Gesamthöhe geschätzt wird. Muss im Spike mitgeprüft werden.
+3. **`ITaskListFilter`-Umbau.** Die Umstellung auf `IQueryable`-Expressions berührt die Filter-Registry (`src/ClaudeDo.Data/Filtering/`) und damit auch die virtuellen Listen. Kann bei Bedarf aus Phase 2 herausgelöst und nachgezogen werden — der Performance-Gewinn liegt heute ohnehin fast vollständig beim Rendering.
+
+## Reihenfolge
+
+Phase 1 → Phase 2 (Spike zuerst) → Phase 3. Phase 1 ist unabhängig und kann parallel oder vorab laufen.

docs/superpowers/specs/2026-08-10-findings-store-design.md

@@ -0,0 +1,262 @@
+# Findings-Store — Design
+
+Stand: 2026-08-10.
+
+Persistenter, projektgebundener Speicher für **Fallen und Invarianten**, den Agents im
+Moment des Schmerzes selbst befüllen und in späteren Sessions vor dem Erkunden lesen.
+Ziel ist Token-Ersparnis durch verhinderte Fehlläufe.
+
+---
+
+## 1. Ausgangslage
+
+Auslöser war die Frage, ob ein Code-Knowledge-Graph (Graphify-Bauart) das
+Wiedererkunden in jeder Session einspart. Die Messung sagt: nein, nicht in dieser Form.
+
+### Die Zahlen (aus `docs/usage-optimization.md`, 2026-08-05)
+
+- Kontext-Resend = **99,3 %** des Rohverbrauchs. Jeder Kontext-Token wird im Schnitt
+  **~425× nachberechnet**. Das gilt symmetrisch: für gespartes *und* für geladenes Wissen.
+- **Explore-note ersetzt Exploration:** Note 4,6k tok in Turn 5 eines 60-Turn-Runs
+  → 4,6k × 55 ≈ **250k**. Ersparte Exploration (~8k tok Findings ab Turn 10) ≈ **400k**.
+  Netto ~150k, Faktor 1,6. Wird die Note geladen, ohne gebraucht zu werden: **−250k**.
+- **Ein verhinderter Retry:** ~11 Mio Token. **27 % der Tasks brauchten einen Retry.**
+
+Faktor 27 zwischen den beiden Klassen. Deshalb ist der Inhalt dieses Stores **nicht**
+„Architektur-Map, damit ich nicht neu erkunden muss" (400k-Klasse), sondern „Agent läuft
+in die bekannte Falle und der Run ist Müll" (11-Mio-Klasse).
+
+### Was heute schon da ist
+
+| Ebene | Größe | Ladeverhalten |
+|---|---:|---|
+| `CLAUDE.md` (root) | 6,4 KB ≈ 1,6k tok | immer |
+| `src/*/CLAUDE.md` (6×) | 1,5–14 KB | beim Arbeiten im Verzeichnis |
+| `docs/explore-notes/` (6 Notes) | 11–18 KB, 92 KB gesamt | on demand, **ganze Datei** |
+| Auto-Memory (`~/.claude/projects/.../memory/`) | 55 Dateien, 397 KB | Index immer (nur interaktiv) |
+
+Die Sektionen der Notes sind bereits 12–36 Zeilen (~150–450 tok) — also schon
+knotengroß. Und `conpty-sessions.md` markiert Fallen bereits konventionell als
+`## ⚠️ Gotcha: …` (5 Stück). Die anderen Notes tragen dieselbe Art Wissen unmarkiert im
+Fließtext. **Das Wissen ist zu großen Teilen schon geschrieben, nur nicht einsammelbar.**
+
+---
+
+## 2. Verworfene Alternativen
+
+- **Code-Knowledge-Graph (Graphify o. ä.).** Ein tree-sitter-Graph liefert Call-Kanten —
+  genau die Klasse, die Grep exakt und billig liefert (Grep = 5–8 % des Kontexts; Read =
+  60–68 %, das Problem ist zu viel *lesen*, nicht Finden). Der wertvolle Inhalt ist
+  semantisch und nicht ableitbar („Approve = merge the whole unit", „no directory arg may
+  end in a separator"). Dazu: Build-/Staleness-Pipeline über N parallele Worktrees und
+  Merge-Konflikte auf einem Graph-Artefakt im Repo. AXAML wird ohnehin nicht geparst.
+- **DB-Tabelle + UI-Editor.** Kuration passiert in VSCode, damit entfällt der einzige
+  Vorteil. Agent-Zugriff bräuchte ein Lese-Tool statt `Read`; Agents könnten veraltete
+  Einträge nicht selbst korrigieren.
+- **Hook-Injektion der Findings in den System-Prompt.** Früh und groß in den Prefix ist
+  das teuerste Muster überhaupt (Befund 5), auch wenn nichts davon gebraucht wird.
+- **Post-Merge-Trigger.** Ursprünglicher Entwurf. Hinfällig, weil der Aufrufer des Tools
+  den Kontext bereits hat — siehe §4.
+- **Retro-Distill aus alten Transkripten.** Zurückgestellt, siehe §8.
+
+---
+
+## 3. Speicher
+
+```
+<working-dir>/.claudedo/
+  INDEX.md              # eine Zeile je Finding — die einzige Datei, die immer gelesen wird
+  traps/<slug>.md       # ein Finding je Datei, ~150–300 tok
+```
+
+`maps/` ist reserviert, aber **nicht Teil von v1**.
+
+Ordner liegt im Repo-Root, das er beschreibt — maximale Erkennbarkeit, reist bei
+Bedarf mit. `.claudedo` ist als Name frei; die Worktrees liegen unter dem *Geschwister*-Pfad
+`.claudedo-worktrees`, und `TranscriptUsageReader` prüft auf das exakte Segment, also kein
+Fehlalarm bei der Scope-Erkennung.
+
+### Finding-Format
+
+```markdown
+---
+slug: conpty-arg-quoting
+scope: src/ClaudeDo.Worker/Planning
+source-task: 5d627df8
+verified-against: e10634b
+---
+
+# Ein Verzeichnis-Argument, das auf `\` endet, frisst alle folgenden Argumente
+
+<2–6 Sätze: was passiert, warum es nicht danach aussieht, was man stattdessen tut.>
+```
+
+### INDEX.md
+
+```markdown
+# Findings
+
+- [conpty-arg-quoting](traps/conpty-arg-quoting.md) — Dir-Arg auf `\` escapet sein eigenes Quote
+- [shared-worktree-partial-commit](traps/shared-worktree-partial-commit.md) — nie blank committen
+```
+
+Reine Routing-Ebene: Titel + einzeiliger Aufhänger + Pfad. Ablauf im Agenten:
+Index lesen (~700 tok) → ein bis zwei Findings lesen (~400 tok), statt 4 600 für eine
+ganze Note.
+
+### Einchecken oder nicht — Toggle je Liste
+
+Beim Anlegen einer Liste: **„`.claudedo` einchecken"**, Default **aus**.
+
+- **Aus** → `/.claudedo/` wird nach `.git/info/exclude` geschrieben (per-Clone,
+  unsichtbar fürs Repo, **keine getrackte Datei angefasst**). Mechanik existiert bereits in
+  `SessionSkillSeeder.AppendExcludeLineAsync` (auflösen über
+  `git rev-parse --git-path info/exclude`) — wiederverwenden, nicht neu bauen.
+- **An** → nichts tun, der Nutzer commitet den Ordner selbst.
+
+### Worktree-Regeln (hart)
+
+- **Geschrieben wird ausschließlich im Haupt-Checkout, nie in einem Worktree.** Sonst
+  entstehen `INDEX.md`-Merge-Konflikte über parallele Tasks — exakt das Problem, das oben
+  gegen den Graph-Ansatz spricht.
+- **Gelesen wird über den absoluten Pfad auf den Haupt-Checkout.** Eine Regel für beide
+  Toggle-Stellungen; in „aus" existiert der Ordner im Worktree ohnehin nicht.
+- Falls der Store getrackt ist und der Distiller committet: pfad-skopiert
+  (`git commit -- .claudedo`), nie blank — der Haupt-Checkout wird von parallelen
+  Sessions geteilt.
+- Ein Finding je Datei heißt: parallele Schreiber kollidieren nicht. Umkämpft ist nur
+  `INDEX.md`; das Tool serialisiert dessen Rewrite prozessintern.
+
+---
+
+## 4. Schreibweg — ein MCP-Tool
+
+`save_finding(slug, title, body, scope = "", list = "")` am bestehenden `claudedo`-MCP-Server.
+
+Signatur folgt den zwei test-erzwungenen Konventionen des Servers: jeder optionale
+Parameter hat einen C#-Defaultwert, und das Tool gibt kein blankes `Task` und keine
+nullable Payload zurück (→ `docs/explore-notes/external-mcp.md`). Beschreibungsstil nach
+`External/McpToolDocs.cs`.
+
+### Welcher Store wird beschrieben?
+
+Der MCP-Server ist global, der Store projektgebunden — die Zuordnung muss explizit sein:
+
+1. **Autonomer Run:** aus dem Aufrufkontext (`TaskRunMcpContext`) → Task → Liste →
+   `working_dir`. Der `list`-Parameter wird ignoriert.
+2. **Interaktive Session ohne Task-Kontext:** `list` (Name oder Id) entscheidet. Fehlt er
+   und es existiert **genau eine** Liste, wird diese genommen; bei mehreren gibt das Tool
+   einen Fehler zurück, der die verfügbaren Listen nennt. Nie raten.
+
+Geschrieben wird immer in `<list.working_dir>/.claudedo/` — also den Haupt-Checkout,
+auch wenn der Aufrufer in einem Worktree läuft.
+
+Bewusst ein **dummes Schreib-Tool**, kein „generiere mir Findings"-Tool: der Aufrufer hat
+den Kontext bereits. Ein zweiter Claude-Lauf (RefineRunner-Bauart) würde ihn aus
+Transkripten rekonstruieren — teurer und schlechter.
+
+**Genau ein Tool.** Gelesen wird mit `Read` auf die Dateien; das kostet nichts und braucht
+kein Tool. Der Server exponiert bereits ~60 Tools, eines mehr ist im Prefix Rauschen —
+fünf wären es nicht.
+
+**Verhalten:**
+- Gleicher `slug` → **überschreiben**, nicht anlegen. Dedupe gehört ins Tool, nicht in die
+  Prompt-Disziplin.
+- Schreibt `traps/<slug>.md` **und** aktualisiert die Zeile in `INDEX.md` atomar.
+- `verified-against` wird vom Tool aus dem aktuellen HEAD des Haupt-Checkouts gesetzt,
+  nicht vom Aufrufer.
+- `source-task` wird aus dem Aufrufkontext gesetzt, wenn vorhanden (autonome Runs),
+  sonst leer (interaktive Sessions).
+
+### Aufrufwege
+
+1. **Im Run.** Ein Task-Agent tritt in eine Falle und hält sie fest. Höchste Qualität —
+   er hat gerade Turns dafür verbrannt. Billigster Weg, kein zusätzlicher Prozess.
+2. **Merge-Helper-Abschlussphase.** Der List-Handler sweept am Ende nach, was ihm über den
+   Batch hinweg auffiel. Er sieht Diffs, nicht das Straucheln — daher Ergänzung zu (1),
+   kein Ersatz.
+3. **Interaktive Sessions.** Der `claudedo`-MCP ist global registriert, das Tool steht
+   dort ohne Weiteres zur Verfügung.
+4. **VSCode.** Nutzer korrigiert und löscht direkt in den Dateien.
+
+### Aufnahmehürde
+
+Ein Finding ist nur, was **dauerhaft**, **nicht offensichtlich** und **verhaltensändernd**
+ist: „X sieht aus wie Y, ist aber Z — mach stattdessen W". Ein gefixter Bug ist **kein**
+Finding, das ist Git-Historie.
+
+Diese Hürde steht in der Tool-Beschreibung. Sie ist kein Stilhinweis, sondern die
+Betriebsbedingung: `INDEX.md` wird immer gelesen; bei ~15 tok je Zeile sind 50 Findings
+≈ 750 tok, 300 Findings ≈ 4 500 tok — ab da kostet der Index so viel wie früher eine ganze
+Note und die Ersparnis ist weg. Deshalb zusätzlich eine **Warnschwelle bei 80 Einträgen**,
+die das Tool im Ergebnis zurückmeldet.
+
+---
+
+## 5. Leseweg
+
+ClaudeDo hängt einen Satz an den System-Prompt seiner eigenen Runs
+(`--append-system-prompt`, wie heute schon für andere Zwecke genutzt):
+
+> Findings-Index für dieses Projekt: `<abs>/.claudedo/INDEX.md`. Lies ihn, bevor du den
+> Code erkundest, und öffne nur die Findings, die zu deiner Aufgabe passen.
+
+~30 Token, komplett in ClaudeDo gekapselt, **keine CLAUDE.md wird angefasst** — weder die
+des Projekts noch die globale.
+
+Interaktive Sessions bekommen diesen Zeiger nicht (ClaudeDo startet sie nicht). Sie können
+schreiben, aber nicht automatisch lesen. Wer das will, setzt selbst eine Zeile in seine
+globale CLAUDE.md — außerhalb des Scopes dieses Features.
+
+---
+
+## 6. UI
+
+Ein Button an der Liste: **„Findings öffnen"** → öffnet `<working-dir>/.claudedo/` im
+Datei-Explorer bzw. der Standardanwendung. **Kein In-App-Editor** — Kuration passiert in
+VSCode.
+
+Dazu der Toggle aus §3 im Dialog „Liste anlegen" und in den Listen-Einstellungen.
+
+---
+
+## 7. Scope-Grenze (bewusst akzeptiert)
+
+Die Kapselung in ClaudeDo deckelt den Lese-Nutzen auf den Agent-Anteil: laut Messung
+**18,4 %** des Verbrauchs (interaktiv = 81,6 %). Das ist kein Argument gegen das Feature —
+Retries passieren ausschließlich auf der Agent-Seite, und dort sitzt der 11-Mio-Hebel.
+Aber „Token-Ersparnis" heißt hier: Ersparnis in den 18 %, nicht auf dem Konto insgesamt.
+
+---
+
+## 8. Nicht in v1
+
+- **`maps/`** — Subsystem-Maps. Ordner reserviert, Inhalt später. Die bestehenden
+  `docs/explore-notes/` bleiben unangetastet.
+- **Retro-Distill aus Transkripten.** Erst interessant, wenn belegt ist, dass Findings
+  überhaupt wirken. Rohmaterial bleibt verfügbar: vollständiges NDJSON je Run unter
+  `~/.todo-app/logs/{taskId}_run{N}.ndjson`, `ResultMarkdown` in `task_runs`,
+  `WorktreeEntity.BaseCommit/HeadCommit/MergeCommit` für den nachträglichen Diff.
+- **Ernte der bestehenden `⚠️ Gotcha:`-Sektionen** aus `docs/explore-notes/` in den Store.
+  Naheliegender erster Füllstand, aber eine eigene, manuelle Aktion.
+- **Wirkungsmessung** (welches Finding wurde je gelesen, hat es einen Retry verhindert).
+  Braucht ein eigenes Konzept; Dateien tragen keinen Zähler.
+- **Automatischer Staleness-Check** gegen `verified-against`. Frontmatter trägt den Commit,
+  ausgewertet wird er in v1 nur vom Menschen.
+
+---
+
+## 9. Testbarkeit
+
+- `save_finding`: Neuanlage, Überschreiben bei gleichem Slug, Index-Update, Slug-Validierung
+  (kein Pfad-Escape), Warnschwelle bei 80 Einträgen, paralleler Index-Rewrite.
+- Store-Auflösung: Task-Kontext schlägt `list`; genau eine Liste ohne `list` → Treffer;
+  mehrere Listen ohne `list` → Fehler statt Raten; Schreibziel ist der Haupt-Checkout,
+  auch wenn der Aufrufer in einem Worktree sitzt.
+- Die beiden `external-mcp`-Konventionen (Default je optionalem Parameter, kein blankes
+  `Task`/nullable Payload) sind test-erzwungen — die bestehenden Tests greifen automatisch.
+- Toggle: `.git/info/exclude`-Zeile wird genau einmal geschrieben (Idempotenz) — die
+  bestehenden Tests zu `SessionSkillSeeder` sind die Vorlage.
+- Kein Test darf die echte `claude`-CLI starten.
+- `IWorkerClient` / `WorkerHub` / ViewModel-Konstruktoren ändern → handgeschriebene Fakes in
+  **beiden** Testprojekten mitziehen.

docs/superpowers/specs/2026-08-11-dependency-chain-display-design.md

@@ -0,0 +1,73 @@
+# Dependency chain display — Design
+
+**Date:** 2026-08-11
+**Status:** approved, not implemented
+
+## Problem
+
+`DependsOnTaskId` is invisible in the UI. `TaskRowViewModel` has no `DependsOnTaskId` property
+and `TaskRowView.axaml` renders nothing for it — a chained task looks exactly like an unrelated
+one. The execution order the user declared is not readable anywhere in the list.
+
+## Target
+
+A chain renders as a group: the head full width, its dependents indented behind a vertical rail,
+each carrying a small circular step badge on the rail.
+
+```
+┌──────────────────────────────────────────┐
+│  chain head (full width, no badge)       │
+└──────────────────────────────────────────┘
+  ╷ ┌────────────────────────────────────┐
+ (1)│  first dependent                   │
+  ╷ └────────────────────────────────────┘
+  ╷ ┌────────────────────────────────────┐
+ (2)│  second                            │
+  ╷ └────────────────────────────────────┘
+  ╷ ┌────────────────────────────────────┐
+ (2)│  parallel to the second            │
+  ╷ └────────────────────────────────────┘
+  ╷ ┌────────────────────────────────────┐
+ (3)│  third                             │
+    └────────────────────────────────────┘
+```
+
+## Model reading
+
+- **Step number = hop distance from the chain head**, not a running counter. `DependsOnTaskId` is
+  a single FK, so several tasks may share one predecessor → same depth → **same number**. Two
+  rows showing `2` means "these two are both unblocked by step 1", which is the intended reading.
+- **Chain head** = a task with no `DependsOnTaskId` that at least one other task points at. A task
+  with no dependents and no dependency is not a chain and renders exactly as today.
+- Cycles are impossible (`TaskStateService.SetDependsOnAsync` rejects them), so the depth walk
+  always terminates. Still cap the walk defensively.
+
+## Decisions
+
+**One indent level only — parent wins.** The 24 px indent track already exists for planning
+children (`TaskRowView.axaml:22-28`, gated on `ShowAsChild`). A planning child that *also* has a
+`DependsOnTaskId` keeps the parent indent and shows its chain membership as a small inline
+chip (`after #123`) instead of a second indent level. No nesting, no 48 px rows.
+
+**The group is pulled together; the head carries it.** Chain members are re-ordered to sit
+directly under their head regardless of `SortOrder`, so displayed order always equals execution
+order. Dragging the head moves the whole group; members are not individually draggable.
+
+**Head not in view → no orphan rails.** Exact precedent exists: `ParentInView` /`ShowAsChild`
+(`TaskRowViewModel.cs:75`, computed in `Regroup` at `TasksIslandViewModel.cs:543`). Same
+treatment — if the head is filtered out (other list, My Day, completed group), the row renders
+flat with the `after #123` chip instead of a dangling rail.
+
+**Badge has no `#`.** If task numbers (`2026-08-11-task-numbers-design.md`) also land, a row
+would show a rail badge and a `#412` title prefix. The rail badge is a step position, not an
+identity — render it bare (`2`), never `#2`.
+
+## Slices
+
+| # | Slice | Depends on |
+|---|---|---|
+| 1 | VM: `DependsOnTaskId` + depth/head computation in `Regroup`, group pull-together, drag semantics | — |
+| 2 | View: rail, step badge, `after …` chip, locale keys | 1 |
+
+Slice 1 exposes the contract Slice 2 binds to: `ShowAsChainMember`, `ChainStep`,
+`ChainAfterLabel`.

docs/superpowers/specs/2026-08-11-operation-feedback-design.md

@@ -0,0 +1,313 @@
+# Feedback für langlaufende Operationen
+
+**Datum:** 2026-08-11
+**Status:** Design freigegeben, Implementierung offen
+**Auslöser:** Ein Merge über das Detail-Pane blockierte minutenlang ohne jede Anzeige.
+
+## Problem
+
+Langlaufende Operationen geben kein Feedback. Der Nutzer klickt, nichts passiert sichtbar,
+die App liest sich als abgestürzt. Der gemeldete Fall war ein Merge mit Verify-Gate, aber das
+ist ein Symptom eines Musters: Feedback wird **pro Fall ad-hoc** gebaut
+(`PrepStarted/Line/Finished`, `RefineStarted/Finished`, `PlanningMerge*`, `MergeProgress`),
+und dabei geht regelmäßig eine Hälfte verloren oder eine Fläche wird vergessen.
+
+Belegend: `HubBroadcaster.MergeProgress` existierte bereits, während `WorkerClient` noch
+keinen Listener hatte — Sender ohne Empfänger. Das wurde parallel zu diesem Design in einer
+anderen Session nachgezogen (siehe *Abhängigkeit zur Parallelarbeit*), deckt aber nur das
+MergeModal ab, nicht den Approve-Pfad im Detail-Pane.
+
+## Vier Fehlerbilder
+
+Die Analyse trennt vier Klassen, die **verschiedene** Lösungen brauchen. Sie zusammen als
+„fehlendes Feedback" zu behandeln war der Fehler der bisherigen Einzelfall-Fixes.
+
+### Bild 1 — Stiller Await im UI
+
+Ein `[RelayCommand]` awaitet einen Call, ohne Busy-State, ohne Anzeige. Der Button bleibt
+klickbar (Doppelklick-Risiko), es gibt keinen Hinweis, dass etwas läuft.
+
+| Stelle | Befund |
+|---|---|
+| `src/ClaudeDo.Ui/ViewModels/Islands/DetailsIslandViewModel.cs:1206` `ApproveReviewAsync` | **Der gemeldete Fall.** Kein Busy-Flag, kein Indikator; das Verify-Gate kann den Call Minuten halten |
+| `DetailsIslandViewModel.cs:1244` `SubmitForReviewAsync` | kein Busy-Flag (`MissionControlViewModel` hat für denselben Call ein `IsSubmitPending`, das Detail-Pane nicht) |
+| `DetailsIslandViewModel.cs` `RejectReviewAsync`, `ParkReviewAsync` | kein Busy-Flag; Fehler werden verschluckt (`catch { return; }`) |
+| `src/ClaudeDo.Ui/ViewModels/Islands/MergeSectionViewModel.cs:121` `PreviewMergeAsync` | kein Indikator |
+| `WorktreesOverviewModalViewModel` (`IsBusy` vorhanden) | `IsBusy` schaltet in `WorktreesOverviewModalView.axaml:107-108` **nur** Buttons aus — kein Spinner, kein Text. Betrifft Cleanup, Reset, ForceRemove, Refresh, Batch-Merge |
+| Settings-Tabs: `SessionSkillsSettingsTabViewModel`, `FilesSettingsTabViewModel`, `OnlineInboxSettingsViewModel` | dito — `IsEnabled="{Binding !IsBusy}"`, keine Anzeige. Skill-Install ist ein `git clone` |
+| `WeeklyReportModalViewModel`, `RepoImportModalViewModel` | `IsBusy` nur als CanExecute-Gate |
+| Islands ↔ SQLite direkt | Die Islands sprechen direkt mit der DB (`new TaskRepository(ctx)` u.ä., ~15 Stellen allein in `DetailsIslandViewModel`). Meist schnell; `ClearCompleted`, Drag-Reorder über viele Zeilen und das Laden großer Listen nicht zwingend |
+
+Bereits sauber gelöst und **nicht** anzufassen: `MergeModalViewModel` (Spinner + Phase +
+Elapsed), `ConflictResolverViewModel` (`IsBusy` + Text), `DiffViewerViewModel.IsLoadingCombined`,
+`UsageMonitorModalViewModel` (Spinner).
+
+### Bild 2 — UI-Thread-Freeze
+
+Eine andere Fehlerklasse: hier hilft kein Indikator, weil der Dispatcher blockiert ist und
+der Spinner nicht gezeichnet werden könnte. Erst auslagern, dann anzeigen.
+
+| Stelle | Befund |
+|---|---|
+| `src/ClaudeDo.Ui/ViewModels/Modals/DiffViewerViewModel.cs:182` und `:260` | `UnifiedDiffParser.Parse(raw)` läuft **synchron auf dem UI-Thread** |
+| `src/ClaudeDo.Ui/Views/Controls/DiffTextView.axaml.cs:102` | `DiffAlignment.Build(File?.Lines)` ebenfalls |
+
+Im gesamten `ClaudeDo.Ui`-Projekt gibt es **zwei** `Task.Run`-Offloads (`RepoScanner`,
+`RestartWorkerService`). CPU-Arbeit auf dem UI-Thread ist damit die Norm, nicht die Ausnahme.
+
+### Bild 3 — Worker-Stille
+
+Operationen ohne UI-Auslöser. Kein Client erfährt, dass sie laufen; die UI zeigt im
+Startfall nur „reconnecting".
+
+| Stelle | Warum langsam |
+|---|---|
+| 6× `src/ClaudeDo.Worker/Lifecycle/*Recovery.cs` beim Worker-Start (`OrphanRecovery`, `StaleTaskRecovery`, `PromptFileRecovery`, `AttachmentOrphanRecovery`, `PlanningLineageRecovery`, `LegacyWorktreeFolderRecovery`) | git + DB über alle Tasks/Worktrees |
+| `src/ClaudeDo.Worker/Runner/WorktreeManager.cs` — Worktree-Anlage beim Task-Start | `git worktree add` + Branch; stille Lücke zwischen `Queued` und erster Ausgabe |
+| `src/ClaudeDo.Worker/Worktrees/WorktreeMaintenanceService.cs` | Hintergrund-git über alle Worktrees |
+| `TaskMergeService.RebaseOthersAfterMergeAsync` | läuft **innerhalb** des Merge-Calls, **nach** dem Phasen-Broadcast — vollständig unsichtbar |
+| `PlanningAggregator`, `PlanningMergeOrchestrator` | ein Merge pro Subtask |
+| `OnlineSyncService`, `UsageMonitorService`, `PrimeScheduler`, `QueueService` | periodisch, Netz/git |
+
+Querverweis: `docs/superpowers/specs/2026-08-07-ui-reaktivitaet-und-listen-performance-design.md`
+führt `WorktreeManager.cs:103` als DB-Write-ohne-Broadcast (Loch 3). C3 muss prüfen, ob das
+inzwischen geschlossen ist, statt es doppelt zu beheben.
+
+### Bild 4 — MCP-Stille
+
+Trifft nicht die UI, sondern Agenten-Runs. Nur drei Dateien reporten Progress:
+`ExternalMcpService` (5 Tools), `TaskWaitMcpTools`, `TaskMergeService`. Ohne Progress laufen
+u.a. die 8 `batch_*`-Tools, `cleanup_task_worktree`, `get_task_diff`, `preview_merge_set`.
+
+Das ist die dokumentierte Ursache des Traps „MCP 300s idle abort leaves merges stuck": der
+Client bricht bei Stille ab, während der Worker weiterarbeitet, und der Task bleibt hängen.
+
+### Bewusst ausgeschlossen: der Installer
+
+`ClaudeDo.Installer` hat eine vollständige `IProgress<string>`-Step-Pipeline mit Live-Anzeige
+(`Core/InstallerService.cs`, `Steps/*`, `Pages/InstallPage`). Das ist die beste Progress-Fläche
+im Repo und braucht nichts.
+
+## Design
+
+### 1. UI-Primitive: `OperationStatus`
+
+Eine `ObservableObject`-Klasse, die ein ViewModel als Property exponiert. Mehrere pro VM sind
+erlaubt und erwünscht — `WorktreesOverviewModalViewModel` braucht getrennte für Refresh,
+Cleanup und Merge, sonst blockiert ein laufender Refresh die Cleanup-Anzeige.
+
+| Property | Verhalten |
+|---|---|
+| `IsRunning` | sofort `true` → treibt `CanExecute`, verhindert Doppelklick |
+| `ShowIndicator` | erst nach **300 ms** `true` → kein Flackern bei schnellen Calls |
+| `Label` | lokalisierter Text, **mid-flight überschreibbar** (`Report(label)`) |
+| `Elapsed` | `mm:ss`, **lokal getickt** |
+| `IsStalled` | `true`, wenn **60 s ohne Aktualisierung** vergangen sind → Hinweis „läuft weiter, Worker antwortet noch" |
+
+`IsStalled` bemisst sich an der Zeit seit dem letzten `Report`, **nicht** an der Gesamtdauer.
+Sonst würde ein regulär mehrminütiges Verify-Gate fälschlich als hängend gemeldet. Eine
+Operation ohne jeden `Report` gilt nach 60 s als stalled — das ist der Fall, der heute wie ein
+Absturz aussieht.
+
+Benutzung:
+
+```csharp
+using var op = Approve.Begin(Loc.T("ops.merge.merging"));
+var result = await _worker.ApproveReviewAsync(...);
+```
+
+`Dispose` beendet die Operation auch im Exception-Fall.
+
+**Zeitquelle ist injizierbar** (`TimeProvider`, in .NET 8 vorhanden), kein statischer
+`DispatcherTimer`. Ein geteilter statischer Timer wäre genau die Sorte Shared State, die die
+`Ui.Tests` reihenfolgen-abhängig flaky macht. Timer-Callbacks kommen vom Threadpool und müssen
+auf den Dispatcher gepostet werden.
+
+**Fehlerbehandlung bleibt unverändert.** Weiter über `ShowErrorAsync` / `ErrorReported` /
+`FlashFooterError`. `OperationStatus` transportiert keine Fehler.
+
+### 2. UI-Control: `OperationIndicator`
+
+`src/ClaudeDo.Ui/Views/Controls/OperationIndicator.axaml` — Spinner (`Ellipse.spinner` aus
+`IslandStyles`) + Label + Elapsed, gebunden an eine `OperationStatus`. Ohne das Control wird
+die Spinner-StackPanel aus `MergeModalView.axaml:28-30` acht Mal von Hand nachgebaut.
+
+Alle Texte über Locale-Keys im Namespace `ops.*`; en/de-Parität erzwingen die
+`Localization.Tests`.
+
+### 3. Worker-Kanal: ein generisches Progress-Event
+
+Der Worker sendet nur, was das UI **nicht erraten kann** — interne Phasen und Zählstände. Beim
+Klick weiß das UI selbst, was es angestoßen hat.
+
+```
+OperationProgress(string opKey, string phase, int current, int total)
+```
+
+- `opKey` = TaskId bei task-gebundenen Operationen, sonst ein stabiler String
+  (`"worktree-cleanup"`, `"startup-recovery"`, `"planning-integration:<taskId>"`)
+- **Kein Elapsed auf der Leitung** — das tickt das UI
+- `current`/`total` erlaubt echten Fortschritt („Worktree 3/12"), was das heutige
+  `MergeProgress` nicht kann
+
+Dieses Event **ersetzt** `MergeProgress`. Begründung, dass sich die Verallgemeinerung lohnt:
+es gibt drei Produzenten (Merge-Phasen, Worktree-Cleanup, Planning-Integration), nicht einen.
+
+**Aber `IWorkerClient.MergeProgressEvent` bleibt als dünner Forwarder bestehen.** Sonst
+zerstört C1 die Gruppen-Isolation: A1 abonniert dieses Event, und ein Rename würde C zwingen,
+`DetailsIslandViewModel` zu ändern — eine Datei, die Gruppe A besitzt. Der Forwarder kostet
+vier Zeilen und hält die vier Sessions unabhängig. Er darf später entfernt werden, wenn A und
+C beide gemergt sind.
+
+### 4. MCP: `ProgressReporter` als eigene Klasse
+
+`TaskMergeService.RunReportingProgressAsync` (Zeile ~175) ist die einzige existierende
+Progress-Schleife. Sie wird als eigenständige Klasse extrahiert, sodass jedes MCP-Tool sie
+nutzen kann, statt die Schleife zu kopieren. Zusätzlich ein Overload für Element-Fortschritt
+(`i/n`) für die `batch_*`-Tools.
+
+## Festgelegte Grenzen
+
+Bewusst **nicht** Teil dieses Designs:
+
+- **Kein Cancel.** Nur Sichtbarkeit. Ein Abbruch wäre bei einem Merge ohnehin irreführend: das
+  Verify-Gate läuft, wenn der Merge-Commit längst geschrieben ist — „abbrechen" könnte nur
+  *aufhören zu warten* bedeuten, nicht zurückrollen. Ohne Cancel entfällt der
+  `opId`-Handshake; die Korrelation läuft über `taskId` bzw. das offene Modal.
+- **Keine Footer-Anzeige für laufende Operationen.** Anzeige am auslösenden Control und an der
+  Task-Zeile / im Detail-Pane. Der Footer bleibt für Fehler (`FlashFooterError`) und den
+  Worker-Log.
+- **Keine Prozent-Balken.** Die meisten Operationen haben kein sinnvolles Total.
+  `current/total` wird als Text gezeigt, nicht als Balken.
+- **Keine EF-Migration.** Damit entfällt der Trap paralleler Migrationen.
+
+## Messung
+
+„Erst messen, dann instrumentieren" gilt für Bild 1 und 3 — aber an **einer** Stelle, nicht an
+zwanzig:
+
+1. Ein Timing-Hook in `WorkerClient` loggt jeden Hub-Invoke mit Dauer.
+2. Ein zweiter im DB-Pfad der Islands.
+
+Ein Tag Nutzung liefert eine sortierte Liste echter Ausreißer. A5 und C entscheiden danach,
+statt zu raten. Bild 2 und 4 brauchen keine Messung — der Befund ist aus dem Code eindeutig.
+
+Faustregel für den Zweifelsfall: instrumentiert wird, was git aufruft, Netz nutzt, einen
+Prozess startet, oder O(n) über unbegrenzt viele DB-Zeilen läuft. Einzelzeilen-Reads nicht.
+
+## Parallelisierung: vier Merge-Helper-Gruppen
+
+Der Zuschnitt folgt dem **Datei-Eigentum**, nicht der Fachlichkeit — nur so können vier
+Sessions gleichzeitig laufen, ohne sich zu überschreiben.
+
+```
+P0 (Fundament, muss allein zuerst landen)
+ ├── Gruppe A  Bild 1: UI-Stille     (5 Pakete)
+ └── Gruppe B  Bild 2: UI-Freeze     (3 Pakete)
+
+Gruppe D  Bild 4: MCP     (4 Pakete)  ← braucht P0 NICHT, kann sofort starten
+Gruppe C  Bild 3: Worker  (5 Pakete)  ← nach P0
+```
+
+| Gruppe | Exklusiv besessene Dateien |
+|---|---|
+| **P0** | `OperationStatus.cs`, `OperationIndicator.axaml`, **beide `locales/*.json`** |
+| **A** | Island-VMs, Modal-VMs und deren AXAML |
+| **B** | `DiffViewerViewModel.cs`, `DiffTextView.axaml.cs` |
+| **C** | `HubBroadcaster`, `WorkerHub`, `WorkerClient`, `IWorkerClient`, `StubWorkerClient`, `Lifecycle/*Recovery`, `WorktreeManager` |
+| **D** | `Worker/External/*McpTools`, `ExternalMcpService` |
+
+**Der einzige echte Konfliktkandidat sind die Locale-Dateien.** A und C brauchen Keys — D
+nicht: MCP-Progress-Meldungen gehen an Agenten, nicht an den Nutzer, und bleiben englische
+Klartext-Strings ohne Locale-Eintrag.
+
+Regel: **P0 legt die Keys für A und C vorab an**, danach fasst keine Gruppe die JSONs mehr an.
+Braucht eine Gruppe doch einen nicht vorgesehenen Key, hängt sie ihn als **letzte** Änderung
+des Pakets an und behandelt ihn im Merge-Helper als bekannte Konfliktstelle.
+
+Drei erzwungene Serialisierungen:
+- `TaskMergeService` — die Parallelsession arbeitet dort; C1 danach.
+- `WorkerClient.cs` — P0-2 setzt dort den Timing-Hook, C ändert dieselbe Datei. P0 liegt
+  ohnehin vor C, damit unkritisch — aber C darf nicht vor P0 starten.
+- Innerhalb jeder Gruppe `serializeOnFileOverlap` auf der Liste setzen.
+
+Ergänzung zum Datei-Eigentum: `Services/UpdateCheckService.cs` gehört zu **A** (Paket A3),
+`Services/WorkerClient.cs` zu **C**. Beide liegen im selben Ordner, sind aber verschiedene
+Dateien.
+
+### Abhängigkeit zur Parallelarbeit
+
+Während dieses Designs hat eine andere Session im gemeinsamen `main`-Checkout das
+Merge-Feedback für das **MergeModal** implementiert — inzwischen committet als
+`cad0582 fix(merge): conventional merge-commit default and live verify progress`:
+Phasen-Broadcast in `TaskMergeService`,
+`HubBroadcaster.MergeProgress`, `IWorkerClient.MergeProgressEvent`,
+`MergeModalViewModel.ProgressMessage`, Spinner in `MergeModalView.axaml`, plus Tests.
+
+Konsequenzen:
+- Der Merge-Fall im MergeModal ist **Vorarbeit**, nicht neu zu bauen.
+- Zwei Nachbesserungen bleiben: A1 schließt den Approve-Pfad im Detail-Pane an, C1 stellt
+  Elapsed auf UI-lokalen Tick um (die Implementierung lässt den Worker alle 30 s ticken —
+  die ersten 30 Sekunden zeigt sie nur „merging").
+- Der Blocker ist damit aufgelöst: C hängt nur noch an P0, nicht mehr an der Parallelsession.
+
+## Pakete
+
+### P0 — Fundament
+
+| # | Inhalt |
+|---|---|
+| P0-1 | `OperationStatus` + `OperationIndicator` + `ops.*`-Keys **für alle vier Gruppen vorab** + `Ui.Tests` mit Fake-`TimeProvider` |
+| P0-2 | Timing-Hook in `WorkerClient` + im DB-Pfad der Islands |
+| P0-3 | Regel in `src/ClaudeDo.Ui/CLAUDE.md` und `src/ClaudeDo.Worker/CLAUDE.md`: jeder `IWorkerClient`-Call in einem `[RelayCommand]` läuft durch eine `OperationStatus`; MCP-Tools über ~5 s reporten Progress |
+
+### Gruppe A — Bild 1: UI-Stille
+
+| # | Inhalt |
+|---|---|
+| A1 | Detail-Pane: Approve & Merge, Submit for review, Reject, Park, Preview-Merge. Abonniert das Merge-Phasen-Event zum Nachschärfen des Labels |
+| A2 | WorktreesOverview: Refresh, Cleanup, Reset, ForceRemove, Batch-Merge (inkl. Zeilen-Status) |
+| A3 | Settings-Tabs: SessionSkill install/update, Restore-Defaults, OnlineInbox-SignIn, RepoImport-Scan, Update-Check |
+| A4 | Reports und Planning-UI: GenerateWeekReport, RunDailyPrepNow, BuildPlanningIntegrationBranch, GetPlanningAggregate, Finalize/QueuePlanningSubtasks |
+| A5 | Island-DB-Pfade — **nur die, die P0-2 als Ausreißer zeigt** |
+
+### Gruppe B — Bild 2: UI-Freeze
+
+| # | Inhalt |
+|---|---|
+| B1 | `UnifiedDiffParser.Parse` nach `Task.Run` + Indikator im DiffViewer |
+| B2 | `DiffAlignment.Build`: Grenze definieren (ab N Zeilen auslagern oder inkrementell aufbauen) |
+| B3 | Guard-Test: Parse/Build über ein großes Fixture blockiert den Dispatcher nicht |
+
+### Gruppe C — Bild 3: Worker-Stille
+
+| # | Inhalt |
+|---|---|
+| C1 | `OperationProgress(opKey, phase, current, total)` ersetzt `MergeProgress`; Elapsed auf UI-lokalen Tick |
+| C2 | Startup-Recovery sichtbar (6 Services) — Anzeige im Shell statt nur „reconnecting" |
+| C3 | Worktree-Anlage beim Task-Start sichtbar an der Task-Zeile. Vorher prüfen, ob der Broadcast-Gap aus dem 08-07-Spec schon geschlossen ist |
+| C4 | `RebaseOthersAfterMergeAsync` und `WorktreeMaintenanceService` in den Kanal |
+| C5 | Periodische Dienste (Usage, OnlineSync, Prime, Queue): nur Aktivität und Fehler, kein Tick-Spam |
+
+### Gruppe D — Bild 4: MCP
+
+| # | Inhalt |
+|---|---|
+| D1 | `ProgressReporter` aus `TaskMergeService.RunReportingProgressAsync` extrahieren, inkl. `i/n`-Overload |
+| D2 | Die 8 `batch_*`-Tools mit Element-Fortschritt |
+| D3 | Worktree- und Diff-Tools: `cleanup_task_worktree`, `batch_cleanup_task_worktrees`, `get_task_diff`, `preview_merge_set` |
+| D4 | Restliche Long-Runner + Doku-Regel im Worker-`CLAUDE.md` |
+
+## Test-Strategie
+
+- **`OperationStatus`**: reine Unit-Tests mit Fake-`TimeProvider` — 300-ms-Grace, 60-s-Stall,
+  Elapsed-Formatierung, `Dispose` im Exception-Fall, `Report` überschreibt Label.
+- **VM-Tests** (`Ui.Tests`, headless): Command setzt `IsRunning`, `CanExecute` sperrt während
+  des Laufs, Zustand ist nach einer Exception zurückgesetzt. Fakes: `StubWorkerClient` muss
+  bei jedem neuen Event mitwachsen.
+- **B3** ist der einzige Test, der Blockierung prüft: großes Diff-Fixture, Messung, dass der
+  Dispatcher weiter Nachrichten verarbeitet.
+- **Worker/MCP** (`Worker.Tests`): Progress-Callbacks werden mit einem Fake-`IProgress`
+  gezählt; keine echte Claude-CLI, keine echten Timeouts.
+- **Visuell**: jedes Paket in A und B hat eine offene visuelle Prüfung. Spinner, Grace-Periode
+  und Layout kann kein Test bestätigen — das läuft über den Nutzer.

docs/superpowers/specs/2026-08-11-task-numbers-design.md

@@ -0,0 +1,116 @@
+# Task Numbers (`#123`) — Design
+
+**Date:** 2026-08-11
+**Status:** approved, not implemented
+
+## Problem
+
+Tasks are only addressable by GUID. Every report from Claude reads
+"task `0ef5ga…` is done", which is unreadable and untraceable for the user. A short,
+stable, human-speakable handle is needed.
+
+## Decision
+
+Add a **global, monotonically increasing integer** `TaskEntity.Number`, displayed as `#123`.
+
+- **Global, not per list.** Per-list numbering would make `#123` ambiguous across the ~15
+  lists and would force a list argument into every lookup. Global costs nothing and is
+  unambiguous.
+- **Alias, not identity.** The GUID stays the primary key and stays in branch names
+  (`claudedo/{id}`), worktree paths, and the `ClaudeDo-Task:` commit trailer. `Number` is
+  purely a display + lookup alias.
+- **Immutable, never reused.** A number that appeared in a log must never later point at a
+  different task. Deleting tasks leaves gaps — that is correct and intended.
+
+## Allocation
+
+`MAX(number) + 1` is **wrong**: deleting the newest task frees its number for reuse.
+Use a persistent counter instead.
+
+- `app_settings.next_task_number` (INTEGER NOT NULL, singleton row — same table as
+  `MaxTurnsCeiling` etc.).
+- Allocation is one statement, atomic under SQLite's single-writer model:
+  `UPDATE app_settings SET next_task_number = next_task_number + 1
+   WHERE id = 1 RETURNING next_task_number - 1`
+  executed in the **same transaction** as the task insert.
+- `tasks.number` gets a **UNIQUE index** (`idx_tasks_number`) so a collision is a DB error,
+  not silent corruption. On a unique violation, retry the allocation (bounded, 5 attempts).
+
+Only **two** insert sites exist and both must allocate — every other creation path
+(UI, `add_task`, `batch_add_tasks`, Online Inbox sync, merge-helper handler task,
+planning children) routes through one of them:
+
+- `TaskRepository.AddAsync` (`src/ClaudeDo.Data/Repositories/TaskRepository.cs:20`)
+- `TaskRepository.AddChildAsync` (same file, ~line 297)
+
+Do **not** reuse `SortOrder` — it is per list and mutable via drag & drop.
+
+## Migration + backfill
+
+One migration, created **alone** (never in parallel with another migration — sibling
+migrations off the same parent silently drop each other's columns on a SQLite table rebuild):
+
+1. `ALTER TABLE tasks ADD COLUMN number INTEGER NOT NULL DEFAULT 0`
+2. Backfill in creation order:
+   `UPDATE tasks SET number = (SELECT COUNT(*) FROM tasks t2
+    WHERE t2.created_at < tasks.created_at OR (t2.created_at = tasks.created_at AND t2.id <= tasks.id))`
+   (or the equivalent `ROW_NUMBER()` window function).
+3. `ALTER TABLE app_settings ADD COLUMN next_task_number INTEGER NOT NULL DEFAULT 1`
+   then set it to `(SELECT COALESCE(MAX(number), 0) + 1 FROM tasks)`.
+4. Create the unique index **after** the backfill.
+
+⚠️ Tests use `EnsureCreated`, which bypasses migrations — the backfill needs a test that
+explicitly runs `Migrate()` against a DB seeded with pre-migration rows.
+
+## Resolution: `#123` → GUID
+
+New `TaskIdResolver` in `src/ClaudeDo.Worker/External/`:
+
+- Input `#123` or bare `123` (a GUID is never all-digits, so this is unambiguous) → look up
+  by number.
+- Anything else → passed through as a GUID.
+- Unknown number → a clear MCP error (`no task with number 123`), never a silent null.
+
+Wired at the top of every MCP tool taking a task id (~44 parameters across `External/`),
+including the id arrays of the `batch_*` tools.
+
+## Output surface
+
+Two central mappers cover most tools:
+
+- `ExternalMcpService.ToDto` (line ~1629) → `TaskDto`
+- `ExternalMcpService.GetTaskRefAsync` (line ~335) → `TaskRefDto`
+
+Add `Number` to both. Then the DTOs that carry a bare task id and bypass those mappers:
+`RunTaskNowResult`, `MergeTaskResultDto`, `PossibleDuplicateDto`, `SubsetRelationDto`,
+`FileOverlapDto`, the `BatchMcpTools` results, `TaskWaitMcpTools`, `QueueStateMcpTools`,
+`RunHistoryMcpTools`.
+
+`McpToolDocs` gets a shared clause instructing the agent to **refer to tasks as `#<number>`
+when reporting to the user**. Without this the number is present in the payload but never
+spoken — this clause is the actual point of the feature.
+
+## UI surface
+
+- `TaskRowViewModel.Number` → dim `#123` in the row, tokenized (no inline literals).
+- Detail pane header.
+- `HubBroadcaster.WorkerLog` business events in `TaskRunner` / `TaskMergeService` /
+  `TaskResetService` say `#123` instead of the GUID.
+
+## Out of scope (possible follow-up)
+
+Branch names and worktree folder names (`claudedo/123-<slug>`, `123-<slug>`). Cheap once
+numbers exist, but a separate change — it touches merge, self-heal, and the merge helper.
+
+## Slices
+
+| # | Slice | Depends on |
+|---|---|---|
+| 1 | Schema, counter, allocator, backfill migration + tests | — |
+| 2 | MCP output: `Number` in all task-carrying DTOs | 1 |
+| 3 | MCP input: `TaskIdResolver` + `McpToolDocs` reporting clause | 2 |
+| 4 | UI: row/detail display + worker-log messages | 1 |
+| 5 | Docs: `CLAUDE.md` (Data, Worker), explore-notes | 3, 4 |
+
+2 and 3 both edit `ExternalMcpService.cs` heavily, so 3 waits for 2 rather than running
+beside it. 4 touches disjoint files and can run beside 2.

docs/usage-optimization.md

@@ -0,0 +1,196 @@
+# Usage-Optimierung — Befunde und Messmethodik
+
+Stand: 2026-08-05. Ausgangsfrage: Wie lassen sich autonome ClaudeDo-Agents
+token-effizient betreiben? Abrechnung läuft über **Abo-Session-Limits, nicht über
+die API** — relevant ist roher Token-Verbrauch gegen 5h-/7d-Fenster, nicht Geld.
+
+Dieses Dokument ist bewusst kompakt gehalten. Was eine Session früh in den Prefix
+lädt, wird mit jeder weiteren Nachricht multipliziert (siehe Befund 5) — ein
+30k-Handover-Dokument würde das Problem reproduzieren, das es beschreibt.
+
+---
+
+## 1. Verbrauchsstruktur
+
+Gemessen über alle Transcripts unter `C:\Users\mika.kuns\.claude\projects`.
+
+| Posten | Roh-Token | Anteil |
+|---|---:|---:|
+| Cache-Read | 3.118.025.644 | 95,6 % |
+| Cache-Write | 140.783.227 | 4,3 % |
+| Output | 22.466.702 | 0,7 % |
+| Input frisch | 141.496 | 0,0 % |
+
+**Kontext-Resend = 99,3 % des Rohverbrauchs.** Auch unter API-Preisgewichtung
+(read 0,1× / write 1,25× / out 5×) bleibt es bei 81,3 %. Die Rangfolge ist gegen
+jede plausible Gewichtung robust.
+
+Verstärkung: ~3,6 Mio einzigartiger Inhalt → 1,59 Mrd abgerechnete Prompt-Token
+in ClaudeDo-Sessions. **Jeder Kontext-Token wird im Schnitt ~425× erneut
+abgerechnet.**
+
+## 2. Scope-Split — wer verbraucht
+
+| Scope | Roh-Token | Anteil |
+|---|---:|---:|
+| INTERAKTIV (Mikas eigene Sessions) | 2.690.028.785 | **81,6 %** |
+| AGENT (ClaudeDo-Runs) | 606.222.055 | **18,4 %** |
+
+Interaktiv nach Modell: opus-4-8 33,0 % · opus-5 28,5 % · sonnet-5 14,0 % ·
+fable-5 5,2 %. Agent-Runs fahren überwiegend sonnet-5 — der Default greift, die
+Modelldisziplin auf Agent-Seite ist in Ordnung.
+
+**Konsequenz:** ClaudeDo-Optimierung adressiert maximal 18 % des Limits. Der
+größere Block sind die eigenen Opus-Sessions.
+
+## 3. Session-Länge ist der Treiber
+
+Verbrauch ≈ Nachrichten × Ø-Kontext, und der Kontext wächst mit den Nachrichten →
+**quadratisch**. Eine Session in k Teile schneiden bringt grob 1/k.
+
+Interaktiv: **Top 20 von 255 Sessions = 55,9 % des Verbrauchs.**
+
+| Roh-Token | Msgs | Ø Kontext | Modell |
+|---:|---:|---:|---|
+| 199.516.097 | 716 | 278.653 | opus-4-8 |
+| 138.020.247 | 440 | 313.682 | opus-5 |
+| 123.586.522 | 463 | 266.925 | opus-4-8 |
+
+## 4. Was den Kontext füllt
+
+| Tool | Anteil (Agent) | Anteil (interaktiv) |
+|---|---:|---:|
+| Read | 59,8 % | 68,2 % |
+| Bash | 16,3 % | 15,4 % |
+| Grep | 8,3 % | 5,2 % |
+
+Read ohne `offset`/`limit`: **57 % (Agent) / 62 % (interaktiv)**.
+Re-Reads derselben Datei in derselben Session: 18 % der Read-Calls.
+Subagent-Nutzung: nur 40 Calls bei 1.325 Reads (Agent-Seite) — die
+Kontext-Firewall ist praktisch ungenutzt. Interaktiv sind Subagent-Sessions
+dagegen 20 % des Verbrauchs.
+
+Teuerste Read-Ziele sind God-Files: `TasksIslandViewModel.cs` (1121 Z.),
+`ExternalMcpService.cs` (1002 Z.), `WorkerHub.cs` (979 Z.).
+
+## 5. Prefix-Größe × Nachrichtenzahl schlägt alles
+
+Fallstudie an der Analyse-Session selbst (136 Msgs, 43.492.835 Roh-Token):
+
+```
+msg  1 :     39.914
+msg  3 :    273.822   (+233.908)  <-- claude-api-Skill geladen
+msg 136:    380.327
+```
+
+Der Skill in Nachricht 3 wurde danach 136× mitgelesen: **31,8 Mio Token = 73 %
+der Session**. Zum Vergleich: **alle tool_results zusammen = 21.600 Token
+(0,05 %)**.
+
+Discovery ist praktisch gratis, wenn man aggregiert statt Dateien dumpt. Teuer ist
+ausschließlich, was früh und groß in den Prefix wandert. Derselbe Block in
+Nachricht 120 geladen hätte ein Zwanzigstel gekostet.
+
+## 6. Amortisation von Planungssessions
+
+| Posten | Token |
+|---|---:|
+| Analyse-Session gesamt | 43,5 Mio |
+| davon vermeidbarer Prefix-Ballast | −31,8 Mio |
+| echte Planungsleistung | ≈ 11,7 Mio |
+
+Gegenrechnung: **10 von 37 Tasks brauchten einen Retry (27 %)**, 13 von 54 Runs
+sind Wiederholungen. Ein Agent-Run liegt im Schnitt bei ~11 Mio Roh-Token — ein
+vermiedener Retry spart also grob eine ganze Planungssession. Dazu ersparte
+Rediscovery: ein Fund von ~8k Token, den ein Agent in Turn 10 eines 60-Turn-Runs
+selbst machen müsste, wird danach ~50× mitgelesen = ~400k pro Fund.
+
+**Fazit: gründliche Planung rechnet sich — aber nur bei schlankem Prefix.**
+
+---
+
+## Was NICHT hilft (geprüft und verworfen)
+
+- **`--effort` senken.** Thinking ist 12.536 Token über alle interaktiven
+  Sessions = **0,00 %** des Verbrauchs. Effort zu senken spart nichts und kostet
+  Qualität. Endgültig erledigt.
+- **Skill-Trigger entschärfen.** Der `claude-api`-Skill kostete in einer Session
+  73 % — feuerte aber nur **2× in 3 Wochen** (2026-07-14, 2026-08-05). Erwarteter
+  Nutzen vernachlässigbar, Risiko (Antworten aus veraltetem Prior) real. Er hat
+  sich in dieser Session sogar bezahlt gemacht: der Hinweis, dass `input_tokens`
+  nur der uncached Rest ist, hat den Accounting-Bug aufgedeckt.
+- **God-Files splitten.** Eigenes Risiko; Read-Disziplin entschärft das Symptom
+  billiger.
+
+## Offene Hebel — noch nicht untersucht
+
+- Interaktive Session-Hygiene: ab wann lohnt `/clear`, messbar an Ø-Kontext?
+- Modellrouting interaktiv (opus-4-8 + opus-5 = 61,5 % des Accounts).
+- Subagent-Ökonomie: Firewall-Nutzen gegen Eigenverbrauch (20 % interaktiv).
+- MCP-Tool-Definitionen im Prefix: Umfang bei ~200 deferred Tools nicht gemessen.
+- Kalibrierung der tatsächlichen Limit-Gewichtung gegen die Rohtoken-Zahlen
+  (braucht `/usage`-Ausgabe; der OAuth-Endpoint ist für Claude nicht zugänglich,
+  weil `~/.claude/.credentials.json` hart blockiert ist).
+
+---
+
+## Messmethodik (reproduzierbar)
+
+Datenquelle: `C:\Users\mika.kuns\.claude\projects\**\*.jsonl`, ein Record je
+Message, Verbrauch in `message.usage`.
+
+```python
+raw = (u.get('input_tokens',0) + u.get('output_tokens',0)
+       + u.get('cache_read_input_tokens',0) + u.get('cache_creation_input_tokens',0))
+```
+
+Kontextgröße einer Message = `input_tokens + cache_read + cache_write` (ohne
+Output). Der Verlauf über die Session zeigt Prefix-Sprünge.
+
+### Fallstricke
+
+1. **Scope-Filter.** NICHT nach Pfadname `claudedo` filtern — das zieht
+   interaktive Sessions im ClaudeDo-Repo mit rein und verfälscht den Split massiv
+   (53 % statt korrekt 18,4 %). Agent-Runs erkennt man an `claudedo-worktrees`
+   oder `sandbox` im Projektordner, so wie es `TranscriptUsageReader` macht.
+2. **`<synthetic>`-Messages** überspringen — keine echten API-Calls.
+3. **`task_runs.tokens_in` ist unbrauchbar** — liest nur `input_tokens`, also den
+   uncached Rest. Lag bei einer 79-Mio-Token-Session bei 200 (Faktor ~400.000).
+   `tokens_out` zusätzlich 3,8× zu niedrig. Siehe Task `38394081`.
+4. **In Bash absolute Pfade verwenden** — `$HOME`/`~` zeigt auf dieser Maschine
+   auf das P:-Laufwerk, nicht auf `C:\Users\mika.kuns`.
+5. **DB nie direkt lesen** während die App läuft — Kopie ziehen (`todo.db` +
+   `todo.db-wal`).
+6. **Grundrate prüfen, bevor ein Hebel empfohlen wird.** Ein teurer Einzelfall ist
+   kein Muster (siehe Skill-Trigger oben).
+
+---
+
+## Abgeleitete Tasks (Liste „Claude do")
+
+Empfohlene Reihenfolge:
+
+| # | ID | Titel |
+|---|---|---|
+| 1 | `1b599d67` | Prompt-Dateien frieren Default ein — `SuggestImprovement`/`AskUser` tot |
+| 2 | `38394081` | Limit-Verbrauch pro Run sichtbar machen (Cache-Token in `task_runs`) |
+| 3 | `0d0aa8b0` | Read-Disziplin + Explorer-Subagent im System-Prompt |
+| 4 | `2de2f008` | `max_turns` deckeln (Ceiling, Defaults, UI-Warnung) |
+| 5 | `87105f5e` | UsageGate: Parallelität stufenweise drosseln |
+
+(1) zuerst, weil es ein echter Funktionsbug ist und Voraussetzung dafür, dass (3)
+den Nutzer überhaupt erreicht. (2) als Nächstes, weil ohne korrektes Accounting
+nichts messbar ist.
+
+### Ist-Zustand zum Zeitpunkt der Analyse
+
+- `app_settings`: `default_model` = sonnet, `default_max_turns` = 100,
+  `max_parallel_executions` = 3, `model_presets` = **null** (fällt auf Defaults
+  zurück: haiku 20 / sonnet 30 / opus 40 / fable 25 — greifen faktisch nie).
+- 15 Tasks überschreiben `max_turns` nach oben: 10× auf 100, 5× auf 200.
+- UsageGate existiert bereits: 5h @ 80 %, 7d @ 90 %
+  (Migration `20260805074906_AddUsageGateAndRunModel`, dieselbe Migration hat auch
+  die `model`-Spalte auf `task_runs` gebracht).
+- `~/.todo-app/prompts/system.md` stammt vom 2026-06-04 und weicht vom
+  `SystemDefault` in `PromptFiles.cs` ab; `agent.md` und `planning.md` dort sind
+  verwaiste Reste eines alten Namensschemas.

docs/verification-handoff.md

@@ -0,0 +1,113 @@
+# Verifikations-Handoff (Stand 2026-07-24)
+
+Manuelle Verifikation am laufenden System. **Mika bedient die UI, die Session protokolliert Pass/Fail** und bereitet Fixtures vor (Tasks via ClaudeDo-MCP, Git-Setups im Testrepo). Aktive Findings landen in `docs/open.md`; hier steht der Fortschritt je Abschnitt.
+
+## Handoff für die nächste Session
+
+**Erledigt (2026-07-24):** §1 Detail-Insel/Diff-Viewer (bis auf DiffModal-Fehler-State), §2 Worktree-Pipeline (alle 3), §3 Planning-Walkthrough (inkl. UnfinishedPlanning-Modal: dismiss/Finalize/Discard PASS, **Resume BUG**), §4 Merge-Editor (Single-Task **und** Planning-Unit-Konflikt **und** Abort), §6 Pick-up-Gating (Code), §7 AskUser (Happy-Path + Timeout + UI-Cleanup; Finding: Banner nur in Mission Control), §8 Session Skills (Install/Aktivierung/Seeding/Gegenprobe/Remove; Findings: fehlender Empty-State + abweichendes Agent-Gear-Icon), §9 Attachments (Drag&Drop-UI + MCP + ComposedPreview; Finding: intermittenter erster-Drop-Fehler), §12 RunNow (moot).
+
+**Noch offen:**
+- **§10 Daily Prep/Weekly** — **Bewusst zurückgestellt (2026-07-24)**: Mika will Daily Prep + Weekly Report ohnehin überarbeiten — Verifikation lohnt erst nach dem Rework.
+- **§11 Self-Update/Autostart** — **Nicht formell gefahren, aber laut Mika „läuft bisher sehr gut" (2026-07-24)** → als OK behandelt; bei Bedarf später gezielt nachtesten.
+- ~~**Kanten:** §1 DiffModal-Fehler-State, §3 UnfinishedPlanning-Modal, §4 Abort~~ — **alle erledigt (2026-07-24)**: §4 Abort PASS, §3 Modal (Finalize/Discard PASS, Resume BUG), §1 via Code-Analyse geklärt (defensiv/unerreichbar).
+
+**Vorbedingungen:** Worker + App laufen (SignalR 37821, External MCP 47822 — lt. `~/.todo-app/worker.config.json`). Testliste **`ClaudeDoTests`** (`C:\TestRepos\ClaudeDoTests`, listId `e7992fee6035448394b646d069690e05`) für zerstörungsfreie Runs.
+
+**Wichtige Gotchas / Lessons (diese Session):**
+- **NIE `model:"haiku"` für schreibende Task-/Verifikations-Runs** — unter dem Default `--permission-mode auto` werden haiku-Writes denied (still no-op). Immer **sonnet**. (Memory `auto_permission_haiku_footgun`.)
+- **Merge-Preflight blockt bei dirty Ziel-Working-Tree** (getrackte uncommittete Änderung im `main`-Checkout) — und **Approve schluckt das still** (Bug, open.md). Vor Merge-Checks `git -C C:\TestRepos\ClaudeDoTests status --short` prüfen; fremde WIP nur mit Rücksprache verwerfen (Memory `shared_worktree_partial_commits`: nur pfad-scoped committen).
+- **Konflikt-Fixture-Rezept:** Task (sonnet) überschreibt eine getrackte Datei im Branch → danach dieselbe Datei auf `main` divergent ändern + `git commit -- <pfad>` → Approve konfliktet. Für Planning-Unit-Konflikt: main-Edit erst scharfschalten, wenn der Parent in WaitingForReview steht.
+- **Datenwahrheit** notfalls direkt aus der DB: `sqlite3 -readonly ~/.todo-app/todo.db "SELECT substr(id,1,8),status,planning_phase,substr(blocked_by_task_id,1,8),title FROM tasks WHERE …"`.
+
+**Testrepo-/Fixture-Zustand:** Aufgeräumt (2026-07-24, §7+§8-Session-Ende) — alle `verif §7/§8`-Tasks gelöscht, deren Worktrees + Branches entfernt, `ClaudeDoTests`-`main` unangetastet bei `ecad650` (Tree clean; die §7-Runs liefen isoliert in Worktrees, main nie berührt). ponytail-Skills nach dem Remove-Test wieder deinstalliert (`session_skills` leer, `~/.todo-app/session-skills/` leer). Keine `verif`-Tasks und keine claudedotests-Worktrees übrig. Die übrigen `claudedo/*`-Branches im Testrepo stammen aus früheren Sessions — nicht anfassen. **Die nächste Session baut Fixtures frisch** (Rezepte s. Gotchas oben).
+
+**Erfasste Folge-Tasks** (Liste „Claude do", Idle, brauchen Brainstorm vor Umsetzung): `f9809a93` Approve erzwingt Diff/Review vor Merge (+ blocked-Merge-Silent-Fail-Fix), `5d627df8` Planning-Session über embedded ConPTY statt wt (+ Planning-Permission-Prompt).
+
+**Fix-Session:** Alle fixbaren Findings sind für eine frische Session in **`docs/fix-plan-2026-07-24.md`** aufbereitet (gruppiert nach Fixbarkeit: A mechanisch, B error-surfacing, C entscheidungsbedürftig, D investigation, E nits). Volltext je Finding bleibt in `docs/open.md`.
+
+**Nacharbeit:** Erledigtes aus `docs/open.md` austragen; dieses File löschen, sobald §10 (nach Rework) + evtl. §11-Nachtest erledigt sind.
+
+---
+
+## 1. Detail-Insel & Diff-Viewer (reines Durchklicken)
+
+- [~] Detail-Insel komplett: Output/Git/Session-Tabs, Merge-Sektion, Agent-Settings-Overrides (InheritedBadge korrekt), Prep-Panel — nach dem VM-Split (`DetailsIslandViewModel` → Sektions-VMs) alles gebunden, keine leeren Panels. — **TEILWEISE (2026-07-24, User-Sichtprüfung an `verif §1 diff matrix`):** Output/Git-Tabs, Merge-Sektion, Agent-Badges vorhanden & gebunden, keine leeren Panels. Git-Tab: `+1 −37`, „merges cleanly" korrekt. **BUG:** OUTCOME-Karte zeigt rohes JSON (s. open.md). Session-Tab fehlt — **erwartet** (nur bei Parent mit Kindern, `HasChildOutcomes`; wird in §4/§3 mit echtem Parent geprüft). Minor: TurnsText `0/max` bei terminalem Reload (open.md). Prep-Panel → §10.
+- [~] Diff-Viewer: Dateiliste, Added/Deleted/Renamed/Binary-Erkennung, Commit-Range-Diff nach einem Merge. — **Added/Deleted/Binary PASS**; **Renamed** erkannt + „R"-Badge, aber schwach dargestellt (kein alt→neu-Pfad, „+0 −0" — nit, s. open.md); „Review Combined Diff" korrekt ausgegraut (kein Planning-Parent). **Commit-Range-Diff nach Merge: PASS (2026-07-24)** — Diff des gemergten Done-Tasks rendert über `base..head` trotz entferntem Worktree.
+- [x] DiffModal-Fehler-State: Commit-Range ohne aufgezeichnete Commits → „Diff nicht mehr verfügbar" statt Crash/leer. — **GEKLÄRT via Code-Analyse (2026-07-24): der Fehler-State ist defensiv/unerreichbar.** `vm.diff.unavailable` (DiffViewerViewModel.cs:117-119) feuert nur bei `FromCommitRange && (BaseRef==null || HeadCommit==null)` oder `WorktreePath==null`. Alle Aufrufer sind gegated: `MergeSectionViewModel.OpenDiffAsync` ruft `ConfigureCommitRange` nur unter `CanDiffMergedRange` (base **und** head non-null) und `ConfigureWorktree` nur unter `hasLiveWorktree` (Pfad non-null + existiert); `WorktreesOverviewModalViewModel` übergibt `row.Path` (non-null). Damit können die Null-Checks über die UI nie wahr werden — der „Crash/leer"-Fall, den der Check absichern wollte, ist durch die CanExecute-/Modus-Gates ausgeschlossen. (Fehlende Commit-Objekte bei vorhandenem base+head → `GetCommitRangeDiffAsync` wirft → „loadFailed", nicht „unavailable".) Nicht manuell auslösbar; kein Bug.
+- [x] „children need attention"-Band auf dem Session-Tab eines Parents mit failed/blocked Kind. — **PASS (2026-07-24, in §3)**: Band + OUTCOMES-Liste mit Roadblock-Hinweis auf dem Session-Tab des Planning-Parents (`verif §3`, Roadblock-Kind).
+
+## 2. Worktree-Pipeline (3 falsifizierbare Fälle)
+
+- [x] Happy-Path: Task mit WorkingDir → `worktrees.state='active'`, `head_commit` gesetzt, `diff_stat` non-empty, Branch `claudedo/<id[:8]>` existiert auf Disk. — **PASS (2026-07-24)** via Task `e63eb2f5` (sonnet): Worktree active, `headCommit 8a3ae86` (ahead=1 vom Base), `diff_stat` non-empty (`review-cancel.txt`), Branch `claudedo/e63eb2f5…` auf Disk. (Mein erster Versuch mit `model=haiku` schlug fehl — das war ein haiku/auto-Footgun, keine Pipeline-Sache; s. open.md.)
+- [x] No-Changes-Run: → `status='Done'`, `head_commit IS NULL`, `diff_stat IS NULL`. — **PASS (2026-07-24)**; Präzisierung: aktueller Flow endet in `WaitingForReview` (nicht `Done`, das ist erst nach Approve) — Doc-„Done" ist veraltet. Kein neuer Commit, leerer Diff bestätigt.
+- [x] Kein Git-Repo (WorkingDir = `C:\Temp`): → `status='Failed'`, KEINE `worktrees`-Row, Git-Fehler im Log. — **PASS (2026-07-24)**; Fehler: „Worktree creation failed: working_dir is not a git repository".
+
+## 3. Planning-Flow-Walkthrough
+
+- [x] Draft → Finalize → Kette: Finalize queued NICHT automatisch (Kinder bleiben Idle); „Queue plan" setzt alle nicht-terminalen Kinder Queued, Kette läuft sequenziell durch (blocked-by löst sich je Vorgänger). — **PASS (2026-07-24, End-to-End mit `verif §3`)**: 3 Kinder gedraftet, Finalize → Parent WaitingForChildren+finalized, Kinder Idle+Kette (clean→conflict→roadblock), Queue plan → sequenzieller Durchlauf, alle Done. **Begleit-Findings (open.md):** „Waiting for Improvements"-Mislabel, Kind-Badge-Live-Refresh (Draft→Planned erst nach Listenwechsel), Kette nicht visualisiert, planning-aktiver Parent zeigt „Idle", Dequeue-X fehlt auf wartenden Kindern, Planning-Permission-Prompt, Planning nutzt wt statt ConPTY.
+- [x] Parent landet nach letztem terminalen Kind in WaitingForReview; Approve merged die ganze Unit (Parent-Worktree falls Active + jedes Done-Kind in Reihenfolge). — **PASS (2026-07-24)**: Parent → WaitingForReview auch mit Roadblock-Kind; Approve → Unit-Merge (child-clean clean, child-conflict → Konflikt-Editor pro Subtask → aufgelöst → Continue, child-roadblock no-op) → Parent Done, Merge gelandet.
+- [x] UnfinishedPlanning-Modal: Resume / FinalizeNow / Discard. — **GETESTET (2026-07-24, `verif §3 unfinished-planning` + `verif §3 resume-discard`)**: Modal wird via Rechtsklick→„Resume planning session" ausgelöst, zeigt Titel + „N draft task(s) waiting to be finalized" + Buttons Discard/Finalize/Resume + ×. **× (dismiss)**: No-op (State bleibt `active`). **Finalize**: Parent → `finalized`+`WaitingForChildren`, Kinder Idle+Blocked-by-Kette (= Planned) — PASS. **Discard**: Draft-Kinder gelöscht, Parent → `none`+`idle` — funktional PASS. **Resume: BUG — macht nichts** (`planning_session_id` nie erfasst → `ResumeAsync` wirft „No Claude session ID captured yet", vom UI im leeren `catch` verschluckt; s. open.md). Beide State-ändernden Aktionen reproduzieren das Kind-Rows-Live-Refresh-Finding (Finalize: Badges stale; Discard: gelöschte Rows bleiben bis Reload; open.md).
+
+## 4. Merge-Editor (Rider-Style 3-Pane) mit echtem Konflikt
+
+Konflikt provozieren: gleiche Datei auf main ändern, während der Task-Branch sie ändert. Beide Wege testen: **(a)** Single-Task-Approve mit Konflikt, **(b)** Planning-Unit-Merge mit Konflikt in einem Subtask (`PlanningMergeConflict` → Editor öffnet pro Subtask).
+
+**Verifiziert 2026-07-24 (Single-Task-Approve mit Konflikt, 2 Dateien, `verif §4`): End-to-End PASS** — Approve→Konflikt→3-Pane-Resolver→beide Dateien auflösen→Continue→Merge→Task Done (Merge-Commit gelandet). Sauberer additiver Approve (`verif §1b`, kein Konflikt) → direkt gemergt → Done, kein Editor: **PASS (2026-07-24)**. ⚠ **Vorbedingung-Fund:** ein dirty Ziel-Working-Tree (getrackte uncommittete Änderung) blockt den Merge und Approve schluckt das **still** (s. open.md „Approve & Merge schluckt blocked"). Planning-Unit-Merge-Konflikt (Weg b): **PASS (2026-07-24, in §3)** — Approve eines Planning-Parents mit einem konfliktenden Subtask öffnet den 3-Pane-Editor pro Subtask (`PlanningMergeConflict`), Continue führt den Unit-Merge fort → Parent Done.
+
+- [x] Drei Panes: MAIN read-only | Result editierbar | INCOMING read-only; Konfliktblöcke rot, aufgelöst grün, in allen Panes. — **PASS**.
+- [x] Gutter-Toggle `›`/`‹`: Seite rein/raus, Klickreihenfolge = Reihenfolge im Result; main/incoming/beide/keine möglich. — **PASS**.
+- [x] Nur Konfliktregionen im Result editierbar (Stable read-only); Edits fließen in den Block zurück. — **PASS**.
+- [~] Synchrones vertikales Scrollen; File-Switcher bei mehreren Dateien; `M conflicts · K resolved`-Readout; Conflict-Ruler (Klick springt). — **PASS**, aber **Multi-File schlecht erkennbar** (2 Konfliktdateien schwer zu sehen — UX-Nit, open.md).
+- [~] Continue erst aktiv, wenn ALLE Konflikte in ALLEN Dateien gelöst; Binär-Guard greift. — **funktional PASS** (merged erst nach Auflösung beider Dateien), aber **Button ist klickbar statt disabled** solange offen → stummer No-op (UX-Bug, open.md). Binär-Guard hier n/a.
+- [x] Abort: Tree sauber, Task bleibt WaitingForReview. — **PASS (2026-07-24, `verif §4 abort`)**: Single-Task-Approve mit divergentem main→Konflikt→3-Pane-Editor→**Abort**: Editor schließt, Task bleibt `WaitingForReview`, `main`-Tree sauber (kein `MERGE_HEAD`, kein dirty), `main`-Inhalt + HEAD unverändert.
+- [FEATURE-WUNSCH] farbliches Hervorheben der übernommenen/eingefügten Zeilen im Result-Pane (open.md).
+- Bekannte Kanten (nur gegenprüfen, nicht als Fail werten): leere Ours-Seite → null-lange Result-Region (Accept geht, Handtippen fummelig); Gutter-Y-Ausrichtung bei sehr hohen Fenstern/großem Scroll; vertikaler Drift nachfolgender Blöcke nach Konflikt mit ungleicher Zeilenzahl.
+
+## 5. Embedded ConPTY / Mission Control
+
+- [x] **Kritisch:** Task-basiert (Kontextmenü „Open ConPTY session"): frischer Task → Worktree wird on-demand angelegt, `claude` startet — Task-Prompt wirklich GESENDET. — **PASS (2026-07-24)**: Agent antwortete mit dem Marker `CONPTY-PROMPT-RECEIVED-4Q7`, Worktree on-demand angelegt.
+- [~] Ad-hoc: „New session"-Button → Ordnerwahl → freie Session im gewählten Verzeichnis. — **funktioniert, aber Button unsichtbar**: `Icon.Plus` ist Strich-Only → `PathIcon` rendert nichts (Bug, open.md). Über Tooltip/Klick auf die leere Header-Fläche erreichbar; Ordnerwahl + Ad-hoc-Session funktionieren.
+- [x] Grid↔Tabs-Toggle; Close killt den Prozess + entfernt die Kachel; mehrere Sessions parallel; Pane-Resize reflowt das TUI. — **PASS (2026-07-24)**: Resize/Reflow ok; Close entfernt Kachel UND killt den Prozess (verifiziert: ConPTY-PID 50964, Kind von ClaudeDo.App, nach Close tot).
+- [~] Resume: im Worktree-Dir per `claude --continue` möglich (ClaudeDo persistiert die ConPTY-Session-Id bewusst nicht). — **wie designt**: erneutes „Open ConPTY session" resumt NICHT, sondern startet frisch und **sendet den Prompt erneut** (UX-Falle, open.md). In-App-Resume gibt es nicht; nur claude-eigenes `--continue`/`--resume` im Worktree-Dir.
+
+## 6. Pick up in terminal
+
+- [x] Sichtbarkeit: Kontextmenü-Eintrag + Terminal-Button (ArrowOut) NUR bei WaitingForReview und Failed; bei Idle/Running/Queued/Done nicht. — **PASS (2026-07-24, Code+Test)**: `CanPickUpInTerminal => Status is WaitingForReview or Failed` (TaskRowViewModel.cs:69, DetailsIslandViewModel.cs:898), gebunden in TaskRowView.axaml:56 + TaskHeaderBar.axaml:34, Notify bei Statuswechsel, Unit-Test `CanPickUpInTerminal_OnlyForReviewOrFailed`. (Klick→Terminal + Fehler-Surfacing bleiben manueller UI/CLI-Check.)
+- [ ] Klick → neues Windows-Terminal im Worktree-Verzeichnis, `claude --resume <id>` nimmt die Session mit Kontext wieder auf.
+- [ ] Fehlerfälle surfacen sauber (Footer-Strip bzw. Fehlerdialog): laufende/gequeuete Task, keine persistierte Session-Id, kein aktiver Worktree.
+- Bekannte Kante: parked-Idle (reject-park) hat oft Session+Worktree, zeigt die Aktion aber bewusst NICHT (Idle nicht unterscheidbar). Nervt das in der Praxis → `CanPickUpInTerminal` erweitern.
+
+## 7. AskUser (Frage aus laufendem Task)
+
+Runtime-Toolname ist `mcp__claudedo_run__ask_user` (snake_case, nicht `AskUser`). Fixture: sonnet-Task mit Prompt „zwei sich widersprechende, irreversible Optionen — du MUSST `ask_user` fragen, nicht raten" erzwingt den Call zuverlässig.
+
+- [x] Task, dessen Prompt eine Rückfrage erzwingt → Frage erscheint im Task-Monitor (Mission Control), Prozess wartet. — **PASS (2026-07-24, `verif §7 askuser 2`)**: Banner in Mission Control, Run blockiert im `ask_user`-Tool-Call. **BUG:** in der Task-Detail-Insel erscheint KEIN Banner (nur Mission Control) → s. open.md.
+- [x] Antwort inline absenden → Run läuft mit der Antwort weiter. — **PASS (2026-07-24)**: Antwort „A" inline gesendet → Agent bekam „option A", benannte `merge-playground.txt` → `renamed-by-agent.txt` um, schrieb `askuser-result.txt` = „USER CHOSE: A", Task → WaitingForReview.
+- [x] Timeout-/Cleanup-Verhalten der PendingQuestionRegistry (Frage unbeantwortet lassen): Task schlägt kontrolliert fehl, UI räumt die Frage auf (MCP_TOOL_TIMEOUT-Gotcha). — **PASS (2026-07-24)**: Backend (`verif §7 askuser`) nach exakt 3 min Fallback zurück, Agent hielt sich an „MUST NOT guess", meldete `CLAUDEDO_BLOCKED`, Repo untouched, Registry im `finally` aufgeräumt, Run endete `success` → WaitingForReview. **UI-Cleanup visuell bestätigt** (`verif §7 timeout-ui`, MC-Kachel offen/subscribt bis zum Timeout): Banner verschwindet beim Timeout automatisch (`TaskQuestionResolved` → `ClearPendingQuestion`).
+
+## 8. Session Skills (E2E + UI)
+
+- [x] Settings → Skills: `https://github.com/DietrichGebert/ponytail` installieren → 6 Skills erscheinen (ponytail, -help, -review, -audit, -debt, -gain), auf Commit gepinnt, Dateien unter `~/.todo-app/session-skills/<name>/`. — **PASS (2026-07-24)**: 6 Rows in `session_skills`, alle auf Commit `16f29800` gepinnt, `subpath=skills/<name>`, Dateien inkl. `SKILL.md` am erwarteten Ort. UI-Install nahm die URL an. **Nit:** Skills-Tab hat keinen Empty-State (s. open.md).
+- [x] Skill per-Task (Agent-Settings-Flyout) oder global aktivieren → Task laufen lassen → im Worktree liegt `.claude/skills/<name>/`, Agent kann ihn nutzen, `git status` im Worktree bleibt sauber (info/exclude greift). — **PASS (2026-07-24, per-Task, `verif §8 skill-activate`)**: `ponytail-help` per Flyout aktiviert (`task.SessionSkills=["ponytail-help"]`), Run → `.claude/skills/ponytail-help/SKILL.md` im Worktree, `info/exclude` bekam `/.claude/skills/ponytail-help/`, `git status` clean, Auto-Commit enthält NUR `skill-proof.txt` (Skill NICHT im Tree). Agent hat den Skill nachweislich genutzt (`skill-proof.txt` = ponytail-help-Referenzkarte verbatim). Global-Aktivierung (AppSettings.SessionSkills, General-Tab) nutzt denselben Seeding-Union-Pfad — funktional äquivalent, nicht separat gefahren.
+- [x] Gegenprobe: nicht-aktivierte/andere interaktive Session sieht den Skill NICHT (kein Leak nach `~/.claude`). — **PASS (2026-07-24)**: `~/.claude/skills/` enthält nur die vorbestehenden globalen Skills, KEIN ponytail. Seeder schreibt per Konstruktion nur nach `<workingDir>/.claude/skills` (SessionSkillSeeder), nie nach `~/.claude`.
+- [~] UI: Skills-Tab (Install-Zeile, Karten mit Update/Remove), Checkbox-Listen im General-Tab + AgentConfigEditor (Flyout-Höhe!), leerer Zustand (0 Skills — Empty-State fehlt evtl., dann entscheiden), lange Namen/URLs (Trimming). — **TEILWEISE (2026-07-24)**: Install-Zeile nimmt URL an (PASS); AgentConfigEditor-Flyout-Checkbox-Liste zeigt alle 6 Skills, Höhe ok, Trimming ok (User: „funktioniert wie erhofft"). **Empty-State fehlt** (nackte Fläche — open.md). **Agent-Settings-Gear ⚙ weicht vom Listen-Gear ab** (open.md). Skills-Tab-**Karten** (Name/Beschreibung/Pinned-Commit + Update/Remove) und **General-Tab-Checkbox-Liste** (6 Skills) sichtgeprüft (User: „sieht alles gut aus"). **Remove PASS (2026-07-24)**: ein Remove-Klick auf eine ponytail-Karte entfernte alle 6 Skills per Quell-URL (`session_skills` leer, alle Verzeichnisse unter `~/.todo-app/session-skills/` weg). **Update** nicht separat gefahren (Code-Pfad `SessionSkillRegistry.UpdateAsync`).
+
+## 9. Attachments (Drag & Drop + MCP)
+
+- [x] Drop aufs Detail-Pane: „Drop to attach"-Overlay, Datei erscheint in der Liste, landet unter `~/.todo-app/attachments/<taskId>/`; „Add file…"-Picker; Remove-Button. — **PASS (2026-07-24, `verif §9 attachments-ui`)**: Overlay/Highlight beim Drüberziehen, Drop-Round-Trip (`drop-me.txt` in Liste + Disk + DB, 29 B), „Add file…"-Picker (`pick-me.md`), Remove (Datei aus Liste + Disk + DB) — alle bestätigt. **Finding:** der ALLERERSTE Drop der Session schlug einmalig mit inline „An error occurred" fehl (nichts persistiert), danach fehlerfrei — intermittierend, nicht reproduzierbar (s. open.md).
+- [x] `ComposedPreview` enthält die Attachment-Pfade („## Reference files"). — **PASS (2026-07-24, Code+Test)**: TaskPromptComposer.cs:31 emittiert „## Reference files", ComposedPreview reicht Pfade durch, TaskRunner.cs:132 injiziert zur Laufzeit; TaskPromptComposerTests decken es ab.
+- [x] MCP: `add_task_attachment` / `list_task_attachments` / `remove_task_attachment`; Running-Task verweigert add/remove. — **PASS (2026-07-24)** für add/list/remove-Round-Trip inkl. Datei unter `~/.todo-app/attachments/<taskId>/` (71 B, korrekt, nach Remove weg). Running-Task-Verweigerung ist code-guarded (AttachmentMcpTools), aber ohne dauerhaft laufende Task nicht live geprüft → manueller Rest.
+
+## 10. Daily Prep (Prime) & Weekly Report
+
+- [ ] Prime-Trigger: Schedule feuert bzw. „Plan day" manuell → Prep-Log streamt live, `daily-prep.log` enthält letzten Run, MyDay-Auswahl respektiert `DailyPrepMaxTasks`.
+- [ ] Weekly Report: Range-Default „seit letztem Standup-Wochentag → heute", Markdown rendert, Cache pro Range.
+
+## 11. Self-Update & Autostart (am Gerät)
+
+- [ ] Update-Banner → Update durchführen → danach „up to date".
+- [ ] Autostart: Logoff/Logon startet den Worker (Startup-`.lnk`); Update-Pfad erhält den Autostart; Uninstall entfernt die `.lnk`.
+
+## 12. Status-Bar / RunNow (Mini-Codecheck, erst messen)
+
+- [x] Worker trennen/verbinden → prüfen, ob RunNow-Enable pro Task-Row sauber re-evaluiert (Connection-State lebt in `IslandsShellViewModel`). Nur fixen, wenn tatsächlich kaputt. — **PASS/moot (2026-07-24, Code)**: Es gibt kein per-Row-RunNow-Control in der UI; `RunNowAsync` (IWorkerClient/WorkerClient) hat keinen VM/View-Aufrufer (RunNow nur via MCP `run_task_now`). Die realen Detail-Pane-Aktionen (Enqueue/Dequeue/Continue/ResetAndRetry) re-evaluieren korrekt bei Connection-Change (DetailsIslandViewModel.cs:317-323). Nebenbefund: `RunNowAsync` in der UI ist toter Code.

src/ClaudeDo.App/App.axaml

@@ -21,6 +21,8 @@
             <converters:DotBrushConverter          x:Key="DotBrush"/>
             <converters:BoolToItalicConverter      x:Key="BoolToItalic"/>
             <converters:BoolToDraftOpacityConverter x:Key="BoolToDraftOpacity"/>
+            <converters:LogKindForegroundConverter  x:Key="LogKindForeground"/>
+            <converters:KeepLastNumberConverter     x:Key="KeepLastNumber"/>
 
         </ResourceDictionary>
     </Application.Resources>
@@ -31,6 +33,7 @@
 
     <Application.Styles>
         <FluentTheme />
+        <StyleInclude Source="avares://AvaloniaEdit/Themes/Fluent/AvaloniaEdit.xaml" />
         <StyleInclude Source="avares://ClaudeDo.Ui/Design/IslandStyles.axaml" />
         <!-- Global defaults: every Window inherits Inter Tight + body size.
              Controls that need mono opt in via their own class/style. -->

src/ClaudeDo.App/App.axaml.cs

@@ -1,7 +1,11 @@
 using System;
 using Avalonia;
+using Avalonia.Controls;
 using Avalonia.Controls.ApplicationLifetimes;
 using Avalonia.Markup.Xaml;
+using Avalonia.Threading;
+using ClaudeDo.Ui;
+using ClaudeDo.Ui.Localization;
 using ClaudeDo.Ui.Services;
 using ClaudeDo.Ui.ViewModels;
 using ClaudeDo.Ui.Views;
@@ -21,6 +25,8 @@ public partial class App : Application
     public override void Initialize()
     {
         AvaloniaXamlLoader.Load(this);
+        if (_services?.GetService<AppSettings>() is { } settings)
+            AccentPresetService.Apply(AccentPresets.Find(settings.AccentPreset));
     }
 
     public override void OnFrameworkInitializationCompleted()
@@ -32,9 +38,26 @@ public partial class App : Application
 
             FocusClearing.Install();
 
+            // The main window is authoritative — closing it shuts the app down even if the
+            // modeless Mission Control window is still open.
+            desktop.ShutdownMode = ShutdownMode.OnMainWindowClose;
+
+            var shell = services.GetRequiredService<IslandsShellViewModel>();
+
+            // Last-resort backstop: an exception escaping a dispatcher job kills the process, and
+            // ClaudeDo hosts third-party UI (the ConPTY terminal control) whose async void key and
+            // render handlers have done exactly that — one bad keystroke took the whole app down,
+            // losing every open session. Swallowing is the lesser evil here: the failing job is
+            // already dead either way, and the user still gets told via the footer error strip.
+            Dispatcher.UIThread.UnhandledException += (_, e) =>
+            {
+                e.Handled = true;
+                shell.FlashFooterError(Loc.T("vm.shell.unexpectedError", e.Exception.Message));
+            };
+
             desktop.MainWindow = new MainWindow
             {
-                DataContext = services.GetRequiredService<IslandsShellViewModel>(),
+                DataContext = shell,
             };
 
             // Kick off the SignalR retry loop — reconnects indefinitely if the worker

src/ClaudeDo.App/CLAUDE.md

@@ -8,19 +8,13 @@ Desktop entry point for the ClaudeDo application. Configures DI, initializes the
 - `App.axaml` / `App.axaml.cs` — Avalonia application lifecycle, main window creation, static `ServiceProvider` accessor
 - `ViewLocator.cs` — reflection-based IDataTemplate that maps ViewModels to Views by naming convention
 
-## Dependencies
-
-- Avalonia 12.0.0 (Desktop, Fluent theme, Inter fonts)
-- CommunityToolkit.Mvvm 8.4.1
-- Microsoft.Extensions.DependencyInjection 8.0.1
-- Microsoft.AspNetCore.SignalR.Client 8.0.11
-- Microsoft.Data.Sqlite 8.0.11
-- Project references: ClaudeDo.Data, ClaudeDo.Ui
+Project references: `ClaudeDo.Data`, `ClaudeDo.Ui`. Package versions are in the `.csproj` — see
+the root CLAUDE.md for the tech stack.
 
 ## DI Registration Pattern
 
-- **Singletons**: `IDbContextFactory`, all Repositories, GitService, WorkerClient, `IReleaseClient`, `InstallerLocator` / `WorkerLocator`, the island VMs (`ListsIslandViewModel`, `TasksIslandViewModel`, `DetailsIslandViewModel`) and `IslandsShellViewModel` (the window's DataContext)
-- **Transients**: modal VMs (`SettingsModalViewModel`, `MergeModalViewModel`, `ListSettingsModalViewModel`, `RepoImportModalViewModel`, `WorktreeModalViewModel`, `WorktreesOverviewModalViewModel`, `PrimeClaudeTabViewModel`), several exposed as `Func<T>` factories for on-demand dialog creation
+- **Singletons** — `IDbContextFactory`, all repositories, `GitService`, `WorkerClient`, `IReleaseClient`, `UpdateCheckService`, `IPrimeScheduleApi`, `INotesApi`, `InstallerLocator`/`WorkerLocator`, the three island VMs, and `IslandsShellViewModel` (the window's DataContext)
+- **Transients** — modal VMs, several exposed as `Func<T>` factories for on-demand dialog creation (e.g. `Func<DiffViewerViewModel>`). `ConflictResolverViewModel` uses a `Func<string, ConflictResolverViewModel>` factory keyed by taskId (singleton factory, handed to `IslandsShellViewModel.ConflictResolverFactory`).
 
 ## Notes
 

src/ClaudeDo.App/ClaudeDo.App.csproj

@@ -14,10 +14,12 @@
   </ItemGroup>
 
   <ItemGroup>
-    <PackageReference Include="Avalonia" Version="12.0.0" />
-    <PackageReference Include="Avalonia.Desktop" Version="12.0.0" />
-    <PackageReference Include="Avalonia.Themes.Fluent" Version="12.0.0" />
-    <PackageReference Include="Avalonia.Fonts.Inter" Version="12.0.0" />
+    <PackageReference Include="Avalonia" Version="12.0.4" />
+    <PackageReference Include="Avalonia.Desktop" Version="12.0.4" />
+    <PackageReference Include="Avalonia.Themes.Fluent" Version="12.0.4" />
+    <PackageReference Include="Avalonia.Fonts.Inter" Version="12.0.4" />
+    <!-- Direct ref so the App.axaml AvaloniaEdit theme (avares://AvaloniaEdit/...) resolves at runtime. -->
+    <PackageReference Include="Avalonia.AvaloniaEdit" Version="12.0.0" />
     <PackageReference Include="AvaloniaUI.DiagnosticsSupport" Version="2.2.0">
       <IncludeAssets Condition="'$(Configuration)' != 'Debug'">None</IncludeAssets>
       <PrivateAssets Condition="'$(Configuration)' != 'Debug'">All</PrivateAssets>

src/ClaudeDo.App/Program.cs

@@ -52,8 +52,14 @@ sealed class Program
             // Dispose the container so WorkerClient.DisposeAsync runs —
             // cancels the retry loop and closes the SignalR connection cleanly
             // instead of abandoning it.
-            try { services.DisposeAsync().AsTask().GetAwaiter().GetResult(); }
-            catch { /* best effort on shutdown */ }
+            try
+            {
+                services.DisposeAsync().AsTask().GetAwaiter().GetResult();
+            }
+            catch
+            {
+                /* best effort on shutdown */
+            }
         }
     }
 
@@ -102,7 +108,9 @@ sealed class Program
         sc.AddSingleton<IWorkerClient>(sp => sp.GetRequiredService<WorkerClient>());
 
         // Release check + installer update
-        sc.AddSingleton<HttpClient>(_ => new HttpClient { Timeout = TimeSpan.FromSeconds(10) });
+        sc.AddSingleton<HttpClient>(_ =>
+            new HttpClient(new SocketsHttpHandler { PooledConnectionLifetime = TimeSpan.FromMinutes(5) })
+                { Timeout = TimeSpan.FromSeconds(10) });
         sc.AddSingleton<IReleaseClient>(sp => new ReleaseClient(sp.GetRequiredService<HttpClient>()));
         sc.AddSingleton<InstallerLocator>();
         sc.AddSingleton<WorkerLocator>();
@@ -111,18 +119,27 @@ sealed class Program
             var releases = sp.GetRequiredService<IReleaseClient>();
             var informational = Assembly.GetEntryAssembly()?
                 .GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion;
-            // Strip MinVer build metadata ("+sha") and any prerelease suffix for the update-compare.
+            // Strip MinVer build metadata ("+sha") only — keep the prerelease suffix
+            // (e.g. "-alpha.0.14"), VersionComparer needs it to tell a dev build on
+            // main apart from a tagged release of the same numeric core.
             var version = (informational ?? "0.0.0").Split('+')[0];
             return new UpdateCheckService(releases, version);
         });
 
+        // Conflict-merge coordinator: single seam the shell wires to its resolver entry.
+        sc.AddSingleton<MergeCoordinator>();
+        sc.AddSingleton<IMergeCoordinator>(sp => sp.GetRequiredService<MergeCoordinator>());
+
         // ViewModels
-        sc.AddTransient<WorktreeModalViewModel>();
-        sc.AddTransient<Func<WorktreeModalViewModel>>(sp => () => sp.GetRequiredService<WorktreeModalViewModel>());
+        sc.AddTransient<DiffViewerViewModel>();
+        sc.AddTransient<Func<DiffViewerViewModel>>(sp => () => sp.GetRequiredService<DiffViewerViewModel>());
         sc.AddTransient<WorktreesOverviewModalViewModel>();
-        sc.AddTransient<Func<WorktreesOverviewModalViewModel>>(sp => () => sp.GetRequiredService<WorktreesOverviewModalViewModel>());
+        sc.AddTransient<Func<WorktreesOverviewModalViewModel>>(sp =>
+            () => sp.GetRequiredService<WorktreesOverviewModalViewModel>());
+        sc.AddTransient<MergeHelperSelectionModalViewModel>();
         sc.AddSingleton<IPrimeScheduleApi, WorkerPrimeScheduleApi>();
         sc.AddSingleton<INotesApi, WorkerNotesApi>();
+        sc.AddSingleton<IOnlineLoginService, OnlineLoginService>();
         sc.AddTransient<PrimeClaudeTabViewModel>();
         sc.AddTransient<SettingsModalViewModel>();
         sc.AddTransient<MergeModalViewModel>();
@@ -131,25 +148,47 @@ sealed class Program
         sc.AddTransient<RepoImportModalViewModel>();
         sc.AddTransient<Func<RepoImportModalViewModel>>(sp => () => sp.GetRequiredService<RepoImportModalViewModel>());
         sc.AddTransient<WeeklyReportModalViewModel>();
-        sc.AddTransient<Func<WeeklyReportModalViewModel>>(sp => () => sp.GetRequiredService<WeeklyReportModalViewModel>());
+        sc.AddTransient<Func<WeeklyReportModalViewModel>>(sp =>
+            () => sp.GetRequiredService<WeeklyReportModalViewModel>());
+        sc.AddTransient<UsageMonitorModalViewModel>();
+        sc.AddTransient<Func<UsageMonitorModalViewModel>>(sp =>
+            () => sp.GetRequiredService<UsageMonitorModalViewModel>());
+        sc.AddSingleton<Func<string, ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel>>(sp =>
+            taskId => new ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel(
+                sp.GetRequiredService<IWorkerClient>(), taskId));
 
         // Islands shell VMs
         sc.AddSingleton<ListsIslandViewModel>(sp =>
             new ListsIslandViewModel(
                 sp.GetRequiredService<IDbContextFactory<ClaudeDoDbContext>>(),
                 sp,
-                sp.GetRequiredService<WorkerClient>()));
+                sp.GetRequiredService<IWorkerClient>()));
         sc.AddSingleton<TasksIslandViewModel>(sp =>
             new TasksIslandViewModel(
                 sp.GetRequiredService<IDbContextFactory<ClaudeDoDbContext>>(),
-                sp.GetRequiredService<WorkerClient>()));
+                sp.GetRequiredService<IWorkerClient>()));
         sc.AddSingleton<DetailsIslandViewModel>(sp =>
             new DetailsIslandViewModel(
                 sp.GetRequiredService<IDbContextFactory<ClaudeDoDbContext>>(),
-                sp.GetRequiredService<WorkerClient>(),
+                sp.GetRequiredService<IWorkerClient>(),
                 sp,
-                sp.GetRequiredService<INotesApi>()));
-        sc.AddSingleton<IslandsShellViewModel>();
+                sp.GetRequiredService<INotesApi>(),
+                sp.GetRequiredService<IMergeCoordinator>()));
+        sc.AddSingleton<UsagePillViewModel>(sp =>
+            new UsagePillViewModel(sp.GetRequiredService<IWorkerClient>()));
+        sc.AddSingleton<MissionControlViewModel>(sp =>
+            new MissionControlViewModel(
+                sp.GetRequiredService<IDbContextFactory<ClaudeDoDbContext>>(),
+                sp.GetRequiredService<IWorkerClient>(),
+                sp.GetRequiredService<UsagePillViewModel>()));
+        sc.AddSingleton<IslandsShellViewModel>(sp =>
+        {
+            var shell = ActivatorUtilities.CreateInstance<IslandsShellViewModel>(sp);
+            shell.ConflictResolverFactory =
+                sp.GetRequiredService<Func<string, ClaudeDo.Ui.ViewModels.Conflicts.ConflictResolverViewModel>>();
+            sp.GetRequiredService<MergeCoordinator>().Handler = shell.RequestConflictResolutionAsync;
+            return shell;
+        });
 
         return sc.BuildServiceProvider();
     }

src/ClaudeDo.Data/AttachmentStore.cs

@@ -0,0 +1,85 @@
+namespace ClaudeDo.Data;
+
+public sealed class AttachmentStore
+{
+    private const long MaxBytes = 5 * 1024 * 1024; // 5 MB
+
+    private readonly string _root;
+
+    public AttachmentStore(string? root = null)
+        => _root = root ?? Paths.Expand("~/.todo-app/attachments");
+
+    public string Root => _root;
+
+    public IReadOnlyList<string> EnumerateTaskIds()
+    {
+        if (!Directory.Exists(_root)) return Array.Empty<string>();
+        return Directory.GetDirectories(_root)
+            .Select(Path.GetFileName)
+            .Where(n => n is not null)
+            .Select(n => n!)
+            .ToList();
+    }
+
+    public string TaskDir(string taskId)
+        => Path.Combine(_root, taskId);
+
+    public async Task<long> SaveAsync(string taskId, string fileName, Stream content, CancellationToken ct = default)
+    {
+        if (Path.GetFileName(fileName) != fileName)
+            throw new ArgumentException("fileName must not contain path separators or '..'.", nameof(fileName));
+
+        var dir = TaskDir(taskId);
+        var resolvedPath = Path.GetFullPath(Path.Combine(dir, fileName));
+
+        // Containment guard: resolved path must stay inside TaskDir
+        var resolvedDir = Path.GetFullPath(dir);
+        if (!resolvedPath.StartsWith(resolvedDir + Path.DirectorySeparatorChar, StringComparison.Ordinal)
+            && !resolvedPath.Equals(resolvedDir, StringComparison.Ordinal))
+            throw new ArgumentException("fileName resolves outside the task directory.", nameof(fileName));
+
+        Directory.CreateDirectory(dir);
+
+        // Buffer up to MaxBytes + 1 to detect oversize without reading fully
+        await using var fs = new FileStream(resolvedPath, FileMode.Create, FileAccess.Write, FileShare.None,
+            bufferSize: 81920, useAsync: true);
+
+        var buffer = new byte[81920];
+        long total = 0;
+        int read;
+        while ((read = await content.ReadAsync(buffer, ct)) > 0)
+        {
+            total += read;
+            if (total > MaxBytes)
+            {
+                fs.Close();
+                try { File.Delete(resolvedPath); } catch { }
+                throw new InvalidOperationException($"Attachment exceeds the 5 MB size limit.");
+            }
+            await fs.WriteAsync(buffer.AsMemory(0, read), ct);
+        }
+
+        return total;
+    }
+
+    public void DeleteFile(string taskId, string fileName)
+    {
+        if (Path.GetFileName(fileName) != fileName)
+            return; // traversal attempt — ignore silently
+
+        var dir = TaskDir(taskId);
+        var resolvedPath = Path.GetFullPath(Path.Combine(dir, fileName));
+        var resolvedDir = Path.GetFullPath(dir);
+        if (!resolvedPath.StartsWith(resolvedDir + Path.DirectorySeparatorChar, StringComparison.Ordinal)
+            && !resolvedPath.Equals(resolvedDir, StringComparison.Ordinal))
+            return; // containment violation — ignore silently
+
+        try { File.Delete(resolvedPath); } catch (DirectoryNotFoundException) { } catch (FileNotFoundException) { }
+    }
+
+    public void DeleteTaskDir(string taskId)
+    {
+        var dir = TaskDir(taskId);
+        try { Directory.Delete(dir, recursive: true); } catch (DirectoryNotFoundException) { } catch (IOException) { }
+    }
+}

src/ClaudeDo.Data/CLAUDE.md

@@ -4,46 +4,108 @@ Shared data layer: models, repositories, SQLite infrastructure, and git operatio
 
 ## Models
 
-- **TaskEntity** — Id, ListId, Title, Description, Status (`Idle|Queued|Running|WaitingForReview|Done|Failed|Cancelled`), PlanningPhase (`None|Active|Finalized` — parent-only), BlockedByTaskId (nullable FK to predecessor in a chain), ScheduledFor, Result, ReviewFeedback (nullable; reviewer's rejection comment, consumed and cleared by the runner on the next re-run), LogPath, timestamps, CommitType, Model / SystemPrompt / AgentPath / MaxTurns (nullable overrides), IsStarred, IsMyDay, Notes, ParentTaskId, PlanningSessionId, PlanningSessionToken, PlanningFinalizedAt, CreatedBy. Legacy values `Manual`/`Planning`/`Planned`/`Draft`/`Waiting` were retired; existing rows backfill automatically via the `RetireLegacyTaskStatus` migration.
-- **ListEntity** — Id, Name, WorkingDir, DefaultCommitType, CreatedAt
-- **ListConfigEntity** — ListId (PK, 1:1 with list), Model, SystemPrompt, AgentPath, MaxTurns (all nullable)
-- **WorktreeEntity** — TaskId (PK, 1:1 with task), Path, BranchName, BaseCommit, HeadCommit, DiffStat, State (Active|Merged|Discarded|Kept)
-- **TaskRunEntity** — per-run record (session_id, tokens, turns, result, structured output, exit code, log path)
-- **PrimeScheduleEntity** — Id, Days (`[Flags] PrimeDays` weekday bitmask, stored as `days_of_week` int), TimeOfDay, Enabled, LastRunAt, PromptOverride, CreatedAt. Recurs on the selected weekdays; no date range.
-- **DailyNoteEntity** — Id, Date (DateOnly), Text, SortOrder, CreatedAt → table `daily_notes`
-- **WeekReportEntity** — Id, StartDate/EndDate (DateOnly), Markdown, GeneratedAt → table `week_reports`, unique index on (start_date, end_date)
-- **AppSettingsEntity** also carries `ReportExcludedPaths` (string?, JSON array of excluded path prefixes, column `report_excluded_paths`), `StandupWeekday` (int DayOfWeek, default Wednesday, column `standup_weekday`), and `DailyPrepMaxTasks` (int, default 5, column `daily_prep_max_tasks` — hard cap on how many open tasks the daily-prep / "Prime Claude" feature may place in MyDay)
-- **SubtaskEntity**, **AppSettingsEntity**, **AgentInfo** — existing helpers / settings / record for scanned agent files
+- **TaskEntity** — Id, ListId, Title, Description, Status, PlanningPhase, BlockedByTaskId (FK to predecessor in a chain), DependsOnTaskId (FK to a user/MCP-declared predecessor, distinct from BlockedByTaskId), ScheduledFor, Result, ReviewFeedback, LogPath, timestamps, CommitType, Model / SystemPrompt / AgentPath / MaxTurns (nullable overrides), IsStarred, IsMyDay, IsManual, Notes, ParentTaskId, PlanningSessionId / PlanningSessionToken / PlanningFinalizedAt, CreatedBy, HandlerBaseCommit / HandlerHeadCommit, InteractiveSessionId, Number (global immutable human-readable alias).
+  - Status / PlanningPhase / BlockedByTaskId / DependsOnTaskId semantics + allowed transitions: `ClaudeDo.Worker/CLAUDE.md` → Status Model.
+  - `HandlerBaseCommit`/`HandlerHeadCommit` = the review range for a **worktree-less "list handler" host task** ("Let Claude handle it"), which commits straight into the list's working dir instead of a per-task worktree. Everything that reads a task's diff falls back to this pair whenever `Worktree` is null → [conpty-sessions](../../docs/explore-notes/conpty-sessions.md).
+  - `InteractiveSessionId` = the claude session id an embedded ConPTY interactive task session runs under, persisted by `InteractiveLaunchSpecService` before launch so a closed/aborted session can be resumed → [conpty-sessions](../../docs/explore-notes/conpty-sessions.md).
+  - `Number` (INTEGER NOT NULL, unique index `idx_tasks_number`) — a global, monotonically increasing display alias for tasks. **Never reused**: deleting a task leaves a gap in numbering, ensuring that a task number that appears in a log or report always points to the same task (if it exists). Allocated by `TaskNumberAllocator.AddWithNumberAsync` on every insert via a persistent counter (`app_settings.next_task_number`). **Why not `MAX(number) + 1`:** deleting the highest-numbered task would free its number for reuse, breaking the immutability guarantee. The allocator uses an `UPDATE…RETURNING` statement to claim numbers atomically, retrying up to 5 times if a uniqueness collision occurs (the counter advances on each attempt, so retries always allocate fresh numbers). ⚠️ Tests use `EnsureCreated`, which bypasses migrations — the backfill needs a migration that runs `Migrate()` explicitly (not tested by default; see `worker-task-pipeline` notes).
+  - Legacy status values `Manual`/`Planning`/`Planned`/`Draft`/`Waiting` were retired; existing rows backfill via the `RetireLegacyTaskStatus` migration.
+- **ListEntity** — Id, Name, WorkingDir, DefaultCommitType, CreatedAt, IsManual (reminder list — tasks created here default to `IsManual`)
+- **ListConfigEntity** — ListId (PK, 1:1), Model, SystemPrompt, AgentPath, MaxTurns, SessionSkills, VerifyCommand (all nullable). `VerifyCommand` is an optional post-merge gate; null/blank = no gate → [review-merge](../../docs/explore-notes/review-merge.md).
+- **WorktreeEntity** — TaskId (PK, 1:1), Path, BranchName, BaseCommit, HeadCommit, DiffStat, MergeCommit (nullable — SHA of the merge commit this branch produced; the only thing making `revert_merge` possible without searching `git log`), State (`Active|Merged|Discarded|Kept`)
+- **TaskRunEntity** — per-run record: session_id, turns, result, structured output, exit code, log path, nullable `Model` (what the run actually executed with), and `TokensIn`/`TokensOut`/`CacheReadTokens`/`CacheWriteTokens`. ⚠️ Token fields come from the **session transcript**, not the stream-json event, as a per-run delta → [usage-monitoring](../../docs/explore-notes/usage-monitoring.md).
+- **PrimeScheduleEntity** — Id, Days (`[Flags] PrimeDays` weekday bitmask, column `days_of_week`), TimeOfDay, Enabled, LastRunAt, PromptOverride, CreatedAt. Recurs on selected weekdays; no date range.
+- **DailyNoteEntity** — Id, Date (DateOnly), Text, SortOrder, CreatedAt → `daily_notes`
+- **WeekReportEntity** — Id, StartDate/EndDate (DateOnly), Markdown, GeneratedAt → `week_reports`, unique index on (start_date, end_date)
+- **TaskAttachmentEntity** — Id, TaskId (FK, ON DELETE CASCADE), FileName, ByteSize, CreatedAt → `task_attachments`
+- **SubtaskEntity**, **AgentInfo** — subtasks / record for scanned agent files
+
+### AppSettingsEntity
+
+Beyond the basics it carries:
+
+| Property | Column | Default | Note |
+|---|---|---|---|
+| `DefaultMaxTurns` | `default_max_turns` | **40** | Lowered from 100; `AddMaxTurnsCeiling` backfilled the seeded row. |
+| `MaxTurnsCeiling` | `max_turns_ceiling` | 80 | Hard ceiling every resolved max-turns value (task/list/global) is clamped to before a run. `UpdateAsync` clamps to min 1. |
+| `ModelPresets` | `model_presets` | seeded | JSON array of `ModelPreset` rows. ⚠️ `AppSettingsRepository.GetAsync` **backfills shipping defaults on the first read after it's null**, so it's never null once a run has started. |
+| `UsageGateFiveHourPct` / `UsageGateSevenDayPct` | `usage_gate_*_pct` | 80 / 90 | Queue pause thresholds; `0` = off. |
+| `UsageThrottle{FiveHour,SevenDay}{Soft,Hard}Pct` | `usage_throttle_{five_hour,seven_day}_{soft,hard}_pct` | 50 / 65 per bucket | Staged parallelism below the hard gate, **per bucket**; `0` = that stage off. Edited by dragging the usage-monitor gauges. |
+| `DailyPrepMaxTasks` | `daily_prep_max_tasks` | 5 | Hard cap on MyDay tasks the daily prep may place. |
+| `ReportExcludedPaths` | `report_excluded_paths` | null | JSON array of excluded path prefixes. |
+| `StandupWeekday` | `standup_weekday` | Wednesday | int `DayOfWeek`. |
+| `NextTaskNumber` | `next_task_number` | 1 | Persistent counter for `TaskEntity.Number` allocation. Incremented atomically in `TaskNumberAllocator.AddWithNumberAsync` on every task insert. **Monotonic only:** the counter itself advances across all tasks (no per-list numbering), and it never resets. A deleted task leaves a gap. |
+
+All four usage percentages are clamped 0..100 by `AppSettingsRepository.UpdateAsync`.
+Gate/throttle semantics → [usage-monitoring](../../docs/explore-notes/usage-monitoring.md).
+
+### Model / effort registries
+
+- **ModelPresets / ModelPreset** — per-model run defaults (`Model`, `Effort`, `MaxTurns`), one row per `ModelRegistry.Aliases` entry, supplying the **global** effort and max-turns defaults. Ship defaults: haiku medium/20, sonnet high/30, opus high/40, fable high/25. `Parse`/`Serialize` normalize (unknown models dropped, missing aliases filled from `Defaults`, effort validated, turns clamped 1–200) and **never throw** — a malformed settings row must not stop a run. `For(presets, model, fallbackMaxTurns)` always returns a usable row; resolution order and the fallback trap → [worker-task-pipeline](../../docs/explore-notes/worker-task-pipeline.md).
+- **ModelRegistry** — `NormalizeAlias` is the strict, **throwing** validator for `add_task`/planning model input. `TryNormalizeAlias` is the non-throwing counterpart for the run path (exact alias match, then substring match against a full model id, else `null`). `ByCostAscending` = the cost order the prompts use.
+- **EffortRegistry** — the `--effort` levels (`low|medium|high|xhigh|max`) + `NormalizeLevel` (blank → null = don't pass the flag).
 
 ## Repositories
 
-All repositories use EF Core LINQ queries via `ClaudeDoDbContext`. The atomic `Queued -> Running` claim lives in the Worker's `QueuePicker` (uses `FromSqlRaw`), not here.
+All use EF Core LINQ via `ClaudeDoDbContext`. The atomic `Queued → Running` claim lives in the
+Worker's `QueuePicker` (`FromSqlRaw`), **not** here.
 
-- **TaskRepository** — CRUD, planning helpers (`CreateChildAsync`, `SetPlanningStartedAsync`, `DiscardPlanningAsync`, `TryCompleteParentAsync`, `UpdateChildAsync`), `UpdateAgentSettingsAsync` (model / system-prompt / agent-path overrides). Status-mutation primitives `MarkRunningAsync` / `MarkDoneAsync` / `MarkFailedAsync` / `FlipAllRunningToFailedAsync` are `internal` and called only by `TaskStateService` in the worker. `CreateChildAsync` produces children with `Status=Idle, PlanningPhase=None`; once their parent's `PlanningPhase` becomes `Finalized`, the chain coordinator queues them.
-- **ListRepository** — CRUD, `GetConfigAsync` / `SetConfigAsync` (upsert) / `DeleteConfigAsync` for `list_config`
-- **WorktreeRepository** — CRUD, `UpdateHeadAsync`, `SetStateAsync`
-- **TaskRunRepository**, **SubtaskRepository**, **AppSettingsRepository**
-- **DailyNoteRepository** — `ListByDayAsync`, `ListBetweenAsync`, `AddAsync`, `UpdateAsync`, `DeleteAsync`
-- **WeekReportRepository** — `GetByRangeAsync`, `UpsertAsync`
+- **TaskRepository** — CRUD, planning helpers (`CreateChildAsync`, `SetPlanningStartedAsync`, `DiscardPlanningAsync`, `UpdateChildAsync`), `UpdateAgentSettingsAsync`. ⚠️ Status-mutation primitives (`MarkRunningAsync`/`MarkDoneAsync`/`MarkFailedAsync`/`FlipAllRunningToFailedAsync`) are **`internal`** — only the Worker's `TaskStateService` may call them. `CreateChildAsync` produces children with `Status=Idle, PlanningPhase=None`. **Task-number allocation:** `AddAsync` (line 20) and `CreateChildAsync` (line 276) are the two sole task-creation paths; both call `TaskNumberAllocator.AddWithNumberAsync` to allocate a number atomically during the same transaction as the insert. Every other creation path (UI, MCP `add_task`, `batch_add_tasks`, Online Inbox sync, merge-helper handler tasks, planning children) routes through one of these two.
+- **ListRepository** — CRUD, `GetConfigAsync`/`SetConfigAsync` (upsert)/`DeleteConfigAsync` for `list_config`
+- **WorktreeRepository** — CRUD, `UpdateHeadAsync`, `SetStateAsync`, `SetMergedAsync` (atomically sets State=Merged **and** stamps MergeCommit in one update — the only writer of MergeCommit)
+- **TaskAttachmentRepository** — `AddAsync`, `UpdateAsync`, `GetAsync(taskId, fileName)`, `ListByTaskIdAsync`, `DeleteAsync(taskId, fileName)`, `DeleteAllForTaskAsync`
+- **DailyNoteRepository**, **WeekReportRepository**, **TaskRunRepository**, **SubtaskRepository**, **AppSettingsRepository**
+
+`TaskRepository.DeleteAsync` and `ListRepository.DeleteAsync` also delete the on-disk attachment
+dir(s) via an optional `AttachmentStore` ctor param (defaults to the production store).
 
 ## Infrastructure
 
-- **ClaudeDoDbContext** — EF Core DbContext; configured with WAL mode and foreign keys via `UseSqlite` options
-- **IDbContextFactory<ClaudeDoDbContext>** — registered in DI; used by singleton consumers (e.g. Worker hosted service)
-- **Paths** — expands `~` and `%USERPROFILE%`, resolves relative paths. App root: `~/.todo-app`
+- **ClaudeDoDbContext** — EF Core DbContext; WAL mode + foreign keys via `UseSqlite` options
+- **IDbContextFactory\<ClaudeDoDbContext\>** — registered in DI; used by singleton consumers (e.g. the Worker hosted service)
+- **Paths** — expands `~` and `%USERPROFILE%`, resolves relative paths. App root `~/.todo-app`
 - **AppSettings** — loads `~/.todo-app/ui.config.json` (DbPath, SignalRUrl)
+- **AttachmentStore** — dependency-free file store, default root `~/.todo-app/attachments/<taskId>/`. `SaveAsync` enforces a 5 MB cap and a path-traversal/containment guard. Also `DeleteFile`, `DeleteTaskDir`, `TaskDir`, `Root`, `EnumerateTaskIds` (used by the worker orphan sweep). Attachment files live **outside** git worktrees intentionally.
 
 ## Git
 
-- **GitService** — async wrapper around git CLI (ProcessStartInfo, no shell). Operations: worktree add/remove, add all, commit (stdin for message), merge ff-only, rev-parse, diff-stat, has-changes, is-git-repo, `PreviewMergeAsync` (non-destructive mergeability check via `git merge-tree --write-tree`), `CountChangedFilesAsync`
+**GitService** — async wrapper around the git CLI (`ProcessStartInfo`, no shell):
+
+- Worktrees: add (**serialized** to avoid a commondir race), remove, prune, list paths for branch
+- Branches: current, list local, checkout, delete
+- Staging/commit: status porcelain, add-all, add-path, commit via stdin
+- Diffs: working tree, branch vs base, commit range `base..head` (shows a merged task's diff after the worktree is gone), per-file, diff-stat, committed files, has-changes
+- Merge: ff-only, no-ff, abort, mid-merge detection (`MERGE_HEAD`), conflicted files
+- Revert: `RevertMergeCommitAsync` (`git revert --no-edit -m 1 <sha>`), `RevertAbortAsync`, `IsMidRevertAsync` (`REVERT_HEAD`, mirrors `IsMidMergeAsync`)
+- `PreviewMergeAsync` (non-destructive check via `git merge-tree --write-tree`), `CountChangedFilesAsync`, rev-parse, is-git-repo
+
+⚠️ **Revert never resets or rewrites** — it always produces a new commit, because the working
+directory it operates on is shared with other concurrent sessions.
 
 ## Schema
 
-Tables: `lists`, `tasks`, `worktrees`, `list_config`, `task_runs`, `subtasks`, `app_settings`, `prime_schedules`, `daily_notes`, `week_reports`. Managed by EF Core migrations in the `Migrations/` folder. The `tasks` table holds `status`, `planning_phase` (default `none`), and `blocked_by_task_id` (FK to `tasks.id`, `ON DELETE SET NULL`). Migration `WeeklyReport` added `daily_notes`, `week_reports`, and the two new `app_settings` columns. Migration `DailyPrepMaxTasks` added the `daily_prep_max_tasks` column to `app_settings` (no new tables).
+Tables (one per line so parallel migrations don't collide on the same line):
+- `lists`
+- `tasks`
+- `worktrees`
+- `list_config`
+- `task_runs`
+- `subtasks`
+- `app_settings`
+- `prime_schedules`
+- `daily_notes`
+- `week_reports`
+- `task_attachments`
+
+Managed by EF Core migrations in `Migrations/` — **`ls Migrations/` is the authoritative history**;
+don't maintain a changelog here. `tasks` holds `status`, `planning_phase` (default `none`),
+`blocked_by_task_id` (FK to `tasks.id`, `ON DELETE SET NULL`), and `depends_on_task_id` (same FK
+shape, but a separate column — see Worker/CLAUDE.md → Status Model for why it isn't unified with
+`blocked_by_task_id`).
 
 ## Conventions
 
-- Enum <-> string mapping via EF Core `ValueConverter` (configured in `IEntityTypeConfiguration<T>`)
-- Entity configurations live in the `Configuration/` folder
+- Enum ↔ string mapping via EF Core `ValueConverter`, configured in `IEntityTypeConfiguration<T>`
+- Entity configurations live in `Configuration/`
 - Primary keys are `init`-only strings (GUIDs assigned at creation)
 - All methods are async with CancellationToken where applicable

src/ClaudeDo.Data/ClaudeDo.Data.csproj

@@ -17,6 +17,7 @@
   <ItemGroup>
     <InternalsVisibleTo Include="ClaudeDo.Worker" />
     <InternalsVisibleTo Include="ClaudeDo.Worker.Tests" />
+    <InternalsVisibleTo Include="ClaudeDo.Data.Tests" />
   </ItemGroup>
 
 </Project>

src/ClaudeDo.Data/ClaudeDoDbContext.cs

@@ -1,6 +1,8 @@
+using System.Data.Common;
 using ClaudeDo.Data.Models;
 using ClaudeDo.Data.Seeding;
 using Microsoft.EntityFrameworkCore;
+using Microsoft.EntityFrameworkCore.Diagnostics;
 using Microsoft.EntityFrameworkCore.Infrastructure;
 using Microsoft.EntityFrameworkCore.Storage;
 using Microsoft.EntityFrameworkCore.Storage.ValueConversion;
@@ -9,18 +11,47 @@ namespace ClaudeDo.Data;
 
 public class ClaudeDoDbContext : DbContext
 {
+    // Runs PRAGMA foreign_keys=ON on every EF-managed connection open so FK
+    // enforcement is active for all IDbContextFactory-created contexts, not
+    // just the single context used in MigrateAndConfigure.
+    private sealed class SqliteForeignKeyInterceptor : DbConnectionInterceptor
+    {
+        internal static readonly SqliteForeignKeyInterceptor Instance = new();
+
+        public override void ConnectionOpened(DbConnection connection, ConnectionEndEventData eventData)
+            => Apply(connection);
+
+        public override Task ConnectionOpenedAsync(DbConnection connection, ConnectionEndEventData eventData, CancellationToken cancellationToken = default)
+        {
+            Apply(connection);
+            return Task.CompletedTask;
+        }
+
+        private static void Apply(DbConnection connection)
+        {
+            using var cmd = connection.CreateCommand();
+            cmd.CommandText = "PRAGMA foreign_keys=ON;";
+            cmd.ExecuteNonQuery();
+        }
+    }
+
     public ClaudeDoDbContext(DbContextOptions<ClaudeDoDbContext> options) : base(options) { }
 
+    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
+        => optionsBuilder.AddInterceptors(SqliteForeignKeyInterceptor.Instance);
+
     public DbSet<TaskEntity> Tasks => Set<TaskEntity>();
     public DbSet<ListEntity> Lists => Set<ListEntity>();
     public DbSet<ListConfigEntity> ListConfigs => Set<ListConfigEntity>();
     public DbSet<WorktreeEntity> Worktrees => Set<WorktreeEntity>();
     public DbSet<TaskRunEntity> TaskRuns => Set<TaskRunEntity>();
     public DbSet<SubtaskEntity> Subtasks => Set<SubtaskEntity>();
+    public DbSet<TaskAttachmentEntity> TaskAttachments => Set<TaskAttachmentEntity>();
     public DbSet<AppSettingsEntity> AppSettings => Set<AppSettingsEntity>();
     public DbSet<PrimeScheduleEntity> PrimeSchedules => Set<PrimeScheduleEntity>();
     public DbSet<DailyNoteEntity> DailyNotes => Set<DailyNoteEntity>();
     public DbSet<WeekReportEntity> WeekReports => Set<WeekReportEntity>();
+    public DbSet<SessionSkillEntity> SessionSkills => Set<SessionSkillEntity>();
 
     private static readonly ValueConverter<DateTime, DateTime> UtcConverter =
         new(v => v, v => DateTime.SpecifyKind(v, DateTimeKind.Utc));

src/ClaudeDo.Data/Configuration/AppSettingsEntityConfiguration.cs

@@ -13,15 +13,21 @@ public class AppSettingsEntityConfiguration : IEntityTypeConfiguration<AppSettin
         builder.HasKey(s => s.Id);
         builder.Property(s => s.Id).HasColumnName("id").ValueGeneratedNever();
 
+        builder.Property(s => s.NextTaskNumber)
+            .HasColumnName("next_task_number").IsRequired().HasDefaultValue(1);
+
         builder.Property(s => s.DefaultClaudeInstructions)
             .HasColumnName("default_claude_instructions").IsRequired().HasDefaultValue(string.Empty);
         builder.Property(s => s.DefaultModel)
             .HasColumnName("default_model").IsRequired().HasDefaultValue("sonnet");
         builder.Property(s => s.DefaultMaxTurns)
-            .HasColumnName("default_max_turns").IsRequired().HasDefaultValue(30);
+            .HasColumnName("default_max_turns").IsRequired().HasDefaultValue(40);
         builder.Property(s => s.DefaultPermissionMode)
             .HasColumnName("default_permission_mode").IsRequired().HasDefaultValue("bypassPermissions");
 
+        builder.Property(s => s.MaxTurnsCeiling)
+            .HasColumnName("max_turns_ceiling").IsRequired().HasDefaultValue(80);
+
         builder.Property(s => s.MaxParallelExecutions)
             .HasColumnName("max_parallel_executions").IsRequired().HasDefaultValue(1);
 
@@ -44,6 +50,23 @@ public class AppSettingsEntityConfiguration : IEntityTypeConfiguration<AppSettin
         builder.Property(s => s.DailyPrepMaxTasks)
             .HasColumnName("daily_prep_max_tasks").IsRequired().HasDefaultValue(5);
 
+        builder.Property(s => s.SessionSkills).HasColumnName("session_skills");
+        builder.Property(s => s.ModelPresets).HasColumnName("model_presets");
+
+        builder.Property(s => s.UsageGateFiveHourPct)
+            .HasColumnName("usage_gate_five_hour_pct").IsRequired().HasDefaultValue(80);
+        builder.Property(s => s.UsageGateSevenDayPct)
+            .HasColumnName("usage_gate_seven_day_pct").IsRequired().HasDefaultValue(90);
+
+        builder.Property(s => s.UsageThrottleFiveHourSoftPct)
+            .HasColumnName("usage_throttle_five_hour_soft_pct").IsRequired().HasDefaultValue(50);
+        builder.Property(s => s.UsageThrottleFiveHourHardPct)
+            .HasColumnName("usage_throttle_five_hour_hard_pct").IsRequired().HasDefaultValue(65);
+        builder.Property(s => s.UsageThrottleSevenDaySoftPct)
+            .HasColumnName("usage_throttle_seven_day_soft_pct").IsRequired().HasDefaultValue(50);
+        builder.Property(s => s.UsageThrottleSevenDayHardPct)
+            .HasColumnName("usage_throttle_seven_day_hard_pct").IsRequired().HasDefaultValue(65);
+
         builder.HasData(new AppSettingsEntity { Id = AppSettingsEntity.SingletonId });
     }
 }

src/ClaudeDo.Data/Configuration/ListConfigEntityConfiguration.cs

@@ -16,5 +16,9 @@ public class ListConfigEntityConfiguration : IEntityTypeConfiguration<ListConfig
         builder.Property(c => c.SystemPrompt).HasColumnName("system_prompt");
         builder.Property(c => c.AgentPath).HasColumnName("agent_path");
         builder.Property(c => c.MaxTurns).HasColumnName("max_turns");
+        builder.Property(c => c.SessionSkills).HasColumnName("session_skills");
+        builder.Property(c => c.VerifyCommand).HasColumnName("verify_command");
+        builder.Property(c => c.SerializeOnFileOverlap).HasColumnName("serialize_on_file_overlap")
+            .IsRequired().HasDefaultValue(false);
     }
 }

src/ClaudeDo.Data/Configuration/ListEntityConfiguration.cs

@@ -17,6 +17,8 @@ public class ListEntityConfiguration : IEntityTypeConfiguration<ListEntity>
         builder.Property(l => l.WorkingDir).HasColumnName("working_dir");
         builder.Property(l => l.DefaultCommitType).HasColumnName("default_commit_type").IsRequired().HasDefaultValue("chore");
         builder.Property(l => l.SortOrder).HasColumnName("sort_order").IsRequired().HasDefaultValue(0);
+        builder.Property(l => l.IsManual).HasColumnName("is_manual").IsRequired().HasDefaultValue(false);
+        builder.Property(l => l.FindingsTracked).HasColumnName("findings_tracked").IsRequired().HasDefaultValue(false);
 
         builder.HasIndex(l => l.SortOrder).HasDatabaseName("idx_lists_sort");
 

src/ClaudeDo.Data/Configuration/SessionSkillEntityConfiguration.cs

@@ -0,0 +1,21 @@
+using ClaudeDo.Data.Models;
+using Microsoft.EntityFrameworkCore;
+using Microsoft.EntityFrameworkCore.Metadata.Builders;
+
+namespace ClaudeDo.Data.Configuration;
+
+public class SessionSkillEntityConfiguration : IEntityTypeConfiguration<SessionSkillEntity>
+{
+    public void Configure(EntityTypeBuilder<SessionSkillEntity> builder)
+    {
+        builder.ToTable("session_skills");
+
+        builder.HasKey(s => s.Name);
+        builder.Property(s => s.Name).HasColumnName("name");
+        builder.Property(s => s.SourceUrl).HasColumnName("source_url").IsRequired();
+        builder.Property(s => s.PinnedRef).HasColumnName("pinned_ref").IsRequired();
+        builder.Property(s => s.Subpath).HasColumnName("subpath").IsRequired();
+        builder.Property(s => s.Description).HasColumnName("description").IsRequired();
+        builder.Property(s => s.AddedAt).HasColumnName("added_at").IsRequired();
+    }
+}

src/ClaudeDo.Data/Configuration/TaskAttachmentEntityConfiguration.cs

@@ -0,0 +1,27 @@
+using ClaudeDo.Data.Models;
+using Microsoft.EntityFrameworkCore;
+using Microsoft.EntityFrameworkCore.Metadata.Builders;
+
+namespace ClaudeDo.Data.Configuration;
+
+public class TaskAttachmentEntityConfiguration : IEntityTypeConfiguration<TaskAttachmentEntity>
+{
+    public void Configure(EntityTypeBuilder<TaskAttachmentEntity> builder)
+    {
+        builder.ToTable("task_attachments");
+
+        builder.HasKey(a => a.Id);
+        builder.Property(a => a.Id).HasColumnName("id");
+        builder.Property(a => a.TaskId).HasColumnName("task_id").IsRequired();
+        builder.Property(a => a.FileName).HasColumnName("file_name").IsRequired();
+        builder.Property(a => a.ByteSize).HasColumnName("byte_size").IsRequired();
+        builder.Property(a => a.CreatedAt).HasColumnName("created_at").IsRequired();
+
+        builder.HasOne(a => a.Task)
+            .WithMany()
+            .HasForeignKey(a => a.TaskId)
+            .OnDelete(DeleteBehavior.Cascade);
+
+        builder.HasIndex(a => a.TaskId).HasDatabaseName("idx_task_attachments_task_id");
+    }
+}

src/ClaudeDo.Data/Configuration/TaskEntityConfiguration.cs

@@ -66,6 +66,7 @@ public class TaskEntityConfiguration : IEntityTypeConfiguration<TaskEntity>
 
         builder.HasKey(t => t.Id);
         builder.Property(t => t.Id).HasColumnName("id");
+        builder.Property(t => t.Number).HasColumnName("number").IsRequired();
         builder.Property(t => t.ListId).HasColumnName("list_id").IsRequired();
         builder.Property(t => t.Title).HasColumnName("title").IsRequired();
         builder.Property(t => t.Description).HasColumnName("description");
@@ -74,10 +75,14 @@ public class TaskEntityConfiguration : IEntityTypeConfiguration<TaskEntity>
         builder.Property(t => t.PlanningPhase).HasColumnName("planning_phase").IsRequired()
             .HasConversion(PhaseConverter).HasDefaultValue(PlanningPhase.None);
         builder.Property(t => t.BlockedByTaskId).HasColumnName("blocked_by_task_id");
+        builder.Property(t => t.DependsOnTaskId).HasColumnName("depends_on_task_id");
         builder.Property(t => t.ScheduledFor).HasColumnName("scheduled_for");
         builder.Property(t => t.Result).HasColumnName("result");
         builder.Property(t => t.ReviewFeedback).HasColumnName("review_feedback");
         builder.Property(t => t.RoadblockCount).HasColumnName("roadblock_count").HasDefaultValue(0);
+        builder.Property(t => t.FailureReason).HasColumnName("failure_reason");
+        builder.Property(t => t.FailureTurnsUsed).HasColumnName("failure_turns_used");
+        builder.Property(t => t.FailureMaxTurns).HasColumnName("failure_max_turns");
         builder.Property(t => t.LogPath).HasColumnName("log_path");
         builder.Property(t => t.CreatedAt).HasColumnName("created_at").IsRequired();
         builder.Property(t => t.StartedAt).HasColumnName("started_at");
@@ -89,8 +94,14 @@ public class TaskEntityConfiguration : IEntityTypeConfiguration<TaskEntity>
         builder.Property(t => t.MaxTurns).HasColumnName("max_turns");
         builder.Property(t => t.IsStarred).HasColumnName("is_starred").HasDefaultValue(false);
         builder.Property(t => t.IsMyDay).HasColumnName("is_my_day").HasDefaultValue(false);
+        builder.Property(t => t.IsManual).HasColumnName("is_manual").HasDefaultValue(false);
         builder.Property(t => t.Notes).HasColumnName("notes");
         builder.Property(t => t.SortOrder).HasColumnName("sort_order").IsRequired().HasDefaultValue(0);
+        builder.Property(t => t.SessionSkills).HasColumnName("session_skills");
+        builder.Property(t => t.ScopeGlobs).HasColumnName("scope_globs");
+        builder.Property(t => t.HandlerBaseCommit).HasColumnName("handler_base_commit");
+        builder.Property(t => t.HandlerHeadCommit).HasColumnName("handler_head_commit");
+        builder.Property(t => t.InteractiveSessionId).HasColumnName("interactive_session_id");
 
         builder.Property(t => t.ParentTaskId).HasColumnName("parent_task_id");
         builder.Property(t => t.PlanningSessionId).HasColumnName("planning_session_id");
@@ -110,6 +121,13 @@ public class TaskEntityConfiguration : IEntityTypeConfiguration<TaskEntity>
             .HasForeignKey(t => t.BlockedByTaskId)
             .OnDelete(DeleteBehavior.SetNull);
 
+        // DependsOn: user/MCP-declared predecessor. SetNull on delete so the dependent becomes
+        // pickable rather than blocked forever on a task that no longer exists.
+        builder.HasOne<TaskEntity>()
+            .WithMany()
+            .HasForeignKey(t => t.DependsOnTaskId)
+            .OnDelete(DeleteBehavior.SetNull);
+
         builder.HasOne(t => t.List)
             .WithMany(l => l.Tasks)
             .HasForeignKey(t => t.ListId)
@@ -119,10 +137,12 @@ public class TaskEntityConfiguration : IEntityTypeConfiguration<TaskEntity>
             .WithOne(w => w.Task)
             .HasForeignKey<WorktreeEntity>(w => w.TaskId);
 
+        builder.HasIndex(t => t.Number).IsUnique().HasDatabaseName("idx_tasks_number");
         builder.HasIndex(t => t.ListId).HasDatabaseName("idx_tasks_list_id");
         builder.HasIndex(t => t.Status).HasDatabaseName("idx_tasks_status");
         builder.HasIndex(t => new { t.ListId, t.SortOrder }).HasDatabaseName("idx_tasks_list_sort");
         builder.HasIndex(t => t.ParentTaskId).HasDatabaseName("idx_tasks_parent_task_id");
         builder.HasIndex(t => t.BlockedByTaskId).HasDatabaseName("idx_tasks_blocked_by");
+        builder.HasIndex(t => t.DependsOnTaskId).HasDatabaseName("idx_tasks_depends_on");
     }
 }

src/ClaudeDo.Data/Configuration/TaskRunEntityConfiguration.cs

@@ -24,9 +24,15 @@ public class TaskRunEntityConfiguration : IEntityTypeConfiguration<TaskRunEntity
         builder.Property(r => r.TurnCount).HasColumnName("turn_count");
         builder.Property(r => r.TokensIn).HasColumnName("tokens_in");
         builder.Property(r => r.TokensOut).HasColumnName("tokens_out");
+        builder.Property(r => r.CacheReadTokens).HasColumnName("cache_read_tokens");
+        builder.Property(r => r.CacheWriteTokens).HasColumnName("cache_write_tokens");
         builder.Property(r => r.LogPath).HasColumnName("log_path");
         builder.Property(r => r.StartedAt).HasColumnName("started_at");
         builder.Property(r => r.FinishedAt).HasColumnName("finished_at");
+        builder.Property(r => r.Model).HasColumnName("model");
+        builder.Property(r => r.ResultSubtype).HasColumnName("result_subtype");
+        builder.Property(r => r.TerminalReason).HasColumnName("terminal_reason");
+        builder.Property(r => r.Errors).HasColumnName("errors");
 
         builder.HasOne(r => r.Task)
             .WithMany(t => t.Runs)

src/ClaudeDo.Data/Configuration/WorktreeEntityConfiguration.cs

@@ -35,6 +35,7 @@ public class WorktreeEntityConfiguration : IEntityTypeConfiguration<WorktreeEnti
         builder.Property(w => w.BaseCommit).HasColumnName("base_commit").IsRequired();
         builder.Property(w => w.HeadCommit).HasColumnName("head_commit");
         builder.Property(w => w.DiffStat).HasColumnName("diff_stat");
+        builder.Property(w => w.MergeCommit).HasColumnName("merge_commit");
         builder.Property(w => w.State).HasColumnName("state").IsRequired()
             .HasDefaultValue(WorktreeState.Active)
             .HasConversion(StateConverter);

src/ClaudeDo.Data/Environment/ExecutableResolver.cs

@@ -0,0 +1,116 @@
+using SysEnvironment = System.Environment;
+
+namespace ClaudeDo.Data.Environment;
+
+public sealed record ResolvedExecutable(string Path, bool IsShim);
+
+public sealed record ShimStartInfo(string FileName, string Arguments);
+
+/// <summary>
+/// Resolves a command the way Windows' CreateProcess/PATH search does, but also finds
+/// non-.exe shims (.cmd/.bat/.ps1) that UseShellExecute=false alone would miss.
+/// </summary>
+public static class ExecutableResolver
+{
+    private const string DefaultPathExt = ".COM;.EXE;.BAT;.CMD";
+
+    // Known npm/claude install locations to try when PATH search comes up empty.
+    private static readonly string[] FallbackDirectoryTemplates =
+    {
+        "%APPDATA%\\npm",
+        "%LOCALAPPDATA%\\Programs\\claude",
+        "%USERPROFILE%\\.local\\bin",
+    };
+
+    public static ResolvedExecutable? Resolve(string command, string? pathOverride = null, string? pathExtOverride = null)
+    {
+        var pathExts = ParsePathExt(pathExtOverride);
+
+        if (LooksLikePath(command))
+        {
+            return ResolveAsPath(command, pathExts);
+        }
+
+        var directories = ParsePath(pathOverride);
+        foreach (var dir in directories)
+        {
+            var resolved = ResolveInDirectory(dir, command, pathExts);
+            if (resolved is not null) return resolved;
+        }
+
+        foreach (var template in FallbackDirectoryTemplates)
+        {
+            var dir = SysEnvironment.ExpandEnvironmentVariables(template);
+            var resolved = ResolveInDirectory(dir, command, pathExts);
+            if (resolved is not null) return resolved;
+        }
+
+        return null;
+    }
+
+    /// <summary>Expanded fallback directories tried when PATH search comes up empty (for diagnostics).</summary>
+    public static IReadOnlyList<string> FallbackDirectories() =>
+        FallbackDirectoryTemplates.Select(SysEnvironment.ExpandEnvironmentVariables).ToList();
+
+    public static ShimStartInfo BuildShimStartInfo(string shimPath, IReadOnlyList<string> arguments)
+    {
+        var parts = new List<string> { "/c", Quote(shimPath) };
+        parts.AddRange(arguments.Select(Quote));
+        return new ShimStartInfo("cmd.exe", string.Join(' ', parts));
+    }
+
+    private static bool LooksLikePath(string command) =>
+        command.Contains(Path.DirectorySeparatorChar) || command.Contains(Path.AltDirectorySeparatorChar);
+
+    private static ResolvedExecutable? ResolveAsPath(string command, IReadOnlyList<string> pathExts)
+    {
+        if (File.Exists(command)) return new ResolvedExecutable(command, IsShimExtension(Path.GetExtension(command)));
+
+        if (Path.HasExtension(command)) return null;
+
+        foreach (var ext in pathExts)
+        {
+            var candidate = command + ext;
+            if (File.Exists(candidate)) return new ResolvedExecutable(candidate, IsShimExtension(ext));
+        }
+
+        return null;
+    }
+
+    private static ResolvedExecutable? ResolveInDirectory(string directory, string command, IReadOnlyList<string> pathExts)
+    {
+        if (!Directory.Exists(directory)) return null;
+
+        if (Path.HasExtension(command))
+        {
+            var candidate = Path.Combine(directory, command);
+            return File.Exists(candidate) ? new ResolvedExecutable(candidate, IsShimExtension(Path.GetExtension(candidate))) : null;
+        }
+
+        foreach (var ext in pathExts)
+        {
+            var candidate = Path.Combine(directory, command + ext);
+            if (File.Exists(candidate)) return new ResolvedExecutable(candidate, IsShimExtension(ext));
+        }
+
+        return null;
+    }
+
+    private static bool IsShimExtension(string extension) =>
+        !extension.Equals(".exe", StringComparison.OrdinalIgnoreCase)
+        && !extension.Equals(".com", StringComparison.OrdinalIgnoreCase);
+
+    private static IReadOnlyList<string> ParsePathExt(string? pathExtOverride)
+    {
+        var raw = pathExtOverride ?? SysEnvironment.GetEnvironmentVariable("PATHEXT") ?? DefaultPathExt;
+        return raw.Split(';', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries);
+    }
+
+    private static IReadOnlyList<string> ParsePath(string? pathOverride)
+    {
+        var raw = pathOverride ?? SysEnvironment.GetEnvironmentVariable("PATH") ?? "";
+        return raw.Split(Path.PathSeparator, StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries);
+    }
+
+    private static string Quote(string value) => value.Contains(' ') ? $"\"{value}\"" : value;
+}

src/ClaudeDo.Data/Filtering/Filters/ReviewFilter.cs

@@ -1,14 +1,12 @@
+using System.Linq.Expressions;
 using ClaudeDo.Data.Models;
 using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
 
 namespace ClaudeDo.Data.Filtering.Filters;
 
-public sealed class ReviewFilter : ITaskListFilter
+public sealed class ReviewFilter : TaskListFilterBase
 {
-    public string Id => "virtual:review";
-    public bool Matches(TaskEntity t) =>
-        t.Status == TaskStatus.Done &&
-        t.Worktree is { State: WorktreeState.Active };
-    public bool ShouldCount(TaskEntity t) => Matches(t);
-    public bool MatchesAsContext(TaskEntity t, IReadOnlyList<TaskEntity> all) => false;
+    public override string Id => "virtual:review";
+    protected override Expression<Func<TaskEntity, bool>> MatchExpr => t => t.Status == TaskStatus.WaitingForReview;
+    public override bool ShouldCount(TaskEntity t) => Matches(t);
 }

src/ClaudeDo.Data/Filtering/Filters/SmartFlagFilter.cs

@@ -1,3 +1,4 @@
+using System.Linq.Expressions;
 using ClaudeDo.Data.Models;
 using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
 
@@ -7,10 +8,11 @@ namespace ClaudeDo.Data.Filtering.Filters;
 /// Filter for a smart list keyed off a boolean/nullable task flag
 /// (My Day, Important, Planned). Counts only non-done matches.
 /// </summary>
-public sealed class SmartFlagFilter(string id, Func<TaskEntity, bool> flag) : ITaskListFilter
+public sealed class SmartFlagFilter(string id, Expression<Func<TaskEntity, bool>> flag) : TaskListFilterBase
 {
-    public string Id => id;
-    public bool Matches(TaskEntity t) => flag(t);
-    public bool ShouldCount(TaskEntity t) => flag(t) && t.Status != TaskStatus.Done;
-    public bool MatchesAsContext(TaskEntity t, IReadOnlyList<TaskEntity> all) => false;
+    private readonly Func<TaskEntity, bool> _flag = flag.Compile();
+
+    public override string Id => id;
+    protected override Expression<Func<TaskEntity, bool>> MatchExpr => flag;
+    public override bool ShouldCount(TaskEntity t) => _flag(t) && t.Status != TaskStatus.Done;
 }

src/ClaudeDo.Data/Filtering/Filters/StatusFilter.cs

@@ -1,3 +1,4 @@
+using System.Linq.Expressions;
 using ClaudeDo.Data.Models;
 using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
 
@@ -7,12 +8,12 @@ namespace ClaudeDo.Data.Filtering.Filters;
 /// Virtual list filter matching tasks by a single status (Queued, Running).
 /// Planning parents appear contextually when they host a matching child.
 /// </summary>
-public sealed class StatusFilter(string id, TaskStatus status) : ITaskListFilter
+public sealed class StatusFilter(string id, TaskStatus status) : TaskListFilterBase
 {
-    public string Id => id;
-    public bool Matches(TaskEntity t) => t.Status == status;
-    public bool ShouldCount(TaskEntity t) => t.Status == status;
-    public bool MatchesAsContext(TaskEntity t, IReadOnlyList<TaskEntity> all) =>
+    public override string Id => id;
+    protected override Expression<Func<TaskEntity, bool>> MatchExpr => t => t.Status == status;
+    public override bool ShouldCount(TaskEntity t) => t.Status == status;
+    public override bool MatchesAsContext(TaskEntity t, IReadOnlyList<TaskEntity> all) =>
         PlanningRules.IsPlanningParent(t) &&
         PlanningRules.HasMatchingChild(t, all, c => c.Status == status);
 }

src/ClaudeDo.Data/Filtering/Filters/TaskListFilterBase.cs

@@ -0,0 +1,27 @@
+using System.Linq.Expressions;
+using ClaudeDo.Data.Models;
+
+namespace ClaudeDo.Data.Filtering.Filters;
+
+/// <summary>
+/// Base for <see cref="ITaskListFilter"/> implementations: subclasses express their
+/// primary-match condition once as an expression tree (<see cref="MatchExpr"/>), which
+/// doubles as a SQL-translatable predicate (<see cref="MatchExpression"/>) and, compiled
+/// on first use, as the in-memory <see cref="Matches"/> predicate.
+/// </summary>
+public abstract class TaskListFilterBase : ITaskListFilter
+{
+    private Func<TaskEntity, bool>? _compiled;
+
+    public abstract string Id { get; }
+
+    protected abstract Expression<Func<TaskEntity, bool>> MatchExpr { get; }
+
+    public Expression<Func<TaskEntity, bool>> MatchExpression => MatchExpr;
+
+    public bool Matches(TaskEntity t) => (_compiled ??= MatchExpr.Compile())(t);
+
+    public abstract bool ShouldCount(TaskEntity t);
+
+    public virtual bool MatchesAsContext(TaskEntity t, IReadOnlyList<TaskEntity> all) => false;
+}

src/ClaudeDo.Data/Filtering/Filters/UserListFilter.cs

@@ -1,3 +1,4 @@
+using System.Linq.Expressions;
 using ClaudeDo.Data.Models;
 using TaskStatus = ClaudeDo.Data.Models.TaskStatus;
 
@@ -7,7 +8,7 @@ namespace ClaudeDo.Data.Filtering.Filters;
 /// Filter for any user-defined list. Constructed on demand from the list id —
 /// one instance per list.
 /// </summary>
-public sealed class UserListFilter : ITaskListFilter
+public sealed class UserListFilter : TaskListFilterBase
 {
     private readonly string _listId;
 
@@ -17,8 +18,7 @@ public sealed class UserListFilter : ITaskListFilter
         Id = $"user:{listId}";
     }
 
-    public string Id { get; }
-    public bool Matches(TaskEntity t) => t.ListId == _listId;
-    public bool ShouldCount(TaskEntity t) => t.ListId == _listId && t.Status != TaskStatus.Done;
-    public bool MatchesAsContext(TaskEntity t, IReadOnlyList<TaskEntity> all) => false;
+    public override string Id { get; }
+    protected override Expression<Func<TaskEntity, bool>> MatchExpr => t => t.ListId == _listId;
+    public override bool ShouldCount(TaskEntity t) => t.ListId == _listId && t.Status != TaskStatus.Done;
 }

src/ClaudeDo.Data/Filtering/Interfaces/ITaskListFilter.cs

@@ -1,3 +1,4 @@
+using System.Linq.Expressions;
 using ClaudeDo.Data.Models;
 
 namespace ClaudeDo.Data.Filtering;
@@ -15,6 +16,9 @@ public interface ITaskListFilter
     /// <summary>True if <paramref name="t"/> is a primary citizen of this list — appears as a row.</summary>
     bool Matches(TaskEntity t);
 
+    /// <summary>The primary-match predicate as an expression tree, so EF Core can push it into SQL.</summary>
+    Expression<Func<TaskEntity, bool>> MatchExpression { get; }
+
     /// <summary>True if <paramref name="t"/> should be counted in this list's badge.</summary>
     bool ShouldCount(TaskEntity t);
 

src/ClaudeDo.Data/Git/ConflictMarkerParser.cs

@@ -0,0 +1,140 @@
+using System;
+using System.Collections.Generic;
+using System.Linq;
+using System.Text;
+
+namespace ClaudeDo.Data.Git;
+
+/// <summary>
+/// One piece of a conflicted file: either common ("stable") text both sides agree on,
+/// or a conflict region holding the two — or, with diff3 markers, three — competing versions.
+/// </summary>
+public sealed record MergeSegment
+{
+    public bool IsConflict { get; init; }
+
+    /// <summary>Stable text (verbatim, line endings preserved) when <see cref="IsConflict"/> is false.</summary>
+    public string Text { get; init; } = "";
+
+    /// <summary>"Ours" side (the target branch) when <see cref="IsConflict"/> is true.</summary>
+    public string Ours { get; init; } = "";
+
+    /// <summary>Merge base, present only when the merge used diff3 conflict style; null otherwise.</summary>
+    public string? Base { get; init; }
+
+    /// <summary>"Theirs" side (the incoming branch) when <see cref="IsConflict"/> is true.</summary>
+    public string Theirs { get; init; } = "";
+
+    /// <summary>1-based line number in the file where this segment starts (the marker line for a conflict).</summary>
+    public int StartLine { get; init; } = 1;
+
+    public static MergeSegment Stable(string text, int startLine = 1) => new() { Text = text, StartLine = startLine };
+
+    public static MergeSegment Conflict(string ours, string? @base, string theirs, int startLine = 1) =>
+        new() { IsConflict = true, Ours = ours, Base = @base, Theirs = theirs, StartLine = startLine };
+}
+
+/// <summary>
+/// Parses a conflicted file's text into ordered stable / conflict segments and reassembles it.
+/// Reads git conflict markers verbatim, so a file with no markers yields a single stable
+/// segment, and reassembling the stable text plus one chosen resolution per conflict
+/// round-trips the file exactly (line endings included).
+/// </summary>
+public static class ConflictMarkerParser
+{
+    private const string OursMarker   = "<<<<<<<";
+    private const string BaseMarker   = "|||||||";
+    private const string SepMarker    = "=======";
+    private const string TheirsMarker = ">>>>>>>";
+
+    public static IReadOnlyList<MergeSegment> Parse(string fileText)
+    {
+        var segments = new List<MergeSegment>();
+        var lines = SplitKeepLineEndings(fileText);
+        var stable = new StringBuilder();
+        var stableStartLine = 1;
+        var i = 0;
+
+        while (i < lines.Count)
+        {
+            if (!IsMarker(lines[i], OursMarker))
+            {
+                if (stable.Length == 0) stableStartLine = i + 1;
+                stable.Append(lines[i++]);
+                continue;
+            }
+
+            if (stable.Length > 0)
+            {
+                segments.Add(MergeSegment.Stable(stable.ToString(), stableStartLine));
+                stable.Clear();
+            }
+
+            var conflictStartLine = i + 1;
+            i++; // consume "<<<<<<<"
+            var ours = new StringBuilder();
+            while (i < lines.Count && !IsMarker(lines[i], BaseMarker) && !IsMarker(lines[i], SepMarker))
+                ours.Append(lines[i++]);
+
+            string? @base = null;
+            if (i < lines.Count && IsMarker(lines[i], BaseMarker))
+            {
+                i++; // consume "|||||||"
+                var baseText = new StringBuilder();
+                while (i < lines.Count && !IsMarker(lines[i], SepMarker))
+                    baseText.Append(lines[i++]);
+                @base = baseText.ToString();
+            }
+
+            if (i < lines.Count && IsMarker(lines[i], SepMarker)) i++; // consume "======="
+
+            var theirs = new StringBuilder();
+            while (i < lines.Count && !IsMarker(lines[i], TheirsMarker))
+                theirs.Append(lines[i++]);
+
+            if (i < lines.Count && IsMarker(lines[i], TheirsMarker)) i++; // consume ">>>>>>>"
+
+            segments.Add(MergeSegment.Conflict(ours.ToString(), @base, theirs.ToString(), conflictStartLine));
+        }
+
+        if (stable.Length > 0)
+            segments.Add(MergeSegment.Stable(stable.ToString(), stableStartLine));
+
+        return segments;
+    }
+
+    /// <summary>True when the file still contains an opening conflict marker.</summary>
+    public static bool HasConflicts(string fileText) =>
+        SplitKeepLineEndings(fileText).Any(l => IsMarker(l, OursMarker));
+
+    /// <summary>
+    /// Reassembles a file from its segments. Stable segments emit their text verbatim;
+    /// each conflict segment emits whatever <paramref name="resolveConflict"/> returns for it.
+    /// </summary>
+    public static string Compose(
+        IEnumerable<MergeSegment> segments, Func<MergeSegment, string> resolveConflict) =>
+        string.Concat(segments.Select(s => s.IsConflict ? resolveConflict(s) : s.Text));
+
+    // A marker line starts with exactly the 7-char marker, then end-of-line or whitespace/label.
+    private static bool IsMarker(string line, string marker)
+    {
+        if (!line.StartsWith(marker, StringComparison.Ordinal)) return false;
+        if (line.Length == marker.Length) return true;
+        return line[marker.Length] is ' ' or '\t' or '\r' or '\n';
+    }
+
+    // Splits into physical lines, each retaining its trailing "\n" (and "\r" if present).
+    private static List<string> SplitKeepLineEndings(string s)
+    {
+        var lines = new List<string>();
+        var i = 0;
+        while (i < s.Length)
+        {
+            var nl = s.IndexOf('\n', i);
+            if (nl < 0) { lines.Add(s[i..]); break; }
+            lines.Add(s[i..(nl + 1)]);
+            i = nl + 1;
+        }
+        return lines;
+    }
+}

src/ClaudeDo.Data/Git/GitService.cs

@@ -3,10 +3,18 @@ using System.Text;
 
 namespace ClaudeDo.Data.Git;
 
-public sealed record MergePreview(bool Supported, bool Clean, IReadOnlyList<string> ConflictFiles);
+// TreeOid is only populated when Clean — the tree `merge-tree --write-tree` would produce,
+// usable to materialize the merge result into a scratch worktree without touching the real
+// working tree, index, or refs (see GitService.CommitTreeAsync / WorktreeAddDetachedAsync).
+public sealed record MergePreview(bool Supported, bool Clean, IReadOnlyList<string> ConflictFiles, string? TreeOid = null);
 
 public sealed class GitService
 {
+    // git mutates shared .git/worktrees/ metadata during `worktree add`; concurrent adds
+    // race and fail with "failed to read .git/worktrees/<other>/commondir". Serialize them
+    // process-wide so parallel task starts don't collide.
+    private static readonly SemaphoreSlim WorktreeAddGate = new(1, 1);
+
     public async Task<bool> IsGitRepoAsync(string dir, CancellationToken ct = default)
     {
         var (exitCode, _, _) = await RunGitAsync(dir, ["rev-parse", "--git-dir"], ct);
@@ -21,17 +29,66 @@ public sealed class GitService
         return stdout.Trim();
     }
 
-    public async Task WorktreeAddAsync(string repoDir, string branchName, string worktreePath, string baseCommit, CancellationToken ct = default)
+    /// <summary>
+    /// True if <paramref name="ancestorSha"/> is an ancestor of (or equal to) <paramref name="descendantSha"/>,
+    /// via `git merge-base --is-ancestor`. Null means the answer can't be determined (e.g. the commit is
+    /// unknown in this repo) — callers must treat that as "unknown", never as "not an ancestor".
+    /// </summary>
+    public async Task<bool?> IsAncestorAsync(string repoDir, string ancestorSha, string descendantSha, CancellationToken ct = default)
     {
-        var (exitCode, _, stderr) = await RunGitAsync(repoDir,
-            ["worktree", "add", "-b", branchName, worktreePath, baseCommit], ct);
-        if (exitCode != 0)
-            throw new InvalidOperationException($"git worktree add failed (exit {exitCode}): {stderr}");
+        var (exitCode, _, _) = await RunGitAsync(repoDir, ["merge-base", "--is-ancestor", ancestorSha, descendantSha], ct);
+        return exitCode switch
+        {
+            0 => true,
+            1 => false,
+            _ => null,
+        };
     }
 
+    /// <summary>
+    /// The merge base of two refs, or null when git can't find one (e.g. an unresolvable ref) —
+    /// callers treat that as "can't evaluate", not "no common history".
+    /// </summary>
+    public async Task<string?> MergeBaseAsync(string repoDir, string refA, string refB, CancellationToken ct = default)
+    {
+        var (exitCode, stdout, _) = await RunGitAsync(repoDir, ["merge-base", refA, refB], ct);
+        return exitCode == 0 ? stdout.Trim() : null;
+    }
+
+    public async Task WorktreeAddAsync(string repoDir, string branchName, string worktreePath, string baseCommit, CancellationToken ct = default)
+    {
+        await WorktreeAddGate.WaitAsync(ct);
+        try
+        {
+            const int maxAttempts = 3;
+            for (var attempt = 1; ; attempt++)
+            {
+                var (exitCode, _, stderr) = await RunGitAsync(repoDir,
+                    ["worktree", "add", "-b", branchName, worktreePath, baseCommit], ct);
+                if (exitCode == 0)
+                    return;
+
+                // Transient races leave a half-written worktree metadata dir; retry briefly.
+                var transient = stderr.Contains("commondir", StringComparison.OrdinalIgnoreCase)
+                    || stderr.Contains("failed to read", StringComparison.OrdinalIgnoreCase);
+                if (!transient || attempt >= maxAttempts)
+                    throw new InvalidOperationException($"git worktree add failed (exit {exitCode}): {stderr}");
+
+                await Task.Delay(150 * attempt, ct);
+            }
+        }
+        finally
+        {
+            WorktreeAddGate.Release();
+        }
+    }
+
+    // --untracked-files=all: without it, a brand-new untracked directory collapses into a single
+    // "?? dir/" entry instead of listing the files inside it — callers matching against specific
+    // paths (e.g. the untracked-collision guard) need the individual files.
     public async Task<string> GetStatusPorcelainAsync(string workingDirectory, CancellationToken ct = default)
     {
-        var (exitCode, stdout, stderr) = await RunGitAsync(workingDirectory, ["status", "--porcelain"], ct);
+        var (exitCode, stdout, stderr) = await RunGitAsync(workingDirectory, ["status", "--porcelain", "--untracked-files=all"], ct);
         if (exitCode != 0)
             throw new InvalidOperationException($"git status --porcelain failed (exit {exitCode}): {stderr}");
         return stdout;
@@ -46,9 +103,22 @@ public sealed class GitService
         return stdout;
     }
 
-    public async Task<bool> HasChangesAsync(string worktreePath, CancellationToken ct = default)
+    public Task<bool> HasChangesAsync(string worktreePath, CancellationToken ct = default) =>
+        HasChangesAsync(worktreePath, includeUntracked: true, ct);
+
+    /// <summary>
+    /// Uncommitted-changes check. <paramref name="includeUntracked"/>=false ignores untracked
+    /// files — use this for merge preflights on a shared target working dir, where stray
+    /// untracked files (e.g. from a concurrent session) shouldn't block a merge. Auto-commit
+    /// and data-loss-guard callers keep the default (true): a new file a task created, or an
+    /// untracked file about to be discarded, is a real uncommitted change.
+    /// </summary>
+    public async Task<bool> HasChangesAsync(string worktreePath, bool includeUntracked, CancellationToken ct = default)
     {
-        var (exitCode, stdout, stderr) = await RunGitAsync(worktreePath, ["status", "--porcelain"], ct);
+        string[] args = includeUntracked
+            ? ["status", "--porcelain"]
+            : ["status", "--porcelain", "--untracked-files=no"];
+        var (exitCode, stdout, stderr) = await RunGitAsync(worktreePath, args, ct);
         if (exitCode != 0)
             throw new InvalidOperationException($"git status --porcelain failed (exit {exitCode}): {stderr}");
         return !string.IsNullOrWhiteSpace(stdout);
@@ -69,16 +139,20 @@ public sealed class GitService
             throw new InvalidOperationException($"git commit failed (exit {exitCode}): {stderr}");
     }
 
-    public async Task<string> GetDiffAsync(string worktreePath, CancellationToken ct = default)
+    public async Task<string> GetDiffAsync(
+        string worktreePath, IReadOnlyList<string>? paths = null, CancellationToken ct = default)
     {
-        var (exitCode, stdout, stderr) = await RunGitAsync(worktreePath,
-            ["diff", "HEAD"], ct);
+        var args = new List<string> { "diff", "HEAD" };
+        AppendPathFilter(args, paths);
+        var (exitCode, stdout, stderr) = await RunGitAsync(worktreePath, args, ct);
         if (exitCode != 0)
             throw new InvalidOperationException($"git diff HEAD failed (exit {exitCode}): {stderr}");
         // If nothing staged vs HEAD, try the index (untracked is never in diff)
         if (string.IsNullOrWhiteSpace(stdout))
         {
-            var (e2, s2, _) = await RunGitAsync(worktreePath, ["diff", "--cached"], ct);
+            var cachedArgs = new List<string> { "diff", "--cached" };
+            AppendPathFilter(cachedArgs, paths);
+            var (e2, s2, _) = await RunGitAsync(worktreePath, cachedArgs, ct);
             if (e2 == 0) return s2;
         }
         return stdout;
@@ -89,25 +163,58 @@ public sealed class GitService
     /// (committed-on-branch changes + uncommitted work). Used for viewing a Claude
     /// task's total impact relative to where the branch started.
     /// </summary>
-    public async Task<string> GetBranchDiffAsync(string worktreePath, string baseRef, CancellationToken ct = default)
+    public async Task<string> GetBranchDiffAsync(
+        string worktreePath, string baseRef, IReadOnlyList<string>? paths = null, CancellationToken ct = default)
     {
-        var (exitCode, stdout, _) = await RunGitAsync(worktreePath,
-            ["diff", baseRef], ct);
+        var args = new List<string> { "diff", baseRef };
+        AppendPathFilter(args, paths);
+        var (exitCode, stdout, _) = await RunGitAsync(worktreePath, args, ct);
         if (exitCode == 0 && !string.IsNullOrWhiteSpace(stdout))
             return stdout;
-        // Fallback: whatever the worktree has vs HEAD (uncommitted only).
-        return await GetDiffAsync(worktreePath, ct);
+        // Fallback: whatever the worktree has vs HEAD (uncommitted only). The same pathspec has to
+        // come along — a filter makes an empty ranged diff the common case (the caller asked for
+        // paths this range never touched), and an unfiltered fallback would answer that with the
+        // whole worktree diff, the exact opposite of what was requested.
+        return await GetDiffAsync(worktreePath, paths, ct);
     }
 
-    public async Task<string> DiffStatAsync(string worktreePath, string baseCommit, string headCommit, CancellationToken ct = default)
+    /// <summary>
+    /// Diff between two commits, run in any repo that can reach them. Used to view a
+    /// task's changes after its worktree has been merged away (the commits survive on
+    /// the target branch even though the worktree directory and branch ref are gone).
+    /// </summary>
+    public async Task<string> GetCommitRangeDiffAsync(
+        string repoDir, string baseCommit, string headCommit, IReadOnlyList<string>? paths = null, CancellationToken ct = default)
     {
-        var (exitCode, stdout, stderr) = await RunGitAsync(worktreePath,
-            ["diff", "--stat", $"{baseCommit}..{headCommit}"], ct);
+        var args = new List<string> { "diff", $"{baseCommit}..{headCommit}" };
+        AppendPathFilter(args, paths);
+        var (exitCode, stdout, stderr) = await RunGitAsync(repoDir, args, ct);
+        if (exitCode != 0)
+            throw new InvalidOperationException($"git diff {baseCommit}..{headCommit} failed (exit {exitCode}): {stderr}");
+        return stdout;
+    }
+
+    public async Task<string> DiffStatAsync(
+        string worktreePath, string baseCommit, string headCommit, IReadOnlyList<string>? paths = null, CancellationToken ct = default)
+    {
+        var args = new List<string> { "diff", "--stat", $"{baseCommit}..{headCommit}" };
+        AppendPathFilter(args, paths);
+        var (exitCode, stdout, stderr) = await RunGitAsync(worktreePath, args, ct);
         if (exitCode != 0)
             throw new InvalidOperationException($"git diff --stat failed (exit {exitCode}): {stderr}");
         return stdout.Trim();
     }
 
+    // Appends a `-- <paths>` pathspec filter so git itself narrows the diff instead of the
+    // caller filtering the result after the fact (works identically for --stat and full diffs).
+    // No-op when paths is null/empty so existing callers see no behavior change.
+    private static void AppendPathFilter(List<string> args, IReadOnlyList<string>? paths)
+    {
+        if (paths is not { Count: > 0 }) return;
+        args.Add("--");
+        args.AddRange(paths);
+    }
+
     public async Task<string> GetFileDiffAsync(string worktreePath, string? baseCommit, string relativePath, CancellationToken ct = default)
     {
         string[] args = string.IsNullOrEmpty(baseCommit)
@@ -213,8 +320,11 @@ public sealed class GitService
     public async Task<(int ExitCode, string Stderr)> MergeNoFfAsync(
         string repoDir, string sourceBranch, string message, CancellationToken ct = default)
     {
+        // diff3 conflict style writes the merge base (|||||||) into conflict markers so the
+        // in-app resolver can show a true three-way view. It only enriches conflicted hunks;
+        // clean merges are unaffected.
         var (exitCode, _, stderr) = await RunGitAsync(repoDir,
-            ["merge", "--no-ff", "-m", message, sourceBranch], ct);
+            ["-c", "merge.conflictStyle=diff3", "merge", "--no-ff", "-m", message, sourceBranch], ct);
         return (exitCode, stderr);
     }
 
@@ -225,6 +335,36 @@ public sealed class GitService
             throw new InvalidOperationException($"git merge --abort failed (exit {exitCode}): {stderr}");
     }
 
+    public async Task<bool> IsMidRevertAsync(string repoDir, CancellationToken ct = default)
+    {
+        var (exitCode, stdout, _) = await RunGitAsync(repoDir, ["rev-parse", "--git-dir"], ct);
+        if (exitCode != 0) return false;
+        var gitDir = stdout.Trim();
+        if (!Path.IsPathRooted(gitDir))
+            gitDir = Path.Combine(repoDir, gitDir);
+        return File.Exists(Path.Combine(gitDir, "REVERT_HEAD"));
+    }
+
+    /// <summary>
+    /// Reverts a single commit with `-m 1` (diff against its first parent) — the form needed to
+    /// revert a merge commit. On success this creates a new commit with the inverse changes;
+    /// the original commit and all history stay intact (no rewrite, no reset).
+    /// </summary>
+    public async Task<(int ExitCode, string Stderr)> RevertMergeCommitAsync(
+        string repoDir, string mergeCommitSha, CancellationToken ct = default)
+    {
+        var (exitCode, _, stderr) = await RunGitAsync(repoDir,
+            ["-c", "merge.conflictStyle=diff3", "revert", "--no-edit", "-m", "1", mergeCommitSha], ct);
+        return (exitCode, stderr);
+    }
+
+    public async Task RevertAbortAsync(string repoDir, CancellationToken ct = default)
+    {
+        var (exitCode, _, stderr) = await RunGitAsync(repoDir, ["revert", "--abort"], ct);
+        if (exitCode != 0)
+            throw new InvalidOperationException($"git revert --abort failed (exit {exitCode}): {stderr}");
+    }
+
     public async Task<List<string>> ListConflictedFilesAsync(string repoDir, CancellationToken ct = default)
     {
         var (exitCode, stdout, stderr) = await RunGitAsync(repoDir,
@@ -238,6 +378,13 @@ public sealed class GitService
             .ToList();
     }
 
+    public async Task AddPathAsync(string repoDir, string path, CancellationToken ct = default)
+    {
+        var (exitCode, _, stderr) = await RunGitAsync(repoDir, ["add", "--", path], ct);
+        if (exitCode != 0)
+            throw new InvalidOperationException($"git add '{path}' failed (exit {exitCode}): {stderr}");
+    }
+
     /// <summary>
     /// Non-destructive mergeability probe via `git merge-tree --write-tree`. Writes only
     /// loose objects — the working tree, index, and refs are left untouched.
@@ -249,7 +396,8 @@ public sealed class GitService
             ["merge-tree", "--write-tree", "--name-only", targetBranch, sourceBranch], ct);
 
         if (exitCode == 0)
-            return new MergePreview(true, true, Array.Empty<string>());
+            // stdout is just the written tree's oid on a clean merge.
+            return new MergePreview(true, true, Array.Empty<string>(), stdout.Trim());
 
         if (exitCode == 1)
         {
@@ -269,6 +417,62 @@ public sealed class GitService
         return new MergePreview(false, false, Array.Empty<string>());
     }
 
+    /// <summary>Resolves <paramref name="revision"/> (a branch, tag, or SHA) to a full commit SHA.</summary>
+    public async Task<string> RevParseAsync(string repoDir, string revision, CancellationToken ct = default)
+    {
+        var (exitCode, stdout, stderr) = await RunGitAsync(repoDir, ["rev-parse", revision], ct);
+        if (exitCode != 0)
+            throw new InvalidOperationException($"git rev-parse '{revision}' failed (exit {exitCode}): {stderr}");
+        return stdout.Trim();
+    }
+
+    /// <summary>
+    /// Creates a new commit object wrapping <paramref name="treeOid"/> with <paramref name="parentSha"/>
+    /// as its single parent, writing only a loose object — no ref is created or moved.
+    /// </summary>
+    public async Task<string> CommitTreeAsync(
+        string repoDir, string treeOid, string parentSha, string message, CancellationToken ct = default)
+    {
+        var (exitCode, stdout, stderr) = await RunGitAsync(repoDir,
+            ["commit-tree", treeOid, "-p", parentSha, "-m", message], ct);
+        if (exitCode != 0)
+            throw new InvalidOperationException($"git commit-tree failed (exit {exitCode}): {stderr}");
+        return stdout.Trim();
+    }
+
+    /// <summary>
+    /// Materializes <paramref name="commitish"/> into a new, branchless worktree at
+    /// <paramref name="worktreePath"/> (detached HEAD) — used to build/verify a merge-tree
+    /// result without ever creating a branch or touching the real working tree.
+    /// </summary>
+    public async Task WorktreeAddDetachedAsync(
+        string repoDir, string worktreePath, string commitish, CancellationToken ct = default)
+    {
+        await WorktreeAddGate.WaitAsync(ct);
+        try
+        {
+            const int maxAttempts = 3;
+            for (var attempt = 1; ; attempt++)
+            {
+                var (exitCode, _, stderr) = await RunGitAsync(repoDir,
+                    ["worktree", "add", "--detach", worktreePath, commitish], ct);
+                if (exitCode == 0)
+                    return;
+
+                var transient = stderr.Contains("commondir", StringComparison.OrdinalIgnoreCase)
+                    || stderr.Contains("failed to read", StringComparison.OrdinalIgnoreCase);
+                if (!transient || attempt >= maxAttempts)
+                    throw new InvalidOperationException($"git worktree add --detach failed (exit {exitCode}): {stderr}");
+
+                await Task.Delay(150 * attempt, ct);
+            }
+        }
+        finally
+        {
+            WorktreeAddGate.Release();
+        }
+    }
+
     /// <summary>Count of files that differ on <paramref name="sourceBranch"/> since its merge base with the target.</summary>
     public async Task<int> CountChangedFilesAsync(
         string repoDir, string targetBranch, string sourceBranch, CancellationToken ct = default)
@@ -281,15 +485,45 @@ public sealed class GitService
             .Count(s => s.Length > 0);
     }
 
-    public async Task MergeFfOnlyAsync(string repoDir, string branchName, CancellationToken ct = default)
+    /// <summary>Files that differ between two exact refs (2-dot, no merge-base resolution) -- used to see
+    /// what a target branch itself picked up since a task's fork point, as opposed to
+    /// <see cref="CountChangedFilesAsync"/>'s 3-dot count of a branch's own changes.</summary>
+    public async Task<IReadOnlyList<string>> GetChangedFileNamesAsync(
+        string repoDir, string fromRef, string toRef, CancellationToken ct = default)
     {
-        var (exitCode, _, stderr) = await RunGitAsync(repoDir, ["merge", "--ff-only", branchName], ct);
-        if (exitCode != 0)
-            throw new InvalidOperationException($"Fast-forward merge of '{branchName}' failed. Manual merge required. git stderr: {stderr}");
+        var (exitCode, stdout, _) = await RunGitAsync(repoDir,
+            ["diff", "--name-only", $"{fromRef}..{toRef}"], ct);
+        if (exitCode != 0) return Array.Empty<string>();
+        return stdout
+            .Split('\n', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries)
+            .Where(s => s.Length > 0)
+            .ToList();
     }
 
+    /// <summary>
+    /// Rebases the branch checked out at <paramref name="worktreePath"/> onto <paramref name="ontoRef"/>.
+    /// On conflict or any other failure the rebase is aborted before returning, so the worktree is left
+    /// exactly as it was rather than stranded mid-rebase; <c>ConflictFiles</c> is best-effort and only
+    /// populated when the failure was an actual conflict.
+    /// </summary>
+    public async Task<(int ExitCode, string Stderr, IReadOnlyList<string> ConflictFiles)> RebaseAsync(
+        string worktreePath, string ontoRef, CancellationToken ct = default)
+    {
+        var (exitCode, _, stderr) = await RunGitAsync(worktreePath, ["rebase", ontoRef], ct);
+        if (exitCode == 0)
+            return (0, stderr, Array.Empty<string>());
+
+        List<string> conflictFiles;
+        try { conflictFiles = await ListConflictedFilesAsync(worktreePath, ct); }
+        catch { conflictFiles = new(); }
+
+        await RunGitAsync(worktreePath, ["rebase", "--abort"], ct);
+        return (exitCode, stderr, conflictFiles);
+    }
+
+
     private static async Task<(int ExitCode, string Stdout, string Stderr)> RunGitAsync(
-        string workDir, IEnumerable<string> args, CancellationToken ct, string? stdinData = null)
+        string workDir, IEnumerable<string> args, CancellationToken ct, string? stdinData = null, bool trimOutput = true)
     {
         var psi = new ProcessStartInfo
         {
@@ -338,6 +572,6 @@ public sealed class GitService
 
         ct.ThrowIfCancellationRequested();
 
-        return (proc.ExitCode, stdout.TrimEnd(), stderr.TrimEnd());
+        return (proc.ExitCode, trimOutput ? stdout.TrimEnd() : stdout, stderr.TrimEnd());
     }
 }

src/ClaudeDo.Data/Migrations/20260609000000_UniqueListName.Designer.cs

@@ -0,0 +1,696 @@
+// <auto-generated />
+using System;
+using ClaudeDo.Data;
+using Microsoft.EntityFrameworkCore;
+using Microsoft.EntityFrameworkCore.Infrastructure;
+using Microsoft.EntityFrameworkCore.Migrations;
+using Microsoft.EntityFrameworkCore.Storage.ValueConversion;
+
+#nullable disable
+
+namespace ClaudeDo.Data.Migrations
+{
+    [DbContext(typeof(ClaudeDoDbContext))]
+    [Migration("20260609000000_UniqueListName")]
+    partial class UniqueListName
+    {
+        /// <inheritdoc />
+        protected override void BuildTargetModel(ModelBuilder modelBuilder)
+        {
+#pragma warning disable 612, 618
+            modelBuilder.HasAnnotation("ProductVersion", "8.0.11");
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.AppSettingsEntity", b =>
+                {
+                    b.Property<int>("Id")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("id");
+
+                    b.Property<string>("CentralWorktreeRoot")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("central_worktree_root");
+
+                    b.Property<int>("DailyPrepMaxTasks")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(5)
+                        .HasColumnName("daily_prep_max_tasks");
+
+                    b.Property<string>("DefaultClaudeInstructions")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("")
+                        .HasColumnName("default_claude_instructions");
+
+                    b.Property<int>("DefaultMaxTurns")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(30)
+                        .HasColumnName("default_max_turns");
+
+                    b.Property<string>("DefaultModel")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("sonnet")
+                        .HasColumnName("default_model");
+
+                    b.Property<string>("DefaultPermissionMode")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("bypassPermissions")
+                        .HasColumnName("default_permission_mode");
+
+                    b.Property<int>("MaxParallelExecutions")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(1)
+                        .HasColumnName("max_parallel_executions");
+
+                    b.Property<string>("RepoImportFolders")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("repo_import_folders");
+
+                    b.Property<string>("ReportExcludedPaths")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("report_excluded_paths");
+
+                    b.Property<int>("StandupWeekday")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(3)
+                        .HasColumnName("standup_weekday");
+
+                    b.Property<int>("WorktreeAutoCleanupDays")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(7)
+                        .HasColumnName("worktree_auto_cleanup_days");
+
+                    b.Property<bool>("WorktreeAutoCleanupEnabled")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(false)
+                        .HasColumnName("worktree_auto_cleanup_enabled");
+
+                    b.Property<string>("WorktreeStrategy")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("sibling")
+                        .HasColumnName("worktree_strategy");
+
+                    b.HasKey("Id");
+
+                    b.ToTable("app_settings", (string)null);
+
+                    b.HasData(
+                        new
+                        {
+                            Id = 1,
+                            DailyPrepMaxTasks = 5,
+                            DefaultClaudeInstructions = "",
+                            DefaultMaxTurns = 100,
+                            DefaultModel = "sonnet",
+                            DefaultPermissionMode = "auto",
+                            MaxParallelExecutions = 1,
+                            StandupWeekday = 3,
+                            WorktreeAutoCleanupDays = 7,
+                            WorktreeAutoCleanupEnabled = false,
+                            WorktreeStrategy = "sibling"
+                        });
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.DailyNoteEntity", b =>
+                {
+                    b.Property<string>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<DateTime>("CreatedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_at");
+
+                    b.Property<DateOnly>("Date")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("note_date");
+
+                    b.Property<int>("SortOrder")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("sort_order");
+
+                    b.Property<string>("Text")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("text");
+
+                    b.HasKey("Id");
+
+                    b.HasIndex("Date");
+
+                    b.ToTable("daily_notes", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.ListConfigEntity", b =>
+                {
+                    b.Property<string>("ListId")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("list_id");
+
+                    b.Property<string>("AgentPath")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("agent_path");
+
+                    b.Property<int?>("MaxTurns")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("max_turns");
+
+                    b.Property<string>("Model")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("model");
+
+                    b.Property<string>("SystemPrompt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("system_prompt");
+
+                    b.HasKey("ListId");
+
+                    b.ToTable("list_config", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.ListEntity", b =>
+                {
+                    b.Property<string>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<DateTime>("CreatedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_at");
+
+                    b.Property<string>("DefaultCommitType")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("chore")
+                        .HasColumnName("default_commit_type");
+
+                    b.Property<string>("Name")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("name");
+
+                    b.Property<int>("SortOrder")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(0)
+                        .HasColumnName("sort_order");
+
+                    b.Property<string>("WorkingDir")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("working_dir");
+
+                    b.HasKey("Id");
+
+                    b.HasIndex("SortOrder")
+                        .HasDatabaseName("idx_lists_sort");
+
+                    b.ToTable("lists", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.PrimeScheduleEntity", b =>
+                {
+                    b.Property<Guid>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<DateTimeOffset>("CreatedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_at");
+
+                    b.Property<int>("Days")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(31)
+                        .HasColumnName("days_of_week");
+
+                    b.Property<bool>("Enabled")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(true)
+                        .HasColumnName("enabled");
+
+                    b.Property<DateTimeOffset?>("LastRunAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("last_run_at");
+
+                    b.Property<string>("PromptOverride")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("prompt_override");
+
+                    b.Property<TimeSpan>("TimeOfDay")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("time_of_day");
+
+                    b.HasKey("Id");
+
+                    b.ToTable("prime_schedules", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.SubtaskEntity", b =>
+                {
+                    b.Property<string>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<bool>("Completed")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(false)
+                        .HasColumnName("completed");
+
+                    b.Property<DateTime>("CreatedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_at");
+
+                    b.Property<int>("OrderNum")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("order_num");
+
+                    b.Property<string>("TaskId")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("task_id");
+
+                    b.Property<string>("Title")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("title");
+
+                    b.HasKey("Id");
+
+                    b.HasIndex("TaskId")
+                        .HasDatabaseName("idx_subtasks_task_id");
+
+                    b.ToTable("subtasks", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.TaskEntity", b =>
+                {
+                    b.Property<string>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<string>("AgentPath")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("agent_path");
+
+                    b.Property<string>("BlockedByTaskId")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("blocked_by_task_id");
+
+                    b.Property<string>("CommitType")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("chore")
+                        .HasColumnName("commit_type");
+
+                    b.Property<DateTime>("CreatedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_at");
+
+                    b.Property<string>("CreatedBy")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_by");
+
+                    b.Property<string>("Description")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("description");
+
+                    b.Property<DateTime?>("FinishedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("finished_at");
+
+                    b.Property<bool>("IsMyDay")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(false)
+                        .HasColumnName("is_my_day");
+
+                    b.Property<bool>("IsStarred")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(false)
+                        .HasColumnName("is_starred");
+
+                    b.Property<string>("ListId")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("list_id");
+
+                    b.Property<string>("LogPath")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("log_path");
+
+                    b.Property<int?>("MaxTurns")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("max_turns");
+
+                    b.Property<string>("Model")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("model");
+
+                    b.Property<string>("Notes")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("notes");
+
+                    b.Property<string>("ParentTaskId")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("parent_task_id");
+
+                    b.Property<DateTime?>("PlanningFinalizedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("planning_finalized_at");
+
+                    b.Property<string>("PlanningPhase")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("none")
+                        .HasColumnName("planning_phase");
+
+                    b.Property<string>("PlanningSessionId")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("planning_session_id");
+
+                    b.Property<string>("PlanningSessionToken")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("planning_session_token");
+
+                    b.Property<string>("Result")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("result");
+
+                    b.Property<string>("ReviewFeedback")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("review_feedback");
+
+                    b.Property<int>("RoadblockCount")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(0)
+                        .HasColumnName("roadblock_count");
+
+                    b.Property<DateTime?>("ScheduledFor")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("scheduled_for");
+
+                    b.Property<int>("SortOrder")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(0)
+                        .HasColumnName("sort_order");
+
+                    b.Property<DateTime?>("StartedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("started_at");
+
+                    b.Property<string>("Status")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("status");
+
+                    b.Property<string>("SystemPrompt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("system_prompt");
+
+                    b.Property<string>("Title")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("title");
+
+                    b.HasKey("Id");
+
+                    b.HasIndex("BlockedByTaskId")
+                        .HasDatabaseName("idx_tasks_blocked_by");
+
+                    b.HasIndex("ListId")
+                        .HasDatabaseName("idx_tasks_list_id");
+
+                    b.HasIndex("ParentTaskId")
+                        .HasDatabaseName("idx_tasks_parent_task_id");
+
+                    b.HasIndex("Status")
+                        .HasDatabaseName("idx_tasks_status");
+
+                    b.HasIndex("ListId", "SortOrder")
+                        .HasDatabaseName("idx_tasks_list_sort");
+
+                    b.ToTable("tasks", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.TaskRunEntity", b =>
+                {
+                    b.Property<string>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<string>("ErrorMarkdown")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("error_markdown");
+
+                    b.Property<int?>("ExitCode")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("exit_code");
+
+                    b.Property<DateTime?>("FinishedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("finished_at");
+
+                    b.Property<bool>("IsRetry")
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("INTEGER")
+                        .HasDefaultValue(false)
+                        .HasColumnName("is_retry");
+
+                    b.Property<string>("LogPath")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("log_path");
+
+                    b.Property<string>("Prompt")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("prompt");
+
+                    b.Property<string>("ResultMarkdown")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("result_markdown");
+
+                    b.Property<int>("RunNumber")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("run_number");
+
+                    b.Property<string>("SessionId")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("session_id");
+
+                    b.Property<DateTime?>("StartedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("started_at");
+
+                    b.Property<string>("StructuredOutputJson")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("structured_output");
+
+                    b.Property<string>("TaskId")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("task_id");
+
+                    b.Property<int?>("TokensIn")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("tokens_in");
+
+                    b.Property<int?>("TokensOut")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("tokens_out");
+
+                    b.Property<int?>("TurnCount")
+                        .HasColumnType("INTEGER")
+                        .HasColumnName("turn_count");
+
+                    b.HasKey("Id");
+
+                    b.HasIndex("TaskId")
+                        .HasDatabaseName("idx_task_runs_task_id");
+
+                    b.ToTable("task_runs", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.WeekReportEntity", b =>
+                {
+                    b.Property<string>("Id")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("id");
+
+                    b.Property<DateOnly>("EndDate")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("end_date");
+
+                    b.Property<DateTime>("GeneratedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("generated_at");
+
+                    b.Property<string>("Markdown")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("markdown");
+
+                    b.Property<DateOnly>("StartDate")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("start_date");
+
+                    b.HasKey("Id");
+
+                    b.HasIndex("StartDate", "EndDate")
+                        .IsUnique();
+
+                    b.ToTable("week_reports", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.WorktreeEntity", b =>
+                {
+                    b.Property<string>("TaskId")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("task_id");
+
+                    b.Property<string>("BaseCommit")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("base_commit");
+
+                    b.Property<string>("BranchName")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("branch_name");
+
+                    b.Property<DateTime>("CreatedAt")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("created_at");
+
+                    b.Property<string>("DiffStat")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("diff_stat");
+
+                    b.Property<string>("HeadCommit")
+                        .HasColumnType("TEXT")
+                        .HasColumnName("head_commit");
+
+                    b.Property<string>("Path")
+                        .IsRequired()
+                        .HasColumnType("TEXT")
+                        .HasColumnName("path");
+
+                    b.Property<string>("State")
+                        .IsRequired()
+                        .ValueGeneratedOnAdd()
+                        .HasColumnType("TEXT")
+                        .HasDefaultValue("active")
+                        .HasColumnName("state");
+
+                    b.HasKey("TaskId");
+
+                    b.ToTable("worktrees", (string)null);
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.ListConfigEntity", b =>
+                {
+                    b.HasOne("ClaudeDo.Data.Models.ListEntity", "List")
+                        .WithOne("Config")
+                        .HasForeignKey("ClaudeDo.Data.Models.ListConfigEntity", "ListId")
+                        .OnDelete(DeleteBehavior.Cascade)
+                        .IsRequired();
+
+                    b.Navigation("List");
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.SubtaskEntity", b =>
+                {
+                    b.HasOne("ClaudeDo.Data.Models.TaskEntity", "Task")
+                        .WithMany("Subtasks")
+                        .HasForeignKey("TaskId")
+                        .OnDelete(DeleteBehavior.Cascade)
+                        .IsRequired();
+
+                    b.Navigation("Task");
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.TaskEntity", b =>
+                {
+                    b.HasOne("ClaudeDo.Data.Models.TaskEntity", null)
+                        .WithMany()
+                        .HasForeignKey("BlockedByTaskId")
+                        .OnDelete(DeleteBehavior.SetNull);
+
+                    b.HasOne("ClaudeDo.Data.Models.ListEntity", "List")
+                        .WithMany("Tasks")
+                        .HasForeignKey("ListId")
+                        .OnDelete(DeleteBehavior.Cascade)
+                        .IsRequired();
+
+                    b.HasOne("ClaudeDo.Data.Models.TaskEntity", "Parent")
+                        .WithMany("Children")
+                        .HasForeignKey("ParentTaskId")
+                        .OnDelete(DeleteBehavior.Restrict);
+
+                    b.Navigation("List");
+
+                    b.Navigation("Parent");
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.TaskRunEntity", b =>
+                {
+                    b.HasOne("ClaudeDo.Data.Models.TaskEntity", "Task")
+                        .WithMany("Runs")
+                        .HasForeignKey("TaskId")
+                        .OnDelete(DeleteBehavior.Cascade)
+                        .IsRequired();
+
+                    b.Navigation("Task");
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.WorktreeEntity", b =>
+                {
+                    b.HasOne("ClaudeDo.Data.Models.TaskEntity", "Task")
+                        .WithOne("Worktree")
+                        .HasForeignKey("ClaudeDo.Data.Models.WorktreeEntity", "TaskId")
+                        .OnDelete(DeleteBehavior.Cascade)
+                        .IsRequired();
+
+                    b.Navigation("Task");
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.ListEntity", b =>
+                {
+                    b.Navigation("Config");
+
+                    b.Navigation("Tasks");
+                });
+
+            modelBuilder.Entity("ClaudeDo.Data.Models.TaskEntity", b =>
+                {
+                    b.Navigation("Children");
+
+                    b.Navigation("Runs");
+
+                    b.Navigation("Subtasks");
+
+                    b.Navigation("Worktree");
+                });
+#pragma warning restore 612, 618
+        }
+    }
+}

src/ClaudeDo.Data/Migrations/20260609000000_UniqueListName.cs

@@ -0,0 +1,30 @@
+using Microsoft.EntityFrameworkCore.Migrations;
+
+#nullable disable
+
+namespace ClaudeDo.Data.Migrations
+{
+    /// <inheritdoc />
+    public partial class UniqueListName : Migration
+    {
+        /// <inheritdoc />
+        protected override void Up(MigrationBuilder migrationBuilder)
+        {
+            // Remove duplicate list rows that have no tasks — keep the oldest rowid.
+            // This handles the startup-race case where both App and Worker seeded
+            // the same default list names concurrently.
+            migrationBuilder.Sql("""
+                DELETE FROM lists
+                WHERE (SELECT COUNT(*) FROM tasks WHERE list_id = lists.id) = 0
+                  AND rowid NOT IN (
+                      SELECT MIN(l2.rowid) FROM lists l2 WHERE l2.name = lists.name
+                  )
+                """);
+        }
+
+        /// <inheritdoc />
+        protected override void Down(MigrationBuilder migrationBuilder)
+        {
+        }
+    }
+}