Richard
9abad277c2
Phase 0: Test-Fundament & Architektur-Doku - IBKRTrader.Tests (xUnit + NSubstitute + FluentAssertions), nur Unit-Tests - Repo-lokale NuGet.config: Test-Pakete in Allowlist ergaenzt - Hauptprojekt: Test-Unterordner aus SDK-Globbing ausgeschlossen - docs/ARCHITECTURE.md: Plan + Phasen-Checkliste - grundregeln.md: .NET 10, Launcher-Modell; DB-Passwort entfernt Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> @
2.7 KiB
trigger
| trigger |
|---|
| always_on |
Projektname: IBKRTrader Ziel: Modulares, hochperformantes C# Trading-Framework (.NET 10) für automatische Aktien-Strategien mit Interactive Brokers API. Vorbild-Konzept: Polytrader (Core + unabhängige Module + Launcher, der die Fenster der einzelnen Module öffnet). Strikte Architektur-Regeln (immer einhalten):
Harter Core + beliebig viele unabhängige Module Module dürfen Core oder andere Module niemals beeinflussen DB-Tabellen-Namensschema: {ModulKürzel}_Tabellenname → Core = core_xxx → CongressTrading = ct_xxx Vollständig modulare Worker-Engine: Jeder Worker ist komplett unabhängig, hat eigenen Zeitplan, ist einzeln aktivierbar/deaktivierbar/manuell startbar Keine gegenseitigen Blockierungen – alles thread-sicher und performant
Technik (fest):
C# .NET 10 WinForms
MySQL – Zugangsdaten NUR in settings.json (gitignored), NIE im Repo/Code/Doku hinterlegen
IBKR TWS/Gateway API (Paper: Port 4002, Live: Port 4001 – Umschaltung über TradingSettings.Mode)
Interne REST-API + lokaler Webserver (für späteres Web-UI)
Settings: settings.json (Vorlage: settings.example.json)
Logging: RichTextBox (rtb_logs) + Dateien unter Logs[Modul][Level]-dd-MM-yy.txt (Info/Warn/Error)
Tests: eigenes Projekt IBKRTrader.Tests (xUnit + NSubstitute + FluentAssertions), NUR Unit-Tests,
alles Externe (DB/IBKR/Scraper) gemockt. DoD jeder Phase: dotnet test grün + Build sauber.
UI-Grundmodell (Launcher-Prinzip nach Polytrader):
LauncherForm = Basis-Fenster. Enthält: Core-Status/Steuerung ("Trading aktivieren", Paper/Live), Workers/Services (dgv_workerlist), Logs (rtb_logs), Settings (PropertyGrid) und eine Modul-Liste. Jedes Modul wird als EIGENSTÄNDIGES Fenster aus dem Launcher geöffnet (nicht als Tab). Der Launcher trackt offene Fenster (Key → Form) und fokussiert bei erneutem Öffnen. dgv_workerlist Spalten: Active | Type | Module | Workername | Last Runtime | Next Runtime | Run Every | Info Type = "Worker" oder "Service" (Service = permanent laufend)
Core-Worker (müssen zuerst):
Backup (alle 30 min) Webserver (Service) WebAPI (Service)
Erstes Modul: CongressTrading → Scrapt https://www.capitoltrades.com/trades?pageSize=96 → Tabellen: ct_congressMember + ct_trade → Zuerst alle Trades der letzten 3 Jahre, danach Worker alle 30 min neue Trades Entwicklungs-Regeln:
Immer extrem saubere, modulare, wartbare Architektur Build-Ordner muss absolut clean sein (nur notwendige Dateien) Arbeite streng schrittweise: zuerst Core fertig, dann Module Jede neue Funktion zuerst als Worker/Service im Core oder im jeweiligen Modul anlegen
Diese Rule hat immer höchste Priorität. Bei jedem Prompt und jedem Neustart gelten diese Vorgaben.