docs(fix-plan): record session progress (A/B done, C#9+#11, D#13+#14; C#10/#12 + group E deferred)

docs/fix-plan-2026-07-24.md

@@ -13,6 +13,32 @@ pfad-scoped stagen). Pro Fix ein Conventional Commit.
 
 ---
 
+## Bearbeitungsstand (Session 2026-07-24, nicht gepusht)
+
+**Erledigt & committed:**
+- Gruppe A #1–5 + beide Optional-Nits (Icon.Plus gefüllt, Gear-PathIcon, Skills-Empty-State,
+  „Subtasks"-Terminologie, Conflict-Continue-Hinweis, Rename-Darstellung, Turns/Tokens-Reload).
+- Gruppe B #7 (Resume-Fehler surfacen) + #8 (Attachment-Drop-Diagnose).
+- Gruppe C #9 (AskUser-Banner in Detail-Insel via geteiltem `TaskMonitorViewModel`),
+  #11 (OUTCOME zeigt `summary` statt rohem JSON: Worker-Unwrap + UI-Sicherheitsnetz).
+- Gruppe D #13 (Kind-Rows live-refresh bei Parent-Planning-Transitionen) + #14 (Idle-Chip auf
+  Planning-Parents ausgeblendet). *Visual-Verification für #13 (Finalize/Discard live) offen.*
+
+**#6** war im aktuellen Code bereits abgedeckt (Worker wirft `HubException` bei `blocked`
+→ UI-Dialog); zusätzlich als ClaudeDo-Task `f9809a93` erfasst. Nicht angefasst.
+
+**Offen:**
+- **#10 + #12** — bewusst gebündelt mit dem ConPTY-Planning-Task `5d627df8` (dort lässt sich
+  die Session-Id sauber greifen bzw. das MCP-Permission-Verhalten klären). Sofort-Schutz für
+  #10 (Resume ausgrauen wenn keine Id) wurde NICHT gebaut — bräuchte Worker-Plumbing, das der
+  ConPTY-Umbau ohnehin liefert; der #7-Fix verhindert bereits das stille Scheitern.
+- **Gruppe E** — nur noch design-/feature-behaftete Punkte. Der scheinbare Quick-Win
+  „Dequeue-X auf blockierten Kettengliedern" wurde bewusst NICHT umgesetzt: einzelnes Dequeue
+  eines Kettenglieds hinterlässt hängende Nachfolger (deren `BlockedByTaskId` zeigt weiter auf
+  das nun idle Glied) → braucht Chain-Repair-Design.
+
+---
+
 ## Gruppe A — Mechanisch, sofort fixbar (keine Entscheidung nötig)
 
 Ideale Kandidaten für den Start / parallele Subagents (disjunkte Dateien).