releases/ClaudeDo
2
0
Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases 24 Wiki Activity
Files
07de89714780afbdbb223edd4cc3c20a6d6bf252
ClaudeDo/docs/open.md
T

15 KiB
Raw Blame History

ClaudeDo — Offene Punkte

Stand: 2026-06-10. 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.
  • UI-Sichtprüfung (neu, 2026-06-10, nach Refactoring-Merges): Detail-Insel komplett durchklicken (Output/Git/Session-Tabs, Merge-Sektion, Agent-Settings-Overrides, Prep-Panel) — DetailsIslandViewModel wurde in Sektions-VMs aufgeteilt, Bindings angepasst. Außerdem: DiffModal-Fehler-State „Diff nicht mehr verfügbar" (Commit-Range ohne aufgezeichnete Commits) und der In-App-Konflikt-Resolver (Hub-Methoden umbenannt).
  • UI-Sichtprüfung (neu, 2026-06-19, Rider-Style 3-Pane Merge-Editor): Echten Konflikt auslösen (Single-Task-Approve mit Konflikt und Planning-Unit-Merge) und prüfen: drei Panes (Ours read-only | Result editierbar | Theirs read-only), Konfliktblöcke rot / aufgelöst grün in allen Panes, Inline-Accept ›/‹ in den Zwischen-Guttern landen die jeweilige Seite im Result, nur Konfliktregionen im Result editierbar (Stable read-only), synchrones vertikales Scrollen, File-Switcher bei mehreren Dateien, M conflicts · K resolved-Readout, Continue erst bei allen Konflikten gelöst, Binär-Guard. Bekannte Kanten: (1) Konflikt mit leerer Ours-Seite → Result-Region ist null-lang (Gutter via 1-Zeichen-Probe positioniert, Accept funktioniert; nur Hand-Tippen in die leere Region ist fummelig). (2) Gutter-Y nutzt TranslatePoint vom Result-TextView — bei sehr hohen Fenstern / großen Scrollständen die Ausrichtung gegenprüfen. (3) Blöcke richten sich nur über Stable-Text aus; nach einem Konflikt mit unterschiedlicher Zeilenzahl je Seite driften nachfolgende Blöcke vertikal (aligned/virtual-space Scroll ist bewusst zurückgestellt).
  • Worker-Autostart am Gerät: Logoff/Logon-Autostart, Update-Pfad, Uninstall entfernt die Startup-.lnk.
  • In-App Interactive Sessions (2026-06-26, REMOVED 2026-07-23): der In-App-Streaming-Chat (StreamingClaudeSession, Composer/Queue auf TaskMonitorViewModel/SessionTerminalView) wurde komplett entfernt und durch die embedded ConPTY-Sessions ersetzt (echte claude-TUI im UI-Prozess, siehe docs/superpowers/specs/2026-07-23-conpty-interactive-sessions-design.md). Kein offener Punkt mehr — nur zur Historie.
  • Embedded ConPTY Sessions (neu, 2026-07-23): Command Center hostet echte claude-TUI-Kacheln (Iciclecreek.Avalonia.Terminal 2.0.3 via TerminalControl.LaunchProcess()). Rendering/Input/Tempo vom User verifiziert. Noch durchzuspielen:
    • Task-basiert (Kontextmenü „Open ConPTY session"): frischer Task → Worktree wird on-demand angelegt, claude startet mit Task-Prompt (Title+Description als positionaler Prompt) — verifizieren, dass claude "<prompt>" interaktiv wirklich SENDET, nicht nur vorbefüllt.
    • Ad-hoc („New session"-Button → Ordnerwahl): freie Session im gewählten Verzeichnis.
    • Grid↔Tabs-Toggle, Close killt Session + entfernt Kachel, mehrere Sessions parallel, Pane-Resize reflowt.
    • Resume einer interaktiven Session: nur via claude-eigenes claude --continue/--resume im Worktree-Dir (ClaudeDo speichert die Session-Id NICHT — ConPTY ist opak).
    • Zurückgestellt: Avalonia-12.1-Upgrade (braucht .NET-9-SDK-Floor wg. Roslyn-4.14-XAML-Generator; CI-Risiko) — bleibt auf 12.0.x.
  • Pick up in terminal (neu, 2026-07-01): neue Aktion, die die Claude-Session einer Task per claude --resume <id> in einem echten wt-Terminal fortsetzt (echte TUI: Permission-Prompts/Fragen inklusive) — bewusst NICHT der In-App-Streaming-Chat. Real-CLI-Smoke (kein Claude in Tests):
    • Kontextmenü einer Task in WaitingForReview oder Failed → „Pick up in terminal" sowie der Terminal-Button (Icon ArrowOut) im Detail-Header sind sichtbar; bei anderen Status (Idle/Running/Queued/Done) NICHT.
    • Klick → neues Windows-Terminal im Worktree-Verzeichnis der Task, Claude nimmt die letzte Session mit erhaltenem Kontext wieder auf.
    • Fehlerfälle surfacen sauber (Footer-Strip aus der Task-Insel bzw. Fehler-Dialog im Detail): laufende/gequeuete Task (verboten), keine persistierte Session-Id, kein aktiver Worktree.
    • Gating-Kante: parked-Idle (reject-park) hat oft noch Session+Worktree, wird aber bewusst NICHT angezeigt (Idle nicht von fresh-Idle unterscheidbar). Falls das nervt → CanPickUpInTerminal erweitern.
  • Session Skills (neu, 2026-07-03): per-Ebene (global/list/task, additiv-union) Skills für headless Task-Agenten; Registry klont+pinnt ein GitHub-Repo, Worker seedet aktivierte Skills in <cwd>/.claude/skills/ vor jedem Run (worktree-info/exclude, damit git add -A sie nicht committet). Discovery-Mechanismus ist bereits verifiziert (headless claude -p lädt cwd-Skills). Spec: docs/superpowers/specs/2026-07-03-session-skills-design.md. Offen (kein Code, nur Durchspielen):
    • E2E-Smoke (echter Worker, kein Claude in Tests): In Settings → Skills https://github.com/DietrichGebert/ponytail installieren → 6 Skills erscheinen (ponytail, -help, -review, -audit, -debt, -gain), gepinnt auf einen Commit, Dateien unter ~/.todo-app/session-skills/<name>/. Skill per-Task (Agent-Settings-Flyout) und/oder global aktivieren → eine Task laufen lassen → im Worktree liegt .claude/skills/<name>/, der Skill ist dem Agenten verfügbar, und er wird nicht mitcommittet (git status im Worktree sauber). Gegenprobe: eine nicht aktivierte/andere interaktive Session sieht den Skill nicht (kein global-Leak in ~/.claude).
    • UI-Sichtprüfung: neuer Skills-Tab (Install-Zeile, installierte-Skill-Karten mit Update/Remove), Session-Skills-Checkbox-Liste im General-Tab und im AgentConfigEditor (List-Settings-Modal + per-Task-Flyout — Flyout-Höhe prüfen). Leerer Zustand (0 installierte Skills) rendert eine leere Liste ohne Platzhaltertext — ok oder Empty-State ergänzen. Lange Namen/URLs (Trimming).
  • Drag-and-drop file attachments on the detail pane: verify the "Drop to attach" hover overlay, drop round-trip (file appears in the list), "Add file…" picker, remove button, and that files land under ~/.todo-app/attachments/<taskId>/. Also verify the MCP AddTaskAttachment/ListTaskAttachments/RemoveTaskAttachment tools and that a Running task refuses add/remove. (Manual; can't be unit-tested.)

Offene Code-Punkte

  • [OFFEN, 2026-07-24] --permission-mode auto + Modell haiku → Writes werden denied (haiku-Footgun, KEINE CLI-Regression): Kontrolliert verifiziert (CLI 2.1.207, gleicher Worker/Tag): unter dem Default-Mode auto bekommt sonnet Writes auto-approved (permission_denials:[], Datei entsteht), haiku wird denied (permission_denials:[Write], keine Datei) — haiku steigt beim auto-Permission-Flow aus, statt zu schreiben. Folge: eine Task, die (per MCP model:"haiku" oder Task-Override) auf haiku läuft, macht unter auto still nichts und landet ohne Änderung in WaitingForReview. Normalbetrieb (Default = sonnet) ist nicht betroffen; die Gap-Tasks 2026-07-23 liefen sonnet und haben geschrieben+committet. Ursprünglich fälschlich als CLI-auto-Regression gemeldet — das war ein Testartefakt (haiku-Tasks zum „Sparen"). Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf acceptEdits/bypassPermissions (modell-unabhängig) statt auto.
  • [BUG, 2026-07-24] OUTCOME-Karte rendert rohes Structured-Output-JSON: TaskMonitorViewModel.ApplyOutcome (ClaudeDo.Ui) setzt bei Tasks ohne Roadblock-Marker SessionOutcome = result wörtlich (Zeile ~261). Der Worker legt in task.Result das rohe {"summary":…,"files_changed":[…]} ab (die lesbare Fassung steht in task_runs.resultMarkdown), also zeigt die Detail-Insel OUTCOME als JSON-Blob statt als Text. Fix-Optionen: (a) UI parst ein JSON-Result und zeigt summary, oder (b) der Worker schreibt summary/resultMarkdown statt des JSON in task.Result. Verifiziert am Task verif §1 diff matrix (2026-07-24). Deckt sich mit Memory worker_testing_findings.
  • [NIT, 2026-07-24] Diff-Viewer: reiner Rename wird schwach dargestellt: Rename wird korrekt erkannt (UnifiedDiffParser → DiffFileStatus.Renamed, Badge StatusCode="R"), aber der File-Tree zeigt nur den neuen Namen + „+0 −0" ohne „alt → neu"-Pfad; ein reiner Rename liest sich dadurch wie „keine Änderung". Kein Korrektheitsfehler, nur UX. Optional: alten Pfad + „renamed"-Label anzeigen.
  • [MINOR, 2026-07-24] Header-TurnsText zeigt 0/max für abgeschlossene Runs: TurnsText => {Turns}/{EffectiveMaxTurns} — Turns wird beim Laden eines terminalen Tasks nicht aus task_runs.turnCount restauriert (nur live gefüllt), also erscheint 0/<max>. Kosmetisch.
  • [BUG, 2026-07-24] Approve & Merge schluckt einen „blocked"-Merge still: DetailsIslandViewModel.ApproveReviewAsync reagiert nur auf result.Status == "conflict" (öffnet den Resolver); bei "blocked" (z.B. Ziel-Working-Tree hat uncommittete getrackte Änderungen) und anderen Nicht-merged/Nicht-conflict-Status passiert nichts — kein Footer-Fehler, kein Dialog (der catch greift nur bei Exceptions, „blocked" ist aber ein normaler Rückgabewert mit ErrorMessage). User sieht „Klick tut nichts". Verifiziert 2026-07-24 doppelt: sowohl der Konflikt-Approve als auch ein sauberer additiver Approve (verif §1b) taten bei dirty main-Checkout still nichts (kein Footer). Fix: bei blocked/unerwartetem Status result.ErrorMessage via ShowErrorAsync/FlashFooterError surfacen. Verstößt gegen feedback_ui_error_surfacing. (Der eigentliche Konflikt-Resolver + 3-Pane-Editor funktionieren, sobald der Ziel-Tree sauber ist.)
  • [UX, 2026-07-24] Conflict-Resolver: Continue/Merge-Button ist klickbar, obwohl noch nicht alle Konflikte gelöst — Klick tut dann nichts: Das Continue-Gate greift funktional (merged erst wenn alle Konflikte in allen Dateien gelöst), aber der Button ist optisch nicht disabled/gegraut, solange offene Konflikte bestehen; ein früher Klick ist ein stummer No-op. Besser: Button disabled bis AllResolved, oder Hinweis „N Konflikte in M Dateien offen". Verifiziert 2026-07-24 (§4-Walkthrough).
  • [UX, 2026-07-24] Conflict-Resolver: Mehrere Konfliktdateien schlecht erkennbar: Beim 2-Datei-Konflikt war schwer zu sehen, dass zwei Dateien betroffen sind (File-Switcher/Anzahl zu unauffällig). Prominentere Datei-Liste / „x von y Dateien" wäre besser. (§4-Walkthrough 2026-07-24.)
  • [FEATURE-WUNSCH, 2026-07-24] Conflict-Resolver: farbliches Hervorheben eingefügter Zeilen im Result-Pane (grüner „flow" der übernommenen Zeilen) fehlt — kein Bug, UI-Verbesserung (User-Wunsch).
  • [BUG, 2026-07-24] Planning-Session fragt nach Permission für das claudedo-MCP-Tool: Obwohl WindowsTerminalLauncher --allowedTools "mcp__claudedo__*,Read,Grep,Glob,WebFetch,WebSearch,Skill" + --permission-mode plan setzt (Zeile 33/130), prompted die interaktive Planning-Session beim ersten mcp__claudedo__create_child_task-Aufruf. Verdacht: der mcp__claudedo__*-Glob matcht in CLI 2.1.207 nicht (Syntax evtl. mcp__claudedo für den ganzen Server), oder Plan-Mode gated MCP-Writes generell (evtl. dieselbe Permission-Verhaltensänderung wie bei --permission-mode auto, s.o.). User kann in der TUI approven, sollte aber nicht müssen. Verifiziert 2026-07-24 (§3-Walkthrough).
  • [UX, 2026-07-24] Planning-aktiver Parent zeigt weiter „Idle": Ein Parent in planning_phase=active hat Status=Idle (korrekt im Modell), aber der Row-Status-Chip zeigt „Idle" (StatusLabel/StatusChipClass), der PlanningBadge ersetzt das nicht sichtbar → liest sich wie ein normaler Idle-Task. User erwartet einen klaren „Planning/Draft aktiv"-Zustand, der Idle überschreibt. (Kinder zeigen korrekt „Draft".) §3-Walkthrough 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)

Alle 9 Review-Tasks (5 Refactorings, 4 Bugfixes) sind umgesetzt und gemerged; Details in den Commits. Offen geblieben:

  • DetailsIslandViewModel ist nach dem Split noch 1258 Zeilen (Ziel war ~800) — die drei Sektions-VMs (AgentSettings, Merge, Prep) sind extrahiert, weitere Extraktion (z.B. ChildOutcomes/Subtasks-Sektion) lohnt erst, wenn die Datei wieder wächst.
  • Bewusst zurückgestellt: WorkerHub-Split nach Concern (~60 Methoden in einer Hub-Klasse). Die Interface-Parität löst das akute Testbarkeits-Problem; ein Hub-Split ist eine größere Architekturentscheidung → erst besprechen.
  • Lessons learned: Der StartRunningAsync-Guard-Task hat isoliert grün getestet, aber den Queue-Pfad gebrochen (Picker claimt vor dem Dispatch) — Integrationsfix 74ca2e0. Bei parallelen Tasks, die denselben Pfad berühren, nach JEDEM Merge-Schwung die volle Suite auf main fahren.

Bug-Befunde (Korrektheits-Review 2026-06-09)

Plausibel, noch nicht einzeln verifiziert (bei Gelegenheit prüfen):

  • Kleinkram: MergePreview-Race bei schnellem Target-Wechsel, CTS-Dispose-Leak in Debounce-Saves, Environment.CurrentDirectory-Fallback im Konflikt-Dialog, Doppel-Continue-Fenster im Orchestrator.

Geprüft und verworfen (keine Bugs): ReviewFeedback-„Endlosschleife" (Fallback existiert), Cross-Thread-Crashes im DetailsIslandViewModel (Dispatcher-Marshalling im WorkerClient), Chain-Wedge nach Child-Delete (FK ON DELETE SET NULL), \ No newline-Parsing.

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).
Reference in New Issue View Git Blame Copy Permalink