docs: slim open.md down to open items only
Drop the changelog of completed/verified work — that lives in commits and code. Keep only pending manual verification, the one open code item, and a short "decided against" list to prevent re-proposing dropped ideas. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
228
docs/open.md
228
docs/open.md
@@ -1,222 +1,30 @@
|
|||||||
# ClaudeDo — Offene Punkte
|
# ClaudeDo — Offene Punkte
|
||||||
|
|
||||||
Stand: 2026-06-04. Neu generiert nach Code-Audit gegen den tatsächlichen Stand auf `main`.
|
Stand: 2026-06-04. **Nur noch offene Punkte.** Was erledigt ist, steht in den Commits und im Code — nicht hier.
|
||||||
|
|
||||||
Die vorherige Version war auf 2026-04-30 datiert und inzwischen deutlich veraltet: zahlreiche als „offen" geführte Punkte sind gebaut, mehrere große Features (Localization, Weekly-Report + Daily-Notes, Daily-Prep) fehlten komplett, und das inzwischen entfernte Tag-System wurde noch als lebendig behandelt. Diese Version trennt sauber: **was seit 2026-04-30 dazukam**, **was wirklich noch offen ist**, **was inzwischen erledigt wurde** und **was fallengelassen / obsolet ist**.
|
|
||||||
|
|
||||||
Legende: ✅ DONE — 🟡 PARTIAL — ⬜ OPEN — ⛔ DROPPED/OBSOLET
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 0. Was seit 2026-04-30 dazugekommen ist
|
## Manuelle Verifikation (offen)
|
||||||
|
|
||||||
Diese Features gab es im alten Dokument noch gar nicht. Sie sind **fertig im Code**, brauchen aber teils noch manuelle Verifikation (siehe §1).
|
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.
|
||||||
|
|
||||||
| Feature | Anker | Status |
|
- **Worktree-Pipeline:**
|
||||||
|---|---|---|
|
- Worktree-Happy-Path → `worktrees.state='active'`, `head_commit` gesetzt, `diff_stat` non-empty, Branch `claudedo/<id>` auf Disk.
|
||||||
| **Localization / i18n** | Eigenes Projekt `ClaudeDo.Localization` (`Localizer`, `CultureResolver`, `LocaleStore`, nested-JSON Parser); `loc:Tr` Markup-Extension; `locales/en.json` + `locales/de.json`; Settings-Sprachwahl; Installer-Sprachwahl | ✅ Code, Localization.Tests erzwingt Key-Parität |
|
- No-Changes-Run → `status='Done'`, `head_commit IS NULL`, `diff_stat IS NULL`.
|
||||||
| **Weekly Report** | `Worker/.../WeekReportService`, `ClaudeHistoryReader` (distilliert Session-Logs), Day-Major-Prompt-Builder; `WeekReportRepository`; `WeeklyReportModalView(Model)` | ✅ Code, manuelle Verifikation siehe §1.4 |
|
- Kein Git-Repo (`working_dir=C:\Temp`) → `status='Failed'`, **keine** `worktrees`-Row, Git-Fehler im Log.
|
||||||
| **Daily Notes** | `DailyNoteRepository`, `INotesApi`, `NotesEditorView(Model)` mit Tagesnavigation + Bullet-CRUD; Notes-Mode in der Details-Island; gepinnte Notes-Row in MyDay | ✅ Code |
|
- **Feature-Walkthroughs:** Planning-Session-Flow (Draft→Finalize→Chain), Prime/Daily-Prep-Trigger, Weekly-Report-Generierung, Self-Update (Banner → Update → „up to date").
|
||||||
| **Daily-Prep („Plan My Day")** | `Prime/PrimeRunner` ruft Daily-Prep über erlaubte MCP-Tools; `get_daily_prep_candidates` + `set_my_day` MCP-Tools mit Cap-Guard; `DailyPrepMaxTasks`-Setting; Live-Prep-Output-Mode in der Details-Island (`PrepStarted/PrepLine/PrepFinished`); persistierter Prep-Log; MyDay-Header-Iconreihe (Prepare, Clear-day, Prep-log) | ✅ Code, manuelle Verifikation siehe §1.5 |
|
- **Worker-Autostart am Gerät:** Logoff/Logon-Autostart, Update-Pfad, Uninstall entfernt die Startup-`.lnk`.
|
||||||
| **Waiting-for-Review-State** | Eigene Status-Stufe zwischen Run-Erfolg und Done; Approve/Reject-Rerun/Reject-Park/Cancel | ✅ Code |
|
|
||||||
| **Per-User Worker-Autostart** | Startup-Ordner-Verknüpfung statt Scheduled Task / Windows-Service (siehe §4.1) | ✅ Code |
|
|
||||||
| **Worktree-Overview-Modal** | `2026-05-19-worktree-overview-modal-design` | ✅ Code |
|
|
||||||
| **External-MCP UI-Parität** | ExternalMcpService von 11 → 18 Tools (siehe §5.4) | ✅ Code |
|
|
||||||
|
|
||||||
Weitere Specs/Plans seit 2026-04-30 (für die Historie): `planning-draft-planned-gate`, `repo-import-list-helper`, `ui-normalization`, `worker-lifecycle`, `prime-recurring-weekdays`.
|
## 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.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. Verification (vor allem anderen)
|
## Bewusst verworfen (nicht erneut vorschlagen)
|
||||||
|
|
||||||
Der Code ist da; was fehlt, ist die **manuelle Bestätigung mit explizit notiertem Pass-Kriterium**. Ohne falsifizierbare Observable produziert ein Manual-Run nur „sah ok aus".
|
- **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`.
|
||||||
### 1.0 Plan-Verification — Kernpipeline
|
- **`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`).
|
||||||
**2026-06-04: Kernpipeline läuft.** Der User bestätigt, dass Tasks mit echtem `claude` gestartet werden und der Happy-Path (non-worktree) durchläuft — Live-Stream und Wake-up inklusive. Die granularen Observables unten wurden nicht formell protokolliert; offen bleiben die worktree-spezifischen Pfade (5–7).
|
- **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).
|
||||||
|
|
||||||
| # | Item | Status | Pass-Kriterium |
|
|
||||||
|---|------|---|---|
|
|
||||||
| 3 | Smoke-Spawn (`claude -p` „ping") | ✅ | (in der Praxis bestätigt 2026-06-04; formale Observables nicht protokolliert) |
|
|
||||||
| 4 | E2E Happy Path (Non-Worktree) | ✅ | (in der Praxis bestätigt 2026-06-04) |
|
|
||||||
| 5 | Worktree Happy Path | ⬜ | Liste mit `working_dir` auf temp-Repo, Task mit Codeänderung → `worktrees.state='active'`, `head_commit IS NOT NULL`, `diff_stat` non-empty, Branch `claudedo/<id>` auf Disk |
|
|
||||||
| 6 | No-Changes-Run | ⬜ | Prompt der nichts ändert → `status='Done'`, `worktrees.head_commit IS NULL`, `diff_stat IS NULL` |
|
|
||||||
| 7 | Kein Git-Repo | ⬜ | `working_dir=C:\Temp` → `status='Failed'`, **keine** `worktrees`-Row, Git-Fehler im Log |
|
|
||||||
| 8 | Merge-UI | 🟡 | `MergeTask` + `MergeModalView` da; manueller Run offen → `worktrees.state='merged'`, Commit im Ziel-Repo, kein Branch in `git worktree list` |
|
|
||||||
| 9 | Override-Parallelität | 🟡 | `OverrideSlotService`-Tests grün; UI-E2E offen → `GetActive` ≥ 2 Einträge bei Run+RunNow |
|
|
||||||
| 10 | Schedule | 🟡 | `QueuePicker`-Tests grün; UI-E2E offen → `scheduled_for=now+2min` bleibt Queued, dann automatisch Running |
|
|
||||||
| 11 | Worker-Offline-Erkennung | 🟡 | Auto-Reconnect implementiert; visuell prüfen: nach `taskkill` Statusbar in ≤ 5s „Offline", RunNow disabled |
|
|
||||||
| 12 | Live-Stream | 🟡 | `ClaudeProcess` streamt NDJSON via `TaskMessage`; visuell: ndjson-Zeilen laufen während Run ein |
|
|
||||||
| 13 | Wake-up (`WakeQueue`) | 🟡 | `QueueWaker.Wake()` bei Enqueue; visuell: Task in ≤ 1s auf Running statt nach Backstop-Intervall |
|
|
||||||
|
|
||||||
**Empfohlener Sprint:** Steps 3–7 in einem Rutsch (alles non-UI), 8–13 parallel beim normalen App-Lauf visuell abhaken.
|
|
||||||
|
|
||||||
### 1.1 Planning Sessions — Manual Verification
|
|
||||||
|
|
||||||
1. Manual-Task mit Title + TODO-Description anlegen.
|
|
||||||
2. Rechtsklick → **Open planning Session** → Terminal mit Claude CLI öffnet.
|
|
||||||
3. In CLI zwei Children via `mcp__claudedo__create_child_task` anlegen.
|
|
||||||
4. UI: Drafts eingerückt, italic, `DRAFT`-Badge; Parent `PLANNING`-Badge; Chevron klappt.
|
|
||||||
5. CLI `finalize` → Children Queued bzw. Queued+BlockedBy; Parent `Finalized` (`PLANNED`-Badge, blau); erste Child startet automatisch.
|
|
||||||
6. Terminal ohne Finalize schließen → Rechtsklick öffnet Resume/Finalize-now/Discard-Modal.
|
|
||||||
7. Delete auf Parent mit Children → freundlicher Fehlerdialog, kein Delete.
|
|
||||||
|
|
||||||
### 1.2 Prime Claude — Manual Verification
|
|
||||||
|
|
||||||
1. Settings → Prime-Claude-Tab → Schedule mit Uhrzeit + Wochentag-Toggles anlegen.
|
|
||||||
2. Trigger (ggf. verschobener `IPrimeClock`) → Footer-Notification, neuer Task in Ziel-Liste.
|
|
||||||
3. Worker-Restart im Schedule-Fenster → Catch-up genau einmal (kein Doppelfeuer).
|
|
||||||
4. Schedule editieren → `next_due_at` neu berechnet, UI aktualisiert.
|
|
||||||
5. Schedule löschen → keine weiteren Trigger, keine ghost-Tasks.
|
|
||||||
|
|
||||||
### 1.3 Self-Update — Manual Verification
|
|
||||||
|
|
||||||
Voraussetzung: Gitea-Release unter `git.kuns.dev/releases/ClaudeDo` mit `ClaudeDo-<version>-win-x64.zip`, `ClaudeDo.Installer-<version>.exe`, `checksums.txt`.
|
|
||||||
|
|
||||||
1. Baseline (z.B. `0.2.x`) installieren.
|
|
||||||
2. Neues Release `v0.3.0` veröffentlichen.
|
|
||||||
3. App starten → Banner `Update available: v0.2.x → v0.3.0`.
|
|
||||||
4. **Update now** → App schließt, Installer im Update-Mode, restartet Worker.
|
|
||||||
5. App neu starten → Banner weg; `Help → Check for updates` → „You're up to date".
|
|
||||||
6. Alten Installer manuell starten → bietet Self-Update an. **Update** / **Continue anyway** / **Cancel** je einmal durchspielen.
|
|
||||||
7. Network-Kill beim Start in App und Installer → silent fallback (kein Error, kein Banner).
|
|
||||||
|
|
||||||
### 1.4 Weekly Report — Manual Verification (NEU)
|
|
||||||
|
|
||||||
1. Menü → Weekly Report öffnen → Default-Range stimmt (Standup-Wochentag berücksichtigt).
|
|
||||||
2. Generate → Report-Body entsteht aus Session-History; Multi-Repo-Zuordnung korrekt; Standup-Wochentag-Sentinel greift.
|
|
||||||
3. Excluded-Paths in Settings → entsprechende Repos fehlen im Report.
|
|
||||||
4. Report wird persistiert (`WeekReportRepository`) und beim erneuten Öffnen geladen.
|
|
||||||
|
|
||||||
### 1.5 Daily-Prep — Manual Verification (NEU)
|
|
||||||
|
|
||||||
1. `DailyPrepMaxTasks` in Prime-Settings setzen.
|
|
||||||
2. MyDay-Header → **Prepare day** (oder geplanter Prime-Trigger) → Live-Prep-Output läuft in der Details-Island.
|
|
||||||
3. Claude wählt ≤ Cap Tasks aus, `set_my_day` schreibt sie in MyDay; Cap-Guard verhindert Überschreitung.
|
|
||||||
4. **Prep-log** öffnet den persistierten letzten Lauf im Terminal-View; **Clear-day** leert MyDay.
|
|
||||||
5. Re-Open des Prep-Windows lädt den persistierten Log; Empty-State-Hinweis startet Planung aus dem Fenster.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. UI — Offene Punkte
|
|
||||||
|
|
||||||
### 2.1 Status-Bar Live-Update 🟡 (durch Refactor verschoben)
|
|
||||||
- `StatusBarViewModel` existiert **nicht mehr** als Datei — Connection-Status lebt jetzt in `IslandsShellViewModel` + `WorkerConnectionModalViewModel` (Islands-Architektur). Die Footer-Connection-Pill ist gebaut und farbcodiert.
|
|
||||||
- **Verbleibendes Risiko:** Ob `RunNow`-Enable/Disable pro Task-Row bei Connection-Change sauber re-evaluiert wird, ist nicht verifiziert. Gegen die aktuelle Architektur neu bewerten statt das alte `WeakReferenceMessenger`-Rezept blind umzusetzen.
|
|
||||||
- **Aufwand:** klein (erst messen, dann ggf. fixen).
|
|
||||||
|
|
||||||
> Erledigt seit letztem Backlog: Folder-Picker (§alt 2.1), Delete-Confirmation (§alt 2.2), Markdown-Rendering, Live-Log Auto-Scroll (§alt 2.4), Task-Level-Diff-Viewer (§alt 2.5, kein `cmd /k git diff` mehr), Settings-Dialog, Planning-Badge-Farben, tote Converter-Statics — siehe §6.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Worker-Robustheit
|
|
||||||
|
|
||||||
### 3.1 Worktree-Cleanup bei Anlage-Failed ✅
|
|
||||||
- `WorktreeManager.cs:64-92` heilt eine „branch already exists"-Kollision (remove + prune + delete + retry).
|
|
||||||
- Der DB-Insert (`:96-122`) ist jetzt in `try/catch` gekapselt: schlägt er fehl, nachdem `WorktreeAddAsync` erfolgreich war, wird der verwaiste Worktree + Branch best-effort (non-cancellable) entfernt und die Exception rethrown. Test: `WorktreeManagerTests.CreateAsync_DbInsertFails_RemovesOrphanedWorktreeAndBranch`.
|
|
||||||
|
|
||||||
### 3.2 CLI-Preflight beim Worker-Start ✅
|
|
||||||
- `Worker/Lifecycle/ClaudeCliPreflight.cs` + Wiring in `Program.cs`; skippable via `CLAUDEDO_SKIP_CLI_PREFLIGHT=1`; Tests vorhanden.
|
|
||||||
|
|
||||||
### 3.3 File-Sink-Logging ✅
|
|
||||||
- `Program.cs:34-40`: `UseSerilog` + `WriteTo.File("~/.todo-app/logs/worker-.log", rollingInterval: Day, retainedFileCountLimit: 7)`.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. Service-Deployment
|
|
||||||
|
|
||||||
### 4.1 Worker-Autostart via Startup-Shortcut ✅ (ersetzt Scheduled Task + Windows-Service)
|
|
||||||
- Worker als `WinExe` + Serilog-File-Sink + Single-Instance-Mutex.
|
|
||||||
- Autostart über Startup-Ordner-Verknüpfung `ClaudeDo Worker.lnk`, vom Installer via `AutostartShortcut`/`ShortcutFactory` angelegt. Kein Scheduled Task, kein Windows-Service.
|
|
||||||
- `UninstallRunner` löscht die `.lnk` und migriert Legacy-Installs (best-effort Löschen des alten Scheduled-Tasks + Windows-Service).
|
|
||||||
- **Manuelle E2E-Verifikation am Gerät ausstehend** (Logoff/Logon-Autostart, Update-Pfad, Uninstall).
|
|
||||||
|
|
||||||
### 4.2 Pfad-Auflösung absolut ✅
|
|
||||||
- `WorkerConfig.Load` expandiert `~`/`%USERPROFILE%`.
|
|
||||||
|
|
||||||
### 4.3 Installer-Projekt ✅
|
|
||||||
- `ClaudeDo.Installer` (WPF) + `ClaudeDo.Releases` — Self-Update funktioniert (siehe §1.3).
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. Tests / CI
|
|
||||||
|
|
||||||
### 5.1 CI-Pipeline (Gitea Actions) ⛔ DROPPED
|
|
||||||
- Bewusst nicht gebaut: Workflow ist push-to-main ohne PRs, `.gitea/workflows/release.yml` baut bei jedem Push ein Release, und Tests laufen am Ende jeder Entwicklungssession. Eine separate `ci.yml` (Build/Test auf Push/PR) wäre für diesen Workflow reine Dopplung.
|
|
||||||
|
|
||||||
### 5.2 SignalR-Hub-Tests ✅
|
|
||||||
- `Hub/PlanningHubTests.cs`, `AgentSettingsHubTests.cs` decken Hub-Methoden via Fakes ab.
|
|
||||||
- **Optional:** echter Roundtrip mit `WebApplicationFactory<Program>` + `HubConnectionBuilder` — niedriger Mehrwert.
|
|
||||||
|
|
||||||
### 5.3 Smoke gegen echten `claude` ⛔ (kein automatisierter Test — manuell, siehe §1.0 Step 3)
|
|
||||||
- Bewusst **kein** xUnit-Test: ein Test, der das echte `claude`-Binary spawnt, soll nicht in der Suite leben (kein Claude-Aufruf in `dotnet test`). Stattdessen als manueller Verification-Schritt geführt (§1.0 Step 3): Task mit Prompt „ping" laufen lassen → `task_runs`-Row mit `session_id NOT NULL`, `result` non-empty, `output_tokens > 0`.
|
|
||||||
|
|
||||||
### 5.4 ExternalMcpService-Tests ✅
|
|
||||||
- Service exponiert **18 Tools** (war 11): `ListTaskLists`, `ListTasks`, `GetTask`, `AddTask`, `UpdateTask`, `UpdateTaskStatus`, `ReviewTask`, `RunTaskNow`, `CancelTask`, `DeleteTask`, `GetTaskStatusValues`, `GetTaskWorktree`, `GetTaskDiff`, `MergeTask`, `ListWorktrees`, `CleanupTaskWorktree`, `GetDailyPrepCandidates`, `SetMyDay`.
|
|
||||||
- `ExternalMcpServiceTests.cs` hat jetzt 26 Tests (war 14): die zuvor ungetesteten Worktree/Git-Tools (`GetTaskWorktree`, `GetTaskDiff`, `MergeTask`, `ListWorktrees`, `CleanupTaskWorktree`) haben je Error-Pfad + git-gestützten Happy-Path (skippen wenn git fehlt). Plus 4 Sibling-Dateien (`ConfigMcpToolsTests`, `LifecycleMcpToolsTests`, `ListMcpToolsTests`, `RunHistoryMcpToolsTests`).
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 6. Dokumentation
|
|
||||||
|
|
||||||
### 6.1 README.md ✅
|
|
||||||
- Existiert mit Inhalt (Projektbeschreibung, Architektur, Zwei-Prozess-SignalR-Modell).
|
|
||||||
|
|
||||||
### 6.2 docs/architecture.md ⛔ (bewusst nicht ausgegliedert)
|
|
||||||
- Entscheidung 2026-06-04: Die per-Projekt `CLAUDE.md`-Dateien sind bereits die lebende Architektur-Doku (detailliert + aktuell). Ein separates `architecture.md` würde duplizieren und veralten. Kein Mehrwert für ein Solo-Projekt.
|
|
||||||
|
|
||||||
### 6.3 ADRs ⛔ (bewusst nicht angelegt)
|
|
||||||
- Entscheidung 2026-06-04: ADRs lohnen sich primär für Teams, die das „Warum" früherer Entscheidungen rekonstruieren müssen. Solo-Projekt, Entscheidungen sind dem Autor präsent — nicht den Churn wert.
|
|
||||||
|
|
||||||
### 6.4 Mailbox-Proposal ✅ GEPARKT (2026-06-04)
|
|
||||||
- Entscheidung getroffen: **parken, nicht bauen.** Das generische Claude-Mailbox-Plugin (`mcp__mailbox__*`) deckt den Cross-Session-Bedarf bereits ab; die ClaudeDo-interne Integration wäre ein großer Build für marginalen Mehrwert. `docs/mailbox-proposal.md` trägt jetzt einen `Status: PARKED`-Header mit Begründung; Proposal bleibt als Referenz erhalten.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 7. Erledigt seit dem letzten Backlog (Beweis-geführt)
|
|
||||||
|
|
||||||
Diese Punkte standen 2026-04-30 noch als offen/partial und sind verifiziert fertig:
|
|
||||||
|
|
||||||
| Item | Beleg |
|
|
||||||
|---|---|
|
|
||||||
| Folder-Picker (Working Directory) | `ListSettingsModalView.axaml.cs:73` `OpenFolderPickerAsync` |
|
|
||||||
| Delete-Confirmation (Listen + Tasks) | `ConfirmAsync(...)` in `ListSettingsModalViewModel.cs:98`, `DetailsIslandViewModel.cs:939`, `TasksIslandViewModel.cs:785` |
|
|
||||||
| Live-Log Auto-Scroll | `SessionTerminalView.axaml.cs:45` `ScrollToEnd()` |
|
|
||||||
| Task-Level Diff-Viewer | `DiffModalView` via `DetailsIslandViewModel.cs:845`; kein `cmd /k git diff` mehr |
|
|
||||||
| File-Sink-Logging | `Program.cs:34` Serilog |
|
|
||||||
| README.md | vorhanden |
|
|
||||||
| `.gitattributes` | vorhanden, `* text=auto eol=lf` |
|
|
||||||
| `WorkerHub.GetActive` → `ActiveTaskDto` | `WorkerHub.cs:21` Record statt anonymem Typ |
|
|
||||||
| TODO in `DetailsIslandViewModel` (SendPromptAsync) | entfernt — kein TODO mehr in der Datei |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 8. Fallengelassen / Obsolet
|
|
||||||
|
|
||||||
| Item | Begründung |
|
|
||||||
|---|---|
|
|
||||||
| ⛔ Tag-Negation / Exclusion (alt §3.4) | Tag-System wurde entfernt — `TaskEntity` hat keine `Tags`-Property mehr, Queue-Picker filtert nicht mehr nach Tags. |
|
|
||||||
| ⛔ Tag Multi-Select Control (alt IP-4) | Dito — kein Tag-Control existiert, kein Bedarf mehr. |
|
|
||||||
| ⛔ Install-Service-Skript (alt §4.3) | App nutzt Startup-Ordner-Shortcut statt Windows-Service → ein Service-Install-Skript ist architektonisch obsolet. |
|
|
||||||
| ⛔ Notes-Mode `lists.kind`-Switch (alt IP-2) | Ursprüngliche Rahmung überholt: Daily-Notes + Notes-Mode in der Details-Island sind separat gebaut; ein List-Kind-Feld auf der Entity ist nicht nötig. |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 9. Bekannte Code-Schulden / Smells
|
|
||||||
|
|
||||||
| Stelle | Issue | Status |
|
|
||||||
|---|---|---|
|
|
||||||
| `TaskRunner` Worktree-vs-Sandbox-Branch | In `PrepareRunDirectoryAsync` ausgelagert (kleiner Helper, kein Strategy-Pattern — bei 2 Pfaden Over-Engineering). `RunAsync` liest jetzt linear. | ✅ |
|
|
||||||
| `App.Services` statischer ServiceProvider | Entfernt: `App` bekommt den Provider per Constructor-Injection über `AppBuilder.Configure(() => new App(services))`; parameterloser Ctor + `BuildAvaloniaApp()` bleiben für den Designer. **UI-Start manuell smoke-testen** (kein headless-Lauf möglich). | ✅ |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 10. Empfohlene Reihenfolge
|
|
||||||
|
|
||||||
**Block 1 — Kernpipeline beweisen** (kein neuer Code, nur Beweis): §1.0 Steps 3–7 manuell durchspielen. Das ist das größte ungedeckte Risiko.
|
|
||||||
|
|
||||||
**Block 2 — Neue Features verifizieren:** §1.4 Weekly-Report, §1.5 Daily-Prep, dazu §1.1/§1.2 Walkthroughs.
|
|
||||||
|
|
||||||
**Block 3 — Robustheit & Sicherheitsnetz:** §5.3 Real-`claude`-Smoke-Test. (§3.1 Worktree-Cleanup und §5.4 ExternalMcp-Tests sind erledigt; §5.1 CI fallengelassen.)
|
|
||||||
|
|
||||||
**Block 4 — Doku & Aufräumen:** §6.2 architecture.md (oder bewusst verwerfen), §6.3 ADRs, §6.4 Mailbox-Entscheidung, §2.1 Status-Bar-Risiko prüfen, §9 Smells.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user