RichardandClaude Opus 5
c176b05ea1
Das Suffix ".Avalonia" gab es nur, weil daneben ein WinForms-IBKRTrader.App
stand. Das ist seit L5 weg, also faellt auch das Suffix. Git erkennt alle
Dateien als Umbenennung; Assembly, Wurzel-Namensraum und die
avares://-Ressourcen-URI sind mitgezogen.
Nebeneffekt der Umbenennung: die global::Avalonia-Qualifizierungen entfallen.
Sie waren noetig, weil der Namensraum IBKRTrader.App.Avalonia das
Avalonia-Paket verdeckt hat - ein Ueberbleibsel genau der Namensgebung, die
jetzt weg ist.
Inhaltlich falsch gewordene Aussagen berichtigt - das waren die eigentlichen
Ueberbleibsel, nicht die Kommentare:
- .agents/rules/grundregeln.md schrieb weiterhin "C# .NET 10 WinForms",
RichTextBox-Logging, LauncherForm und PropertyGrid vor. Das ist die Regel,
nach der kuenftig gearbeitet wird - sie haette die Portierung Stueck fuer
Stueck rueckgaengig gemacht. Jetzt: Avalonia, keine Plattform-Suffixe, die
11er-Pinnung mit Begruendung, dazu die beiden Regeln, die uns in L1b am
meisten gekostet haben (UTC persistieren + AppTimeZone statt DateTime.Now;
jede Formatierung mit ausdruecklichem IFormatProvider).
- Core: LogEntry ("wird in RichTextBox geschrieben"), IWorker/WorkerEngine/
WorkerInfo ("DataGridView-Zeile"/"-Binding"), ModuleView ("die
WinForms-Shell castet auf Form").
- Doku: ARCHITECTURE (Modul-Ui-Ordner, "designbare Forms mit Initialize"),
KONZEPT-Modul-Accounting ("UI (WinForms, ein Fenster mit Tabs)").
BEWUSST STEHEN GEBLIEBEN sind die Kommentare, die WinForms nur als
Begruendung nennen - warum LoggingService ein Ereignis hat statt einer
RichTextBox, warum ModuleView Func<object> liefert, warum es benannte
Record-Zeilentypen gibt, warum die Einstellungsmaske aus Attributen entsteht.
Das ist die Herleitung des heutigen Entwurfs; ohne sie sieht spaeter jede
dieser Stellen nach Umstaendlichkeit ohne Grund aus.
KONZEPT-Linux-Portierung.md bekommt einen Statusvermerk: umgesetzt, die
Pfadangaben im Fundstellenverzeichnis beziehen sich auf den alten Aufbau.
Zwei Abweichungen von der Schaetzung sind dort festgehalten - der geringere
Aufwand dank der PolytraderSharp-Vorlage, und dass die dort empfohlene
InvariantGlobalization ein Fehler gewesen waere.
Verifiziert: Build 0 Fehler/0 Warnungen, 193 Tests gruen, Smoke-UI
konstruiert alle 7 Ansichten + Launcher + Dialog, Daemon-Prueflauf OK,
publish -r linux-x64 fuer beide Einstiegspunkte fehlerfrei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
74 lines
4.2 KiB
Markdown
74 lines
4.2 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, **Avalonia** für die Oberfläche – plattformneutral (Windows und Linux).
|
||
KEIN WinForms und kein System.Drawing: beides bindet an Windows. Alle Projekte sind `net10.0`
|
||
ohne Plattform-Suffix; ein `net10.0-windows` irgendwo ist ein Fehler.
|
||
Avalonia bleibt auf der 11er-Linie (11.3.19 / DataGrid 11.3.13), bis LiveCharts2 Avalonia 12
|
||
unterstützt – sonst brechen die Diagramme der kommenden Module.
|
||
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: LoggingService meldet Einträge über das Ereignis `EntryWritten` (die Oberfläche hängt sich
|
||
ein und färbt selbst) + Dateien unter Logs/[Modul]/[Level]-dd-MM-yy.txt sowie Logs/[Datum].jsonl
|
||
Zeit: Zeitstempel IMMER in UTC persistieren. Für Anzeige, Tagesgrenzen und Zeitpläne
|
||
`AppTimeZone` verwenden, NIE `DateTime.Now` oder `DateTimeKind.Local` – wir betreiben Instanzen
|
||
in EU und US, die Ortszeit darf nicht am Rechner hängen.
|
||
Kultur: Jede Zahl-/Datumsformatierung und jedes Parsen braucht einen ausdrücklichen
|
||
IFormatProvider (i. d. R. InvariantCulture). Ohne ihn hängt das Ergebnis an der Kultur des Hosts.
|
||
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):
|
||
|
||
LauncherWindow = Basis-Fenster mit einer Schaltfläche je registrierter Ansicht und dem
|
||
gemeinsamen Fenster-Menü. Die Inhalte (Dashboard, Workers, Logs, Settings, Modul-Fenster) sind
|
||
eigenständige Fenster, keine Tabs; je Ansicht höchstens eines, erneutes Öffnen fokussiert.
|
||
Layout deklarativ in .axaml, nicht zur Laufzeit im Code. Kompilierte Bindings sind aktiv, jeder
|
||
Datenkontext braucht ein x:DataType – dadurch fallen Bindungsfehler beim Kompilieren auf.
|
||
Module tragen KEINEN UI-Code: sonst müssten sie Avalonia referenzieren und wären nicht mehr
|
||
kopflos lauffähig. Ihr RegisterUi bleibt leer, die Fenster registriert die Shell zentral in
|
||
src/IBKRTrader.App/Shell/ModuleViews.cs.
|
||
Workers-Ansicht, Spalten: Aktiv | Typ | Modul | Worker | Letzter Lauf | Nächster Lauf | Intervall | Info
|
||
Type = "Worker" oder "Service" (Service = permanent laufend)
|
||
|
||
Betriebsformen (beide aus derselben Host-Zusammenstellung, src/IBKRTrader.Hosting):
|
||
|
||
src/IBKRTrader.App – mit Oberfläche; `--smoke-ui` prüft die Fenster-Konstruktion ohne Anzeigegerät
|
||
src/IBKRTrader.Daemon – kopflos für Linux/systemd; `--check` fährt die Startprüfungen ohne Dienste
|
||
|
||
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. |