docs(open): trim to actively-verified 2026-07-24 findings; drop stale manual-verif/historical blocks

docs/open.md

@@ -1,81 +1,44 @@
 # ClaudeDo — Offene Punkte
 
-Stand: 2026-06-10. **Nur noch offene Punkte.** Was erledigt ist, steht in den Commits und im Code — nicht hier.
+Stand: 2026-07-24. Diese Datei listet die **aktiv verifizierten Findings** aus der Verifikations-Session vom 2026-07-24. Die laufende Verifikations-Checkliste (Pass/Fail je Abschnitt, inkl. noch offener Abschnitte §7–§11 und Kanten) lebt in `docs/verification-handoff.md`. Erledigtes steht in den Commits/im Code, nicht hier.
 
 ---
 
-## Manuelle Verifikation (offen)
+## Bugs (verifiziert 2026-07-24)
 
-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.
+- **OUTCOME-Karte rendert rohes Structured-Output-JSON:** `TaskMonitorViewModel.ApplyOutcome` (ClaudeDo.Ui) setzt bei Tasks ohne Roadblock-Marker `SessionOutcome = result` wörtlich (Zeile ~261). Der Worker legt in `task.Result` das rohe `{"summary":…,"files_changed":[…]}` ab (die lesbare Fassung steht in `task_runs.resultMarkdown`), also zeigt die Detail-Insel OUTCOME als JSON-Blob statt als Text. Fix: (a) UI parst ein JSON-Result und zeigt `summary`, oder (b) Worker schreibt `summary`/`resultMarkdown` statt des JSON in `task.Result`. Verifiziert am Task `verif §1 diff matrix`. Deckt sich mit Memory `worker_testing_findings`.
+- **Approve & Merge schluckt einen „blocked"-Merge still:** `DetailsIslandViewModel.ApproveReviewAsync` reagiert nur auf `result.Status == "conflict"` (öffnet den Resolver); bei `"blocked"` (z.B. Ziel-Working-Tree hat uncommittete getrackte Änderungen) und anderen Nicht-`merged`/Nicht-`conflict`-Status passiert **nichts** — kein Footer-Fehler, kein Dialog (der `catch` greift nur bei Exceptions, „blocked" ist aber ein normaler Rückgabewert mit `ErrorMessage`). User sieht „Klick tut nichts". Doppelt verifiziert (Konflikt-Approve UND sauberer additiver Approve `verif §1b`, beide bei dirty `main`-Checkout still). Fix: bei `blocked`/unerwartetem Status `result.ErrorMessage` via `ShowErrorAsync`/`FlashFooterError` surfacen. Verstößt gegen `feedback_ui_error_surfacing`. (Der Konflikt-Resolver + 3-Pane-Editor funktionieren, sobald der Ziel-Tree sauber ist.)
+- **Planning-Session fragt nach Permission für das claudedo-MCP-Tool:** Obwohl `WindowsTerminalLauncher` `--allowedTools "mcp__claudedo__*,Read,Grep,Glob,WebFetch,WebSearch,Skill"` + `--permission-mode plan` setzt (Zeile 33/130), prompted die interaktive Planning-Session beim ersten `mcp__claudedo__create_child_task`-Aufruf. Verdacht: der `mcp__claudedo__*`-Glob matcht in CLI 2.1.207 nicht (Syntax evtl. `mcp__claudedo` für den ganzen Server), oder Plan-Mode gated MCP-Writes generell. User kann in der TUI approven, sollte aber nicht müssen. Verifiziert §3.
+- **„Waiting for Improvements" für Planning-Parents (Terminologie):** `taskStatus.waitingForChildren` = „Waiting for Improvements" (en.json:504), `agentStatus.children` dito (503), `childOutcomesLabel` = „IMPROVEMENTS" (191). Seit dem unified-parent-Modell gilt `WaitingForChildren` für Planning **und** Improvement-Parents — „Improvements" ist für einen Planning-Parent falsch. Auf neutrales „Waiting for Subtasks"/„Subtasks" umstellen (en **und** de — Localization.Tests-Parität). Verifiziert §3.
+- **Kind-Badges aktualisieren nach Parent-Finalize nicht live:** Nach „Finalize planning" bleiben die Kind-Rows auf „Draft" (`IsDraft`), obwohl der Parent `finalized` ist — sie müssten „Planned" (`IsPlanned`) zeigen. Erst ein Listenwechsel (Re-Fetch) korrigiert es. Die Kind-`TaskRowViewModel`s bekommen den geänderten `ParentFinalized` nicht über das Parent-`TaskUpdated`-Broadcast propagiert. Verifiziert §3.
+- **„New session"-Button (Mission Control) unsichtbar — Icon.Plus ist Strich-Only:** `Icon.Plus` = `M12 5v14M5 12h14` (IslandStyles.axaml:61) ist reine Linien-Geometrie ohne Fläche; im `<PathIcon>` (MissionControlView.axaml:38, füllt Geometrie) rendert sie **unsichtbar** → der Ad-hoc-„New session"-Button erscheint leer und ist nicht auffindbar (Feature + VM `OpenAdHocConPtySessionAsync` + Tests funktionieren, nur das Icon fehlt sichtbar). Fix: Icon.Plus als gefüllte Geometrie authoren ODER als gestricheltes `Path` rendern (Icon-Gotcha in CLAUDE.md). **Andere `Icon.Plus`-Verwendungen mitprüfen.** Verifiziert §5.
 
-- **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").
-- **UI-Sichtprüfung (neu, 2026-06-09):** Diff-Viewer (Dateiliste, Added/Deleted/Renamed/Binary-Erkennung, Commit-Range-Diff nach Merge) und das „children need attention"-Band auf dem Session-Tab des Parents.
-- **UI-Sichtprüfung (neu, 2026-06-10, nach Refactoring-Merges):** Detail-Insel komplett durchklicken (Output/Git/Session-Tabs, Merge-Sektion, Agent-Settings-Overrides, Prep-Panel) — `DetailsIslandViewModel` wurde in Sektions-VMs aufgeteilt, Bindings angepasst. Außerdem: DiffModal-Fehler-State „Diff nicht mehr verfügbar" (Commit-Range ohne aufgezeichnete Commits) und der In-App-Konflikt-Resolver (Hub-Methoden umbenannt).
-- **UI-Sichtprüfung (neu, 2026-06-19, Rider-Style 3-Pane Merge-Editor):** Echten Konflikt auslösen (Single-Task-Approve mit Konflikt **und** Planning-Unit-Merge) und prüfen: drei Panes (Ours read-only | Result editierbar | Theirs read-only), Konfliktblöcke rot / aufgelöst grün in allen Panes, Inline-Accept `›`/`‹` in den Zwischen-Guttern landen die jeweilige Seite im Result, nur Konfliktregionen im Result editierbar (Stable read-only), synchrones vertikales Scrollen, File-Switcher bei mehreren Dateien, `M conflicts · K resolved`-Readout, Continue erst bei allen Konflikten gelöst, Binär-Guard. **Bekannte Kanten:** (1) Konflikt mit leerer Ours-Seite → Result-Region ist null-lang (Gutter via 1-Zeichen-Probe positioniert, Accept funktioniert; nur Hand-Tippen in die leere Region ist fummelig). (2) Gutter-Y nutzt `TranslatePoint` vom Result-`TextView` — bei sehr hohen Fenstern / großen Scrollständen die Ausrichtung gegenprüfen. (3) Blöcke richten sich nur über Stable-Text aus; nach einem Konflikt mit unterschiedlicher Zeilenzahl je Seite driften nachfolgende Blöcke vertikal (aligned/virtual-space Scroll ist bewusst zurückgestellt).
-- **Worker-Autostart am Gerät:** Logoff/Logon-Autostart, Update-Pfad, Uninstall entfernt die Startup-`.lnk`.
-- **In-App Interactive Sessions (2026-06-26, REMOVED 2026-07-23):** der In-App-Streaming-Chat (`StreamingClaudeSession`, Composer/Queue auf `TaskMonitorViewModel`/`SessionTerminalView`) wurde komplett entfernt und durch die **embedded ConPTY**-Sessions ersetzt (echte `claude`-TUI im UI-Prozess, siehe `docs/superpowers/specs/2026-07-23-conpty-interactive-sessions-design.md`). Kein offener Punkt mehr — nur zur Historie.
-- **Embedded ConPTY Sessions (neu, 2026-07-23):** Command Center hostet echte `claude`-TUI-Kacheln (`Iciclecreek.Avalonia.Terminal` 2.0.3 via `TerminalControl.LaunchProcess()`). Rendering/Input/Tempo vom User verifiziert. **Noch durchzuspielen:**
-  - Task-basiert (Kontextmenü „Open ConPTY session"): frischer Task → Worktree wird on-demand angelegt, `claude` startet mit Task-Prompt (Title+Description als positionaler Prompt) — **verifizieren, dass `claude "<prompt>"` interaktiv wirklich SENDET**, nicht nur vorbefüllt.
-  - Ad-hoc („New session"-Button → Ordnerwahl): freie Session im gewählten Verzeichnis.
-  - Grid↔Tabs-Toggle, Close killt Session + entfernt Kachel, mehrere Sessions parallel, Pane-Resize reflowt.
-  - Resume einer interaktiven Session: nur via claude-eigenes `claude --continue`/`--resume` im Worktree-Dir (ClaudeDo speichert die Session-Id NICHT — ConPTY ist opak).
-  - **Zurückgestellt:** Avalonia-12.1-Upgrade (braucht .NET-9-SDK-Floor wg. Roslyn-4.14-XAML-Generator; CI-Risiko) — bleibt auf 12.0.x.
-- **Pick up in terminal (neu, 2026-07-01):** neue Aktion, die die Claude-Session einer Task per `claude --resume <id>` in einem **echten** `wt`-Terminal fortsetzt (echte TUI: Permission-Prompts/Fragen inklusive) — bewusst NICHT der In-App-Streaming-Chat. Real-CLI-Smoke (kein Claude in Tests):
-  - Kontextmenü einer Task in **WaitingForReview** oder **Failed** → „Pick up in terminal" sowie der Terminal-Button (Icon `ArrowOut`) im Detail-Header sind sichtbar; bei anderen Status (Idle/Running/Queued/Done) NICHT.
-  - Klick → neues Windows-Terminal im Worktree-Verzeichnis der Task, Claude nimmt die letzte Session mit erhaltenem Kontext wieder auf.
-  - Fehlerfälle surfacen sauber (Footer-Strip aus der Task-Insel bzw. Fehler-Dialog im Detail): laufende/gequeuete Task (verboten), keine persistierte Session-Id, kein aktiver Worktree.
-  - **Gating-Kante:** parked-Idle (reject-park) hat oft noch Session+Worktree, wird aber bewusst NICHT angezeigt (Idle nicht von fresh-Idle unterscheidbar). Falls das nervt → `CanPickUpInTerminal` erweitern.
-- **Session Skills (neu, 2026-07-03):** per-Ebene (global/list/task, additiv-union) Skills für headless Task-Agenten; Registry klont+pinnt ein GitHub-Repo, Worker seedet aktivierte Skills in `<cwd>/.claude/skills/` vor jedem Run (worktree-`info/exclude`, damit `git add -A` sie nicht committet). Discovery-Mechanismus ist bereits verifiziert (headless `claude -p` lädt cwd-Skills). Spec: `docs/superpowers/specs/2026-07-03-session-skills-design.md`. Offen (kein Code, nur Durchspielen):
-  - **E2E-Smoke (echter Worker, kein Claude in Tests):** In Settings → Skills `https://github.com/DietrichGebert/ponytail` installieren → 6 Skills erscheinen (ponytail, -help, -review, -audit, -debt, -gain), gepinnt auf einen Commit, Dateien unter `~/.todo-app/session-skills/<name>/`. Skill per-Task (Agent-Settings-Flyout) und/oder global aktivieren → eine Task laufen lassen → im Worktree liegt `.claude/skills/<name>/`, der Skill ist dem Agenten verfügbar, und er wird **nicht** mitcommittet (`git status` im Worktree sauber). Gegenprobe: eine **nicht** aktivierte/andere interaktive Session sieht den Skill nicht (kein global-Leak in `~/.claude`).
-  - **UI-Sichtprüfung:** neuer Skills-Tab (Install-Zeile, installierte-Skill-Karten mit Update/Remove), Session-Skills-Checkbox-Liste im General-Tab und im `AgentConfigEditor` (List-Settings-Modal + per-Task-Flyout — Flyout-Höhe prüfen). Leerer Zustand (0 installierte Skills) rendert eine leere Liste ohne Platzhaltertext — ok oder Empty-State ergänzen. Lange Namen/URLs (Trimming).
-- **Drag-and-drop file attachments on the detail pane:** verify the "Drop to attach" hover overlay, drop round-trip (file appears in the list), "Add file…" picker, remove button, and that files land under `~/.todo-app/attachments/<taskId>/`. Also verify the MCP `AddTaskAttachment`/`ListTaskAttachments`/`RemoveTaskAttachment` tools and that a Running task refuses add/remove. (Manual; can't be unit-tested.)
+## UX / Nits (verifiziert 2026-07-24)
 
-## Offene Code-Punkte
+- **Diff-Viewer: reiner Rename schwach dargestellt:** Rename korrekt erkannt (`UnifiedDiffParser` → `DiffFileStatus.Renamed`, Badge `StatusCode="R"`), aber der File-Tree zeigt nur den neuen Namen + „+0 −0" ohne „alt → neu"-Pfad; liest sich wie „keine Änderung". Optional: alten Pfad + „renamed"-Label anzeigen. §1.
+- **Header-TurnsText zeigt `0/max` für abgeschlossene Runs:** `TurnsText => {Turns}/{EffectiveMaxTurns}` — `Turns` wird beim Laden eines terminalen Tasks nicht aus `task_runs.turnCount` restauriert (nur live gefüllt). Kosmetisch. §1.
+- **Conflict-Resolver: Continue/Merge-Button klickbar trotz offener Konflikte:** Gate greift funktional (merged erst wenn alle Konflikte in allen Dateien gelöst), aber der Button ist nicht disabled/gegraut → früher Klick ist ein stummer No-op. Besser: disabled bis `AllResolved`, oder Hinweis „N Konflikte in M Dateien offen". §4.
+- **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". §4.
+- **Planning-aktiver Parent zeigt weiter „Idle":** Parent in `planning_phase=active` hat `Status=Idle` (korrekt im Modell), aber der Row-Status-Chip zeigt „Idle"; der `PlanningBadge` ersetzt das nicht sichtbar → liest sich wie ein normaler Idle-Task. Wunsch: klarer „Planning/Draft aktiv"-Zustand, der Idle überschreibt. (Kinder zeigen korrekt „Draft".) §3.
+- **Blocked-by-Kette nicht sichtbar:** Nach Finalize ist die sequentielle Kette korrekt gesetzt (child[i] blocked-by child[i-1]), aber die UI stellt die Reihenfolge/Abhängigkeit nicht dar. Wunsch: Kette visualisieren (z.B. „wartet auf <Vorgänger>"), nicht nur der „waiting"-Chip nach dem Queueen. §3.
+- **Dequeue-„X" fehlt auf wartenden (blockierten) Kettengliedern:** `CanRemoveFromQueue = IsQueued || HasQueuedSubtasks`, `IsQueued` verlangt leeres `blocked_by`. Ein gequeuetes, aber blockiertes Kind (`IsWaiting`) bekommt daher kein Remove-from-queue-X — nur Parent + erstes (entsperrtes) Kind. §3.
+- **„Open ConPTY session" erneut = Prompt wird neu gesendet, kein Resume:** Da die ConPTY-Session-Id bewusst nicht persistiert wird, startet ein erneutes „Open ConPTY session" auf demselben Task eine frische Session und sendet den Task-Prompt erneut (re-runt die Arbeit im selben Worktree) statt zu resumen. So designt, aber UX-Falle — evtl. „Resume"-Affordance oder Re-Open-Warnung. §5.
 
-- **[OFFEN, 2026-07-24] `--permission-mode auto` + Modell `haiku` → Writes werden denied (haiku-Footgun, KEINE CLI-Regression):** Kontrolliert verifiziert (CLI 2.1.207, gleicher Worker/Tag): unter dem Default-Mode `auto` bekommt **sonnet** Writes auto-approved (`permission_denials:[]`, Datei entsteht), **haiku** wird `denied` (`permission_denials:[Write]`, keine Datei) — haiku steigt beim auto-Permission-Flow aus, statt zu schreiben. Folge: eine Task, die (per MCP `model:"haiku"` oder Task-Override) auf haiku läuft, macht unter `auto` **still nichts** und landet ohne Änderung in `WaitingForReview`. Normalbetrieb (Default = sonnet) ist nicht betroffen; die Gap-Tasks 2026-07-23 liefen sonnet und haben geschrieben+committet. Ursprünglich fälschlich als CLI-`auto`-Regression gemeldet — das war ein Testartefakt (haiku-Tasks zum „Sparen"). Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf `acceptEdits`/`bypassPermissions` (modell-unabhängig) statt `auto`.
-- **[BUG, 2026-07-24] OUTCOME-Karte rendert rohes Structured-Output-JSON:** `TaskMonitorViewModel.ApplyOutcome` (ClaudeDo.Ui) setzt bei Tasks ohne Roadblock-Marker `SessionOutcome = result` wörtlich (Zeile ~261). Der Worker legt in `task.Result` das rohe `{"summary":…,"files_changed":[…]}` ab (die lesbare Fassung steht in `task_runs.resultMarkdown`), also zeigt die Detail-Insel OUTCOME als JSON-Blob statt als Text. Fix-Optionen: (a) UI parst ein JSON-Result und zeigt `summary`, oder (b) der Worker schreibt `summary`/`resultMarkdown` statt des JSON in `task.Result`. Verifiziert am Task `verif §1 diff matrix` (2026-07-24). Deckt sich mit Memory `worker_testing_findings`.
-- **[NIT, 2026-07-24] Diff-Viewer: reiner Rename wird schwach dargestellt:** Rename wird korrekt erkannt (`UnifiedDiffParser` → `DiffFileStatus.Renamed`, Badge `StatusCode="R"`), aber der File-Tree zeigt nur den neuen Namen + „+0 −0" ohne „alt → neu"-Pfad; ein reiner Rename liest sich dadurch wie „keine Änderung". Kein Korrektheitsfehler, nur UX. Optional: alten Pfad + „renamed"-Label anzeigen.
-- **[MINOR, 2026-07-24] Header-TurnsText zeigt `0/max` für abgeschlossene Runs:** `TurnsText => {Turns}/{EffectiveMaxTurns}` — `Turns` wird beim Laden eines terminalen Tasks nicht aus `task_runs.turnCount` restauriert (nur live gefüllt), also erscheint `0/<max>`. Kosmetisch.
-- **[BUG, 2026-07-24] Approve & Merge schluckt einen „blocked"-Merge still:** `DetailsIslandViewModel.ApproveReviewAsync` reagiert nur auf `result.Status == "conflict"` (öffnet den Resolver); bei `"blocked"` (z.B. Ziel-Working-Tree hat uncommittete getrackte Änderungen) und anderen Nicht-`merged`/Nicht-`conflict`-Status passiert **nichts** — kein Footer-Fehler, kein Dialog (der `catch` greift nur bei Exceptions, „blocked" ist aber ein normaler Rückgabewert mit `ErrorMessage`). User sieht „Klick tut nichts". Verifiziert 2026-07-24 **doppelt**: sowohl der Konflikt-Approve als auch ein sauberer additiver Approve (`verif §1b`) taten bei dirty `main`-Checkout still nichts (kein Footer). Fix: bei `blocked`/unerwartetem Status `result.ErrorMessage` via `ShowErrorAsync`/`FlashFooterError` surfacen. Verstößt gegen `feedback_ui_error_surfacing`. (Der eigentliche Konflikt-Resolver + 3-Pane-Editor funktionieren, sobald der Ziel-Tree sauber ist.)
-- **[UX, 2026-07-24] Conflict-Resolver: Continue/Merge-Button ist klickbar, obwohl noch nicht alle Konflikte gelöst — Klick tut dann nichts:** Das Continue-Gate greift funktional (merged erst wenn alle Konflikte in allen Dateien gelöst), aber der Button ist optisch nicht disabled/gegraut, solange offene Konflikte bestehen; ein früher Klick ist ein stummer No-op. Besser: Button disabled bis `AllResolved`, oder Hinweis „N Konflikte in M Dateien offen". Verifiziert 2026-07-24 (§4-Walkthrough).
-- **[UX, 2026-07-24] Conflict-Resolver: Mehrere Konfliktdateien schlecht erkennbar:** Beim 2-Datei-Konflikt war schwer zu sehen, dass **zwei** Dateien betroffen sind (File-Switcher/Anzahl zu unauffällig). Prominentere Datei-Liste / „x von y Dateien" wäre besser. (§4-Walkthrough 2026-07-24.)
-- **[FEATURE-WUNSCH, 2026-07-24] Conflict-Resolver: farbliches Hervorheben eingefügter Zeilen im Result-Pane** (grüner „flow" der übernommenen Zeilen) fehlt — kein Bug, UI-Verbesserung (User-Wunsch).
-- **[BUG, 2026-07-24] Planning-Session fragt nach Permission für das claudedo-MCP-Tool:** Obwohl `WindowsTerminalLauncher` `--allowedTools "mcp__claudedo__*,Read,Grep,Glob,WebFetch,WebSearch,Skill"` + `--permission-mode plan` setzt (Zeile 33/130), prompted die interaktive Planning-Session beim ersten `mcp__claudedo__create_child_task`-Aufruf. Verdacht: der `mcp__claudedo__*`-Glob matcht in CLI 2.1.207 nicht (Syntax evtl. `mcp__claudedo` für den ganzen Server), oder Plan-Mode gated MCP-Writes generell (evtl. dieselbe Permission-Verhaltensänderung wie bei `--permission-mode auto`, s.o.). User kann in der TUI approven, sollte aber nicht müssen. Verifiziert 2026-07-24 (§3-Walkthrough).
-- **[UX, 2026-07-24] Planning-aktiver Parent zeigt weiter „Idle":** Ein Parent in `planning_phase=active` hat `Status=Idle` (korrekt im Modell), aber der Row-Status-Chip zeigt „Idle" (`StatusLabel`/`StatusChipClass`), der `PlanningBadge` ersetzt das nicht sichtbar → liest sich wie ein normaler Idle-Task. User erwartet einen klaren „Planning/Draft aktiv"-Zustand, der Idle überschreibt. (Kinder zeigen korrekt „Draft".) §3-Walkthrough 2026-07-24.
-- **[BUG/Terminologie, 2026-07-24] „Waiting for Improvements" für Planning-Parents:** `taskStatus.waitingForChildren` = „Waiting for Improvements" (en.json:504), `agentStatus.children` dito (503), `childOutcomesLabel` = „IMPROVEMENTS" (191). Seit dem unified-parent-Modell gilt `WaitingForChildren` für Planning **und** Improvement-Parents — „Improvements" ist für einen Planning-Parent falsch. Auf neutrales „Waiting for Subtasks"/„Subtasks" umstellen (en **und** de — Localization.Tests-Parität beachten). Verifiziert §3 2026-07-24.
-- **[BUG/UI-Refresh, 2026-07-24] Kind-Badges aktualisieren nach Parent-Finalize nicht live:** Nach „Finalize planning" bleiben die Kind-Rows auf „Draft" (`IsDraft`), obwohl der Parent `finalized` ist — sie müssten „Planned" (`IsPlanned`) zeigen. Erst ein Listenwechsel (Re-Fetch) korrigiert es. Die Kind-`TaskRowViewModel`s bekommen den geänderten `ParentFinalized` nicht über das Parent-`TaskUpdated`-Broadcast propagiert. Verifiziert §3 2026-07-24.
-- **[UX, 2026-07-24] Blocked-by-Kette nicht sichtbar:** Nach Finalize ist die sequentielle Kette korrekt gesetzt (child[i] blocked-by child[i-1]), aber die UI stellt die Reihenfolge/Abhängigkeit **nicht** dar — der User sieht nicht, dass/wie die Kinder verkettet sind. Wunsch: Kette visualisieren (z.B. „wartet auf <Vorgänger>" bzw. Reihenfolge-Indikator), nicht nur der „waiting"-Chip nach dem Queueen. §3 2026-07-24.
-- **[UX, 2026-07-24] Dequeue-„X" fehlt auf wartenden (blockierten) Kettengliedern:** `CanRemoveFromQueue = IsQueued || HasQueuedSubtasks`, und `IsQueued` verlangt leeres `blocked_by`. Ein gequeuetes, aber blockiertes Kind (`IsWaiting`) bekommt daher kein Remove-from-queue-X — nur der Parent und das erste (entsperrte) Kind. Einzelnes Herausnehmen eines wartenden Kettenglieds aus dem Plan-Queue ist so nicht möglich. Klein. §3 2026-07-24.
-- **[BUG, 2026-07-24] „New session"-Button (Mission Control) unsichtbar — Icon.Plus ist Strich-Only:** `Icon.Plus` = `M12 5v14M5 12h14` (IslandStyles.axaml:61) ist eine reine Linien-Geometrie ohne Fläche; im `<PathIcon>` (MissionControlView.axaml:38, füllt Geometrie) rendert sie **unsichtbar** → der Ad-hoc-„New session"-Button erscheint leer und ist nicht auffindbar (Feature + VM `OpenAdHocConPtySessionAsync` + Tests existieren und funktionieren, nur das Icon fehlt sichtbar). Fix: Icon.Plus als gefüllte Geometrie authoren ODER als gestricheltes `Path` rendern (vgl. Icon-Gotcha in CLAUDE.md). **Andere `Icon.Plus`-Verwendungen mit prüfen.** Verifiziert §5 2026-07-24.
-- **[UX, 2026-07-24] „Open ConPTY session" erneut = Prompt wird neu gesendet, kein Resume:** Da die ConPTY-Session-Id bewusst nicht persistiert wird, startet ein erneutes „Open ConPTY session" auf demselben Task eine **frische** Session und **sendet den Task-Prompt erneut** (re-runt die Arbeit im selben Worktree) statt zu resumen. So designt (Resume nur via claude-eigenes `--continue`/`--resume` im Worktree-Dir), aber UX-Falle — evtl. „Resume"-Affordance anbieten oder beim Re-Open warnen. §5 2026-07-24.
-- **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 (aus der Session)
 
-## Nachklapp Refactoring-/Bug-Runde (2026-06-09/10)
+- **Conflict-Resolver: farbliches Hervorheben eingefügter Zeilen im Result-Pane** (grüner „flow" der übernommenen Zeilen). §4.
+- Als ClaudeDo-Tasks in Liste „Claude do" erfasst: **Approve erzwingt Diff/Review vor Merge** (koppelt den blocked-Merge-Silent-Fail-Fix) und **interaktive Planning-Session über embedded ConPTY statt externem wt-Fenster** (koppelt den Planning-Permission-Prompt).
 
-Alle 9 Review-Tasks (5 Refactorings, 4 Bugfixes) sind umgesetzt und gemerged; Details in den Commits. Offen geblieben:
+## Beobachtung (offen — Entscheidung Mika)
 
-- **`DetailsIslandViewModel` ist nach dem Split noch 1258 Zeilen** (Ziel war ~800) — die drei Sektions-VMs (AgentSettings, Merge, Prep) sind extrahiert, weitere Extraktion (z.B. ChildOutcomes/Subtasks-Sektion) lohnt erst, wenn die Datei wieder wächst.
-- **Bewusst zurückgestellt:** WorkerHub-Split nach Concern (~60 Methoden in einer Hub-Klasse). Die Interface-Parität löst das akute Testbarkeits-Problem; ein Hub-Split ist eine größere Architekturentscheidung → erst besprechen.
-- **Lessons learned:** Der `StartRunningAsync`-Guard-Task hat isoliert grün getestet, aber den Queue-Pfad gebrochen (Picker claimt vor dem Dispatch) — Integrationsfix `74ca2e0`. Bei parallelen Tasks, die denselben Pfad berühren, nach JEDEM Merge-Schwung die volle Suite auf main fahren.
-
-## Bug-Befunde (Korrektheits-Review 2026-06-09)
-
-**Plausibel, noch nicht einzeln verifiziert (bei Gelegenheit prüfen):**
-
-- Kleinkram: MergePreview-Race bei schnellem Target-Wechsel, CTS-Dispose-Leak in Debounce-Saves, `Environment.CurrentDirectory`-Fallback im Konflikt-Dialog, Doppel-Continue-Fenster im Orchestrator.
-
-**Geprüft und verworfen (keine Bugs):** ReviewFeedback-„Endlosschleife" (Fallback existiert), Cross-Thread-Crashes im DetailsIslandViewModel (Dispatcher-Marshalling im WorkerClient), Chain-Wedge nach Child-Delete (FK `ON DELETE SET NULL`), `\ No newline`-Parsing.
+- **`--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`.
 
 ---
 
 ## 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.