Bindet Lizenz, Watchdog, Fehler-Stream, UpdateService und Erstinstallation an
das Deploymentcenter 2.5.1 an. Einbauort ist IBKRTrader.Hosting - den Host
teilen sich Shell und Daemon.
Projekt-Befunde aus dem Konzept vorab bereinigt:
P1 Echte DB-Zugangsdaten als Vorgabewerte in AppSettings -> Platzhalter.
Das alte Passwort steht weiterhin in der Git-Historie und ist als
kompromittiert zu behandeln (Rotation ist Nutzer-Aktion).
P2 AppPaths fiel unter Windows auf /etc/ibkrtrader zurueck, was .NET zu
C:\etc\ibkrtrader aufloest. Jetzt %ProgramData%\IBKRTrader.
P3 Globale Ausnahmebehandler (AppDomain / TaskScheduler) - vorher gab es
keinen Logeintrag, wenn der Prozess unbehandelt wegbrach.
P4 Version einmal zentral in Directory.Build.props statt zweimal hartkodiert.
Bewusste Abweichungen vom DC-Leitfaden, beide fuer ein handelndes System:
- Lizenz-Urteil fuehrt zum Sperrbetrieb (TradingEnabled=false) statt zu
Environment.Exit(1). Keine neuen Einstiege, aber Risiko-, Exit- und
Buchhaltungslogik laufen weiter.
- exitCurrentApp bleibt immer false; der Aufrufer beendet geordnet.
Das SDK haengt als Cross-Repo-ProjectReference am Schwester-Repo
Deploymentcenter (Interim, siehe Konzept 2.2). Damit ist P5 offen: die
Gitea-CI checkt das Schwester-Repo nicht aus und wird rot, bis der Bezug auf
ein NuGet-Paket umgestellt ist.
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.
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/konzepte/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/konzepte/KONZEPT-Modul-Supervisor.md.
Status / Nächstes
- Kurskorrektur auf das PolytraderSharp-Konzept (R1–R7) abgeschlossen.
- Accounting- und Supervisor-Modul (inkl. Core-Datenfundament S-0) ergänzt; Live-Abruf (IBKR Flex / OpenRouter-Key) und Steuerschicht sind bewusst noch offen (Stubs/Platzhalter).
- IBKR-Broker über die TWS API / IB Gateway ist implementiert (Paper-Konto steht, Verbindung verifiziert) – Design und offene Punkte: docs/IBKR-Integration.md, TWS-Einstellungen: docs/TWS-Setup-Checkliste.md.
- 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.