RichardandClaude Opus 5 362207c6f2 Handelszeiten im Core: DebugTrading handelt nicht mehr in die geschlossene Boerse
Das Modul erzeugte ueber das Wochenende Dutzende wartender Orders - alle 15
Minuten eine, alle von IBKR angenommen und fuer Montag 09:00 vorgemerkt, alle
gleichzeitig ausloesend. Am 2026-09-06 waren es 31.

Die Auskunft gehoert in den Core, nicht ins Modul: Handelszeiten braucht jede
Strategie, und sie ist nichts, was ein Modul selbst wissen kann.

- MarketHours.cs: MarketSession, MarketSchedule (IsOpen, NextOpenUtc), der
  Parser TradingHours und der Seam IMarketCalendar. Reine Rechnung, damit die
  Formate ohne Broker pruefbar sind - 20 Tests ueber beide Schreibweisen der
  TWS-API, Feiertage, Zeitraeume ueber Mitternacht und unbekannte Zonen.
- Die Zeiten kommen aus derselben Kontraktabfrage, die der Adapter ohnehin
  macht: contractDetails liefert sie mit, eine eigene Runde waere Verschwendung.
- LiquidHours und nicht TradingHours. Letzteres enthaelt bei US-Werten die vor-
  und nachboersliche Zeit; unsere Orders setzen OutsideRth nicht, wuerden dort
  also gar nicht ausgefuehrt, sondern warten - genau der Zustand, den das hier
  verhindern soll.
- Keine Ersatzzeitzone, wenn TWS eine unbekannte meldet. Mit der falschen Zone
  gerechnete Handelszeiten saehen richtig aus und laegen um Stunden daneben.
- Unbekannt gilt als geschlossen. Wer aus fehlender Auskunft auf einen offenen
  Markt schloesse, handelte bei jeder Stoerung ins Geschlossene.

DebugTrading.OnlyDuringMarketHours, Vorgabe an. Die Pruefung gilt fuer beide
Richtungen: Auch eine Schliessung erzeugte dieselbe wartende Order. Eine
Testposition ein paar Stunden laenger zu halten kostet dagegen nichts - und die
nicht geschlossene Position belegt ihren Platz weiter, sonst eroeffnete die
Planung ueber die eigene Grenze hinaus.

Auf der Testmaschine am Sonntagabend nachgewiesen:
  [20:31:28] Kein Instrument handelbar, naechste Eroeffnung SAP:EUR um
             2026-09-07 07:00 UTC.
07:00 UTC ist 09:00 MEZ - dieselbe Zeit, die IBKR heute frueh im Warntext 399
genannt hat. Zwei unabhaengige Quellen, gleiche Antwort. Seither keine neue
Order; der Lauf dauert zwei statt neunzig Sekunden.

524 Tests gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-06 20:33:45 +02:00
@
2026-07-27 10:09:46 +02:00
2026-07-26 18:19:47 +02:00
@
2026-07-28 00:24:00 +02:00
2026-07-26 18:19:47 +02:00
2026-07-26 18:19:47 +02:00

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 als IHostedService.
  • Module über IModule (RegisterServices/RegisterUi/Start/Stop); UI über IModuleUiHost/ModuleView.
  • Persistenz: EF Core (Pomelo/MariaDB), Migrationen extern angewendet (nicht zur Laufzeit).
  • Trading-Kern: IExecutionService (Signal→Risiko→Order→Buchung), IRiskService, IPortfolioService, Broker hinter IBrokerClient: NullBrokerClient (Default, handelt nie) oder IbkrBrokerClient über die TWS API – aktivierbar mit IBKR.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_KEY bzw. master.key für at-rest-Verschlüsselung (AES-256-GCM).
  • Supervisor (optional): IBKRTRADER_OPENROUTER_KEY bzw. openrouter.key (KI-Analyse), sowie die Opt-ins IBKRTRADER_SUPERVISOR_DAILY (Tagesbericht, Stunde 0–23) und IBKRTRADER_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 PlaceOrderAsync mit 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.

S
Description
No description provided
Readme
1.6 MiB
Languages
C# 76.3%
HTML 23.1%
PowerShell 0.6%