From eac47369f023b4bc6777410d1e53bb4b0d58a6b5 Mon Sep 17 00:00:00 2001 From: Richard Date: Thu, 16 Jul 2026 10:36:09 +0200 Subject: [PATCH] Docs: Supervisor-Konzept erweitert (Predictalytics-Quelle, Profil-Team, JSONL+Log-Viewer) Co-Authored-By: Claude Opus 4.8 --- docs/konzepte/KONZEPT-Modul-Supervisor.md | 55 ++++++++++++++++++++--- 1 file changed, 49 insertions(+), 6 deletions(-) diff --git a/docs/konzepte/KONZEPT-Modul-Supervisor.md b/docs/konzepte/KONZEPT-Modul-Supervisor.md index 25c9174..643f4c6 100644 --- a/docs/konzepte/KONZEPT-Modul-Supervisor.md +++ b/docs/konzepte/KONZEPT-Modul-Supervisor.md @@ -51,7 +51,14 @@ - `core_order_events`: Order-Lifecycle (Placed/Rejected/Cancelled/LadderStep/Filled) mit Preisen, CLOB-Response, `SignalId`. - `SignalId` (GUID) im `CopySignal`/RF-Flow erzeugen und bis in `ClosedTrade`/`TradeRecord` durchreichen. -- JSONL-Log-Sink parallel zum Text-Log (TerminalLogger erweitert; CorrelationId=SignalId wo vorhanden). +- **JSONL-Log-Sink** (TerminalLogger erweitert): eine JSON-Zeile je Event (`ts`, `level`, `source`, + `correlationId`, `message`, optional `data`). JSONL statt JSON-Array: append-fähig, streambar, + zeilenweise filterbar — das KI-freundliche UND effiziente Format. Übergang: zunächst Dual-Sink + (Text + JSONL), Text-Sink später abschaltbar, sobald der Log Viewer etabliert ist. +- **Log Viewer im Terminal-Fenster** (zweiter Tab neben der Live-Anzeige): lädt die JSONL-Dateien und + bereitet sie menschenlesbar auf — Filter nach Datum/Level/Quelle/Text und **CorrelationId + („zeig mir alles zu diesem Signal")**; Klick auf eine SignalId springt zur kompletten Kette. Damit + ist das effiziente Speicherformat für Menschen genauso zugänglich wie heute der Freitext. **S-1: Dossier-Generator (pur, testbar):** Für einen Trade / ein abgelehntes Signal alles zusammensetzen: Signal → Journal-Einträge → Order-Events → Fill/Leiter-Verlauf → ClosedTrade/RF-Position → @@ -78,6 +85,13 @@ Abhängigkeit machbar (HttpClient + System.Text.Json). Der Agent bekommt: - `get_ledger(account, zeitraum)` + `get_ledger_diff(...)` — Plattform vs. eigene DB (Accounting) - `get_kpis(scope)` — TradeAnalytics - `get_architecture_context()` — das Kontext-Dokument + - **Predictalytics-Tools** (`query_predictalytics_*`): historische Trade-Daten fremder Trader, + Master-Historien, Markt-Statistiken aus unserem Predictalytics-Tool (dessen API wir ohnehin + integrieren). Analytisch besonders wertvoll: **„schlechtes Signal" von „schlechter Ausführung" + trennen** — z. B. Master-Fill vs. unser Fill (Latenzkosten) oder unser Ergebnis vs. das anderer + Trader im selben Markt (Benchmark). Architektur: `IPredictalyticsClient` im **Core** (auch + Trading-Module nutzen ihn später, z. B. Master-Auswahl/AI-Rating); der Supervisor konsumiert ihn + nur read-only. Eigener Egress-Eintrag (unsere eigene API, aber dokumentiert). **Hart: KEIN Tool kann handeln, canceln oder schreiben.** Der Supervisor ist Beobachter. **Analyse-Modi:** @@ -119,6 +133,26 @@ Warum Modul statt Core-Fenster: passt ins etablierte Muster (eigene Persistenz ` `sup_conversations`, eigene Settings, eigener Launcher-Button), hält die KI-Abhängigkeit aus dem Core heraus und ist einzeln abschaltbar. +## 4a. Supervisor-„Team": Profile statt getrennter Agenten + +Die Idee (technischer Supervisor + je Modul ein Strategie-Supervisor) ist richtig — aber als +**Profile über EINER gemeinsamen Infrastruktur**, nicht als getrennte Agenten/Fenster/Prozesse: + +| Profil | Fokus | Tools (Subset) | Kontext | +|---|---|---|---| +| **Technik-Supervisor** | Fehler-/Warning-Muster in Logs, Job-Health, API-Ausfälle, Latenzen, Reconciliation-Differenzen — KEINE Strategie-Meinung | read_logs, get_ledger_diff, query_order_events | Architektur-Doku | +| **CopyTrading-Supervisor** | Master-Qualität vs. Ausführungsqualität, Leiter-Verhalten, Reject-Muster | query_decisions, get_dossier, Predictalytics (Master-Historie) | + CopyTrading-Kontextabschnitt | +| **ResolutionFarming-Supervisor** | Kalibrierung (Winrate je Preisband vs. Erwartung), Cluster-Risiken, Scanner-Rejects | query_decisions, rf-Kontext, get_kpis | + RF-Kontextabschnitt | +| *(später)* **Chef-Supervisor** | fasst die Einzelberichte zusammen | die Berichte der anderen | Gesamtsicht | + +Ein Profil = System-Prompt + Tool-Subset + Zeitplan + Modellwahl. Gleiche Registry, gleicher Agent- +Runner, gleiche UI (Profil-Auswahl im Analyse-Tab; Berichte je Profil). Modul-Wissen kommt über die +`IAnalysisContextSource`-Registrierung der Module — ein neues Modul bringt seinen Supervisor-Kontext +selbst mit, ohne dass der Supervisor es kennt. + +**Bewusst NICHT (v1):** Agent-zu-Agent-Orchestrierung/Diskussionen — teuer, schwer debugbar, wenig +Mehrwert. Profile laufen unabhängig (on-demand oder per Zeitplan); der „Chef" liest nur deren Berichte. + ## 5. API-Key: ja, getrennt **Separater OpenRouter-Key für den Supervisor** (getrennt von künftigen Trading-Modul-Keys wie dem @@ -145,12 +179,14 @@ Klartext in DB/Config. ## 7. Phasen - **S-0 Datenfundament (Core):** `core_decision_journal` + ReasonCode-Enum + `SignalId`-Durchreichung + - `core_order_events` + JSONL-Sink. Engine/Leiter/Monitor/RF schreiben strukturiert. Pure Logik + - Tests; Migrationen offline. **Sofortnutzen ohne KI** (abfragbare Rejects, Zielland-Debugging). + `core_order_events` + JSONL-Sink + **Log Viewer im Terminal**. Engine/Leiter/Monitor/RF schreiben + strukturiert. Pure Logik + Tests; Migrationen offline. **Sofortnutzen ohne KI** (abfragbare Rejects, + Log-Forensik per CorrelationId, Zielland-Debugging). - **S-1 Dossier:** Generator (pur, testbar) + Dossier-Browser-UI (Modul-Skelett Supervisor). -- **S-2 Agent:** OpenRouter-Client (Core oder Modul), Tool-Registry (read-only), Analyse-Chat-Tab, - Architektur-Kontext-Dokument. -- **S-3 Berichte:** Batch-Analysen, Counterfactual-Report, täglicher Threema-Bericht. +- **S-2 Agent:** OpenRouter-Client, Tool-Registry (read-only, transport-agnostisch), Analyse-Chat-Tab + mit **Profil-Auswahl** (zunächst 1 Profil „Allgemein"), Architektur-Kontext-Dokument. +- **S-3 Team & Berichte:** Technik-/Modul-Supervisor-Profile, Batch-Analysen, Counterfactual-Report, + täglicher Threema-Bericht; `IPredictalyticsClient` (Core) + Predictalytics-Tools. - **S-4 MCP-Light (optional):** Tool-Registry zusätzlich als lokaler MCP-Server für externe Clients. ## 8. Offene Entscheidungen (Richard) @@ -161,3 +197,10 @@ Klartext in DB/Config. (Resolution-Nachverfolgung abgelehnter Signale) oder später? 3. Modellwahl-Defaults (günstig vs. stark) und Tokenbudget/Monat für den Supervisor. 4. Tagesbericht via Threema gewünscht (S-3)? +5. Text-Log-Sink nach Etablierung des Log Viewers abschalten (nur noch JSONL) oder dauerhaft dual? +6. Predictalytics-API: Auth/Key-Mechanik und welche Endpoints der Supervisor bekommt (read-only-Subset). + +## Ergänzungen Richard (2026-07-16, eingearbeitet) +- ✅ Predictalytics-Daten als Analyse-Quelle (§2, `IPredictalyticsClient` im Core, S-3). +- ✅ Supervisor-„Team" — als Profile über einer Infrastruktur statt getrennter Agenten (§4a). +- ✅ Reasoning/Logs KI-freundlich als JSONL + menschenlesbarer Log Viewer im Terminal (§1, S-0).