ClaudeDo/docs/open.md

ClaudeDo — Offene Punkte

Stand: 2026-06-09. Nur noch offene Punkte. Was erledigt ist, steht in den Commits und im Code — nicht hier.

---

Manuelle Verifikation (offen)

Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der Großteil der Pipeline ist laut User bereits in der Praxis getestet; hier das, was noch ein falsifizierbares Observable braucht.

• Worktree-Pipeline:
  • Worktree-Happy-Path → worktrees.state='active', head_commit gesetzt, diff_stat non-empty, Branch claudedo/<id> auf Disk.
  • No-Changes-Run → status='Done', head_commit IS NULL, diff_stat IS NULL.
  • Kein Git-Repo (working_dir=C:\Temp) → status='Failed', keine worktrees-Row, Git-Fehler im Log.
• Feature-Walkthroughs: Planning-Session-Flow (Draft→Finalize→Chain), Prime/Daily-Prep-Trigger, Weekly-Report-Generierung, Self-Update (Banner → Update → „up to date").
• UI-Sichtprüfung (neu, 2026-06-09): Diff-Viewer (Dateiliste, Added/Deleted/Renamed/Binary-Erkennung, Commit-Range-Diff nach Merge) und das „children need attention"-Band auf dem Session-Tab des Parents.
• Worker-Autostart am Gerät: Logoff/Logon-Autostart, Update-Pfad, Uninstall entfernt die Startup-.lnk.

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.

---

Bewusst verworfen (nicht erneut vorschlagen)

• CI-Build/Test-Pipeline — push-to-main + release-on-push deckt das ab; Tests laufen am Ende jeder Session.
• Real-claude-Smoke-Test als xUnit-Test — kein Claude in dotnet test; bleibt manueller Check (siehe oben). Tests nutzen FakeClaudeProcess.
• architecture.md / ADRs — die per-Projekt-CLAUDE.md-Dateien sind die lebende Doku; ADRs lohnen solo nicht.
• Task-Mailbox-Integration — geparkt; das generische mcp__mailbox__*-Plugin reicht (Begründung in mailbox-proposal.md).
• Tag-Negation, Tag-Multi-Select, Notes-lists.kind-Switch, Install-Service-Skript — durch die aktuelle Architektur überholt (Tag-System entfernt, Notes/Autostart anders gelöst).