RichardandClaude Opus 5 7b16474a33 Nachbesserungen am Web-UI: Optionsschluessel, Erreichbarkeit, Vorgaben
Vier Punkte aus der Durchsicht von f923721. Alles Uebrige traegt: Anmeldung
greift (unangemeldet 401 auf jedem /api-Pfad ausser status und login), alle
zwanzig Endpunkte antworten, SSE laeuft, die Oberflaeche zeigt echte Zahlen,
die Daemon-Schalter funktionieren weiter, und die Modul-Routen sitzen richtig
im Hosting-Projekt statt im Core.

1. Die Endpunkte /positions/lock und /positions/reassign deuteten den
   Instrumentenschluessel mit InstrumentRef.ForStock als Ticker. Bei einer Aktie
   ging das zufaellig gut - die Waehrung fiel still auf USD, der Schluessel kam
   trotzdem richtig heraus. Bei einem Optionskontrakt warf Normalize wegen des
   Trennzeichens "|" eine Ausnahme: HTTP 500 ohne Text, auf der Testmaschine
   reproduziert. Jetzt InstrumentRef.TryParse, und ein unlesbarer Schluessel
   ebenso wie ein unsinniger Buchname ergibt eine Antwort statt eines Absturzes.

2. OrderManager las UseTwsApi als Erreichbarkeitsnachweis. Das ist eine
   Einstellung, kein Zustand - sie steht auch dann auf true, wenn TWS nicht
   laeuft. Die Ansicht haette waehrend jeder Stoerung "Broker erreichbar, keine
   offenen Orders" gemeldet und jede Bindung als grundlos dargestellt. Genau
   davor warnt die Beschreibung an IBrokerOrderBook.GetOpenOrdersAsync.

3. AllowRemoteAccess stand als Vorgabe auf true: erster Start heisst 0.0.0.0,
   Klartext-HTTP, und der AuthToken ist anfangs leer. Ausnutzbar war das nicht
   (ohne Token faellt die Anmeldung zu, alles antwortet 401), aber die Vorgabe
   zeigte in die falsche Richtung. Jetzt lokal, mit Begruendung im Text.

4. Das Sitzungstoken stand im Query-String des SSE-Stroms. Unnoetig: EventSource
   schickt das HttpOnly-Cookie bei gleichem Ursprung von selbst. Die Oberflaeche
   nutzt den Weg nicht mehr, und AuthService nimmt ihn nur noch fuer
   /api/logs/stream an - ein Query-String landet in Logs, Verlauf und Referer.

Geminis Test auf den Query-Token bestand auf dem alten, breiten Verhalten. Er
ist durch zwei ersetzt, die die enge Regel in beide Richtungen festhalten.

499 Tests gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-06 20:17:02 +02:00
@
2026-07-27 10:09:46 +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).

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 · Offener Stand: docs/ROADMAP.md.

Build & Test

dotnet build IBKRTrader.slnx
dotnet test  IBKRTrader.slnx

Anwendung starten:

dotnet run --project src/IBKRTrader.App

Prüfläufe – beide ohne Anzeigegerät und ohne laufende Dienste, also CI-tauglich:

dotnet run --project src/IBKRTrader.App -- --smoke-ui
dotnet run --project src/IBKRTrader.Daemon -- --check

Kopflos auf Linux (systemd): siehe 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:

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

Status / Nächstes

➡️ Was noch zu tun ist, steht vollständig in der Roadmap. 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/ 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.

S
Description
No description provided
Readme
1.6 MiB
Languages
C# 76.3%
HTML 23.1%
PowerShell 0.6%