> ### 📦 Archiviert am 2026-08-23 > Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der > [Roadmap](../ROADMAP.md) (Bahn „Supervisor") – dort und nur dort wird der Stand nachgeführt. > > Es bleibt erhalten, weil es S-0 bis S-4 im Einzelnen beschreibt, samt Tool-Registry und den > Sicherheitsgrenzen des Agenten. Zum Nachschlagen also weiterhin richtig, > als Aufgabenliste nicht mehr. --- # Konzept: Modul „Supervisor" (KI-gestützte Handels-Analyse & Forensik) > **UMGESETZT (S-0 bis S-4).** Datenfundament im Core (`core_decision_journal`, `core_order_events`, > durchgereichte `SignalId`, JSONL-Log-Sink), `DossierService`/`DossierBuilder`, der > OpenRouter-Agent mit read-only Tool-Registry und Profilen, `sup_reports`, `CounterfactualJob`, > `DailyReportService` und der MCP-Server (`McpLightServer`, `McpJsonRpc`). > > **Weiterhin offen** sind die beiden Punkte am Ende dieses Dokuments: die Counterfactual-Kursauflösung > (Interface + Stub vorhanden) und der externe Versand des Tagesberichts. > Stand: 2026-07-30 > Ziel: ALLES, was IBKRTrader getan (und bewusst NICHT getan) hat, detailliert analysierbar machen — > Entscheidungen, Orders, Trades und Logs — und die Analyse durch ein KI-Modell (OpenRouter) durchführen > lassen: Warum hat ein Trade funktioniert? Warum nicht? Woran lag es? > **Leitidee: Erst das Datenfundament, dann die KI.** Ein Modell kann nur erklären, was aufgezeichnet wurde. > > Vorbild: gleichnamiges Modul in PolytraderSharp. Hier auf IBKR übertragen; strikt read-only. ## S-0 Datenfundament (Core — umgesetzt) Grundlage jeder guten Analyse, sofort auch OHNE KI nützlich (abfragbare Rejects, Log-Forensik): - **`core_decision_journal`** — JEDE Entscheidung (Executed/Rejected/Skipped/Failed) mit `ReasonCode` (Enum, als String persistiert), SignalId, Kontext-JSON und Freitext. Geschrieben vom `ExecutionService`. - **`core_order_events`** — Order-Lifecycle (Placed/Filled/PlaceFailed/…): Preise, Menge, Broker-Antwort. - **`SignalId`** wird durch `TradeSignal → ExecutionService → Portfolio → core_trade_history` durchgereicht → verbindet Signal → Entscheidung(en) → Order(s) → Trade. - **JSONL-Log-Sink** — zusätzlich zur Textdatei eine Zeile je Event nach `Logs/{yyyy-MM-dd}.jsonl` (`ts, level, source, cid=SignalId, message`); zeilenweise filter-/parsebar. - Pure Core-Analytik: `RealizedPnlEngine` (FIFO), `TradeAnalytics` (KPIs), `DossierBuilder`. - Schreibpfade sind **fehlertolerant** — ein Journal-/DB-Fehler bricht den Handel nie. ## S-1 Dossier `DossierService` setzt zu einer SignalId Entscheidungen + Order-Events + Trades + JSONL-Log-Auszug zusammen; `DossierBuilder` (Core, pur) rendert JSON (fürs Modell) und Markdown (für Menschen). ## S-2 Agent + Tool-Registry - In-Prozess-Function-Calling-Loop gegen **OpenRouter** (`OpenRouterClient`, OpenAI-kompatibel). - **Read-only-Tools** (`SupervisorTools`): `query_decisions`, `query_order_events`, `query_trades`, `get_dossier`, `read_logs`, `get_kpis`, `get_architecture_context`, `query_counterfactuals`. **Kein Tool kann handeln, canceln oder schreiben.** - **Profile** (`SupervisorProfiles`): Allgemein / Technik / CongressTrading = System-Prompt + Tool-Subset über EINER Infrastruktur (bewusst keine Agent-zu-Agent-Orchestrierung). - Harte Iterationsgrenze gegen Endlosschleifen; jeder Tool-Aufruf wird in der UI sichtbar geloggt. - System-Kontext: kuratiertes Architektur-/Verhaltensdokument (`ArchitectureContext`, inline versioniert). ## S-3 Berichte & Counterfactual - `sup_reports` — jede Analyse (Frage/Antwort/Profil/Modell/Tool-Aufrufe) → der Supervisor ist selbst auditierbar. - `CounterfactualJob` — „was wäre aus abgelehnten BUYs geworden?" (späterer Kurs vs. Signalpreis). Die Kursauflösung liegt hinter `ICounterfactualResolutionSource` mit **Null-Stub** (Zielland-Arbeit). - `DailyReportService` — täglicher Bericht, **opt-in** via `IBKRTRADER_SUPERVISOR_DAILY` (Stunde 0–23). ## S-4 MCP-Light `McpLightServer` exponiert dieselbe read-only Tool-Registry als lokalen MCP-Endpoint für externe Clients (z. B. Claude Code). **Opt-in** via `IBKRTRADER_MCP_PORT`, bindet nur `127.0.0.1`. Handler `McpJsonRpc` ist pur + unit-getestet (initialize/ping/tools.list/tools.call). ## Architektur & Unterbringung Projekt `src/IBKRTrader.Modules.Supervisor/` als `IModule` (`Name="Supervisor"`, `DbPrefix="sup_"`), referenziert nur den Core. Eigenes Fenster mit Tabs: Analyse (Chat), Dossier-Browser, Berichte, Settings. ## Sicherheit - **OpenRouter = bewusst freigegebener externer Datenempfänger.** Es werden nur Analyse-Daten der Tools gesendet, niemals Secrets/Keys/Connection-Strings. - Separater API-Key (`IBKRTRADER_OPENROUTER_KEY` oder gitignorierte `openrouter.key`), getrennt von künftigen Trading-Keys. - **Read-only by design** — kein Order-/Schreib-Tool. Prompt-Injection über Fremdtexte bleibt auf „falsche Analyse" begrenzt, kann nie handeln. ## Bewusst offen / Zielland-Arbeit - Counterfactual-Kursauflösung für Aktien (späterer Kurs) — Interface + Stub vorhanden. - Externer Versand des Tagesberichts (z. B. Threema) — heute nur Persistenz/Log.