ClaudeDo/docs/open.md

ClaudeDo — Offene Punkte

Stand: 2026-08-06. Der Findings-Block von 2026-07-24 wurde am 2026-08-06 gegen den Code nachverifiziert (statisch, nicht in der laufenden App); alles, was inzwischen gefixt ist, ist hier entfernt — Erledigtes steht in den Commits/im Code, nicht hier. Die alte Verifikations- Checkliste lebt in docs/verification-handoff.md.

---

Bugs (offen)

• Verwaiste git-Worktrees sind für die App unsichtbar (gefunden 2026-08-06). In C:\Private\ClaudeDo waren nach dem Cleanup 22 git-registrierte Worktrees + 26 claudedo/*-Branches vorhanden, die ClaudeDo-DB kannte davon nur zwei. Die Worktrees-Übersicht listet ausschließlich Zeilen aus worktrees, also kann der Nutzer diese Reste nicht über die App entfernen — und es gibt keinen Sweep dafür (OrphanRecovery räumt nur Task-Zeilen auf, keine Worktrees). Wunsch: entweder ein Startup-Abgleich git worktree list ↔ DB, der Unbekannte als „untracked" in die Übersicht aufnimmt, oder mindestens eine Warnung mit Anzahl.

UX / Nits (offen)

• Planning-aktiver Parent zeigt weiter „Idle": Parent in planning_phase=active hat Status=Idle (korrekt im Modell), aber TaskRowViewModel.StatusLabel (Zeile 132) kennt nur HasInteractiveSession/IsParked als Overrides — der PlanningBadge ersetzt den Chip nicht sichtbar → liest sich wie ein normaler Idle-Task. Wunsch: klarer „Planning/Draft aktiv"-Zustand, der Idle überschreibt. (Kinder zeigen korrekt „Draft".)
• Blocked-by-Kette nicht sichtbar: Nach Finalize ist die sequentielle Kette korrekt gesetzt (child[i] blocked-by child[i-1]), aber die UI stellt Reihenfolge/Abhängigkeit nicht dar — es gibt nur den „waiting"-Chip. Wunsch: Kette visualisieren (z.B. „wartet auf <Vorgänger>").
• Dequeue-„X" fehlt auf wartenden (blockierten) Kettengliedern: CanRemoveFromQueue = IsQueued || HasQueuedSubtasks (TaskRowViewModel.cs:99), IsQueued verlangt leeres blocked_by. Ein gequeuetes, aber blockiertes Kind (IsWaiting) bekommt daher kein Remove-from-queue-X — nur Parent + erstes (entsperrtes) Kind.
• Session-Skills-Tab hat keinen Empty-State: Bei 0 installierten Skills zeigt der Skills-Tab (Settings) nur eine nackte leere Fläche unter der Install-Zeile — kein erklärender Hinweis (z.B. „Noch keine Skills installiert — GitHub-URL oben einfügen"). Im sessionSkillsTab-Locale-Namespace (en.json:674) gibt es keinen empty-Key.
• Modal-Bodies sind unten abgeschnitten (Sichtprüfung 2026-08-06, beobachtet in den Listen-Settings: der Hinweistext unter „Verify command" ist mitten in der Zeile vom Footer weggeschnitten und lässt sich nicht herunterscrollen; laut Mika „fast überall" in den Settings-Modals). Gemeinsames Muster: <ScrollViewer Padding="20,16"> als Modal-Body — in ListSettingsModalView:36, MergeModalView:33, WorktreesOverviewModalView:131, AboutModalView:20, MergeHelperSelectionModal:47, RepoImportModalView:45, LogVisualizerView:45 sowie WorkConsole:295/395. Vermutete Ursache (nicht verifiziert): das untere Padding des ScrollViewers zählt nicht zum scrollbaren Extent, die letzten Pixel sind also unerreichbar. Erst am echten Fall nachmessen, dann ggf. einheitlich das Padding vom ScrollViewer auf ein Margin des inneren Inhalts umziehen.
• Usage-Monitor-Modal: Analyse-Tabellen ausbaufähig (Sichtprüfung 2026-08-06; Gauges, Info-Bänder, Presets/Custom-Range und Refresh-Button sind in Ordnung). Models-Tab: die Spaltenköpfe „OTHER CACHE" und „SHARE" kollidieren zu OTHER CACHISHARE; claude-haiku-4-5-20251001 läuft in die IN-Spalte; alle Zahlen linksbündig und ohne Tausendertrenner (506830708). Tasks-Tab: Task-Titel wird ohne Ellipse hart an der LIST-Spalte abgeschnitten, der LIST-Text ebenfalls; MODEL ist bei Runs von vor der task_runs.model-Spalte leer (besser „—"). Wunsch: Zahlen rechtsbündig + #,##0 (oder k/M), Spaltenbreiten/Truncation fixen.
• Conflict-Resolver: mehrere Konfliktdateien schlecht erkennbar: Beim 2-Datei-Konflikt schwer zu sehen, dass zwei Dateien betroffen sind (File-Switcher/Anzahl zu unauffällig). Prominentere Datei-Liste / „x von y Dateien".
• Attachments: erster Drag&Drop der Session schlug einmalig fehl („An error occurred"): Beim allerersten Drop-to-attach einer UI-Session zeigte die DropStatus-Zeile inline einen generischen Fehler und es wurde nichts persistiert (kein File, keine DB-Row); alle folgenden Drops derselben Session + der „Add file…"-Picker + Remove funktionierten fehlerfrei. Nicht reproduzierbar nach dem ersten Mal. Kandidaten: transiente SQLite-Contention (der UI-Prozess schreibt todo.db direkt via new TaskAttachmentRepository, während der Worker dieselbe DB hält) ODER ein Fehler im Drop-Stream-Pfad (IStorageFile.OpenReadAsync im Code-Behind, außerhalb des try in AddFilesAsync). Falls es erneut auftritt: AddFilesAsync/OnDrop mit robusterem Error-Logging versehen.

Feature-Wünsche

• Conflict-Resolver: farbliches Hervorheben eingefügter Zeilen im Result-Pane (grüner „flow" der übernommenen Zeilen).
• Die Handler-Session soll „Submit for review" selbst auslösen können (Sichtprüfung 2026-08-06). Aktuell ist der Abschluss eines List-Handler-Laufs ein reiner Handgriff über die Schaltfläche in der Mission-Control-Kachel — die Session selbst hat kein Werkzeug dafür, obwohl sie am besten weiß, wann sie fertig ist. Wunsch: ein MCP-Tool auf der In-Task-Oberfläche, das denselben Pfad wie der Button nimmt.
• Handoff-Kachel besser beschriften (Sichtprüfung 2026-08-06). Die zweite Kachel heißt Merge Helper — <Liste> (Handoff) bzw. „(Übergabe)" (missionControl.mergeHelperHandoffTitleSuffix, en.json/de.json:297). „Handoff" ist internes Vokabular und sagt nicht, was die Session tut. Besser etwas, das die Rolle nennt (Ausführen + Mergen der verbliebenen Tasks, Phasen 3-5).

Design-Entscheidungen (27.07.-Batch, Sichtprüfung am 2026-08-06 abgeschlossen)

Der Sichtprüfungs-Block dieses Batches (Ctrl+K/#, Titel-Edit, ConPTY-/Refine-Spinner, Interactive-Chip, Diff-Viewer-Abstände, Manual-Tasks, Vorgaben-pro-Modell-Tabelle) ist von Mika verifiziert und deshalb hier entfernt. Es bleiben die Entscheidungen, die daran hängen:

• Interaktive ConPTY-Sessions bekommen --effort, aber kein --model — die Session läuft weiter unter dem Modell aus Mikas Claude-Config, der Effort kommt aus dem Preset des Modells, das ClaudeDo für die Task auflösen würde. Falls ClaudeDo auch interaktiv das Modell erzwingen soll, ist das ein Folge-Task.
• AppSettings.DefaultMaxTurns ist jetzt tatsächlich verdrahtet (ModelPresets.For(..., global.DefaultMaxTurns) in TaskRunner.ResolveConfigAsync): reiner Fallback für ein Modell, das auch nach ModelRegistry.TryNormalizeAlias auf keine Preset-Zeile trifft — vorher war das Feld tot (hartkodierte 30). Hat weiterhin keinen eigenen Editor mehr (nur die Preset-Tabelle pro Modell); Spalte könnte später entfallen, falls das nie zutrifft.

Beobachtung (offen — Entscheidung Mika)

• --permission-mode auto + Modell haiku → Writes werden denied: Kontrolliert verifiziert (CLI 2.1.207): unter dem Default-Mode auto bekommt sonnet Writes auto-approved (permission_denials:[]), haiku wird denied (permission_denials:[Write], keine Datei) — eine haiku-Task macht unter auto still nichts und landet ohne Änderung in WaitingForReview. Normalbetrieb (Default = sonnet) nicht betroffen. KEINE CLI-Regression, sondern modellabhängiges auto-Verhalten. Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf acceptEdits/bypassPermissions (modell-unabhängig). Mika: erstmal beobachten. Siehe Memory auto_permission_haiku_footgun.
• QueueServiceTests.UsageGate_TransitionLogging_FiresOncePerChange ist zeitbasiert flaky — am 2026-08-06 gefixt: der feste Task.Delay(200) ist durch die schon im selben File vorhandene AssertStableCountAsync ersetzt (pollt bis der erste Backstop-Tick geloggt hat, wartet dann eine Karenzzeit und stellt sicher, dass kein weiterer Tick nachlegt). Historischer Befund zur Einordnung: Schlägt reproduzierbar fehl (Expected 1, Actual 0 Warn-Log-Aufrufe), sowohl solo (--filter) als auch im Vollauf, auf einem sauberen git worktree add gegen main (bdee731) — also kein durch diese Abschluss-Session verursachter Regress (die Session hat keine .cs-Datei angefasst). Ursache: der Test verlässt sich auf einen festen Task.Delay(200), um mehrere 50-ms-Backstop-Ticks abzuwarten (Kommentar im Test: „Several backstop ticks (50ms interval) all observe the same blocked state"); auf einer stark ausgelasteten Maschine (hier: viele parallele ClaudeDo-Worktrees/Builds) reicht das Fenster nicht immer. Zum Vergleich: derselbe Test lief in einer zweiten, isolierten Verifikation (Scratch-Merge für den Environment-Checks-Task) sauber durch (876/876). Fix wäre ein Poll-basiertes Warten statt fixem Sleep — aber außerhalb des Scopes dieser Doku/Verifikations-Session (keine Code-Änderung angefasst).

---

Offene Verifikation (2026-07-27)

• List handler (2026-07-27) — visual pass: the Broom button is gone from the lists footer, the context-menu item appears only on lists with a working dir, and the selection dialog has no LIST column. (Der real-Claude-Smoke-Run der fünf Phasen ist am 2026-07-29 gelaufen — 6/6 sauber gemerged; nur die Sichtprüfung ist noch offen.)

Offene Verifikation (2026-08-05)

• List handler owns a task (2026-08-05) — visuell verifiziert am 2026-08-06 (Lauf über die Liste ClaudeDoTests mit 4 Tasks, davon 2 absichtliche Dubletten): genau ein neuer Task, Mission- Control-Tile task-basiert mit „Submit for review", Dedupe hat die Dublette erkannt, Beschreibungen wurden angereichert, Submit → WaitingForReview, und die Diff-Karte zeigte alle drei Dateien des Laufs. Korrektur zur Erwartung oben: der Task-Chip liest sich „Interactive", nicht Idle — das ist korrekt so (HasInteractiveSession überschreibt den Status-Chip, solange die ConPTY-Session läuft). Die drei dabei gefundenen Punkte stehen unter „Bugs" bzw. „Feature-Wünsche".

• Roadblock reply field (2026-08-05) — Kernfunktion am 2026-08-06 verifiziert: auf einem Task mit gemeldetem Roadblock erscheint das Antwortfeld unter dem Roadblock-Text, die Antwort setzt die Session fort, und der Task landet danach sauber auf WaitingForReview. Dabei ist der Bug oben aufgefallen (Feld deaktiviert, solange der Task seit vor dem Lauf offen ist). Layout der Roadblock-Karte ist in Ordnung. Noch offen: Enter-zum-Senden, und dass ein „Override-Slot besetzt"-Fehler im Footer-Strip landet (nicht als Modal) mit dem getippten Text weiterhin im Feld. Design-Entscheidung dazu: der Review-Bereich lebt als zwei nullable Spalten direkt auf TaskEntity (kein Phantom-WorktreeEntity), damit list_worktrees/die Worktrees-Übersicht ihn nie sehen.

• Post-merge verify gate (2026-08-05) — build + unit tests all green (incl. real-process VerifyCommandRunner exit-code/output/timeout tests and TaskMergeService success/failure/ timeout paths via a fake runner), but not visually verified: open a list's Settings modal, confirm the new "VERIFICATION" section renders below Agent with a settable/clearable VerifyCommand field; approve a task on a list with a failing command configured and confirm the footer/error surfacing (ShowErrorAsync) actually shows the verify failure message instead of silently looking like nothing happened. Also no real-build smoke test (a real dotnet build/ dotnet test invocation as the configured command) — only fast synthetic commands (exit N, ping for timeout) were exercised.

Offene Verifikation (2026-08-11, Task numbers in UI)

Slice 4 der Task-Numbers-Features (UI-Display) ist gemerged (commit 38af549); Build + Tests grün, aber nicht visuell verifiziert:

• Task Row Display: TaskRowViewModel.Number (Zeile 39, TaskRowViewModel.cs) zeigt die Nummer als #<number> dimmed vor dem Titel in der Row an (TaskRowView.axaml Zeile 45+). Prüfen: offene Task in der Übersicht hat sichtbar #<number> vor dem Titel.
• Detail Pane Header: DetailsIslandViewModel.TaskIdBadge (Zeile 77, DetailsIslandViewModel.cs) zeigt jetzt #<number> statt des alten GUID-Präfix. Prüfen: Task-Detail-Chip zeigt #<number>.
• Worker Log Messages: Geschäftsereignisse in TaskRunner (Zeile 199+), TaskMergeService (Zeile 174+), und TaskResetService (Zeile 84+) prefixen Task-Titel mit #<number>. Prüfen: Footer Worker-Log zeigt Task-Messages wie „#42 finished" statt nur dem GUID.

Offene Verifikation (2026-08-06, Fix-Batch aus der Sichtprüfung)

Fünf Findings der Sichtprüfung sind gefixt, Build + Tests grün, aber noch nicht in der App nachgeprüft (der laufende Build ist älter — erst nach Neuinstallation testbar):

• NumericUpDown-Leeren wirft nicht mehr: neuer KeepLastNumberConverter bildet beim ConvertBack null auf BindingOperations.DoNothing ab, an allen acht nicht-nullbaren NumericUpDowns im Settings-Modal verdrahtet. Prüfen: Wert löschen und neu tippen — keine Exception, alter Wert bleibt stehen, bis eine echte Zahl kommt. Damit ist auch der offene Rest von „MaxTurnsCeiling ändern → Hinweistexte ziehen mit" nachholbar.
• Verify-Gate greift jetzt auch ohne Worktree: Approve auf einem List-Handler-Task mit fehlschlagendem VerifyCommand muss verify_failed liefern und den Task aus Done halten (vorher ging er kommentarlos auf Done).
• verify_failed im Merge-Modal und in der Worktrees-Übersicht: Modal zeigt statt „Unknown status" den echten Fehlertext und schließt sich nicht automatisch; die Batch-Übersicht zeigt VerifyFailed und markiert die Zeile trotzdem als Merged (der Merge ist ja gelandet).
• Roadblock-Reply/Continue live: Task offen lassen, während er in den Roadblock läuft — das Antwortfeld und Continue müssen ohne erneutes Öffnen aktiv werden.
• Cleanup-Log: ein Worktree-Cleanup über veraltete DB-Zeilen darf keine WARN-Flut mehr im Footer erzeugen (die „schon erledigt"-Fälle gehen auf Debug).
• Handoff schließt die alte Kachel: beim Übergang von Phase 2 auf Phase 3 muss die alte Merge-Helper-Kachel verschwinden und die neue an ihrer Stelle stehen — keine leere Geister-Pane mehr. (Entscheidung Mika 2026-08-06: automatisch schließen statt Output erhalten.)

Offene Verifikation (2026-08-06, Resume planning session)

planning_session_id wurde nie befüllt (der Setter hatte keinen Aufrufer), weil die interaktive Planning-Session ihre claude-Session-Id nie zurückmeldet — Resume konnte deshalb nie funktionieren. PlanningSessionManager.ResumeAsync liest die Id jetzt beim ersten Resume aus dem Transkript, das Claude Code unter ~/.claude/projects/<encodiertes cwd>/<sessionId>.jsonl für den Planning-Worktree ablegt (PlanningTranscriptLocator), und persistiert sie. Unit-Tests grün, nicht visuell verifiziert:

• Planning-Session starten, Fenster/Pane schließen, Task erneut öffnen → „Resume" muss die ConPTY-Pane mit der fortgesetzten Unterhaltung öffnen (nicht mit leerem Verlauf).
• Ohne Transkript (z. B. Session nie wirklich gestartet): Fehlermeldung „No Claude session transcript found…" landet sichtbar im Footer-Error-Strip (Terminal.StartError → ErrorReported), nicht still.
• Risiko: das Verzeichnis-Encoding (~/.claude/projects/, jedes Nicht-Alphanumerische wird -) ist undokumentiertes CLI-Verhalten — ändert es sich, findet der Locator nichts und Resume meldet sauber „cannot resume" (fail-safe, kein falscher Resume).

Offene Verifikation (2026-08-05, Usage Monitor)

Kein Light-Theme. App.axaml:6 setzt RequestedThemeVariant="Dark" fest, es gibt keinen Umschalter und Tokens.axaml kennt keine Light-Variante. „Dark/Light"-Checks sind deshalb überall aus dieser Datei entfernt — sie waren nie erfüllbar.

• Visueller Pass Usage-Pill (Footer und Mission-Control-Header) — am 2026-08-06 verifiziert: Text/Tooltip lesbar, Dot-Zustände plausibel, Pill in Footer und Mission-Control-Header identisch.
• Visueller Pass Usage-Monitor-Modal — am 2026-08-06 verifiziert: Gauges (dynamisch aus limits[]), Info-Bänder (der Throttle-Hinweis „Queue throttled: 1/3 slots (7d)" stand real an), 7d/30d-Presets + Custom-Range. Die Analyse-Tabellen sind ausbaufähig → siehe „UX / Nits".
• E2E Gate: das Gate greift real, sobald ein Bucket (five_hour/seven_day) die konfigurierte Schwelle reißt — Queue-Nachschub pausiert, laufende Runs/RunNow/ConPTY/ Planning/Prime bleiben unberührt — und die Queue nimmt nach dem Reset selbstständig wieder auf (30s-Backstop, kein persistenter Pause-Zustand).
• Risiko: der Usage-Endpoint (GET https://api.anthropic.com/api/oauth/usage) ist undokumentiert und kann sich ändern; bei Ausfall/Formatänderung ist das Gate wirkungslos (fail-open by design — kein Blocker, aber der Schutz fällt dann aus, ohne dass es auffällt).

Nachtrag 2026-08-05: 429-Fix (Poll-Kadenz + Refresh-Button)

Der 60s-Poll lief in 429s. Neu: aktivitätsabhängige Kadenz (5 Min. solange ein Task Running ist, sonst 15 Min.), 429-Backoff mit Retry-After, und ein „Jetzt aktualisieren"-Button im Usage-Monitor-Modal (RefreshUsage → UsageMonitorService.RefreshNowAsync, 10s-Cooldown). Unit-Tests grün, offen:

• Visueller Pass Refresh-Button im Modal — am 2026-08-06 verifiziert (Button, Hinweiszeile „Polled every 5 min while a task runs, otherwise every 15 min.").
• E2E: über ≥20 Min. mit und ohne laufenden Task beobachten, dass keine 429s mehr im Worker-Log auftauchen und die Pill trotzdem aktuell bleibt.
• Beachten: die Pill wird jetzt erst nach 3× 15 Min. als stale markiert — ein echter Endpoint-Ausfall fällt vorher nur über LastError auf (der IsStale sofort setzt).

Offene Verifikation (2026-08-05, Max-Turns-Ceiling)

Build + unit tests grün (ResolveMaxTurns-Klemmung, Repository-Backfill von model_presets, Migration AddMaxTurnsCeiling gegen eine Scratch-DB angewendet), aber nicht visuell verifiziert:

• Agent-Settings-Editor (Task und Liste): Max-Turns-Feld auf einen Wert über der Ceiling (Default 80) setzen, Hinweistext unter dem NumericUpDown erscheint ("Runs are capped at {N} turns…").
• Settings → Allgemein → Vorgaben pro Modell: eine Zeile über 80 setzen, derselbe Hinweistext erscheint unter der Zeile.
• MaxTurnsCeiling ist seit 2975f90 selbst editierbar (Settings → Allgemein, SettingsModalView.axaml) — Feld prüfen: Wert ändern, speichern, Hinweistexte oben ziehen mit.

Offene Verifikation (2026-08-05, Environment Checks / SystemCheckPage)

Checks + SystemCheckPage (claudedo/06aca9b3…) und das ExecutableResolver-Wiring im Worker (claudedo/40272c0b…) sind seit 2026-08-06 auf main gemerged; die frühere „erst mergen"- Voraussetzung ist erledigt. Details → installer-preflight in docs/explore-notes/README.md und der Abschnitt „Environment Checks" in src/ClaudeDo.Installer/CLAUDE.md.

Update (2026-08-06): beide Folge-Features sind jetzt implementiert und auf main.

• Diagnose-Sektion (Config-Modus/SettingsWindow): Pages/DiagnosePage/ + geteilte Checks/CheckListViewModel.cs/Checks/CheckListView.xaml (auch von SystemCheckPage genutzt, keine zweite Implementierung). Unit-getestet (tests/ClaudeDo.Installer.Tests/Pages/DiagnosePage/DiagnosePageViewModelTests.cs).
• „Claude Help Me"-Button: Core/ClaudeHelpLauncher.cs + SystemCheckPageViewModel/-View, unit-getestet (tests/ClaudeDo.Installer.Tests/Core/ClaudeHelpLauncherTests.cs).

Beides nicht visuell verifiziert:

• Help-Me-Button ist deaktiviert, wenn claude-cli nicht Ok ist oder claude-auth Failed ist (bleibt aktiv bei Unknown), mit erklärendem Tooltip — unit-getestet.
• „Claude Help Me" öffnet tatsächlich ein Terminal mit laufender Claude-Session, und die Session hat den Diagnose-Report gelesen — nicht verifiziert (der eigentliche Terminal-Start/wt.exe-Zusammenspiel und die Session-Qualität sind nur über die injizierte IProcessLauncher-Fake getestet, nie mit einem echten Terminal/CLI).
• Platzierung des Help-Me-Buttons: er sitzt seit dem Merge der Diagnose-Sektion in einer eigenen Zeile unter dem geteilten Check-Listen-Footer (der reservierte Slot im Footer entfiel mit der Extraktion nach CheckListView.xaml). Optisch prüfen, ob das so bleiben soll oder ob der Button in den geteilten Footer gehört.
• Diagnose-Sektion im Config-Modus: Öffnen von SettingsWindow löst keinen Prüflauf aus, Klick auf „Erneut prüfen" schon; zeigt die echten installierten Pfade/Ports (nicht die InstallContext-Defaults), und der laufende Worker auf dem konfigurierten SignalR-Port gilt nicht als Konflikt — unit-verifiziert, visueller Durchlauf noch offen.

Weitere Punkte, gebaut + unit-getestet auf main, aber nicht visuell verifiziert:

• SystemCheckPage: Layout, Icon-/Farbwirkung der vier Status (Ok grün / Warnung orange / Fehler rot / Unbekannt grau — StatusGreenBrush/StatusOrangeBrush/StatusRedBrush/ StatusGrayBrush), Lesbarkeit der Hint-Texte, DE und EN.
• Weiter-Button gesperrt bei einem echten blockierenden Fehler (z. B. claude nicht im PATH → claude-cli Error/Failed), und der Grund ist in der Zusammenfassungszeile sichtbar (nennt den/die blockierenden Check(s) namentlich).
• „Erneut prüfen" wechselt einen Status live (z. B. git-Identity setzen → Warnung verschwindet), ohne dass ein zweiter paralleler Lauf startet, wenn währenddessen erneut geklickt wird.
• Update-Modus zeigt die SystemCheckPage nicht (Wizard bleibt Welcome + Install).
• Auf einem Rechner mit npm-installiertem claude.cmd: claude-cli-Check findet es (Detail-Text „Resolved via a shim…"), und ein Task läuft im Worker durch (bestätigt, dass ClaudeProcess/ClaudeCliPreflight den Shim über cmd.exe /c tatsächlich startet, nicht nur, dass der Check ihn findet).

---

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. Tests nutzen FakeClaudeProcess.
• architecture.md / ADRs — die per-Projekt-CLAUDE.md-Dateien sind die lebende Doku.
• Task-Mailbox-Integration — geparkt; das generische mcp__mailbox__*-Plugin reicht (mailbox-proposal.md).
• Tag-Negation, Tag-Multi-Select, Notes-lists.kind-Switch, Install-Service-Skript — durch die aktuelle Architektur überholt.