Eine Roadmap statt sieben Konzepte; Quelldokumente ins Archiv

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>
2026-08-23 18:14:51 +02:00
parent e1546bd1b1
commit 9f66183f1c
16 changed files with 362 additions and 32 deletions
@@ -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
+**➡️ Was noch zu tun ist, steht vollständig in der [Roadmap](docs/ROADMAP.md).** Sie ist seit dem
-  Flex / OpenRouter-Key) und Steuerschicht sind bewusst noch offen (Stubs/Platzhalter).
+2026-08-23 das einzige Dokument, das den offenen Stand führt – einschließlich der Ideen, die wir
- **IBKR-Broker über die TWS API / IB Gateway** ist implementiert (Paper-Konto steht, Verbindung
+bewusst zurückstellen (🧊) und derer, die wir geprüft und verworfen haben (❌). Die früheren
-  verifiziert) – Design und offene Punkte: [docs/IBKR-Integration.md](docs/IBKR-Integration.md),
+Konzepte liegen unverändert unter [docs/archiv/](docs/archiv/) und tragen die Herleitung.
-  TWS-Einstellungen: [docs/TWS-Setup-Checkliste.md](docs/TWS-Setup-Checkliste.md).
+
 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
@@ -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
@@ -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)
+- [ ] **Offen → Roadmap [H1](ROADMAP.md) / [H2](ROADMAP.md):** `PlaceOrderAsync` mit echter Ausführung verifizieren (Fill → Buchung); asynchrone Fill-Verfolgung (Orders ohne sofortige Ausführung)
- [ ] IBKR-Account-Credentials mit `EncryptedStringConverter` speichern
+- [ ] **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;
+**Offen → Roadmap [H4](ROADMAP.md) / [T3](ROADMAP.md):** IB Gateway kopflos betreiben (IBC + Xvfb)
-LiveCharts2 kommt mit den neuen Modulen (Avalonia deshalb auf der 11er-Linie gepinnt).
+– 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.
 ---
@@ -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).
+Die offenen Punkte dieses Adapters werden seit dem 2026-08-23 in der
-2. IBC für Auto-Login/Neustart einrichten (Server-Betrieb).
+[Roadmap](ROADMAP.md) gefuehrt, nicht mehr hier – sie haengen mit Aufgaben aus anderen Konzepten
-3. Asynchrone Fill-Verfolgung, siehe „Bekannte Grenze" oben.
+zusammen und standen deshalb doppelt. Es sind:
-4. Entscheiden, ob die Marktdaten-Historie von der CP Web API auf `reqHistoricalData` wandert.
+
 | 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.
@@ -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).
@@ -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
@@ -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`,
@@ -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
@@ -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`,
@@ -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
@@ -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`,
@@ -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.**
@@ -47,7 +47,7 @@ public enum OrderEventType
 /// <summary>
 /// 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.
 /// </summary>
 public class CoreDecisionRecord
 {
@@ -25,7 +25,7 @@
    <!-- Externes Schwester-Repo: J:\Softwareprojekte\Deploymentcenter muss neben dem IBKRTrader-Checkout
         liegen (..\..\..\..\ von hier aus). Liefert Lizenz, Watchdog, UpdateService, Fehler-Stream und
         Bugtracker. Interimslösung, solange kein NuGet-Paket in der Gitea-Registry liegt - siehe
-         docs/konzepte/KONZEPT-Deploymentcenter-Integration.md §2.2. -->
+         docs/archiv/KONZEPT-Deploymentcenter-Integration.md §2.2. -->
    <ProjectReference Include="..\..\..\..\Deploymentcenter\client-dotnet\Deploymentcenter.Client\Deploymentcenter.Client.csproj" />
  </ItemGroup>
@@ -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
@@ -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.
 /// </summary>
 public sealed class SupervisorModule : IModule
 {