docs(open): §5 findings — invisible New-session icon (Icon.Plus stroke-only), re-open re-sends prompt

This commit is contained in:
mika kuns
2026-07-24 09:24:15 +02:00
parent 4394623bb0
commit 1b80bb0a2d
+2
View File
@@ -50,6 +50,8 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
- **[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. - **[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] 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. - **[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. - **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) ## Nachklapp Refactoring-/Bug-Runde (2026-06-09/10)