Fork auf Orchestrator V2 portieren #65

Upstream arbeitet seit Mai an Orchestrator V2 (pingdotgg#2829, 1613 Dateien, +342k/-171k, 100 Commits, Stand 26.09.2026 nicht gemerged, gegen main konfliktbehaftet, kein ETA). Wenn das gemerged wird, scheitert der morgendliche Upstream-Sync und der Fork muss von Hand nachgezogen werden.

Analyse vom 26.09.2026 (73 der 250 Fork-Dateien werden von V2 angefasst):

Übersteht unverändert (eigene Ordner, keine Orchestrierungs-Abhängigkeiten): agentStage, gitGraph, split/popout, esveo-Branding/Themes, forkUpdate, Desktop-Update-Slots, Paste-Fixes.

Wird durch V2 überflüssig: Restart-Continuation/BackgroundWorkLedger (V2 hat RestartContinuation.ts + ThreadBackgroundLiveness.ts), settle_thread (V2: ThreadSettlementService + t3_thread_organize), Sidebar-Gruppierung nach Projekt (V2 hat sie).

Muss auf V2-Primitiven neu gebaut werden: subagentChat (importiert ClaudeAdapter, ActivityPayloadProjection, ProviderService – alle gelöscht; AgentsPanel gelöscht, Subagent-Threads haben in V2 keinen Composer), threadOrchestration-Reactor (Reactor-Schicht ersetzt durch EffectOutbox/EffectWorker), threadUsage (UsageService umgebaut), Fork-Edits in ChatView/MessagesTimeline/ChatComposer (V2 schreibt diese Dateien fast komplett neu).

Cross-Project bleibt Fork-Alleinstellungsmerkmal: V2s t3_thread_launch erbt Projekt, Branch und Worktree zwingend vom Aufrufer, andere Projekte sind nicht erreichbar. Muss als Erweiterung von V2s toolkits/project neu implementiert werden, nicht aus dem Fork-Toolkit übernommen.

Empfehlung: nicht vor dem Merge portieren, aber ab jetzt keinen neuen Fork-Code mehr schreiben, der in V1-Interna greift (Reactors, ProviderService, ActivityPayloadProjection, threadReducer).