# Roadmap PolyTrader **Der Planungsstand steht im Deploymentcenter, nicht in dieser Datei.** Was zwischen den `dc:roadmap`-Markern steht, ist eine **erzeugte Kopie** und darf älter sein als der echte Stand — dort niemals von Hand etwas ändern, der nächste Lauf überschreibt es. Der Live-Stand kommt aus `dc_roadmap`; die Kennung eines Vorhabens ist seine Item-Nummer. Was diese Datei behält, ist die Hälfte, die eine Tabellenzelle nicht trägt: **die Begründung.** Warum etwas zurückgestellt wurde, woran man erkennt, dass „später" jetzt ist, und warum ein verworfener Vorschlag verworfen blieb. Wer etwas erneut vorschlagen will, findet hier das Argument, gegen das er antreten muss. > **Arbeitsteilung:** Was **ist** → [PROJEKTSTAND.md](./PROJEKTSTAND.md) (Architektur, > Kennzahlen, Modul-Stand). Was **kommt** → das Deploymentcenter. Warum → diese Datei. Die Detailpläne unter [`archiv/`](./archiv/) sind **nicht tot**: Für die Umsetzung eines Vorhabens ist der jeweilige Plan weiterhin die Bauanleitung mit Code-Bezügen und Akzeptanzkriterien. Nur der *Status* darin ist überholt. --- ## Wie die Reihenfolge gemeint ist **Die Themenbereiche A → P → B → C → D sind eine Reihenfolge, keine Termine.** Jeder schafft die Voraussetzung für den nächsten. Neue Strategiemodule vor der Abnahme des Bestehenden zu bauen, vergrößert nur die Menge an ungeprüftem Code, der echtes Geld bewegt. **Zwei Regeln, die aus Erfahrung in diesem Projekt stammen:** 1. **Kein Livegang ohne Messphase.** Jedes Strategiemodul läuft erst read-only oder in Demo, bis der Edge gemessen ist. Das hat sich bei ResolutionFarming bewährt und ist bei MarketMaking, BundleArbitrage und DataDriven bereits so geplant. 2. **Was blockiert ist, steht auf „zurückgestellt" mit dem Auslöser, der es freigibt.** Ein zurückgestelltes Vorhaben ohne benannten Anlass ist ein vergessenes. Steht im Auslöser eine Item-Nummer, ist das die Abhängigkeit. Für alles, was Geld bewegt, gilt zusätzlich [`.agents/rules/clob.md`](../.agents/rules/clob.md). --- ### Als Naechstes 1. **[A] #135 — Abnahme der Oberflaeche** 2. **[A] #136 — Deploymentcenter live abnehmen** 3. **[A] #137 — Linux-Betrieb auf einer Test-VM** 4. **[A] #50 — Kalendersymbol im Datumsfeld wird unter Linux als sinnlose Zahl gezeichnet** ### A — Abnahme und Fundament | | Vorhaben | Stand | Ziel | |---|---|---|---| | #135 | Abnahme der Oberflaeche | 📋 Offen | — | | #136 | Deploymentcenter live abnehmen | 📋 Offen | — | | #137 | Linux-Betrieb auf einer Test-VM | 📋 Offen | — | | #138 | Feldtest im Zielland | 🧊 Zurueckgestellt — Ausloeser: sobald #136 und #137 abgeschlossen sind | — | | #139 | Master-Key setzen, Zugaenge rotieren | 🧊 Zurueckgestellt — Ausloeser: sobald #138 abgeschlossen ist | — | | #50 | Kalendersymbol im Datumsfeld wird unter Linux als sinnlose Zahl gezeichnet | 📋 Offen | — | | #51 | Leere Tabellen sagen nicht, warum sie leer sind | 📋 Offen | — | | #56 | Master-Trader-Grid: letzte fuenf Spalten werden auf Reststreifen zusammengedrueckt | 📋 Offen | — | ### P — Pruefung und Tests | | Vorhaben | Stand | Ziel | |---|---|---|---| | #140 | CI-Runner registrieren | 🧊 Zurueckgestellt — Ausloeser: sobald auf der Gitea-Maschine oder einer Linux-Test-VM Leistung fuer einen weiteren Container frei ist | — | | #52 | --smoke-ui setzt Datenbank und X-Server voraus, laeuft daher nicht in der CI | 📋 Offen | — | | #141 | Pruefverfahren nach Deploymentcenter-Konvention verankern | 📋 Offen | — | ### B — Module scharf schalten | | Vorhaben | Stand | Ziel | |---|---|---|---| | #142 | CopyTrading Phase 1 - Marktdaten-Fundament | 📋 Offen | — | | #143 | Supervisor: Live-Key-Test | 📋 Offen | — | | #144 | CopyTrading Restposten | 🧊 Zurueckgestellt — Ausloeser: sobald #142 abgeschlossen ist | — | | #145 | ResolutionFarming live schalten | 🧊 Zurueckgestellt — Ausloeser: sobald #138 abgeschlossen ist | — | | #146 | AutoRedeem (On-Chain) | 🧊 Zurueckgestellt — Ausloeser: sobald #145 abgeschlossen ist | — | | #147 | Accounting A-3 - US-Steuerschicht | 🧊 Zurueckgestellt — Ausloeser: sobald die CPA den Fragebogen aus docs/steuer/Accounting-US-Tax-Questionnaire.md beantwortet hat | — | | #148 | Accounting A-5 - Reconciliation | 🧊 Zurueckgestellt — Ausloeser: sobald #145 abgeschlossen ist | — | ### C — Neue Strategiemodule | | Vorhaben | Stand | Ziel | |---|---|---|---| | #149 | Modul MarketMaking | 🧊 Zurueckgestellt — Ausloeser: sobald #142 abgeschlossen ist | — | | #150 | Modul BundleArbitrage | 🧊 Zurueckgestellt — Ausloeser: sobald #142 abgeschlossen ist | — | | #151 | StrategieDrift-Erkennung | 🧊 Zurueckgestellt — Ausloeser: sobald #144 abgeschlossen ist | — | | #152 | AI-Bewertung der Aufloesequalitaet | 🧊 Zurueckgestellt — Ausloeser: sobald #145 abgeschlossen ist | — | ### D — Nicht beschlossen | | Vorhaben | Stand | Ziel | |---|---|---|---| | #153 | Modul DataDriven | 🧊 Zurueckgestellt — Ausloeser: sobald #145 abgeschlossen ist | — | | #154 | Predictalytics-Anbindung | 🧊 Zurueckgestellt — Ausloeser: sobald das Projekt predictalytics eine abfragbare API bereitstellt | — | ### T — Technische Schuld | | Vorhaben | Stand | Ziel | |---|---|---|---| | #155 | 15 Build-Warnungen im Avalonia-Projekt | 📋 Offen | — | | #156 | TerminalLogger auf Microsoft.Extensions.Logging umstellen | 📋 Offen | — | | #157 | God-Methoden aufteilen | 📋 Offen | — | | #158 | CopyTrading-Follow-ups | 📋 Offen | — | | #159 | Deploymentcenter.Client von 2.5.0 auf 2.6.0 nachziehen | 📋 Offen | — | | #160 | Barlow-Schriften einbetten | 📋 Offen | — | ### H — Verlauf | | Vorhaben | Stand | Ziel | |---|---|---|---| | #161 | Modularisierung (Phasen 0-6) - Core und vier Module | ✅ Erledigt | — | | #162 | MySQL-Migration - MongoDB restlos raus | ✅ Erledigt | — | | #163 | CopyTrading-Rentabilitaetsplan - Phase 0, 2-Fundament, 3.1, 3.3, 4.1, 4.2 | ✅ Erledigt | — | | #164 | Fable-Review-Fixes - Slices 0 bis 6 | ✅ Erledigt | — | | #165 | Modul ResolutionFarming - Slices 0 bis 5 | ✅ Erledigt | — | | #166 | Modul Supervisor - S-0 bis S-4 | ✅ Erledigt | — | | #167 | Modul Accounting - A-1, A-2, A-4 | ✅ Erledigt | — | | #168 | Linux-Portierung der Oberflaeche - WinForms zu Avalonia | ✅ Erledigt | — | | #169 | Einfenster-Shell - Mehrfenster-Launcher abgeloest | ✅ Erledigt | — | | #170 | Deploymentcenter D-0 bis D-5 - code-seitig | ✅ Erledigt | — | | #171 | Sicherheit F1 bis F6 - AES-GCM at-rest, Secrets bereinigt | ✅ Erledigt | — | | #172 | WinForms-Ausbau (P11/L5) und LicenseLabrador-Abloesung (D-6) | ✅ Erledigt | — | | #173 | CI-Workflow angelegt | ✅ Erledigt | — | | #174 | Watchdog und LicenseLabrador als getrennte Dienste | ❌ Verworfen | — | --- # Begründungen *Nicht jedes Vorhaben braucht eine Herleitung — die meisten sind eine Zeile wert und mehr nicht. Hier steht, was mehr wert ist.* ## A — Abnahme und Fundament *Alles, was zwischen „gebaut" und „im Betrieb bewährt" steht. Nichts davon ist neue Entwicklung; es ist die Ernte der Arbeit der letzten Monate.* ### [A] #135 — Abnahme der Oberfläche Alle Fenster wurden konstruiert und die App läuft — aber **es wurde nie jedes Fenster mit echten Daten durchgeklickt**. Layout-Details zeigen sich erst im Gebrauch: Spaltenbreiten (feste Pixel wurden teils in Sternbreiten übersetzt), Umbrüche in Werkzeugleisten bei schmalen Fenstern, Splitter-Positionen (Copytrading Master-Trader, Supervisor Dossiers), und ob die KPI-Kacheln bei acht Stück (Accounting) sinnvoll umbrechen. Zum Vergleich mit der alten Oberfläche dient [UI-SPEZIFIKATION-WinForms.md](./UI-SPEZIFIKATION-WinForms.md) oder ein Arbeitsbaum des Tags: ```bash git worktree add ../polytrader-winforms winforms-final ``` **Stand 27.08.2026:** Die Sichtprüfung auf der Linux-VM hat stattgefunden und **fünfzehn Befunde** ergeben. Bis auf drei bewusst zurückgestellte sind alle behoben — darunter B-10 (ohne das DataGrid-Theme rendert keine einzige Tabelle) und ein dabei entdeckter Nebenbefund: **sämtliche Dezimal-Einstellungen waren in der Oberfläche nicht mehr änderbar**, also die komplette Risikokonfiguration. Einzelheiten im Nachtrag 5 von [BEFUND-Linux-Betrieb-2026-08-26.md](./pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md). **Stand 28.08.2026:** Die Gegenprobe am Bild ist gelaufen. Alle Behebungen sind auf der Zielplattform bestätigt; B-9 hat sich als **kein Fehler** entpuppt (Avalonia zeichnet die heutige Tageszahl — am 26.08. eine „26", am 28.08. eine „28"), und die Spaltenumstellung hatte einen eigenen Fehler erzeugt, der ebenfalls behoben ist. **Offener Rest:** Splitterpositionen und Leerzustände im Gebrauch beurteilen. Alles Weitere steht als eigenes Item — #50, #51, #52, #56 —, nicht mehr in Befundberichten. Blockiert nichts, ist aber die letzte offene Zusage der UI-Portierung. Regeln für Nacharbeiten: [LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md). ### [A] #136 — Deploymentcenter live abnehmen D-0 bis D-5 sind code-seitig fertig (#170). Offen ist die Abnahme im Betrieb: Watchdog (D-1) und Lizenz (D-2) gegen den echten Server, Erstinstallation über `setup.json` (D-5). **Serverseitig fehlen noch** der Release-Signierschlüssel (`/api/updateservice/v1/pubkey`) und ein Installationskonto mit der Rolle `installer`. Danach: **erstes Release veröffentlichen** — eine offene Entscheidung aus dem Plan. Erst **nach** dieser Abnahme dürfen `watchdog.mhdf.de` und `license.mhdf.de` abgeschaltet werden; vorher fehlt die Rückfallebene. Mit dem Abschalten erledigen sich zwei alte Sicherheits-Auflagen von selbst — siehe #174. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md) ### [A] #621 — Management-Center-Anbindung **Auslöser: sobald #613 (SDK und Testclient) und #614 (Freigabe vollständig) im Projekt `polytrader-managementcenter` abgeschlossen sind.** Aus rechtlichen Gründen darf PolyTrader nur handeln, solange ein Mensch den Weiterbetrieb in festgelegtem Takt aktiv bestätigt. Bestätigt wird in einem eigenständigen Kundencockpit — eigener Server, eigenes Repository, eigenes Deploymentcenter-Projekt. Dieses Item ist **ausschließlich der Einbau auf der Client-Seite**: SDK einbinden, Prüfung in [`TradingGate`](../src/PolyTrader.Modules.CopyTrading/Logic/TradingGate.cs) hängen — dorthin, wo seit #570 alle Sperren liegen —, cockpit-verwaltete Parameter lokal nur noch lesbar anzeigen, regelmäßigen automatischen Neustart einbauen, Kennzahlen täglich melden. **Damit fällt die Entscheidung vom 31.07.2026** in `Licensing/LicenseGate.cs`: „eine Laufzeit-Revalidierung gibt es bewusst nicht." Betriebsfreigabe ist nicht Lizenz — zwei Fragen, zwei Mechanismen, und die neue verlangt eine Prüfung zur Laufzeit. Für die **Lizenz** bleibt die alte Entscheidung gültig. Zwei Dinge sind bereits vorhanden und werden nicht neu gebaut: `TradingMode.SellOnly` existiert samt Semantik, und die Sperren liegen seit #570 an einer Stelle. Ein zweiter Ort für die Prüfung wäre die Wiederholung von #569 mit höherem Einsatz. **Ohne dieses Vorhaben kein Live-Betrieb.** Es geht damit allem in Themenbereich B voraus. → Konzept im Nachbarprojekt: `PolytraderManagementcenter/docs/KONZEPT.md` ### [A] #137 — Linux-Betrieb auf einer Test-VM **War bis zum 23.08.2026 fälschlich als „blockiert durch die DC-Abnahme" geführt. Ist es nicht.** Am Code nachgeprüft: Das Lizenz-Gate ruft bei fehlender Lizenz **kein** `Environment.Exit` auf — ohne Deploymentcenter startet die Core-Shell im eingeschränkten Modus (Terminal, Einstellungen) ohne die Trading-Module. Damit ist der Linux-Betrieb **ohne** #136 testbar. ✅ **PolyTrader läuft auf Linux.** Build (0 Fehler), 476 Tests, Publish und Start funktionieren — bei Build und Tests **kein einziger Unterschied zu Windows**. Native GUI-Bibliotheken sind für `--headless` nicht nötig, `master.key` bekommt korrekt `0600`. Ein echter Fehler gefunden und behoben: Ohne Datenbankverbindung stürzte die Anwendung mit unbehandelter Ausnahme ab, statt zu sagen, was fehlt — im Dienstbetrieb hätte das eine Neustartschleife im Zehn-Sekunden-Takt ergeben. Jetzt verständlicher Abbruch mit Exitcode 78 (`EX_CONFIG`) und `RestartPreventExitStatus=78` in der systemd-Unit. ✅ **Vollständig durchgearbeitet.** MariaDB 11.8.6 auf der Test-VM, alle fünf Migrationen durch (21 Tabellen), Betrieb mit Datenbank bestätigt — die Anwendung hat **100 echte Märkte von der Polymarket-API geholt und geschrieben**. Als systemd-Dienst: `active`, Shutdown in 0,08 s ohne `SIGKILL`, Neustart nach Absturz greift, und der Exit-78-Schutz verhindert nachweislich die Neustartschleife bei Konfigurationsfehlern. Die D-11-Falle (`server_settings.xml` relativ zum Arbeitsverzeichnis, `master.key` relativ zur Programmdatei) ist **kein Problem** — gezielt geprüft, keine zweite `server_settings.xml`. Logrotate läuft. Alle neun Views konstruieren fehlerfrei. **Der Zeitzonen-Befund ist damit belegt statt behauptet** (siehe #156): Unter UTC meldet die Anwendung „Anzeige-Zeitzone: Europe/Berlin" und stempelte in derselben Zeile mit `20:04` statt `22:04`. **Einziger Rest: Sichtprüfung der Oberfläche** — braucht jemanden am Bildschirm der VM (Schriftrendering, Spaltenbreiten, Dunkelmodus unter GTK). Damit fällt dieser Rest mit **#135** zusammen. → Protokoll: [pruefplaene/PRUEFPLAN-Linux-Betrieb.md](./pruefplaene/PRUEFPLAN-Linux-Betrieb.md) · Befund: [BEFUND-Linux-Betrieb-2026-08-26.md](./pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md) · Testumgebung für **alle** Projekte: [TESTUMGEBUNG-Linux-VM.md](./TESTUMGEBUNG-Linux-VM.md) ### [A] #138 — Feldtest im Zielland **Auslöser: sobald #136 und #137 abgeschlossen sind.** Echter Dauerbetrieb auf dem Zielsystem mit den scharfgeschalteten Deploymentcenter-Funktionen. Erst hier ist der Weg vom Build bis zum laufenden Dienst vollständig durchgespielt — vorher fehlt genau das Stück, an dem erfahrungsgemäß die Überraschungen sitzen. Beobachtungen aus dem Feldtest sammeln wir in [IDEENSAMMLUNG-Feldtest-2026-08.md](./IDEENSAMMLUNG-Feldtest-2026-08.md); was daraus ein Vorhaben wird, wird ein Item. ### [A] #139 — Master-Key setzen, Zugänge rotieren **Auslöser: sobald #138 abgeschlossen ist** — es braucht das Zielsystem. `POLYTRADER_MASTER_KEY` dort setzen und die Bestandsdaten migrieren; AES-GCM at-rest ist gebaut, F1–F6 sind behoben (#171). Zusätzlich **Alchemy- und Mullvad-Zugänge rotieren** — sie liegen in der Git-History und sind damit für jeden lesbar, der das Repo je hatte. → [sicherheit/SICHERHEITSKONZEPT.md](./sicherheit/SICHERHEITSKONZEPT.md) --- ## P — Prüfung und Tests *Die Teststrecke selbst — nicht die Befunde daraus. Ein Befund ist ein Item wie jedes andere und steht in dem Bereich, zu dem er inhaltlich gehört.* ### [P] #140 — CI-Runner registrieren Der Workflow [`.gitea/workflows/ci.yml`](../.gitea/workflows/ci.yml) liegt und wird von Gitea erkannt (ein Lauf steht auf `queued`), aber **auf der Instanz ist kein Actions-Runner registriert** — auf Repo-, Benutzer- und Instanzebene geprüft. > **Zurückgestellt (Entscheidung Richard, 23.08.2026).** Auf der Gitea-Maschine ist derzeit > keine Leistung für einen weiteren Container frei. Der Workflow bleibt liegen und ist sofort > lauffähig, sobald ein Runner da ist — es geht nichts verloren. > > **Auslöser:** sobald auf der Gitea-Maschine oder einer Linux-Test-VM Leistung für einen > weiteren Container frei ist. Bis dahin ist die Plattformneutralität nur eine Momentaufnahme: Eine einzige `net10.0-windows`-Zeile genügt, und der Linux-Build ist kaputt, ohne dass es auf einer Windows-Maschine auffällt. **Solange das so bleibt, ersetzt #137 diese Prüfung teilweise** — dort läuft dieselbe Software auf echtem Linux, nur von Hand statt automatisch. Einrichtung: **[LEITFADEN-CI.md](./LEITFADEN-CI.md) §3** (~10 Minuten). Der Runner gehört nicht auf den Arbeitsrechner — sonst prüft niemand, wenn der Rechner aus ist. **Eine der vorhandenen Linux-Test-VMs wäre der naheliegende Ausweichort.** ### [P] #141 — Prüfverfahren nach Deploymentcenter-Konvention verankern Die Haltung aus `Deploymentcenter/docs/AGENTEN_ANBINDEN.md` („Was sich lohnt zu übernehmen") ist für PolyTrader noch nicht umgesetzt. Sie kostet kein eigenes Testtor: 1. **Ein gefundener Fehler bekommt zweierlei** — ein Item im Bugtracker *und* einen Testfall, der ihn festhält. 2. **Bekannte, noch offene Befunde blockieren nicht.** Der Testfall läuft mit und ist als bekannt vermerkt — mit Item-Nummer. Ein Eintrag ohne Item-Nummer ist eine Ausrede, kein Befund. 3. **Fehlende Voraussetzung heißt übersprungen, nicht rot.** Der Unterschied zwischen „kaputt" und „nicht prüfbar" muss im Bericht sichtbar bleiben — und am Rückgabewert: Ein Lauf, der mehr überspringt als prüft, ist kein bestandener Lauf. **Nicht** zu übernehmen sind die Testinstanz `dc-dev.mhdf.de` und `tests/e2e` — die gehören dem Deploymentcenter, wir sind dessen Kunde und nicht sein Betreiber. --- ## B — Module scharf schalten *Vier Module sind gebaut. Sie handeln noch nicht mit echtem Geld bzw. laufen ohne die echten Datenquellen. Dieser Bereich schließt die Lücke — und liefert nebenbei das Fundament, auf dem Bereich C überhaupt erst möglich ist.* ### [B] #142 — CopyTrading Phase 1: Marktdaten-Fundament **Der wichtigste Einzelposten der ganzen Roadmap.** Nicht wegen CopyTrading selbst, sondern weil MarketMaking (#149) und BundleArbitrage (#150) **harte Voraussetzungen** darauf haben. Ohne diesen Schritt ist Bereich C nicht baubar. | | Inhalt | |---|---| | **1.1** | **CLOB User-Channel** — echte Fills in Echtzeit statt geschätzter Preise; füllt `ct_fill_log` | | **1.2** | **CLOB Market-Channel** — Orderbücher live (`ClobMarketDataService`) | | **1.3** | **Pre-Trade-Orderbuch-Check** in der Engine — vor dem Kauf prüfen, ob die Gegenseite überhaupt Tiefe hat | **Akzeptanz:** Fill-Log füllt sich mit echten Fills; TradeReasoning zeigt die Orderbuch-Lage zum Entscheidungszeitpunkt. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-CopyTrading-Verbesserungen.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-CopyTrading-Verbesserungen.md) §Phase 1 ### [B] #144 — CopyTrading Restposten **Auslöser: sobald #142 abgeschlossen ist** — alle drei hängen an echten Fill-Daten. - **Partial-Fill-Verdrahtung** (Phase 2) — Teilausführungen proportional behandeln - **Sniper-/Verhaltensmetriken** (Phase 3.2) — Median-Haltezeit über Activity-Pagination. ⚠️ Bei Umsetzung mit **#151 (StrategieDrift)** zusammenlegen — die Sniper-Metrik ist ein Spezialfall des dortigen Fingerprints. Doppelt bauen wäre Verschwendung. - **Echte `fee_rate_bps`** (Phase 0.2-Rest) statt der derzeitigen Annahme ### [B] #145 — ResolutionFarming live schalten **Auslöser: sobald #138 abgeschlossen ist** — es braucht das Zielland. Slices 0–5 sind fertig (#165): Logik, Persistenz, Scanner, UI, Demo-Execution, Monitor. Offen ist der Livegang nach Plan-Phasen RF-3 bis RF-5: **eigener Account**, kleines Kapital, dann Kalibrierung und Skalierung. Der On-Chain-Redeem ist #146. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-ResolutionFarming.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-ResolutionFarming.md) ### [B] #146 — AutoRedeem (On-Chain) **Auslöser: sobald #145 abgeschlossen ist.** ⚠️ **Höchste Kritikalitätsstufe** — On-Chain-Signing mit echten Private Keys. Core-Baustein mit Aktivierung **je Modul** (Richards Anforderung: in Testphasen neuer Module gezielt AUS, ohne dass etablierte Module ihren Automatismus verlieren). Architektur: Queue statt Direktaufruf — Module erkennen einlösbare Positionen, der Core löst ein. | Phase | Inhalt | |---|---| | RD-1 | Queue-Tabelle + Schalter + UI-Pending-Liste, **kein On-Chain-Code** — 100 % offline testbar | | RD-2 | `OnChainCtfService` gegen Polygon, **read-only** (Balance, Einlösbarkeit) | | RD-3 | Erster echter Redeem: **ein** Testmarkt, Kleinstbetrag, manuell getriggert | | RD-4 | Worker-Automatik scharf für ResolutionFarming, CopyTrading folgt nach Beobachtung | **RD-3 nie überspringen.** Jede Phase einzeln committen. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md) ### [B] #147 — Accounting A-3: US-Steuerschicht **Auslöser: sobald die CPA den Fragebogen beantwortet hat.** `UsTaxEngine` mit FIFO-Lot-Matching, Haltefristen, Gain/Loss sowie Form-8949- und Schedule-D-Export. **Als einziger Teil des Accounting-Moduls nicht gebaut** — A-1 (Ingest), A-2 (Abrechnung/BWA/FX) und A-4 (CSV+PDF-Export) sind fertig (#167). Fragebogen: [steuer/Accounting-US-Tax-Questionnaire.md](./steuer/Accounting-US-Tax-Questionnaire.md) ### [B] #148 — Accounting A-5: Reconciliation **Auslöser: sobald #145 abgeschlossen ist** — sinnvoll erst mit echten Live-Daten. Abgleich der unabhängig erhobenen Buchhaltung gegen die eigene Trading-DB. Niedrige Priorität, aber der eigentliche Prüfwert des Moduls: **Abweichungen zwischen beiden Quellen sind das Signal.** ### Mehrere Handelsplattformen (#622–#627) **Anlass (16.09.2026):** Ein Kunde mit Wohnsitz in den USA kann KYC machen. polymarket.com sperrt US-IPs, er muss über **Polymarket US** handeln — eine eigene, CFTC-regulierte Börse mit eigener API. Von der heutigen CLOB-Anbindung ist dort nichts verwendbar: andere Anmeldung (Ed25519 statt EIP-712/HMAC), Märkte per Slug statt Token-ID, USD statt USDC, automatische Abwicklung statt Redeem, andere Gebührenformel, eigener Liquiditätspool. Richard hat entschieden: Wir bauen nicht nur einen zweiten Adapter, sondern machen **Plattform zu einem Begriff im Core**, damit später Kalshi ein weiterer Adapter ist und kein weiterer Umbau. Module erklären ausdrücklich, welche Plattformen sie bedienen; Strategien dürfen sich je Plattform unterscheiden. **Warum in B und nicht in C:** Es entsteht kein neues Strategiemodul, sondern ein weiterer Weg, die gebauten Module an echtes Geld zu bringen. Die Abhängigkeit von A bleibt: Ohne Betriebsfreigabe (#621) und Feldtest handelt auch der US-Kunde nicht live. **Die zwei Auflagen, die das Konzept trägt:** 1. **Der Global-CLOB-Code wird umhüllt, nicht umgebaut.** `PolymarketClobClient` bleibt Zeile für Zeile, wie er ist; der Global-Adapter übersetzt nur. Ein Fundament, das den bewährten Geldpfad verändert, wäre teurer als der US-Kunde wert ist. 2. **Die Plattform-Erklärung eines Moduls wirkt im Handelspfad**, nicht nur in der Anzeige. Das Order-Gateway lehnt ab, was das auslösende Modul nicht erklärt hat — dieselbe Lehre wie #569/#570. → [archiv/konzepte/KONZEPT-Multi-Plattform.md](./archiv/konzepte/KONZEPT-Multi-Plattform.md) ### [B] #622 — PL-0: Voraussetzungen für den US-Kunden klären Keine Programmierarbeit, aber ohne sie ist #625 nur lesend baubar: API-Schlüssel des Kunden, Serverstandort (US-Standort gegen US-IP-Sperre von polymarket.com), ob es für die Retail-API eine Testumgebung gibt, und unsere Rolle beim automatisierten Handel auf einem fremden KYC-Konto. ### [B] #623 — PL-1: Plattform-Fundament im Core `PlatformId`, `PlatformCapabilities`, neutrale Verträge mit `InstrumentRef` statt `TokenId`, Registry, Global-Adapter als Hülle, Spalte `platform` mit Vorgabe `polymarket-global`. **Akzeptanz: Verhalten unverändert, Diff an `PolymarketClobClient.cs` leer.** `TokenId` steht in 73 Dateien — deshalb bleibt es als Eigenschaft erhalten und zieht schrittweise um. ### [B] #624 — PL-2: Module erklären ihre Plattformen **Auslöser: sobald #623 abgeschlossen ist.** `IPolyTraderModule.SupportedPlatforms` mit Vorgabe „nur Global" — ein Modul, das nichts erklärt, verhält sich wie heute. Kennzeichen in Modul-Tab und Kontenansicht (Desktop und WebUI aus einer Core-Regel, wie seit #560), Warnung bei Konten ohne Modul, Sperre im Order-Gateway. Warum Erklärung **und** Fähigkeiten: Dass eine Plattform alles Nötige *hat*, heißt nicht, dass die Strategie dort *geprüft* ist. ### [B] #625 — PL-3: Adapter Polymarket US **Auslöser: sobald #623 abgeschlossen ist; echte Orders zusätzlich erst nach #622.** Erst lesend, dann Demo gegen das echte US-Buch, dann Orders. Die Retail-API hat keine dokumentierte Sandbox — Demo gegen Produktion ist damit der einzige Weg zur Messphase. ### [B] #626 — PL-4: ResolutionFarming für Polymarket US **Auslöser: sobald #624 und #625 abgeschlossen sind.** Erste Strategie für den US-Kunden, weil sie keine fremden Wallet-Daten braucht. Die US-Gebühr `Θ·p·(1−p)` ist nahe 0,95 sehr klein, Maker bekommen einen Rabatt, und der Redeem (#146) entfällt. Global-Schwellen sind wegen des getrennten Pools **nicht** übertragbar — Startwerte kommen aus der Messphase. ### [B] #627 — PL-5: Accounting für Polymarket-US-Konten **Auslöser: sobald #625 abgeschlossen ist.** Keine Chain, keine Data-API: Aktivität, Saldo und Balance-Ledger kommen aus der US-API, in USD. Macht nebenbei #147 (US-Steuerschicht) greifbar — der US-Kunde ist genau dieser Fall. --- ## C — Neue Strategiemodule *Erst wenn A und B stehen. Alle vier sind vollständig geplant und haben null Zeilen Code.* ### [C] #149 — Modul MarketMaking **Auslöser: sobald #142 abgeschlossen ist** — harte Voraussetzung ist die Orderbuch-Infrastruktur. Beidseitige Limit-Orders in belohnungsberechtigten Märkten; kombiniert drei Ertragsquellen: tägliche Liquidity Rewards (USDC), Maker-Rebates und den Spread. **Eigener Account**, um den Konflikt mit CopyTrading zu vermeiden. | Phase | Inhalt | |---|---| | MM-1 | Fundament-Verifikation (mehrtägiger Soak-Test der WSS-Kanäle!) + Selector, read-only | | MM-2 | **Paper-Quoting, 2 Wochen** — misst Adverse Selection. Rewards lassen sich nicht simulieren, diese Phase misst nur die Risikoseite | | MM-3 | Live auf 1–2 ruhigen Märkten, 300–500 USDC | | MM-4 | Skalierung + Skew-Feintuning | | MM-5 | Optional: Reward-Optimierung, Laddering | **Pflicht-Fail-Safe ab MM-3:** Keine Book-Updates > N Sekunden → alle Quotes canceln. Muss durch künstliches Trennen der WSS-Verbindung getestet werden — sonst quotet das Modul blind. **Offene Entscheidungen:** Startmärkte (Empfehlung: 1–2 langlaufende Politik-Märkte, wenig Newsflow), Kapital für MM-3, beidseitig quoten von Anfang an (empfohlen — einseitig scored schlechter und halbiert den Lerneffekt). → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-MarketMaking.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-MarketMaking.md) ### [C] #150 — Modul BundleArbitrage **Auslöser: sobald #142 abgeschlossen ist.** Startet bewusst als reines **Mess-Modul**. YES + NO < $1.00 bei binären Märkten, Summenverletzungen bei NegRisk-Multi-Outcome. > **Ehrliche Einordnung aus dem Plan:** Auf den großen Märkten ist das ein HFT-Spiel mit > Sekundenfenstern, dominiert von spezialisierten Bots; die Taker-Fees seit März 2026 haben > viele kleine Anomalien unprofitabel gemacht. Die Chance liegt im **Long Tail** und als > **Beifang** der ohnehin laufenden Orderbuch-Streams von #149. Deshalb: erst messen, dann > entscheiden. | Phase | Inhalt | |---|---| | BA-1 | **Detection-only, 2–4 Wochen.** Endet mit dokumentierter Go/No-Go-Empfehlung | | BA-2 | Execution klein — **nur bei Go**, zunächst nur binäre Märkte | | BA-3 | NegRisk-Execution (mehr Legs = mehr Single-Leg-Risiko) | | BA-4 | `OnChainCtfService` (Merge) — gemeinsam mit #146 als **ein** Core-Baustein bauen | Fees je Leg müssen von Anfang an in der Profitrechnung stehen: Ein Bundle mit 2 ¢ Bruttomarge kann nach Fees negativ sein. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-BundleArbitrage.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-BundleArbitrage.md) ### [C] #151 — StrategieDrift-Erkennung **Auslöser: sobald #144 abgeschlossen ist.** Nicht hart blockiert, aber ohne die echten Fill-Daten nur halb so wirksam — und #144 bringt mit der Sniper-Metrik einen Teil davon schon mit. Verhaltensänderungen eines Master-Traders erkennen, **bevor** sie sich im Copy-PnL niederschlagen. Die bestehende Auto-Pause ist ein nachlaufender Indikator: Bei 95-¢-Tradern sieht man den Schaden erst nach mehreren Verlusten. Ein Wetter-Bot, der plötzlich Politik-Longshots kauft, hat die Strategie gewechselt, lange bevor das messbar wird. Drei Slices: pure Fingerprint-Logik + Persistenz → Job-Integration (Stunden-Tick ohne zusätzliche API-Calls) → Engine-Gate + UI. ⚠️ **Mit #144 zusammenlegen.** Ersetzt **nicht** die PnL-Auto-Pause — Drift ist das Frühwarnsystem, die PnL-Pause das Sicherheitsnetz. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-StrategieDrift.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-StrategieDrift.md) ### [C] #152 — AI-Bewertung der Auflösequalität **Auslöser: sobald #145 abgeschlossen ist** — vorher fehlen die Live-Märkte, an denen sich die Validierungsphase durchführen lässt. Core-Baustein, kein eigenes Modul. Ein LLM (über OpenRouter) bewertet je Markt das **Resolution-Risiko**: subjektive Auflösequellen, Regeltext-Fallen, UMA-Dispute-Muster. Ergebnis wird beim Markt-Import gespeichert und dient als Entry-Gate — zuerst im ResolutionFarming, dann optional im CopyTrading. **Vor dem Scharfschalten ist eine Validierungsphase Pflicht:** ~15–20 bekannte strittige UMA-Resolutions plus ~30 unstrittige Vergleichsmärkte durchschicken. Akzeptanz: ≥ 80 % der Streitfälle unter der Schwelle, ≤ 10 % der sauberen fälschlich blockiert. Ergebnisse als Golden-File einfrieren, damit die CI ohne LLM-Call testen kann. **Leitplanken:** Kostendeckel als Setting (Default 500 Ratings/Tag). Der Rater beeinflusst **nie Exits**, nur Entries — keine Panikverkäufe durch ein Sprachmodell. → [archiv/umsetzungsplaene/UMSETZUNGSPLAN-AI-Aufloesequalitaet.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-AI-Aufloesequalitaet.md) --- ## D — Nicht beschlossen *Hier steht, was durchdacht, aber **nicht entschieden** ist. Vor einer Umsetzung braucht es eine ausdrückliche Entscheidung — nicht nur einen freien Nachmittag.* ### [D] #153 — Modul DataDriven **Auslöser: sobald #145 abgeschlossen ist** — dann lässt sich der einzige Teilaspekt, der schon heute Wert hat, an echten Daten messen, ohne das ganze Modul zu bauen. Ein Strategiemodul, das eigene Handelsentscheidungen aus **externen Datenquellen** ableitet — je Marktkategorie eine eigene Datenquelle und ein eigenes Fair-Value-Modell (Wetter über Open-Meteo, später Sport-Spielstände). **Warum nicht beschlossen — die drei Gründe aus dem Konzept selbst:** 1. **Modell-Risiko ersetzt Master-Risiko.** Ein Bias im Fair-Value-Modell produziert *systematisch* falsche Trades, nicht nur einzelne. 2. **Der Edge schrumpft nachweislich.** Beim Wetter von ~10 auf ~3 Prozentpunkte (2023→2026). 3. **Jede Kategorie ist ein eigenes kleines Forschungsprojekt.** Der Aufwand skaliert nicht. Es gibt noch **keinen Umsetzungsplan**, nur ein Konzept mit Aufbaupfad (DD-0 bis DD-4, jede Kategorie mit eigenem Go/No-Go-Gate). Ein Teilaspekt ist auch ohne das ganze Modul wertvoll: der `SportsScoreStateProvider` als **Filter für ResolutionFarming** (Dip-Freigabe bei klarer Führung) — das wäre der sinnvolle erste Schritt, falls überhaupt. → [archiv/konzepte/KONZEPT-Modul-DataDriven.md](./archiv/konzepte/KONZEPT-Modul-DataDriven.md) ### [D] #154 — Predictalytics-Anbindung **Auslöser: sobald das Projekt `predictalytics` eine abfragbare API bereitstellt.** Predictalytics ist ein **separates Projekt** zur Master-Trader-Auswahl. Die im Supervisor-Konzept vorgesehenen Predictalytics-Werkzeuge lassen sich nicht bauen, solange dort keine API existiert. Berührt auch #151 — die Fingerprint-Baseline wäre von dort importierbar. Prüfplan: [pruefplaene/PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md](./pruefplaene/PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md) ### [D] #628 — PL-6: CopyTrading plattformübergreifend **Auslöser: sobald #625 abgeschlossen ist und Richard entschieden hat, ob sich das lohnt.** Auf Polymarket US sind fremde Wallets nicht sichtbar; CopyTrading hat dort keine eigenen Master. Denkbar wäre: Master weiter auf Polygon beobachten, auf dem passenden US-Markt ausführen. **Warum nicht beschlossen:** Nicht jeder Markt existiert in den USA, der Pool ist getrennt, Kurse und Gebühren weichen ab — der Einstieg liegt systematisch anders als beim Master, und genau dieser Abstand entscheidet heute über die Rentabilität (#163). → [archiv/konzepte/KONZEPT-Multi-Plattform.md](./archiv/konzepte/KONZEPT-Multi-Plattform.md) ### [D] #629 — PL-7: Adapter Kalshi **Auslöser: sobald #623 abgeschlossen ist und ein Kunde Kalshi konkret braucht.** Vorbereitet, nicht beschlossen. Zugleich der Prüfstein für #623: Kommt der Adapter ohne Änderung an einem Modul aus, trägt die Abstraktion. → [archiv/konzepte/KONZEPT-Multi-Plattform.md](./archiv/konzepte/KONZEPT-Multi-Plattform.md) §7 --- ## T — Technische Schuld *Kein eigener Meilenstein — abzuarbeiten, wenn man ohnehin in der Nähe ist.* ### [T] #155 — 15 Build-Warnungen im Avalonia-Projekt 13 × `CS8618` (Felder in Fenster-Konstruktoren), 1 × `CS8848` (Vorrang bei `switch`), 1 × `CS8602` (möglicher Nullverweis, `PdfExporter.cs:40`). **Die letzten beiden sind einen Blick wert** — dahinter kann ein echter Fehler stecken. Erst wenn sie weg sind, ist `-warnaserror` in der CI sinnvoll (#140). ### [T] #156 — TerminalLogger auf Microsoft.Extensions.Logging umstellen **Der Zeitzonen-Teil ist am 27.08.2026 erledigt** — vorgezogen, weil #137 den Fehler nachgewiesen hat: Zeitstempel sind jetzt `DateTimeOffset` in der Anzeige-Zeitzone, Logdatei-Grenzen und Oberfläche passen zusammen, und die `.log`-Dateien heißen wie die `.jsonl` (`yyyy-MM-dd`). **Offen bleibt** die eigentliche Umstellung auf `Microsoft.Extensions.Logging`. ### [T] #159 — Deploymentcenter.Client von 2.5.0 auf 2.6.0 nachziehen `src/PolyTrader.Core/PolyTrader.Core.csproj:29` referenziert **2.5.0**, das SDK steht auf **2.6.0** (`DeploymentcenterSdk.Version`). **Bevor die Anbindung angefasst wird**, erst nachsehen, was seitdem dazugekommen ist: ``` GET /api/updateservice/v1/changelog?since=2.5.0 ``` Die Antwort nennt nur die neueren Fassungen, dazu `action_items` (Punkte mit Handlungsbedarf) und `breaking`. Kommt `"count": 0` zurück, ist nichts zu tun. Danach die referenzierte Fassung hochsetzen und `dc_link_project` mit der neuen `integrated_version` aufrufen — **nicht** eine Versionszeile von Hand in einer Datei pflegen. --- ## H — Verlauf *Was abgeschlossen ist, steht im erzeugten Block. Hier steht nur, was eine Begründung braucht.* ### [H] #174 — Watchdog und LicenseLabrador als getrennte Dienste **Verworfen.** Beide waren als eigenständige Fremdprojekte zur Einbindung vorgesehen — Monitoring per Heartbeat, Lizenzierung per Ed25519 — und ihre Review-Blocker waren am 29.07.2026 alle behoben, die Einbindung hätte starten können. **Warum trotzdem verworfen:** Es wären zwei eigene Dienste geworden, mit eigenen Secrets, eigener Datenhaltung, eigener Anbindung und eigenem Betrieb. Das Deploymentcenter leistet dasselbe an *einer* Stelle und liefert Error-Reporting und Updates gleich mit. Zwei Systeme zu betreiben, die dieselbe Frage beantworten, ist die teurere Hälfte von beidem. Mit dem Abschalten von `watchdog.mhdf.de` und `license.mhdf.de` (nach #136) erledigen sich zwei alte Sicherheits-Auflagen von selbst: **Watchdog-Secrets rotieren** (sie stehen in der History) und der **UTC/`NOW()`-Mix**. Ein erneuter Vorschlag in diese Richtung müsste erklären, was das Deploymentcenter nicht kann — nicht, was die beiden Dienste konnten. --- ## Wiederkehrend Die Audit-Checkliste in [sicherheit/SICHERHEITSKONZEPT.md](./sicherheit/SICHERHEITSKONZEPT.md) §6 bei jedem Release und mindestens quartalsweise. Punkt 1 (Schwachstellen-Scan) übernimmt die CI, sobald #140 steht. ## Archiv [`archiv/`](./archiv/) enthält die Dokumente, aus denen diese Roadmap entstanden ist. Für die Umsetzung eines Vorhabens ist der jeweilige Detailplan weiterhin die **Bauanleitung** mit Code-Bezügen, Akzeptanzkriterien und Begründungen. Nur der *Status* darin ist überholt. Weiterhin aktiv außerhalb des Archivs: [PROJEKTSTAND.md](./PROJEKTSTAND.md) · [LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md) · [LEITFADEN-CI.md](./LEITFADEN-CI.md) · [UI-SPEZIFIKATION-WinForms.md](./UI-SPEZIFIKATION-WinForms.md) · [TESTUMGEBUNG-Linux-VM.md](./TESTUMGEBUNG-Linux-VM.md) · [sicherheit/](./sicherheit/) · [steuer/](./steuer/) · [pruefplaene/](./pruefplaene/) · [IDEENSAMMLUNG-Feldtest-2026-08.md](./IDEENSAMMLUNG-Feldtest-2026-08.md)