d8273c3a1e26b3247f8bf106544da61a0da7dd4c
Wir betreiben Instanzen in zwei Regionen. Bisher hing jede Ortszeit an der Zeitzone des Rechners (DateTime.Now, DateTimeKind.Local): derselbe Code haette auf einem Windows-Desktop mit Europe/Berlin und in einem Linux-Container mit UTC lautlos unterschiedliche Werte geliefert - ohne Fehler, nur um Stunden verschoben, mitten in Buchungszeitstempeln. AppTimeZone (Core/Time): Betriebszeitzone der Instanz, einmalig aus Trading.ApplicationTimeZoneId gesetzt, IANA- und Windows-Schreibweise tragen beide, unbekannter Wert weicht auf die Systemzone aus und warnt. Wird laut Festlegung vor den ersten Trades gesetzt und danach nie gewechselt - ein Wechsel verschoebe rueckwirkend alle Tagesgrenzen. Persistenz bleibt UTC, damit die Daten beider Instanzen vergleichbar sind. IbkrMapping.ParseExecutionTime verwirft die von TWS gemeldete Zeitzone nicht mehr, sondern rechnet gegen sie nach UTC; ohne Zonenangabe gilt die Betriebszeitzone. Das ist der Kern: eine NYSE-Ausfuehrung darf nicht mit demselben nackten Zeitwert in die Buecher wie eine an der Eurex. Rueckgabe ist jetzt immer Kind=Utc. DailyReportService.NextRun -> NextRunUtc(nowUtc, hour, zone): der Bericht laeuft zu einer festen ORTSZEIT. Sommerzeitumstellung wird behandelt - bei der uebersprungenen Stunde weicht er aus, statt den Tag ausfallen zu lassen. LoggingService fuehrt Anzeigezeit und UTC getrennt: Dateinamen und Anzeige in Ortszeit (Tagesgrenzen gehoeren zur Instanz, der Supervisor liest die JSONL-Dateien ueber diese Namen), das ts-Feld im JSONL in UTC. Beides musste getrennt werden, weil die umgerechnete Ortszeit Kind=Unspecified traegt und ein ToUniversalTime() darauf sie als Zeit des HOSTS gedeutet haette. Verbleibende DateTime.Now in Worker-Zeitplaenen und Statuszeilen ebenfalls auf AppTimeZone.Now umgestellt. Verifiziert: 183 Tests gruen (+20), darunter EU/US-Versatz, Winter-/Sommerzeit, unbekannte Zone und die uebersprungene Stunde bei der Zeitumstellung. 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).
Architektur (Kurzform)
IBKRTrader.App WinExe – Generic Host + Launcher/Shell (WinForms)
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)
- 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
dotnet run --project IBKRTrader.App.csproj -- --smoke-ui # Headless-UI-Check
dotnet run --project IBKRTrader.App.csproj # App starten
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.
Languages
C#
76.3%
HTML
23.1%
PowerShell
0.6%