docs(planning): spec for ConPTY planning sessions

2026-07-24 12:12:22 +02:00
parent 04044bd115
commit 2612831a5e
1 changed files with 61 additions and 0 deletions
@@ -0,0 +1,61 @@
+# ConPTY Planning Sessions — Design (2026-07-24)
+
+**Task:** `5d627df8` — interaktive Planning-Session über embedded ConPTY statt externem `wt`-Fenster.
+
+## Problem
+Planning-Sessions (`StartPlanningSession`/`ResumePlanningSession`) öffnen heute ein externes
+Windows-Terminal (`WindowsTerminalLauncher` → `wt.exe`). Seit ConPTY existiert (embedded
+claude-TUI im UI-Prozess, Command Center), soll die interaktive Planning-Session denselben
+Weg nutzen: konsistente UX, keine externen Fenster.
+
+## Approved decisions (Brainstorm 2026-07-24)
+- **Env-Isolation:** Prozess-global akzeptiert (Sessions werden sequenziell per Klick geöffnet;
+  jedes claude-Child snapshottet Env beim Spawn). Keine Änderung an `PtyTerminalSession`.
+- **wt-Launcher:** Code bleibt; nur das Routing für Planning wird auf ConPTY umgestellt
+  (kein Rip-out von `LaunchPlanningStart/ResumeAsync`).
+- Planning-Kachel im Command Center (Mission Control), wie andere ConPTY-Sessions.
+  Finalize/Discard/Queue-Plan bleiben unverändert auf den bestehenden Buttons.
+
+## Change map
+
+### Worker
+1. `WindowsTerminalLauncher`: Planning-Start-Args in einen bare Builder
+   `BuildPlanningStartArgs(PlanningSessionStartContext) -> IReadOnlyList<string>` herausziehen
+   (analog `BuildResumeArgs`); `BuildPlanningStartCommand` nutzt ihn weiter (wt unverändert).
+   Resume-Args `BuildPlanningResumeArgs(sessionId) = ["--permission-mode","plan","--resume",id]`
+   (bisher inline in `LaunchPlanningResumeAsync`).
+2. `InteractiveLaunchSpecService`: `BuildPlanningStart(PlanningSessionStartContext) -> LaunchSpec`
+   und `BuildPlanningResume(PlanningSessionResumeContext) -> LaunchSpec` — resolve claude,
+   Args aus (1), Env `MAX_THINKING_TOKENS=20000` + `CLAUDEDO_PLANNING_TOKEN=<token>`
+   (+ `MCP_TOOL_TIMEOUT` wie interaktiv), Cwd = ctx.WorkingDir. Nimmt den Kontext (keine
+   Manager-Kopplung).
+3. Hub: `GetPlanningStartLaunchSpec(taskId) -> LaunchSpec` (ruft `_planning.StartAsync`,
+   broadcastet `TaskUpdated`, baut Spec; bei Fehler discard+rethrow wie heute),
+   `GetPlanningResumeLaunchSpec(taskId) -> LaunchSpec` (ruft `_planning.ResumeAsync`).
+
+### UI
+4. `IWorkerClient`/`WorkerClient`: `GetPlanningStartLaunchSpecAsync`/`GetPlanningResumeLaunchSpecAsync`
+   (mirror `GetInteractiveLaunchSpecAsync`).
+5. `MissionControlViewModel`: `OpenPlanningConPtySessionAsync(taskId, resume)` — dedupt nach
+   TaskId, holt die Planning-Spec, baut `TerminalLaunchDescriptor` → `ConPtyPaneViewModel`
+   (Titel „<task> (Planning)").
+6. `TasksIslandViewModel`: `OpenPlanningSessionAsync`/`ResumePlanningSessionAsync` (Resume-Zweig
+   der `UnfinishedPlanningModal`) öffnen die Planning-ConPTY-Kachel via neuem Event
+   `OpenPlanningConPtyRequested(taskId, resume)`, statt `StartPlanningSessionAsync`/wt.
+   `IslandsShellViewModel` verdrahtet das Event → `OpenMissionControl()` +
+   `MissionControl.OpenPlanningConPtySessionAsync`.
+
+### #12 (Nebenbefund)
+MCP-Permission-Prompt trotz `--allowedTools "mcp__claudedo__*"`: im interaktiven ConPTY vom
+User bestätigbar (kein Blocker wie headless). Beim Testen prüfen, ob der Glob den Prompt in
+der aktuellen CLI unterdrückt; falls nicht, allowedTools/`--permission-mode`-Kombi nachziehen.
+
+## Out of scope
+- Entfernen des wt-Codes / `ResumeTaskInTerminal`.
+- Per-Child-Env-Isolation in `PtyTerminalSession`.
+- Änderungen an Finalize/Discard/Queue-Plan-Lifecycle.
+
+## Verification
+- Build Worker + App (`-c Release`), Worker.Tests + Ui.Tests grün.
+- Visual (User): Planning-Start öffnet Command-Center-Kachel mit claude-TUI im Plan-Modus;
+  create_child_task erzeugt Draft-Kinder live; Resume greift die Session; kein wt-Fenster.