Docs: Supervisor-Konzept erweitert (Predictalytics-Quelle, Profil-Team, JSONL+Log-Viewer)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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).