diff --git a/docs/open.md b/docs/open.md
index 84641e2..9981820 100644
--- a/docs/open.md
+++ b/docs/open.md
@@ -19,6 +19,19 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
 ## Offene Code-Punkte
 
 - **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.
+- **`AgentMcpTools` liegt in `LifecycleMcpTools.cs`** — beim Suchen irreführend; in eigene Datei verschieben. Ein-Minuten-Fix, lohnt keinen Agent-Lauf — beim nächsten Worker-Touch mitnehmen.
+
+## Refactoring-Backlog (Review 2026-06-09, als ClaudeDo-Tasks in „Claude do" angelegt)
+
+Befunde aus dem Code-Review nach dem Doku-Audit. Alle fünf sind als fertig formulierte Tasks (Idle) in der Liste „Claude do" angelegt; **1→2→3 müssen sequenziell laufen** (gleiche Dateien: `IWorkerClient`, Fakes), 4 und 5 sind unabhängig.
+
+1. **IWorkerClient-Parität:** 15 Methoden, 2 Events und `LastApproveTarget` existieren nur auf der konkreten `WorkerClient`-Klasse; 7 Klassen hängen deshalb an der konkreten Klasse und sind nicht fake-bar.
+2. **Merge-API-Naming:** `ContinueMerge`/`AbortMerge` (Konflikt-Resolver) vs. `ContinuePlanningMerge`/`AbortPlanningMerge` (Unit-Merge) → Hub/Client-Ebene umbenennen in `ContinueConflictMerge`/`AbortConflictMerge`. `TaskMergeService` NICHT anfassen (wird auch vom `PlanningMergeOrchestrator` genutzt).
+3. **`DetailsIslandViewModel` (1431 Zeilen) aufteilen:** drei Sektions-VMs extrahieren (AgentSettings, Merge, Prep); visuelle Verifikation danach offen.
+4. **Test-Hygiene:** `FakeClaudeProcess` doppelt definiert, Hub-Fakes verstreut statt in `Infrastructure/`, `SeedListWithAgentTag(Async)` heißt noch nach dem entfernten Tag-System.
+5. **`FailAsync`-Guard:** erlaubt `Queued→Failed`, hat aber nur einen Caller (TaskRunner-Fehlerpfad eines laufenden Tasks) — erst beweisen, ob erreichbar, dann Guard einschränken oder Race dokumentieren.
+
+**Bewusst zurückgestellt:** WorkerHub-Split nach Concern (~60 Methoden in einer Hub-Klasse). Die Interface-Parität (Punkt 1) löst das akute Testbarkeits-Problem; ein Hub-Split ist eine größere Architekturentscheidung → erst besprechen.
 
 ---