IBKRTrader/docs/ROADMAP.md

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/ – 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 – 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.

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/. 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	Die vollständige Spezifikation: die drei Wahrheiten, Eigentumsregeln, Reservierungs-Lebenszyklus, Invarianten und Testkatalog. Referenz für Stufe 4.
KONZEPT-Modul-OptionsWheel.md	Zustandsautomat, Regelwerk mit Vorgabewerten, ow_-Datenmodell, Sicherungen. Referenz für Stufe 5.
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	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	Die Analyse vor dem Umbau: Fundstellenverzeichnis, Aufwandsschätzung und was anders kam als geschätzt.
KONZEPT-Modul-Accounting.md	Leitprinzipien (unabhängige Quelle, Idempotenz, append-only), Datenbeschaffung über Flex Query.
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 (Aufbau und Phasen-Historie), IBKR-Integration.md (Adapter-Design und Grenzen), TWS-Setup-Checkliste.md (Einrichtung eines neuen Systems).