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> @
55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
---
|
||
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. |