diff --git a/README.md b/README.md index d5a7e92..388857a 100644 --- a/README.md +++ b/README.md @@ -26,7 +26,7 @@ die Fenster registriert die Shell zentral in `Shell/ModuleViews.cs`. ü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). +- Details: [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) · Offener Stand: [docs/ROADMAP.md](docs/ROADMAP.md). ## Build & Test ```bash @@ -67,19 +67,25 @@ powershell -File scripts/provision-db.ps1 - **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). + [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/konzepte/KONZEPT-Modul-Supervisor.md](docs/konzepte/KONZEPT-Modul-Supervisor.md). + [docs/archiv/KONZEPT-Modul-Supervisor.md](docs/archiv/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). + +**➡️ 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 diff --git a/deploy/ibkrtrader.service b/deploy/ibkrtrader.service index 53b2a04..35c8f02 100644 --- a/deploy/ibkrtrader.service +++ b/deploy/ibkrtrader.service @@ -16,7 +16,7 @@ # [Unit] Description=IBKRTrader (kopfloser Handelsdienst) -Documentation=file:///opt/ibkrtrader/docs/konzepte/KONZEPT-Linux-Portierung.md +Documentation=file:///opt/ibkrtrader/docs/ARCHITECTURE.md After=network-online.target Wants=network-online.target diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index bc2daf2..1e9cff8 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -8,6 +8,15 @@ Ziel: modulares C#-Trading-Framework für Interactive-Brokers-Aktien, strukturell wie PolytraderSharp, nur dass statt Polymarket über IBKR gehandelt wird. +> **Was dieses Dokument ist – und was nicht.** Abschnitt 1 beschreibt den **heutigen Aufbau** und ist +> die lebende Architektur-Referenz. Abschnitt 3 ist die **Historie**: die Phasen-Checklisten, an denen +> nachlesbar ist, was wann und warum gebaut wurde. Beides bleibt gepflegt. +> +> **Der offene Stand steht seit dem 2026-08-23 nicht mehr hier, sondern in der +> [Roadmap](ROADMAP.md).** Die wenigen offenen Kästchen unten sind mit ihrer Roadmap-Kennung +> versehen, damit die beiden Listen nicht auseinanderlaufen. Neue Aufgaben gehören ausschließlich +> in die Roadmap. + --- ## 1. Ziel-Architektur (nach PolytraderSharp) @@ -16,7 +25,7 @@ nur dass statt Polymarket über IBKR gehandelt wird. > Plattformbindung. Die WinForms-Shell ist entfernt; der letzte Stand liegt im Tag > `winforms-final`. Einstiegspunkte sind jetzt `IBKRTrader.App` (mit Oberfläche) und > `IBKRTrader.Daemon` (kopflos, systemd); beide bauen ihren Host über `IBKRTrader.Hosting`. -> Analyse und Vorgehen: [konzepte/KONZEPT-Linux-Portierung.md](konzepte/KONZEPT-Linux-Portierung.md). +> Analyse und Vorgehen: [archiv/KONZEPT-Linux-Portierung.md](archiv/KONZEPT-Linux-Portierung.md). ``` src/IBKRTrader.App (WinExe, net10.0) – Oberfläche: Launcher, Shell, Core-Views, Modul-Fenster @@ -131,7 +140,7 @@ Pin `new MariaDbServerVersion(new Version(11, 8, 6))`. Verbindung aus `appsettin - [x] `ConfigureSecretProtection` + TLS-Warnung (`SslMode`) beim Start; `master.key` gitignored - [x] Connection-String in `appsettings.Local.json` (gitignored) - [x] **5 SecretProtection-Tests** (Round-Trip, Idempotenz, Passthrough, Tamper/Key-Fehler) → 56/56 grün -- [ ] **Offen (Nutzer-Aktion):** geleaktes DB-Passwort rotieren (liegt in Git-Historie via `grundregeln.md`, Commit `ebeb035`); EF-Schema per `dotnet ef database update` auf die DB anwenden +- [ ] **Offen → Roadmap [B1](ROADMAP.md) / [B3](ROADMAP.md):** geleaktes DB-Passwort rotieren (liegt in Git-Historie via `grundregeln.md`, Commit `ebeb035`); EF-Schema per `dotnet ef database update` auf die DB anwenden ### R7 – Feinschliff ✅ - [x] Core-**Dashboard-View** (Gesamtüberblick: Trading-Modus, aggregierte Kennzahlen, geladene Module) + Icon @@ -141,11 +150,11 @@ Pin `new MariaDbServerVersion(new Version(11, 8, 6))`. Verbindung aus `appsettin - [x] Gegen Paper-Konto DUR371528 verifiziert: Verbindung, Konto (NetLiquidation 100.105,50 EUR), Kurse (AAPL/MSFT/NVDA, verzögert) und Fehlerpfade - [x] Orderpfad bis zur Broker-Annahme per **What-If-Order** verifiziert (Aktie + Option, keine Ausführung); **Optionsberechtigung im Paper-Konto bestätigt** - [x] **`IBrokerPortfolioReader`** (Bestand + Ausführungen beim Broker) – eigener Seam neben `IBrokerClient`, Grundlage für den Abgleich der eigenen Buchführung; gegen DUR371528 verifiziert (2 Positionen, 2 Ausführungen inkl. Kommissionen) -- [ ] **Offen:** `PlaceOrderAsync` mit echter Ausführung verifizieren (Fill → Buchung); asynchrone Fill-Verfolgung (Orders ohne sofortige Ausführung) -- [ ] IBKR-Account-Credentials mit `EncryptedStringConverter` speichern +- [ ] **Offen → Roadmap [H1](ROADMAP.md) / [H2](ROADMAP.md):** `PlaceOrderAsync` mit echter Ausführung verifizieren (Fill → Buchung); asynchrone Fill-Verfolgung (Orders ohne sofortige Ausführung) +- [ ] **Offen → Roadmap [H3](ROADMAP.md):** IBKR-Account-Credentials mit `EncryptedStringConverter` speichern ### L0–L5 – Linux-Portierung: Avalonia statt WinForms ✅ (2026-08-07) -Analyse und Begründung: [konzepte/KONZEPT-Linux-Portierung.md](konzepte/KONZEPT-Linux-Portierung.md). +Analyse und Begründung: [archiv/KONZEPT-Linux-Portierung.md](archiv/KONZEPT-Linux-Portierung.md). Rückfallpunkt für den letzten WinForms-Stand: Tag `winforms-final`. - [x] **L0** `NuGet.config` repariert – drei Pakete hatten kein `packageSourceMapping`-Muster; ein frischer Klon konnte nicht wiederherstellen (auf dem Entwicklungsrechner unsichtbar, weil gecacht) @@ -160,8 +169,9 @@ Rückfallpunkt für den letzten WinForms-Stand: Tag `winforms-final`. und Oberfläche (32 MB) ohne eine einzige Windows-Abhängigkeit. Der Smoke-UI-Lauf braucht kein Anzeigegerät mehr und ist damit erstmals Teil der CI. -**Offen:** IB Gateway kopflos betreiben (IBC + Xvfb) – eigene Baustelle, unabhängig vom Code; -LiveCharts2 kommt mit den neuen Modulen (Avalonia deshalb auf der 11er-Linie gepinnt). +**Offen → Roadmap [H4](ROADMAP.md) / [T3](ROADMAP.md):** IB Gateway kopflos betreiben (IBC + Xvfb) +– eigene Baustelle, unabhängig vom Code; LiveCharts2 kommt mit den neuen Modulen (Avalonia deshalb +auf der 11er-Linie gepinnt). ### L6 – Namensgebung bereinigt ✅ (2026-08-07) - [x] `IBKRTrader.App.Avalonia` → **`IBKRTrader.App`**. Das Suffix gab es nur, solange daneben eine @@ -175,7 +185,7 @@ LiveCharts2 kommt mit den neuen Modulen (Avalonia deshalb auf der 11er-Linie gep Stück rückgängig gemacht. Dazu Core-Kommentare (`LogEntry`, `IWorker`, `ModuleView`) und Doku. ### DC – Deploymentcenter-Integration ✅ (2026-08-23) -Konzept und Begründung: [konzepte/KONZEPT-Deploymentcenter-Integration.md](konzepte/KONZEPT-Deploymentcenter-Integration.md). +Konzept und Begründung: [archiv/KONZEPT-Deploymentcenter-Integration.md](archiv/KONZEPT-Deploymentcenter-Integration.md). Schritte 0–8 der dortigen Reihenfolge sind umgesetzt; der Stand je Schritt steht in §9 dieses Konzepts. - [x] Lizenz (Sperrbetrieb statt Abbruch), Watchdog-Heartbeat, Fehler-Stream inkl. globaler @@ -183,12 +193,12 @@ Schritte 0–8 der dortigen Reihenfolge sind umgesetzt; der Stand je Schritt ste Einbauort ist `IBKRTrader.Hosting/Deploymentcenter/` – den Host teilen sich Shell und Daemon. - [x] Vier Projekt-Befunde vorab bereinigt: Zugangsdaten aus `AppSettings` (P1), `AppPaths`-Rückfall unter Windows (P2), globale Handler (P3), Version zentral in `Directory.Build.props` (P4). -- [ ] **Offen (P5):** Die Gitea-CI checkt das Schwester-Repo `Deploymentcenter` nicht aus. Solange +- [ ] **Offen (P5) → Roadmap [D1](ROADMAP.md):** Die Gitea-CI checkt das Schwester-Repo `Deploymentcenter` nicht aus. Solange das SDK als Cross-Repo-`ProjectReference` hängt, ist der CI-Lauf rot. Behebt sich mit Schritt 10 (SDK als NuGet-Paket in der Gitea-Registry). -- [ ] **Offen (Schritt 9):** Bugtracker-Baustein – setzt voraus, dass das Projekt `ibkrtrader` im +- [ ] **Offen (Schritt 9) → Roadmap [D2](ROADMAP.md) / [D5](ROADMAP.md):** Bugtracker-Baustein – setzt voraus, dass das Projekt `ibkrtrader` im DC-WebUI angelegt ist und ein Token mit `bugtracker:report` vorliegt (serverseitige Handarbeit). -- [ ] **Offen:** Das Anwenden eines gefundenen Updates ist nicht verdrahtet. `DcUpdateService.LaunchAgent` +- [ ] **Offen → Roadmap [D3](ROADMAP.md):** Das Anwenden eines gefundenen Updates ist nicht verdrahtet. `DcUpdateService.LaunchAgent` ist fertig und dokumentiert, es fehlt der Aufrufer, der danach geordnet herunterfährt. --- @@ -197,7 +207,7 @@ Schritte 0–8 der dortigen Reihenfolge sind umgesetzt; der Stand je Schritt ste IBKRTrader entspricht jetzt strukturell dem PolytraderSharp-Konzept: Multi-Projekt (Core + Modul + App + Tests), Generic Host + `IHostedService`, `IConfiguration`, `IModule`/`ModuleView`/`ShellUiHost`, EF Core (extern migriert), Trading-Kern (Risk/Execution/Portfolio, `NullBroker`-Default), CongressTrading-Strategie, Security (Master-Key/AES-GCM). -**Offen für später:** echte IBKR-Broker-Anbindung (Paper-Gateway), DB-Passwort-Rotation, EF-Schema anwenden. +**Offen für später:** siehe [Roadmap](ROADMAP.md) – die IBKR-Broker-Anbindung ist inzwischen gebaut, DB-Passwort-Rotation (B1) und EF-Schema (B3) stehen weiterhin aus. --- diff --git a/docs/IBKR-Integration.md b/docs/IBKR-Integration.md index e346287..2fb47b6 100644 --- a/docs/IBKR-Integration.md +++ b/docs/IBKR-Integration.md @@ -92,13 +92,13 @@ komplette Prüfkette – inklusive Handelsberechtigung – und verwirft die Orde Fehlte die Berechtigung, hätte IBKR die What-If-Order mit einem Berechtigungsfehler abgelehnt statt eine Margin zu liefern. Für **Realtime**-Optionskurse wäre zusätzlich ein OPRA-Abo nötig; ohne Abo kommen verzögerte Daten (siehe Marktdaten unten). Modul-Konzept: -[konzepte/KONZEPT-Modul-OptionsWheel.md](konzepte/KONZEPT-Modul-OptionsWheel.md). +[archiv/KONZEPT-Modul-OptionsWheel.md](archiv/KONZEPT-Modul-OptionsWheel.md). > **What-If als Testwerkzeug:** Damit lässt sich der gesamte Orderpfad bis zur Broker-Annahme prüfen, > ohne eine Position zu eröffnen. Der Adapter nutzt es nicht produktiv – für Vorabprüfungen > (Margin-Deckung vor einer echten Order) wäre es aber ein naheliegender Ausbau. Welche Daten die API auf diesem Konto tatsächlich liefert – und welche Strategien das trägt – -steht gemessen in [konzepte/KONZEPT-Datenlage-und-Strategien.md](konzepte/KONZEPT-Datenlage-und-Strategien.md). +steht gemessen in [archiv/KONZEPT-Datenlage-und-Strategien.md](archiv/KONZEPT-Datenlage-und-Strategien.md). Kurz: Kurshistorie (30 Jahre), Volatilitätshistorie, Optionsketten und Griechen ja; Fundamentaldaten und Marktscanner nein (Abo nötig). @@ -126,7 +126,16 @@ Später zu entscheiden: [TWS-Setup-Checkliste](TWS-Setup-Checkliste.md), Abschnitt Verifikation. ## Offen -1. `PlaceOrderAsync` gegen das Paper-Konto verifizieren (Order → Fill → Buchung). -2. IBC für Auto-Login/Neustart einrichten (Server-Betrieb). -3. Asynchrone Fill-Verfolgung, siehe „Bekannte Grenze" oben. -4. Entscheiden, ob die Marktdaten-Historie von der CP Web API auf `reqHistoricalData` wandert. +Die offenen Punkte dieses Adapters werden seit dem 2026-08-23 in der +[Roadmap](ROADMAP.md) gefuehrt, nicht mehr hier – sie haengen mit Aufgaben aus anderen Konzepten +zusammen und standen deshalb doppelt. Es sind: + +| Roadmap | Punkt | +|---|---| +| **H1** | `PlaceOrderAsync` gegen das Paper-Konto verifizieren (Order → Fill → Buchung) | +| **H2** | Asynchrone Fill-Verfolgung, siehe „Bekannte Grenze" oben – zugleich Voraussetzung fuer OptionsWheel | +| **H4** | IBC fuer Auto-Login/Neustart einrichten (Server-Betrieb) | +| **T1** | Entscheiden, ob die Marktdaten-Historie von der CP Web API auf `reqHistoricalData` wandert | + +Das **Design** und die **bekannten Grenzen** stehen weiterhin in diesem Dokument – es bleibt die +technische Referenz des Adapters. diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md new file mode 100644 index 0000000..bc01eb7 --- /dev/null +++ b/docs/ROADMAP.md @@ -0,0 +1,235 @@ +# IBKRTrader – Roadmap + +> **Dies ist das einzige Dokument, das sagt, was noch zu tun ist.** Bis zum 2026-08-23 war der +> offene Stand über sieben Konzepte, zwei Referenzdokumente und die Phasen-Checkliste der +> Architektur verteilt; dieselbe Aufgabe stand teils doppelt unter zwei Namen. Diese Roadmap führt +> alles zusammen. Die Quelldokumente bleiben vollständig erhalten und liegen unter +> [archiv/](archiv/) – dort steht das **Warum** und die Herleitung, hier das **Was** und das **Wann**. +> +> Regel für die Zukunft: **Ein offener Punkt gehört hierher.** Steht er nur im Konzept, wird er +> vergessen. Wird er erledigt, bekommt er ein ✅ mit Datum – die Zeile bleibt stehen, damit +> nachvollziehbar ist, wann etwas fertig wurde. + +**Stand: 2026-08-23** + +--- + +## Legende + +| Zeichen | Bedeutung | +|---|---| +| ⬜ | Geplant, noch nicht angefangen | +| 🔶 | Angefangen, halbfertig – der genaue Rest steht in der Zeile | +| ✅ | Fertig, mit Datum | +| 🧊 | **Zurückgestellt** – bewusst nicht jetzt, Idee wird vorgehalten. Kein Versehen. | +| ❌ | **Verworfen** – geprüft und entschieden. Nicht erneut vorschlagen, ohne den Grund zu entkräften. | + +Die Spalte *Herkunft* nennt die ursprüngliche Kennung im Quelldokument, damit die Herleitung +auffindbar bleibt (z. B. `W-2` im OptionsWheel-Konzept, `P5` im Deploymentcenter-Konzept). + +--- + +## Wo wir stehen + +Gebaut und grün: Multi-Projekt-Aufbau nach PolytraderSharp, Generic Host, EF Core, Trading-Kern, +drei Module (CongressTrading, Accounting, Supervisor), Avalonia-Oberfläche auf Windows **und** +Linux, kopfloser Daemon, Deploymentcenter-Anbindung. 198 Tests, Build ohne Warnungen. + +Nicht gebaut: **Es hat noch nie eine echte Order gegeben.** Der Broker-Adapter ist gegen das +Paper-Konto verifiziert – Verbindung, Konto, Kurse, Optionskette, Greeks, What-If-Order – aber +`PlaceOrderAsync` mit echter Ausführung steht aus. Alles, was danach kommt (Fill-Buchung, +Kapitalmodell, OptionsWheel), hängt an diesem einen Nachweis. + +Zwei Sicherungen sind absichtlich getrennt und beide stehen auf „aus": `IBKR.UseTwsApi` schaltet +den Adapter, `TradingEnabled` den Handel. + +--- + +## Stufe 1 – Fundament schließen + +*Diese Punkte blockieren oder gefährden alles Weitere. Sie kommen zuerst.* + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **B1** | **DB-Passwort rotieren.** Das echte Passwort der produktiven MariaDB stand als Vorgabewert in `AppSettings.cs` und liegt damit **in der Git-Historie** (ab Commit `ebeb035`). Der Quelltext trägt seit 2026-08-23 Platzhalter – das ändert an der Historie nichts. Betriebsaktion, nur vom Betreiber ausführbar. | ⬜ | R6, DC-P1 | +| **B2** | **Gitea-Zugangstoken aus der Remote-URL nehmen.** `git remote -v` zeigt den Token im Klartext in der URL; er landet so in jedem Log, jeder Fehlermeldung und jedem Screenshot. Auf Credential-Helper oder SSH umstellen. | ⬜ | Befund 2026-08-23 | +| **B3** | **EF-Schema auf die Datenbank anwenden** (`dotnet ef database update`). Migrationen werden bewusst extern angewendet, nie zur Laufzeit. | ⬜ | R6 | +| **D1** | **CI wieder grün bekommen.** Das Deploymentcenter-SDK hängt als Cross-Repo-`ProjectReference` am Schwester-Repo; `.gitea/workflows/build.yml` checkt nur IBKRTrader aus, also ist der CI-Lauf seit dem 2026-08-23 rot. Das war die bewusst in Kauf genommene Folge der Interimslösung. Auflösung: `dotnet pack` im Deploymentcenter-Repo → Gitea-Registry → `PackageReference` statt Cross-Repo-Pfad → CI-Workflow anpassen. | ⬜ | DC-P5, DC-Schritt 10 | +| **H1** | **`PlaceOrderAsync` gegen das Paper-Konto verifizieren** – echte Order, echter Fill, korrekte Buchung. Der einzige Teil des Broker-Adapters, der nie unter realen Bedingungen lief. | ⬜ | R7, IBKR-Integration §Offen 1 | + +--- + +## Stufe 2 – Den Handelspfad belastbar machen + +*Ohne das ist kein unbeaufsichtigter Betrieb zu verantworten.* + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **H2** | **Asynchrone Order- und Fill-Verfolgung.** `PlaceOrderAsync` ist synchron gedacht: Ausführung oder Fehlschlag innerhalb `OrderTimeoutSeconds`. Eine Limit-Order im Buch oder eine Market-Order außerhalb der Handelszeiten gilt damit als Fehlschlag – **ist bei IBKR aber weiter aktiv.** Nötig: Order-Zustand persistieren (`core_order_state`), `orderStatus`/`execDetails` dauerhaft mitschreiben, Fill nachbuchen, Zustand über einen App-Neustart hinweg rekonstruieren. Ändert den Seam. **Zugleich Voraussetzung für OptionsWheel (dort `W-2`)** – die Aufgabe stand doppelt in zwei Konzepten. | ⬜ | IBKR-Integration, W-2 | +| **H3** | **IBKR-Zugangsdaten mit `EncryptedStringConverter` ablegen.** Der Konverter ist gebaut und getestet, die Credentials nutzen ihn noch nicht. | ⬜ | R7 | +| **H4** | **IBC/IBController einrichten** – IBKR erzwingt 2FA und täglichen Neustart des Gateways. Ohne Auto-Login gibt es keinen unbeaufsichtigten Betrieb. Für Linux zusätzlich kopflos (IBC + Xvfb). Reine Betriebsarbeit, unabhängig vom Code. | ⬜ | L-Ergebnis, IBKR-Integration §Offen 2 | +| **T1** | **Entscheiden, welcher IBKR-Zugangsweg bleibt.** Es gibt zwei parallele: den TWS-API-Adapter (`Trading/Ibkr/`, der handelnde Pfad) und `IBKRGatewayService` (Client Portal REST, versorgt Instrument-Sync, Kurshistorie und den Watchdog-Heartbeat). Zwei Broker-APIs bedeuten zwei Fehlerbilder, zwei Authentifizierungen und zwei Betriebsvoraussetzungen. Entweder die Historie auf `reqHistoricalData` umziehen und den REST-Weg aufgeben – oder die Doppelung ausdrücklich begründen. | ⬜ | IBKR-Integration §Offen 4, Befund 2026-08-23 | + +--- + +## Stufe 3 – Options-Fundament im Core + +*Reine Core-Arbeit. Nützt allen Modulen, nicht nur dem Wheel. Der Aktienpfad bleibt unverändert – +neue Felder sind optional, `Kind = Stock` ist der Default.* + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **O1** | `InstrumentKind`/`OptionSpec`, `IbkrMapping.Option`, Positionen mit Multiplikator. Heute rechnet `Position.Notional` als `Quantity × AvgPrice` – bei Optionen um Faktor 100 falsch, womit **jedes Risikolimit wirkungslos wäre**. | ⬜ | W-0 | +| **O2** | Optionskette + Greeks im Core (`reqSecDefOptParams`, `tickOptionComputation`). Gegen das Paper-Gateway bereits nachgemessen: 24 Verfallstermine, 127 Strikes, Greeks auch mit **verzögerten** Daten über die Tick-Felder 80–83 (Feld 83 = Modell ist die maßgebliche Variante). | ⬜ | W-1 | +| **O3** | *(= **H2**, siehe Stufe 2 – dieselbe Aufgabe, hier als Wheel-Voraussetzung geführt)* | ⬜ | W-2 | +| **O4** | Positionsabgleich (Zuteilung & Verfall ändern Positionen **ohne** Order von uns) + `RiskService` um sell-to-open und Deckungsprüfung erweitern. Heute lehnt `EvaluateSell` einen Verkauf ohne Bestand grundsätzlich ab – das ist die Kernoperation des Wheels. **Niemals nackt:** Short Call nur mit 100 freien Aktien je Kontrakt, Short Put nur mit reserviertem Cash über Strike × 100. Die Prüfung gehört in den Core, damit ein Modulfehler keine ungedeckte Option schreiben kann. | ⬜ | W-3 | +| **O5** | **IV-Rank als Core-Baustein**, nicht als Modul-Interna. Die Kennzahl braucht jede Prämienstrategie und sie gehört neben die Kurshistorie in die Datenschicht. | ⬜ | Datenlage §4 | + +--- + +## Stufe 4 – Kapital- und Buchmodell + +*Wird scharf, sobald ein **zweites** Modul handelt. Heute handelt nur CongressTrading; mit dem +Wheel sind es zwei, die sich ein Konto und ein Guthaben teilen. Das vollständig ausgearbeitete +Konzept liegt im [Archiv](archiv/Kapital-und-Buchmodell.md) – es ist Referenz, gegen die die +Umsetzung geprüft wird, und war nie umgesetzt.* + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **K1** | **Bücher + Eigentumsregeln.** Jede Position hat genau einen Eigentümer; kein Modul fasst die Position eines anderen oder eine manuell angelegte an. Im Core erzwungen, nicht per Konvention. | ⬜ | Kapitalmodell §2 | +| **K2** | **Ein Pool, Obergrenzen.** Kein Kapitaltransfer zwischen Büchern, niemals aktives Schließen zum Balancieren. Limit-Verletzung ist ein hartes Gate mit strukturiertem Feedback – die Reaktion entscheidet die Strategie, nicht der Core. | ⬜ | Kapitalmodell §3, §6 | +| **K3** | **Margin-Sperre in vier Schichten:** richtige Bemessungsgrundlage (`min(TotalCashValue, AvailableFunds)` − Hausreserve − offene Reservierungen), kein Short, Währungstrennung, Watchdog. Modul-Handel ist strikt cash-only; manueller Handel darf Margin nutzen. | ⬜ | Kapitalmodell §4 | +| **K4** | **Reservierungen über den Order-Lebenszyklus** inkl. Crash-Recovery: beim Start alle nicht-terminalen Reservierungen gegen die offenen Broker-Orders abgleichen. Hängt an **H2**. | ⬜ | Kapitalmodell §5 | +| **K5** | **Abgleich (Reconciliation)** gegen den Broker: `Broker < Ledger` heißt Break – betroffene Bücher und Symbol für neue Orders sperren, Alarm. Unzugeordnete Positionen in Quarantäne, Eskalation nach 30 Minuten mit Backoff. | ⬜ | Kapitalmodell §8, §9 | +| **K6** | **Benachrichtigungen** über Outbox + Sink-Abstraktion. Zielkanal Matrix, Telegram optional. | ⬜ | Kapitalmodell §10 | +| **K7** | **Startwerte festlegen** und in `settings.example.json` dokumentieren: `MaxSymbolPercent`, `HouseReserve`, FX-Haircut, Slippage-Puffer, Reservierungs-TTL, Mindestordergröße je Buch, Handelsplatz-Whitelist je Währung. Beim Bauen zu entscheiden. | ⬜ | Kapitalmodell §15 | + +--- + +## Stufe 5 – Modul OptionsWheel + +*Erst ab hier entsteht das Modul selbst. Vollautomatisch von Anfang an – Sicherungen sind Schalter +und Limits, keine Klick-Freigabe. Strike-Wahl delta-basiert im Band 0,15–0,30. Nur Watchlist, +kein Screening.* + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **W1** | Modul-Gerüst: `IModule`, `ow_`-DbContext + Migration, UI-Tabs, Watchlist. Abschluss: App startet, `--smoke-ui` grün, **kein Handel**. | ⬜ | W-4 | +| **W2** | Reine Strategie-Logik + Tests: `StrikeSelector`, Zustandsautomat je Ticker, `RollDecider`, `PremiumMath`, `CoverageCalculator`. Hohe Testabdeckung ohne Broker. | ⬜ | W-5 | +| **W3** | Verdrahtung + vollautomatischer **Paper**-Betrieb über mehrere Verfallszyklen. Abschluss: mindestens ein vollständiger Wheel-Durchlauf im Paper. | ⬜ | W-6 | +| **W4** | **Earnings-Sperre über den IV-Behelf.** Keine neuen Legs, wenn die IV des Basiswerts deutlich über ihrem 30-Tage-Mittel liegt. Die saubere Lösung (echte Termine für Quartalszahlen) ist über die TWS API **nicht** erreichbar – Fehler 10358, Refinitiv-Abo nötig. Einzige Stelle, an der uns eine externe Quelle ernsthaft fehlt. | ⬜ | W-§7.4, Datenlage §2 | +| **W5** | **Accounting-Anschluss für Optionen:** eigene Buchungskategorien im `AccountingClassifier` für Prämien, Zuteilungen und Abrufe. Der `RealizedPnlEngine` (FIFO) kennt heute weder Multiplikator noch die Einstandsverschiebung durch Zuteilung. Arbeit im Accounting-Modul, nicht im Wheel. | ⬜ | W-§7.5 | +| **W6** | **Live-Freigabe.** Eigene Entscheidung nach W3, kein technischer Schritt. | ⬜ | W-7 | + +--- + +## Laufende Bahnen + +*Hängen an keiner Stufe und können jederzeit dazwischen laufen.* + +### Auslieferung / Deploymentcenter + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **D2** | **Projekt `ibkrtrader` im DC-WebUI anlegen** + Token mit `watchdog:ping` und `bugtracker:report`. Serverseitige Handarbeit; ohne sie bleiben Heartbeat, Lizenz und Bugtracker wirkungslos. | ⬜ | DC-Schritt 9 | +| **D3** | **Update-Anwenden verdrahten.** Die Update-**Prüfung** läuft beim Start. `DcUpdateService.LaunchAgent` ist fertig und dokumentiert (`exitCurrentApp` bewusst immer `false`), aber **kein Aufrufer** fährt danach geordnet herunter. Gefundene Updates werden also nie eingespielt. | 🔶 | DC-Schritt 7 | +| **D4** | **Erstes echtes Release fahren.** Pipeline (`scripts/release.*`, `setup.json`) steht, ist aber nie gelaufen. Dabei entsteht `packager.config.json` unter `.dc-tools/`. **Achtung:** Die `preservePatterns` müssen beim *ersten* Release stimmen – ein Update, das `settings.json` überschreibt, nimmt einer laufenden Installation Datenbank, Token und Flex-Zugang gleichzeitig. Ebenso muss der erste Build bereits den `licenseKey` mitgeben, sonst fällt die Tür hinter dem ersten Release zu (bei Predictalytics genau so passiert). | ⬜ | DC-Schritt 8, P6, D2 | +| **D5** | **Bugtracker-Baustein** nach `AGENTS.md` / `.agents/rules`. Braucht **D2**. | ⬜ | DC-Schritt 9 | +| **D6** | **Lizenzfenster für die Shell.** `LicenseGuard` läuft mit `allowPrompt: false` – weder Shell noch Daemon dürfen auf eine Konsoleneingabe warten, die nie kommt. Ein eigenes Fenster für die Desktop-Shell war als Folgeschritt vorgesehen. | ⬜ | DC §5.2 | + +### Accounting + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **A1** | **Live-IBKR-Flex-Abruf** (Token + Query-Id) und Balance-Anker. Heute liegen dort Offline-Null-Stubs: Das Modul läuft vollständig und bucht dabei korrekt nichts. Ohne diesen Schritt entstehen **keine echten Buchungen** – das Modul ist lauffähig, aber nicht in Betrieb. | ⬜ | Accounting §6 | +| **A2** | **EZB-FX-Ingest** (`acc_fx_rates` füllen) für die EUR-Ansicht. USD als Basis ist sofort verfügbar. | ⬜ | Accounting §6 | +| **A3** | **Steuerschicht.** Jurisdiktion (DE-Kapitalertragsteuer / US Form 8949) ist **nicht festgelegt**. Der neutrale Ledger und die Abrechnung gelten unabhängig davon; die Steuer-Engine ist als klar abgetrennter Platzhalter angelegt. Das Jurisdiktionsprofil wird einmalig gesetzt und danach in der DB verankert. **Keine Steuerberatung.** | ⬜ | Accounting §6, Kapitalmodell §11 | + +### Supervisor + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **S1** | **Counterfactual-Kursauflösung für Aktien** (späterer Kurs vs. Signalpreis) – Interface und Stub sind vorhanden, die Auflösung fehlt. | ⬜ | Supervisor §offen | +| **S2** | **Externer Versand des Tagesberichts.** Heute nur Persistenz und Log. Sollte denselben Outbox-/Sink-Weg nehmen wie **K6**, statt einen zweiten zu bauen. | ⬜ | Supervisor §offen | + +### Technische Schulden + +| # | Aufgabe | Stand | Herkunft | +|---|---|---|---| +| **T2** | **Log-Level ist nicht konfigurierbar.** `LoggingService.SetMinLevel` ist der einzige Setter und wird nie gerufen; `_minLevel` steht damit fest auf `Info`, und da `Info = 0` der kleinste Wert ist, filtert die Prüfung `level < _minLevel` nie etwas. Entweder an die Einstellungen anbinden oder den Filter aufgeben. | ⬜ | Befund 2026-08-23 | +| **T3** | **Es gibt kein einziges Diagramm.** LiveCharts2 ist in der NuGet-Allowlist vorgesehen und **Avalonia ist deswegen auf der 11er-Linie festgehalten** (11.3.19 / DataGrid 11.3.13). Diese Pinnung kostet uns Avalonia 12, ohne dass bisher ein Diagramm existiert. Entweder mit den neuen Modulen einlösen oder die Pinnung aufgeben. | ⬜ | L-Ergebnis, grundregeln | + +--- + +## 🧊 Zurückgestellt – vorgehalten, aber nicht jetzt + +*Bewusste Entscheidungen, keine Versäumnisse. Jede Zeile nennt, **was sie wieder aktuell macht**.* + +| Idee | Warum nicht jetzt | Wird aktuell, wenn … | Herkunft | +|---|---|---|---| +| **Trendfolge-/Momentum-Modul** auf Tagesbasis als zweites Standbein | Datenlage ist komfortabel (10 J Tagesbars, dividendenbereinigt), das Risiko liegt in der Strategie. Aber ein zweites handelndes Modul vor dem Kapitalmodell wäre fahrlässig. | Wheel im Paper läuft **und** Stufe 4 steht | Datenlage §4 | +| **Marktdaten-Abo US-Realtime** (NYSE/AMEX/NASDAQ) | Schaltet Scanner und Realtime frei. Für Tages- und Prämienstrategien **nicht nötig** – unsere Signale kommen aus abgeschlossenen Bars, die 15-Minuten-Verzögerung ist dabei irrelevant. | wir Screening oder Intraday wollen | Datenlage §4 | +| **OPRA-Abo** (Optionen-Realtime) | Verbessert die Ausführungsqualität beim Wheel; für die Strike-Auswahl nachweislich nicht erforderlich (Greeks funktionieren verzögert). | die Ausführungsqualität im Paper-Betrieb messbar stört | W-§7.3 | +| **Refinitiv-Fundamentaldaten** | Der Kandidat mit dem größten qualitativen Sprung: löst die Earnings-Sperre und öffnet fundamentale Ansätze. Kostet aber Geld für ein System, das noch nie eine Order platziert hat. | der IV-Behelf (**W4**) sich als zu unscharf erweist | Datenlage §4 | +| **Self-Cross-Netting** (Modul A kauft, B verkauft dasselbe Symbol) | Bei unserer Handelsfrequenz unrealistisch. **Billige Vorstufe stattdessen:** ist im Order-Gateway eine gegenläufige Order für dasselbe Symbol pending, wird protokolliert und gewarnt – der Lock ist ohnehin da. Das liefert Daten darüber, ob das Problem je real wird. | die Warnung tatsächlich anschlägt | Kapitalmodell §14 | +| **Corporate Actions** (Splits, Spin-offs) in der Buchzuordnung | Vorerst über den Flex-Abgleich als Break sichtbar, manuelle Zuordnung. | ein Break real auftritt | Kapitalmodell §14 | +| **Web-UI** über die interne REST-API | Die REST-API existiert, ein Web-UI ist reine Zusatzarbeit ohne Betriebsnutzen, solange Shell und Daemon reichen. | Fernzugriff nötig wird | grundregeln | +| **Desktop-Distribution der Shell** über die Release-Pipeline | Die Vorlage nimmt genau eine csproj für alle Runtimes, und das Skript bleibt laut Anleitung unverändert. Release-Kandidat ist deshalb `IBKRTrader.Daemon`. | die Shell auf fremden Rechnern laufen soll | release.config.json | +| **Ungeprüfte Datenfragen**: `reqNewsArticle` (Volltext), Reichweite der Nachrichtenhistorie, Markttiefe (`reqMktDepth`), leeres `reqHistogramData`, Verlässlichkeit verzögerter Greeks außerhalb der Handelszeiten, Ratenbegrenzung bei Historienabrufen | Keine dieser Fragen blockiert die geplanten Strategien. | eine Strategie sie braucht – die Ratenbegrenzung schon bei einem nächtlichen Watchlist-Abruf | Datenlage §5 | + +--- + +## ❌ Verworfen – geprüft und entschieden + +*Damit nichts davon in sechs Monaten erneut als gute Idee auftaucht.* + +| Idee | Warum verworfen | +|---|---| +| **Echte IBKR-Sub-Accounts** (Advisor-/Family-Struktur) zur brokerseitigen Trennung der Bücher | Erfordert Kontotypwechsel und feste Vorabaufteilung des Kapitals – deutlich unflexibler als virtuelle Bücher, die denselben Zweck erfüllen. | +| **`InvariantGlobalization=true`** für ein schlankes Linux-Image | In der Portierungsanalyse noch empfohlen, **wäre ein Fehler gewesen**: ohne ICU fällt die Auflösung von Windows-Zeitzonen-IDs aus und die feste `de-DE`-Formatierung des PDF-Exports kippt auf invariant. Beides lautlos. Der Daemon setzt es ausdrücklich auf `false`. | +| **Fundamentales Screening** (Value, Quality, Growth) | Keine Fundamentaldaten über die TWS API. | +| **Earnings-Strategien** (Straddle vor Zahlen, Post-Earnings-Drift) | Keine Termine für Quartalszahlen erreichbar (Fehler 10358). | +| **Marktweite Anomalie-Suche / Screener-getriebene Auswahl** | Der Marktscanner ist ohne Realtime-Abo gesperrt. Jede Strategie arbeitet auf einer gepflegten Watchlist. | +| **Daytrading, Scalping, Orderbuch-Strategien** | Verzögerte Kurse (~15 Min). Ausführung träfe den Markt zu spät. | +| **Gap-Strategien auf Eröffnung** | Eröffnungskurs kommt verzögert – nur mit Realtime-Abo sinnvoll. | +| **Strike-Wahl über prozentualen Abstand** statt delta-basiert | Als Ersatzlösung gedacht, falls Greeks mit verzögerten Daten nicht funktionieren. Sie funktionieren (am 2026-08-04 gemessen). Bleibt im `StrikeSelector` nur als Rückfalllinie. | +| **Agent-zu-Agent-Orchestrierung im Supervisor** | Bewusst nicht: Profile sind System-Prompt + Tool-Subset über *einer* Infrastruktur. Einfacher und nachvollziehbarer. | +| **Modulzuordnung als Korrektur des Steuerbuchs** | Harte Regel: Das Managementbuch beeinflusst das Steuerbuch **niemals**. Die Zuordnung ist eine optionale, nicht-autoritative Beistelltabelle – fehlt sie oder ist sie falsch, ändert sich am Steuerergebnis exakt nichts. | + +--- + +## Fertig – der Weg bis hierher + +*Kurzfassung. Die vollständigen Phasen-Checklisten stehen weiterhin in [ARCHITECTURE.md](ARCHITECTURE.md).* + +| Abschnitt | Inhalt | Fertig | +|---|---|---| +| **R1–R7** | Kurskorrektur auf das PolytraderSharp-Konzept: Multi-Projekt, Generic Host, EF Core, Trading-Kern, CongressTrading-Strategie, Security, Dashboard, TWS-Broker-Adapter | 2026-07 | +| **S-0–S-4** | Supervisor: Datenfundament (Entscheidungsjournal, Order-Events, `SignalId`, JSONL-Logs), Dossiers, OpenRouter-Agent mit read-only Tools, Berichte, MCP-Light | 2026-07-30 | +| **Accounting** | `acc_`-Schema, append-only Ingest, Klassifizierung, Abrechnung, FX, CSV-/PDF-Export – mit Offline-Null-Stubs | 2026-07-30 | +| **L0–L6** | Linux-Portierung: Avalonia statt WinForms, Betriebszeitzone, kopfloser Daemon, geteiltes Hosting, WinForms vollständig entfernt, Namensgebung bereinigt | 2026-08-07 | +| **DC 0–8** | Deploymentcenter: Lizenz mit Sperrbetrieb, Watchdog-Heartbeat, globale Ausnahmebehandler + Fehler-Stream, Update-Prüfung, `setup.json`, Release-Pipeline | 2026-08-23 | +| **Frühjahrsputz** | Toter Code entfernt, ungenutzte Symbole und Paketmuster raus, Dokumentenstand an die Wirklichkeit angeglichen | 2026-08-23 | + +--- + +## Archiv + +Die Quelldokumente sind **vollständig erhalten** und liegen unter [archiv/](archiv/). Sie werden +nicht mehr gepflegt – der Stand steht hier –, aber sie tragen die Herleitung, die Messwerte und die +Begründungen, die eine Roadmap nicht fassen kann. + +| Dokument | Was darin steht, das hier fehlt | +|---|---| +| [Kapital-und-Buchmodell.md](archiv/Kapital-und-Buchmodell.md) | Die vollständige Spezifikation: die drei Wahrheiten, Eigentumsregeln, Reservierungs-Lebenszyklus, Invarianten und Testkatalog. Referenz für Stufe 4. | +| [KONZEPT-Modul-OptionsWheel.md](archiv/KONZEPT-Modul-OptionsWheel.md) | Zustandsautomat, Regelwerk mit Vorgabewerten, `ow_`-Datenmodell, Sicherungen. Referenz für Stufe 5. | +| [KONZEPT-Datenlage-und-Strategien.md](archiv/KONZEPT-Datenlage-und-Strategien.md) | **Gegen das laufende Paper-Gateway gemessen**, nicht aus der Doku übernommen: was die TWS API liefert und welche Strategien das trägt. Grundlage der Zurückgestellt- und Verworfen-Listen. | +| [KONZEPT-Deploymentcenter-Integration.md](archiv/KONZEPT-Deploymentcenter-Integration.md) | Die bewussten Abweichungen vom DC-Leitfaden (Sperrbetrieb statt Prozessende, `exitCurrentApp: false`) samt Begründung, die Befunde P1–P6 und D1–D7. | +| [KONZEPT-Linux-Portierung.md](archiv/KONZEPT-Linux-Portierung.md) | Die Analyse vor dem Umbau: Fundstellenverzeichnis, Aufwandsschätzung und was anders kam als geschätzt. | +| [KONZEPT-Modul-Accounting.md](archiv/KONZEPT-Modul-Accounting.md) | Leitprinzipien (unabhängige Quelle, Idempotenz, append-only), Datenbeschaffung über Flex Query. | +| [KONZEPT-Modul-Supervisor.md](archiv/KONZEPT-Modul-Supervisor.md) | S-0 bis S-4 im Detail, Tool-Registry, Sicherheitsgrenzen des Agenten. | + +**Weiter gepflegt** werden – sie sind Referenz, keine Planung: +[ARCHITECTURE.md](ARCHITECTURE.md) (Aufbau und Phasen-Historie), +[IBKR-Integration.md](IBKR-Integration.md) (Adapter-Design und Grenzen), +[TWS-Setup-Checkliste.md](TWS-Setup-Checkliste.md) (Einrichtung eines neuen Systems). diff --git a/docs/konzepte/KONZEPT-Datenlage-und-Strategien.md b/docs/archiv/KONZEPT-Datenlage-und-Strategien.md similarity index 96% rename from docs/konzepte/KONZEPT-Datenlage-und-Strategien.md rename to docs/archiv/KONZEPT-Datenlage-und-Strategien.md index 2521ce3..aab3bed 100644 --- a/docs/konzepte/KONZEPT-Datenlage-und-Strategien.md +++ b/docs/archiv/KONZEPT-Datenlage-und-Strategien.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es **gegen das laufende Paper-Gateway gemessen** ist und nicht aus der IBKR-Doku uebernommen. +> Die Zurueckgestellt- und Verworfen-Listen der Roadmap stuetzen sich auf diese Messwerte. Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # Analyse: Datenlage über die TWS API – und welche Strategien sie trägt > Stand: 2026-08-04. **Alle Angaben in Abschnitt 1 und 2 sind gegen das laufende Paper-Gateway diff --git a/docs/konzepte/KONZEPT-Deploymentcenter-Integration.md b/docs/archiv/KONZEPT-Deploymentcenter-Integration.md similarity index 98% rename from docs/konzepte/KONZEPT-Deploymentcenter-Integration.md rename to docs/archiv/KONZEPT-Deploymentcenter-Integration.md index 6d361d6..43f66e3 100644 --- a/docs/konzepte/KONZEPT-Deploymentcenter-Integration.md +++ b/docs/archiv/KONZEPT-Deploymentcenter-Integration.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) (Bahn „Auslieferung / Deploymentcenter") – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es die bewussten Abweichungen vom DC-Leitfaden begruendet – Sperrbetrieb statt +> Prozessende, `exitCurrentApp: false` – und die Befunde P1–P6 und D1–D7 nachweist. Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # KONZEPT: Deploymentcenter-Integration > Stand: 2026-08-14 · Deploymentcenter-Version **2.5.1** · Quelle: `J:\Softwareprojekte\Deploymentcenter\docs`, diff --git a/docs/konzepte/KONZEPT-Linux-Portierung.md b/docs/archiv/KONZEPT-Linux-Portierung.md similarity index 98% rename from docs/konzepte/KONZEPT-Linux-Portierung.md rename to docs/archiv/KONZEPT-Linux-Portierung.md index 895e35b..06b13b4 100644 --- a/docs/konzepte/KONZEPT-Linux-Portierung.md +++ b/docs/archiv/KONZEPT-Linux-Portierung.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es die Analyse vor dem Umbau ist: Fundstellenverzeichnis, Aufwandsschaetzung und +> was anders kam als geschaetzt. Die Portierung selbst ist abgeschlossen (L0–L6). Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # Analyse: Linux-Fähigkeit des IBKRTrader > **UMGESETZT am 2026-08-07 (L0–L5).** Dieses Dokument ist die Analyse, die der Portierung diff --git a/docs/konzepte/KONZEPT-Modul-Accounting.md b/docs/archiv/KONZEPT-Modul-Accounting.md similarity index 91% rename from docs/konzepte/KONZEPT-Modul-Accounting.md rename to docs/archiv/KONZEPT-Modul-Accounting.md index fb81b70..b2d4bd7 100644 --- a/docs/konzepte/KONZEPT-Modul-Accounting.md +++ b/docs/archiv/KONZEPT-Modul-Accounting.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) (Bahn „Accounting") – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es die Leitprinzipien traegt – unabhaengige Quelle, Idempotenz, append-only – +> und die Datenbeschaffung ueber die Flex Query beschreibt. Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # Konzept: Modul „Accounting" (Buchhaltung/Reporting aller Konten) > **UMGESETZT (Modulgerüst).** Das Modul steht: `acc_`-Schema mit Migration `InitialAccounting`, diff --git a/docs/konzepte/KONZEPT-Modul-OptionsWheel.md b/docs/archiv/KONZEPT-Modul-OptionsWheel.md similarity index 96% rename from docs/konzepte/KONZEPT-Modul-OptionsWheel.md rename to docs/archiv/KONZEPT-Modul-OptionsWheel.md index 5c50e07..c6c2133 100644 --- a/docs/konzepte/KONZEPT-Modul-OptionsWheel.md +++ b/docs/archiv/KONZEPT-Modul-OptionsWheel.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) (Stufe 5, dazu die Core-Voraussetzungen in Stufe 3) – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es den Zustandsautomaten, das Regelwerk mit allen Vorgabewerten und die Begruendung enthaelt, +> warum das Modul nicht additiv auf den heutigen aktienbasierten Core passt. Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # Konzept: Modul „OptionsWheel" (Covered Call / Cash-Secured Put) > Stand: 2026-08-03 diff --git a/docs/konzepte/KONZEPT-Modul-Supervisor.md b/docs/archiv/KONZEPT-Modul-Supervisor.md similarity index 91% rename from docs/konzepte/KONZEPT-Modul-Supervisor.md rename to docs/archiv/KONZEPT-Modul-Supervisor.md index ad6fbfc..25b6077 100644 --- a/docs/konzepte/KONZEPT-Modul-Supervisor.md +++ b/docs/archiv/KONZEPT-Modul-Supervisor.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) (Bahn „Supervisor") – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es S-0 bis S-4 im Einzelnen beschreibt, samt Tool-Registry und den +> Sicherheitsgrenzen des Agenten. Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # Konzept: Modul „Supervisor" (KI-gestützte Handels-Analyse & Forensik) > **UMGESETZT (S-0 bis S-4).** Datenfundament im Core (`core_decision_journal`, `core_order_events`, diff --git a/docs/Kapital-und-Buchmodell.md b/docs/archiv/Kapital-und-Buchmodell.md similarity index 97% rename from docs/Kapital-und-Buchmodell.md rename to docs/archiv/Kapital-und-Buchmodell.md index ff0da18..fd6a37f 100644 --- a/docs/Kapital-und-Buchmodell.md +++ b/docs/archiv/Kapital-und-Buchmodell.md @@ -1,3 +1,13 @@ +> ### 📦 Archiviert am 2026-08-23 +> Dieses Dokument wird **nicht mehr gepflegt**. Was davon noch offen ist, steht in der +> [Roadmap](../ROADMAP.md) (Stufe 4) – dort und nur dort wird der Stand nachgeführt. +> +> Es bleibt erhalten, weil es die vollstaendige Spezifikation ist, gegen die die Umsetzung geprueft wird – +> die drei Wahrheiten, Eigentumsregeln, Reservierungs-Lebenszyklus, Invarianten und Testkatalog. Zum Nachschlagen also weiterhin richtig, +> als Aufgabenliste nicht mehr. + +--- + # Kapital- und Buchmodell > **Status: Konzept (2026-08-03) – noch nicht implementiert.** diff --git a/src/IBKRTrader.Core/Persistence/Entities/AnalysisEntities.cs b/src/IBKRTrader.Core/Persistence/Entities/AnalysisEntities.cs index fe74315..e8926a3 100644 --- a/src/IBKRTrader.Core/Persistence/Entities/AnalysisEntities.cs +++ b/src/IBKRTrader.Core/Persistence/Entities/AnalysisEntities.cs @@ -47,7 +47,7 @@ public enum OrderEventType /// /// Eine Zeile im Entscheidungsjournal (core_decision_journal): JEDE Handelsentscheidung – /// ausgeführt, abgelehnt oder übersprungen – strukturiert und abfragbar. Grundlage für -/// Supervisor-Analysen („warum (nicht) gehandelt?"). Siehe docs/konzepte/KONZEPT-Modul-Supervisor.md. +/// Supervisor-Analysen („warum (nicht) gehandelt?"). Siehe docs/archiv/KONZEPT-Modul-Supervisor.md. /// public class CoreDecisionRecord { diff --git a/src/IBKRTrader.Hosting/IBKRTrader.Hosting.csproj b/src/IBKRTrader.Hosting/IBKRTrader.Hosting.csproj index 3b10178..fe7425c 100644 --- a/src/IBKRTrader.Hosting/IBKRTrader.Hosting.csproj +++ b/src/IBKRTrader.Hosting/IBKRTrader.Hosting.csproj @@ -25,7 +25,7 @@ + docs/archiv/KONZEPT-Deploymentcenter-Integration.md §2.2. --> diff --git a/src/IBKRTrader.Modules.Accounting/AccountingModule.cs b/src/IBKRTrader.Modules.Accounting/AccountingModule.cs index 568bece..40e1b91 100644 --- a/src/IBKRTrader.Modules.Accounting/AccountingModule.cs +++ b/src/IBKRTrader.Modules.Accounting/AccountingModule.cs @@ -14,7 +14,7 @@ namespace IBKRTrader.Modules.Accounting; /// Modul „Accounting": von unserer Trading-DB UNABHÄNGIGE, buchhalterisch korrekte Erfassung aller /// Kontobewegungen (IBKR-Kontoauszug → append-only Ledger) mit Periodenabrechnung/BWA, FX (USD/EUR) und /// CSV/PDF-Export. Reines Ingest-/Reporting-Modul, KEIN Handel. Konzept: -/// docs/konzepte/KONZEPT-Modul-Accounting.md. +/// docs/archiv/KONZEPT-Modul-Accounting.md. /// /// Live-Abruf (IBKR Flex Query) liegt hinter Interfaces mit Null-Stubs → das Modul läuft offline und /// bucht dann korrekt nichts. Die konkrete Steuerschicht ist bewusst offen (neutraler Ledger gilt diff --git a/src/IBKRTrader.Modules.Supervisor/SupervisorModule.cs b/src/IBKRTrader.Modules.Supervisor/SupervisorModule.cs index 7fb0952..ebc6a60 100644 --- a/src/IBKRTrader.Modules.Supervisor/SupervisorModule.cs +++ b/src/IBKRTrader.Modules.Supervisor/SupervisorModule.cs @@ -18,7 +18,7 @@ namespace IBKRTrader.Modules.Supervisor; /// Supervisor-Modul: KI-gestützte Analyse/Forensik über ALLE Module — strikt read-only (kein Handel). /// Dossier-Browser über Entscheidungsjournal/Order-Events/Trade-Log/JSONL-Logs, OpenRouter-Agent mit /// read-only Tool-Registry, optional Counterfactual-Auswertung, Tagesbericht und MCP-Light. Konzept: -/// docs/konzepte/KONZEPT-Modul-Supervisor.md. +/// docs/archiv/KONZEPT-Modul-Supervisor.md. /// public sealed class SupervisorModule : IModule {