docs(verification): §3 PASS end-to-end (+§1 children-band, +§4 planning-conflict); dequeue-X UX nit
This commit is contained in:
@@ -49,6 +49,7 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
|
||||
- **[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.
|
||||
- **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)
|
||||
|
||||
Reference in New Issue
Block a user