RichardandClaude Opus 5 afae3c9c4a L3: Avalonia-Shell und Core-Ansichten - die Oberflaeche laeuft auf Linux
Neues Projekt IBKRTrader.App.Avalonia (net10.0, plattformneutral) mit
Launcher, Fenster-Menue, Beenden-Abfrage und den vier Core-Ansichten
Dashboard, Workers, Logs und Settings. Nutzt denselben AppHostBuilder wie
der Daemon; ShellServices ergaenzt nur, was ohne Oberflaeche nicht existiert.

Versionen bewusst auf der 11er-Linie: Avalonia 11.3.19, DataGrid 11.3.13.
LiveCharts2 2.0.5 ist gegen Avalonia 11 gebaut und bricht unter 12
(Gestures.PinchEvent gibt es dort nicht mehr). Diagramme kommen mit den
neuen Modulen - bis LiveCharts2 Avalonia 12 unterstuetzt, darf hier nicht
angehoben werden. Erfahrung aus PolytraderSharp, im csproj vermerkt.

Ersatz fuer WinForms-Bausteine ohne Gegenstueck:
- PropertyGrid -> SettingsModelBuilder erzeugt die Maske aus den bereits
  vorhandenen Category-/DisplayName-/Description-Attributen von AppSettings.
  Eine neue Einstellung erscheint damit automatisch, ohne dass jemand die
  Oberflaeche anfasst - genau der Vorteil des PropertyGrid. Kennwortfelder
  (DB-Passwort, Flex-Token) werden verdeckt. Gemessen: 11 Abschnitte,
  41 Felder.
- MessageBox.Show -> ShutdownConfirmWindow (Avalonia bringt keinen
  Meldungsdialog mit). Schliessen ueber das X zaehlt als Abbruch, damit ein
  versehentlicher Klick nie den Handelsbetrieb stoppt.
- RichTextBox mit SelectionColor -> eingefaerbte Elemente je Logzeile, mit
  Filter, Auto-Scroll und Zeilenbegrenzung (im Dauerbetrieb waere die Liste
  sonst unbegrenzt gewachsen).
- ToolStrip/StatusStrip -> zentrale Stilklassen in App.axaml (toolbar,
  statusbar, kpi, section). Die neuen Module setzen darauf auf.

Gemeinsame Bausteine bewusst jetzt schon zentral, weil die neuen Module
direkt in Avalonia entwickelt werden sollen.

Kompilierte Bindings sind aktiv (x:DataType je Datenkontext) - Tippfehler in
Bindings fallen damit beim Kompilieren auf statt erst zur Laufzeit. Dafuer
brauchte es benannte Record-Zeilentypen statt der anonymen Typen, die
DataGridView.DataSource frueher bekommen hat.

--smoke-ui laeuft jetzt ueber SetupWithoutStarting, also OHNE Anzeigegeraet
und ohne laufende Dienste. Das war mit WinForms nicht moeglich und macht die
Konstruktionspruefung erstmals CI-tauglich. Der Host wird dabei bewusst nicht
gestartet, sonst liefen Worker und Broker-Verbindungen gegen die echten
Endpunkte an.

AVLN3001 unterdrueckt: die Fenster haben absichtlich keinen parameterlosen
Konstruktor. Einer wuerde sie ohne ihre Dienste konstruierbar machen und
genau den Fehler verdecken, den die Konstruktionspruefung finden soll.

Verifiziert: Build 0 Fehler/0 Warnungen, 193 Tests gruen, Avalonia-Smoke-UI
konstruiert alle 6 Fenster, publish -r linux-x64 liefert 32 MB mit
ELF-Launcher samt libSkiaSharp.so/libHarfBuzzSharp.so und ohne
Windows-Abhaengigkeiten. Die WinForms-Shell ist unveraendert lauffaehig.

Offen fuer L4: die drei Modul-Fenster (ModuleViews ist noch leer).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 10:18:44 +02:00
@
2026-07-27 09:58:49 +02:00
@
2026-07-28 10:25:14 +02:00
@
2026-07-28 10:25:14 +02:00
@
2026-07-27 10:09:46 +02:00
@
2026-07-28 19:53:21 +02:00
2026-07-26 18:19:47 +02:00
@
2026-07-28 00:24:00 +02:00
2026-07-26 18:19:47 +02:00
2026-07-26 18:19:47 +02:00

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).

Architektur (Kurzform)

IBKRTrader.App                     WinExe  Generic Host + Launcher/Shell (WinForms)
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)
  • 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.

Build & Test

dotnet build IBKRTrader.slnx
dotnet test  IBKRTrader.slnx
dotnet run --project IBKRTrader.App.csproj -- --smoke-ui   # Headless-UI-Check
dotnet run --project IBKRTrader.App.csproj                 # App starten

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 023) und IBKRTRADER_MCP_PORT (MCP-Light, nur 127.0.0.1).

Datenbank aufsetzen

Schema wird per EF-Migrationen extern angewendet siehe scripts/README.md:

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.
  • 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.

Status / Nächstes

  • Kurskorrektur auf das PolytraderSharp-Konzept (R1R7) 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, TWS-Einstellungen: 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.

S
Description
No description provided
Readme
635 KiB
Languages
C# 76.3%
HTML 23.1%
PowerShell 0.6%