docs(open): §3 finalize findings — improvements-mislabel, child-badge live-refresh, chain not visualized

2026-07-24 09:10:44 +02:00
parent 07de897147
commit f0b0582517
1 changed files with 3 additions and 0 deletions
@@ -46,6 +46,9 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
 - **[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.
 - **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.
 ## Nachklapp Refactoring-/Bug-Runde (2026-06-09/10)