Files
IBKRTrader/docs/konzepte/KONZEPT-Modul-Supervisor.md
T
RichardandClaude Opus 5 e1546bd1b1 Fruehjahrsputz: toter Code, ungenutzte Symbole, Dokumentenstand
Alles Entfernte war nachweislich ohne Aufrufer. Build, 198/198 Tests, Smoke-UI
und Daemon-Prueflauf sind vor und nach jedem Schritt gruen.

Code:
  - AIModelService: Platzhalter, der immer 0.5 lieferte. Im DI registriert,
    aber nie irgendwo injiziert. Ordner Core/AI faellt mit weg.
  - CtApiWrapper + CtMeta: JSON-Modelle fuer einen {data,meta}-Umschlag, den
    CapitolTrades nicht mehr liefert. Der Scraper deserialisiert seit laengerem
    direkt List<CtTrade>.
  - IBKRGatewayService: DisconnectAsync, InitBrokerageSessionAsync und
    SearchStocksBySymbolAsync. Der Dienst selbst bleibt - er versorgt
    Instrument-Sync, Kurshistorie und den Watchdog-Heartbeat.
  - Je eine Methode ohne Aufrufer: BudgetService.GetAvailableBudgetAsync,
    TradeHistoryService.GetRecentTradesAsync, CongressRepository.
    GetAllTradeIdsAsync und .ResetHistoryImportAsync, IbkrMapping.DefaultPortFor,
    SecretProtection.IsEncrypted.
  - CongressRepository bekam damit einen LoggingService injiziert, den es nicht
    mehr benutzt - Abhaengigkeit samt Konstruktorparameter raus.

Ressourcen:
  - 17 Symbole der WinForms-Oberflaeche entfernt. Das Wildcard-Muster im csproj
    nahm sie in die Binaerdatei auf, ViewIcons.cs bildet aber nur sieben
    Schluessel ab. Resources/ enthaelt jetzt genau die sieben.

NuGet-Allowlist:
  - Dapper und HtmlAgilityPack sind seit R3 bzw. R1 aus dem Projekt raus,
    Microsoft.WindowsDesktop.* seit L5. Muster entfernt.
  - MySqlConnector und Newtonsoft.Json stehen NUR transitiv in den
    Projektdateien und wurden zuerst mitentfernt - ein Restore in einen leeren
    Paket-Ordner scheiterte darauf mit NU1100. Beide wieder aufgenommen, jetzt
    mit Begruendung, damit der naechste Aufraeumlauf nicht dieselbe Falle tritt.

Dokumente an den tatsaechlichen Stand angeglichen:
  - ARCHITECTURE: R2 fuehrte die Umstellung auf IHostedService als offen, obwohl
    R4 sie erledigt hat. L6 und die Deploymentcenter-Phase fehlten ganz.
  - DC-Konzept: Schritte 0-8 standen auf "dieser Durchlauf", sind aber umgesetzt.
    Jetzt je Schritt der wirkliche Stand - inklusive der beiden Halbfertigen:
    Update-PRUEFUNG laeuft, das Anwenden hat keinen Aufrufer; die
    Release-Pipeline steht, ist aber nie gelaufen. P5 ist eingetreten.
  - Accounting und Supervisor trugen keinen Umsetzungsvermerk, obwohl beide
    Module gebaut sind. Vermerk nach dem Muster des Linux-Konzepts ergaenzt,
    mit dem, was jeweils offen bleibt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 12:25:03 +02:00

4.7 KiB
Raw Blame History

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

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.