docs(verification): §7 AskUser PASS (happy-path + backend timeout); finding — banner only in Mission Control, absent in detail island

docs/open.md

@@ -11,6 +11,7 @@ Stand: 2026-07-24. Diese Datei listet die **aktiv verifizierten Findings** aus d
 - **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.
+- **AskUser-Frage erscheint NUR in Mission Control, nicht in der Task-Detail-Insel:** Der `ask_user`-Banner (Frage + Antwort-Eingabe) lebt ausschließlich in `MonitorPaneView` (Mission Control). Die Detail-Insel (`DetailsIslandView`) streamt zwar den Live-Log eines laufenden Tasks, zeigt aber **kein** Frage-Banner — ein Nutzer, der nur die Detailansicht offen hat, sieht nicht, dass der Run auf eine Antwort wartet, und läuft nach 3 min in den Timeout-Fallback. Verifiziert §7 (User schaute Detailansicht, Frage war unsichtbar; erst in Mission Control sichtbar). Fix: Frage-Banner + Inline-Antwort auch in der Detail-Insel für den gebundenen laufenden Task surfacen (VM-Zustand liegt bereits in `TaskMonitorViewModel`, müsste für die Detail-Insel repliziert/geteilt werden). §7.
 - **„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.
 
 ## UX / Nits (verifiziert 2026-07-24)

docs/verification-handoff.md

@@ -80,9 +80,11 @@ Konflikt provozieren: gleiche Datei auf main ändern, während der Task-Branch s
 
 ## 7. AskUser (Frage aus laufendem Task)
 
-- [ ] Task, dessen Prompt eine Rückfrage erzwingt → Frage erscheint im Task-Monitor (Mission Control), Prozess wartet.
+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.
-- [ ] Antwort inline absenden → Run läuft mit der Antwort weiter.
+
-- [ ] Timeout-/Cleanup-Verhalten der PendingQuestionRegistry (Frage unbeantwortet lassen): Task schlägt kontrolliert fehl, UI räumt die Frage auf (MCP_TOOL_TIMEOUT-Gotcha).
+- [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.
+- [~] Timeout-/Cleanup-Verhalten der PendingQuestionRegistry (Frage unbeantwortet lassen): Task schlägt kontrolliert fehl, UI räumt die Frage auf (MCP_TOOL_TIMEOUT-Gotcha). — **Backend PASS (2026-07-24, `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-Klausel (räumt die MC-Kachel den Banner nach Timeout sichtbar auf?) noch nicht visuell verifiziert** — braucht einen Lauf mit offener/subscribter MC-Kachel bis zum Timeout.
 
 ## 8. Session Skills (E2E + UI)