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>
90 lines
5.0 KiB
Markdown
90 lines
5.0 KiB
Markdown
# 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](docs/ARCHITECTURE.md).
|
||
|
||
## Build & Test
|
||
```bash
|
||
dotnet build IBKRTrader.slnx
|
||
dotnet test IBKRTrader.slnx
|
||
```
|
||
|
||
Anwendung starten:
|
||
```bash
|
||
dotnet run --project src/IBKRTrader.App
|
||
```
|
||
|
||
Prüfläufe – beide ohne Anzeigegerät und ohne laufende Dienste, also CI-tauglich:
|
||
```bash
|
||
dotnet run --project src/IBKRTrader.App -- --smoke-ui
|
||
dotnet run --project src/IBKRTrader.Daemon -- --check
|
||
```
|
||
|
||
Kopflos auf Linux (systemd): siehe [deploy/README.md](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](scripts/README.md):
|
||
```bash
|
||
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](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](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](docs/IBKR-Integration.md),
|
||
TWS-Einstellungen: [docs/TWS-Setup-Checkliste.md](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.
|