RichardandClaude Opus 5
9f66183f1c
Der offene Stand lag ueber sieben Konzepte, zwei Referenzdokumente und die
Phasen-Checkliste der Architektur verteilt. Dieselbe Aufgabe stand teils
doppelt unter zwei Namen - die asynchrone Fill-Verfolgung etwa als "bekannte
Grenze" in IBKR-Integration.md und zugleich als W-2 im OptionsWheel-Konzept.
Wer wissen wollte, was als Naechstes ansteht, musste alles neun lesen.
docs/ROADMAP.md fuehrt das zusammen:
- Fuenf Stufen in Abhaengigkeitsreihenfolge, von "Fundament schliessen" bis
zum OptionsWheel, dazu vier laufende Bahnen (Auslieferung, Accounting,
Supervisor, technische Schulden).
- Jede Zeile traegt ihre Herkunft (W-2, P5, Kapitalmodell 5, ...), damit die
Herleitung im Archiv auffindbar bleibt.
- Eigene Abschnitte fuer Zurueckgestelltes und Verworfenes. Zurueckgestellte
Ideen nennen ausdruecklich, WAS sie wieder aktuell macht; verworfene nennen
den Grund, damit sie nicht in sechs Monaten erneut vorgeschlagen werden.
- Erledigtes bleibt als Zeile mit Datum stehen statt zu verschwinden.
Archiv (git erkennt alle sieben als Umbenennung, Historie bleibt):
docs/konzepte/* -> docs/archiv/
docs/Kapital-und-Buchmodell.md -> docs/archiv/
Jedes archivierte Dokument bekommt oben einen Vermerk, warum es erhalten bleibt
und wo der lebende Stand steht. Inhaltlich ist keines veraendert.
Weiter gepflegt werden ARCHITECTURE.md (Aufbau + Phasen-Historie),
IBKR-Integration.md (Adapter-Design und Grenzen) und die TWS-Setup-Checkliste -
das sind Referenzen, keine Planung. Ihre eigenen Offen-Listen verweisen jetzt
mit Roadmap-Kennung dorthin, statt einen zweiten Stand zu fuehren.
Alle 63 relativen Markdown-Links geprueft, keiner tot. Fuenf Pfadverweise in
Code, csproj und systemd-Unit mitgezogen; die Unit zeigte auf die
Portierungsanalyse, die ausdruecklich den Stand VOR dem Umbau beschreibt - jetzt
auf ARCHITECTURE.md. Build 0 Warnungen, 198/198 Tests gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
96 lines
5.4 KiB
Markdown
96 lines
5.4 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) · Offener Stand: [docs/ROADMAP.md](docs/ROADMAP.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/archiv/KONZEPT-Modul-Accounting.md](docs/archiv/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/archiv/KONZEPT-Modul-Supervisor.md](docs/archiv/KONZEPT-Modul-Supervisor.md).
|
||
|
||
## Status / Nächstes
|
||
|
||
**➡️ Was noch zu tun ist, steht vollständig in der [Roadmap](docs/ROADMAP.md).** Sie ist seit dem
|
||
2026-08-23 das einzige Dokument, das den offenen Stand führt – einschließlich der Ideen, die wir
|
||
bewusst zurückstellen (🧊) und derer, die wir geprüft und verworfen haben (❌). Die früheren
|
||
Konzepte liegen unverändert unter [docs/archiv/](docs/archiv/) und tragen die Herleitung.
|
||
|
||
Kurzfassung:
|
||
- Gebaut: R1–R7 (Kurskorrektur auf das PolytraderSharp-Konzept), Accounting und Supervisor inkl.
|
||
Core-Datenfundament S-0, Linux-Portierung L0–L6, Deploymentcenter-Anbindung.
|
||
- **Es hat noch nie eine echte Order gegeben.** Der TWS-Adapter ist gegen das Paper-Konto
|
||
verifiziert (Verbindung, Konto, Kurse, Optionskette, Greeks, What-If-Order), aber
|
||
`PlaceOrderAsync` mit echter Ausführung steht aus – daran hängt alles Weitere.
|
||
- **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.
|