Der Core kennt jetzt die handelbaren Verfallstage und Strikes eines Basiswerts
(reqSecDefOptParams) und die Bewertungsgroessen eines Kontrakts
(tickOptionComputation). Damit steht der letzte Baustein, den eine
Wheel-Strategie braucht, um ueberhaupt einen Kontrakt auswaehlen zu koennen.
OptionChain ist bewusst nur eine Liste und trifft keine Marktentscheidung. Die
Auswahlhilfen daran sind reine Rechnung - "der Verfall bei etwa 35 Tagen" ist
eine Kalenderfrage, "welches Delta will ich" nicht. Letzteres gehoert ins Modul.
Zwei Eigenheiten der TWS-API sind beim Messen aufgefallen und haben je einen
Fehler gekostet:
1. Greeks kommen NICHT im Snapshot. reqMktData mit snapshot=true liefert Geld-,
Brief- und letzten Kurs, aber keine tickOptionComputation. Es braucht ein Abo,
das beim ersten Modell-Tick wieder abbestellt wird.
2. TWS meldet je Basiswert MEHRERE Serien. Fuer AAPL kamen "AAPL" und "2AAPL" -
letztere eine Sonderserie mit eigenen Ausuebungspreisen. Der erstbeste Satz
war die falsche: Strike 320 in "2AAPL" gibt es nicht, TWS antwortete mit 200
("No security definition has been found"). Die Auswahl nimmt jetzt SMART vor
allen anderen Boersen und darin die Handelsklasse, die dem Symbol entspricht.
Massgeblich ist ausserdem allein das Modell-Feld (13 bzw. 83 bei verzoegerten
Daten). Die Varianten zu Geld-, Brief- und letztem Kurs fehlen bei illiquiden
Serien und lieferten sonst ein Delta aus einem Kurs, den niemand stellt. Fehlende
Werte meldet TWS als double.MaxValue oder -1; sie werden zu null, nicht zu 0 -
ein Delta von 0 hiesse "reagiert nicht auf den Basiswert".
Gemessen gegen das Paper-Gateway:
AAPL (USD, SMART/AAPL, x100): 22 Verfallstage, 123 Strikes
Auswahl wie beim Wheel: AAPL|20261009|P|320 (Kurs 320.01, 34 Tage Laufzeit)
Deckungsbedarf je Kontrakt: 32.000,00 USD
IV 24.5 %, Delta -0.471, Gamma 0.0169, Vega 0.392, Theta -0.123 (verzoegert)
Der Schalter --option-chain SYMBOL [--currency X] faehrt genau diesen Ablauf und
bleibt als Pruefwerkzeug. 414 Tests gruen.
Behebt #299.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
IBKRTrader
Modulares C#-Trading-Framework für Interactive-Brokers-Aktien. Harter Core + unabhängige Strategie-Module + Launcher, der die Fenster der Module öffnet. Konzept nach dem Vorbild von PolytraderSharp (nur IBKR statt Polymarket).
Läuft auf Windows und Linux – wahlweise mit Oberfläche (Avalonia) oder kopflos als Dienst.
Architektur (Kurzform)
src/IBKRTrader.App Oberfläche (Avalonia, plattformneutral)
src/IBKRTrader.Daemon kopfloser Dienst (systemd) – dieselbe Anwendung ohne Fenster
src/IBKRTrader.Hosting Host-Zusammenstellung, von beiden Einstiegspunkten geteilt
src/IBKRTrader.Core Contracts, EF-Persistenz, Trading-Kern, Worker, Security
src/IBKRTrader.Modules.* je Modul ein eigenes Projekt (referenziert nur Core)
tests/IBKRTrader.Tests xUnit (Unit + EF-InMemory)
Alle Projekte sind net10.0 ohne Plattformbindung. Der UI-Contract im Core ist toolkit-neutral
(Func<object> CreateView, IconKey statt Bild), damit Core und Module auch kopflos laufen –
die Fenster registriert die Shell zentral in Shell/ModuleViews.cs.
- Generic Host (
Host.CreateDefaultBuilder), Worker/Services alsIHostedService. - Module über
IModule(RegisterServices/RegisterUi/Start/Stop); UI überIModuleUiHost/ModuleView. - Persistenz: EF Core (Pomelo/MariaDB), Migrationen extern angewendet (nicht zur Laufzeit).
- Trading-Kern:
IExecutionService(Signal→Risiko→Order→Buchung),IRiskService,IPortfolioService, Broker hinterIBrokerClient:NullBrokerClient(Default, handelt nie) oderIbkrBrokerClientüber die TWS API – aktivierbar mitIBKR.UseTwsApi. - Analyse-Datenfundament:
core_decision_journal(jede Entscheidung + ReasonCode),core_order_events,SignalId-Korrelation, JSONL-Log-Sink (Logs/{yyyy-MM-dd}.jsonl) – speist den Supervisor. - Details: docs/ARCHITECTURE.md · Offener Stand: docs/ROADMAP.md.
Build & Test
dotnet build IBKRTrader.slnx
dotnet test IBKRTrader.slnx
Anwendung starten:
dotnet run --project src/IBKRTrader.App
Prüfläufe – beide ohne Anzeigegerät und ohne laufende Dienste, also CI-tauglich:
dotnet run --project src/IBKRTrader.App -- --smoke-ui
dotnet run --project src/IBKRTrader.Daemon -- --check
Kopflos auf Linux (systemd): siehe deploy/README.md.
Konfiguration
appsettings.Local.json(gitignored) hält den DB-Connection-String (Database:MySqlConnectionString).settings.json(gitignored) – App-Settings (IBKR-Ports, Logging, Worker, Trading).- Optional
IBKRTRADER_MASTER_KEYbzw.master.keyfür at-rest-Verschlüsselung (AES-256-GCM). - Supervisor (optional):
IBKRTRADER_OPENROUTER_KEYbzw.openrouter.key(KI-Analyse), sowie die Opt-insIBKRTRADER_SUPERVISOR_DAILY(Tagesbericht, Stunde 0–23) undIBKRTRADER_MCP_PORT(MCP-Light, nur 127.0.0.1).
Datenbank aufsetzen
Schema wird per EF-Migrationen extern angewendet – siehe scripts/README.md:
mysql ... < scripts/drop-app-tables.sql # nur falls Alt-Tabellen existieren
powershell -File scripts/provision-db.ps1
Module
- CongressTrading – kopiert US-Kongress-Trades (capitoltrades.com) →
TradeSignal→ ExecutionService. - Accounting – von der Trading-DB unabhängige Buchführung aus dem IBKR-Kontoauszug (Activity Flex
Query) → append-only Ledger
acc_*, Periodenabrechnung/BWA, FX (USD/EUR), CSV/PDF-Export. Kein Handel. Live-Abruf hinter Interfaces (Offline-Null-Stubs); Steuerschicht bewusst offen. Konzept: docs/archiv/KONZEPT-Modul-Accounting.md. - Supervisor – read-only KI-Analyse/Forensik über alle Module (OpenRouter-Agent + read-only
Tool-Registry, Dossier-Browser, optional MCP-Light). Stützt sich auf das Core-Datenfundament
(
core_decision_journal,core_order_events,SignalId, JSONL-Logs). Konzept: docs/archiv/KONZEPT-Modul-Supervisor.md.
Status / Nächstes
➡️ Was noch zu tun ist, steht vollständig in der Roadmap. Sie ist seit dem 2026-08-23 das einzige Dokument, das den offenen Stand führt – einschließlich der Ideen, die wir bewusst zurückstellen (🧊) und derer, die wir geprüft und verworfen haben (❌). Die früheren Konzepte liegen unverändert unter docs/archiv/ und tragen die Herleitung.
Kurzfassung:
- Gebaut: R1–R7 (Kurskorrektur auf das PolytraderSharp-Konzept), Accounting und Supervisor inkl. Core-Datenfundament S-0, Linux-Portierung L0–L6, Deploymentcenter-Anbindung.
- Es hat noch nie eine echte Order gegeben. Der TWS-Adapter ist gegen das Paper-Konto
verifiziert (Verbindung, Konto, Kurse, Optionskette, Greeks, What-If-Order), aber
PlaceOrderAsyncmit echter Ausführung steht aus – daran hängt alles Weitere. - Sicherheit: DB-Passwort rotieren (liegt in der Git-Historie, Commit
ebeb035).
Sicherheitshinweis
Automatisierter Handel ist riskant. Standardmäßig handelt die App nicht: der Broker-Adapter ist
über IBKR.UseTwsApi abgeschaltet, und selbst mit aktivem Adapter platziert der ExecutionService
ohne globales TradingEnabled=true keine Order. Beide Schalter sind bewusst getrennt. Echter Handel
erst nach Verifikation gegen den Paper-Account.