Portierung der beiden fehlenden Grundbausteine aus PolytraderSharp (voller Ausbau). Core S-0 (Datenfundament fuer Analyse/Forensik): - core_decision_journal + core_order_events (+ ReasonCode/Decision/OrderEvent-Enums), IDecisionJournal/IOrderEventLog mit fehlertoleranten EF-Impls (Handel bricht nie). - SignalId-Durchreichung TradeSignal -> ExecutionService -> core_trade_history; ExecutionService schreibt an jeder Verzweigung Journal/Order-Events. - JSONL-Log-Sink (LogJson + Dual-Sink), pure Analytik: RealizedPnlEngine (FIFO), TradeAnalytics, DossierBuilder. Migration AddAnalysisFoundation. Accounting-Modul (acc_): unabhaengiger IBKR-Kontoauszug (Activity Flex Query) hinter Interfaces mit Offline-Null-Stubs -> append-only Ledger + Periodenabrechnung/BWA + FX (USD/EUR) + CSV/PDF (PDFsharp/MigraDoc). Steuerschicht bewusst offen (Platzhalter-Tab). Kein Handel. Migration InitialAccounting. Supervisor-Modul (sup_): read-only OpenRouter-Agent (Function-Calling-Loop) + read-only Tool-Registry (8 Tools) + Profile + Dossier-Browser + Counterfactual-Job (Stub) + Tagesbericht/MCP-Light (opt-in). Migration InitialSupervisor. Verdrahtung: Program.cs (beide Module + Icons), slnx/App/Tests-Referenzen, provision-db.ps1, AppSettings-Sektionen, docs/konzepte, README. Tests: 79 -> 117 gruen (FIFO/KPIs/Dossier/JSONL, Classifier/Engine/FX/Idempotenz, OpenRouter/Registry/Agent/MCP, STA-Konstruktion beider neuen Fenster). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.1 KiB
Konzept: Modul „Supervisor" (KI-gestützte Handels-Analyse & Forensik)
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) mitReasonCode(Enum, als String persistiert), SignalId, Kontext-JSON und Freitext. Geschrieben vomExecutionService.core_order_events— Order-Lifecycle (Placed/Filled/PlaceFailed/…): Preise, Menge, Broker-Antwort.SignalIdwird durchTradeSignal → ExecutionService → Portfolio → core_trade_historydurchgereicht → 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 hinterICounterfactualResolutionSourcemit Null-Stub (Zielland-Arbeit).DailyReportService— täglicher Bericht, opt-in viaIBKRTRADER_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_KEYoder gitignorierteopenrouter.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.