PolyTraderSharp/docs/ROADMAP.md

Roadmap PolyTrader

Stand: 23.08.2026 (A2 pausiert, A4 aufgeteilt) · Das eine Steuerungsdokument. Zusammengeführt aus elf Umsetzungsplänen, drei Konzepten und der Linux-Analyse — diese liegen jetzt unter archiv/ und bleiben die Bauanleitungen; maßgeblich für Status und Reihenfolge ist ab jetzt nur noch dieses Dokument.

Arbeitsteilung: Was ist → PROJEKTSTAND.md (Architektur, Kennzahlen, Modul-Stand). Was kommt → dieses Dokument.

---

0. Wie diese Roadmap zu lesen ist

Zeichen	Bedeutung
✅	Erledigt
⬜	Offen und eingeplant — kann angefangen werden
🔒	Blockiert — die Ursache steht dabei
⏸️	Bewusst zurückgestellt. Fertig geplant, aber wir bauen es jetzt nicht
💤	Idee, nicht beschlossen. Vor der Umsetzung ist eine Entscheidung nötig

Die Stufen A–D sind eine Reihenfolge, keine Termine. Stufe A vor B vor C ist keine Bürokratie: Jede Stufe schafft die Voraussetzung für die nächste. 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. Plandokument und Code wandern im selben Commit. Beim letzten Verstoß dagegen wies die Doku wochenlang Arbeit als offen aus, die längst erledigt war. Wer hier etwas abhakt, committet die Roadmap mit.

Für alles, was Geld bewegt, gilt zusätzlich .agents/rules/clob.md.

---

1. Überblick

	Vorhaben	Status	Stufe
A1	Abnahme der Oberfläche (A5)	⬜	A
A2	CI-Runner registrieren	⏸️	A
A3	Deploymentcenter live abnehmen	⬜	A
A4a	Linux-Betrieb auf einer Test-VM	⬜	A
A4b	Feldtest im Zielland	🔒 A3	A
A5	Master-Key setzen, Zugänge rotieren	🔒 A4b	A
B1	CopyTrading Phase 1 — Marktdaten-Fundament	⬜	B
B2	CopyTrading Restposten	🔒 B1	B
B3	ResolutionFarming live schalten	🔒 A4b	B
B4	AutoRedeem (On-Chain)	🔒 B3	B
B5	Supervisor: Live-Key-Test	⬜	B
B6	Accounting A-3 (US-Steuer)	🔒 CPA	B
B7	Accounting A-5 (Reconciliation)	🔒 B3	B
C1	Modul MarketMaking	🔒 B1	C
C2	Modul BundleArbitrage	🔒 B1	C
C3	StrategieDrift-Erkennung	⏸️	C
C4	AI-Bewertung der Auflösequalität	⏸️	C
D1	Modul DataDriven	💤	D
D2	Predictalytics-Anbindung	💤	D
T1–T5	Technische Schuld	⬜	laufend

---

Stufe A — Abnahme & 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.

A1 ⬜ Abnahme der Oberfläche (A5)

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.

Vorgehen: App starten, jedes Fenster öffnen. Zum Vergleich mit der alten Oberfläche dient UI-SPEZIFIKATION-WinForms.md oder ein Arbeitsbaum des Tags:

git worktree add ../polytrader-winforms winforms-final

Stand 27.08.2026: Die Sichtprüfung auf der Linux-VM hat stattgefunden (A4a, Nachträge 2–4) 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 und Begründungen im Nachtrag 5 von BEFUND-Linux-Betrieb-2026-08-26.md.

Stand 28.08.2026: Die Gegenprobe am Bild ist gelaufen (Nachtrag 6). 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 ab jetzt im Bugtracker (Items #50–#57), nicht mehr in Befundberichten.

Blockiert nichts — aber es ist die letzte offene Zusage der UI-Portierung. Regeln für Nacharbeiten: LEITFADEN-Avalonia-Portierung.md.

A2 ⏸️ CI-Runner registrieren — pausiert

Der Workflow .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.

Pausiert (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.

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 A2 pausiert, ersetzt A4a diese Prüfung teilweise — dort läuft dieselbe Software auf echtem Linux, nur von Hand statt automatisch.

Einrichtung, wenn wieder Kapazität da ist: 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, falls dort Leistung frei ist.

A3 ⬜ Deploymentcenter live abnehmen

D-0 bis D-5 sind code-seitig fertig. 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: 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 (Watchdog-Secrets rotieren, UTC/NOW()-Mix).

→ archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md

A4a ⬜ Linux-Betrieb auf einer Test-VM

War bis zum 23.08.2026 fälschlich als „blockiert durch A3" 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. Watchdog, Error-Reporting und Update-Prüfung stehen in appsettings.json ohnehin auf false. Damit ist der Linux-Betrieb ohne A3 testbar, und Richard hat dafür Test-VMs.

Die Anwendung ist noch nie auf Linux gelaufen — verifiziert ist bisher nur, dass sie publisht. Das ist die größte ungetestete Fläche im Projekt.

Zu prüfen:

	Was
Start	Läuft PolyTrader.App.Avalonia --headless überhaupt? Fehlen native Abhängigkeiten (SkiaSharp/HarfBuzz brauchen je nach Distro libfontconfig1, libice6, libsm6)?
Datenbank	Verhalten ohne erreichbare MySQL: sauberer Fehler oder Absturz? Mit erreichbarer MySQL: laufen die Migrationen durch?
systemd	deploy/polytrader.service einspielen. Besonders die WorkingDirectory-Falle aus D-11 prüfen: server_settings.xml wird relativ zum Arbeitsverzeichnis geladen, master.key relativ zur Programmdatei — bei falschem WorkingDirectory legt ServerSettings.Load() kommentarlos eine neue Datei an, ohne dass es auffällt
Shutdown	systemctl stop → SIGTERM → geordnetes Herunterfahren innerhalb TimeoutStopSec=45. Restart=on-failure gegentesten
Zeitzone	T2 hier mitprüfen: Der TerminalLogger stempelt mit DateTime.Now statt AppTimeZone. Auf einer UTC-VM mit Anzeigezone Europe/Berlin müssten die Logdatei-Grenzen sichtbar von der angezeigten Uhrzeit abweichen — das ist der Beweis für den bislang nur theoretischen Befund
Logrotate	Rotation einrichten und prüfen, dass die App weiterschreibt
Master-Key	POLYTRADER_MASTER_KEY als Umgebungsvariable im Dienst — Zusammenspiel mit MasterKeyResolver und FilePermissions unter Linux-Rechten

Ergebnis: Danach ist belegt, dass die Software auf Linux läuft — nicht nur, dass sie sich übersetzen lässt.

→ Durchführung: pruefplaene/PRUEFPLAN-Linux-Betrieb.md — Schritt-für-Schritt-Protokoll mit erwarteten Ergebnissen.

Teilergebnis vom 26.08.2026 → BEFUND-Linux-Betrieb-2026-08-26.md

✅ 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 (Vermutung bestätigt), 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 neue Exit-78-Schutz verhindert nachweislich die Neustartschleife bei Konfigurationsfehlern. Die D-11-Falle ist kein Problem (gezielt geprüft: keine zweite server_settings.xml). Logrotate läuft. Alle neun Views konstruieren fehlerfrei.

T2 ist jetzt belegt statt behauptet: Unter UTC meldet die Anwendung „Anzeige-Zeitzone: Europe/Berlin" und stempelt 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 A1 zusammen.

Testumgebung dauerhaft nutzbar: TESTUMGEBUNG-Linux-VM.md beschreibt Zugang und Konventionen für alle Projekte (eigene Datenbank je Projekt, eigenes Dienstkonto, Aufräumregeln).

A4b 🔒 Feldtest im Zielland

Blockiert durch A3 und A4a.

Echter Dauerbetrieb auf dem Zielsystem mit den scharfgeschalteten Deploymentcenter-Funktionen. Erst hier ist der Weg vom Build bis zum laufenden Dienst vollständig durchgespielt.

A5 🔒 Master-Key setzen, Zugänge rotieren

Blockiert durch A4b (braucht das Zielsystem).

POLYTRADER_MASTER_KEY auf dem Zielsystem setzen und die Bestandsdaten migrieren (AES-GCM at-rest ist gebaut, F1–F6 sind behoben). Zusätzlich Alchemy- und Mullvad-Zugänge rotieren — sie liegen in der Git-History.

→ sicherheit/SICHERHEITSKONZEPT.md

---

Stufe B — Bestehende Module scharf schalten

Vier Module sind gebaut. Sie handeln noch nicht mit echtem Geld bzw. laufen ohne die echten Datenquellen. Diese Stufe schließt die Lücke — und liefert nebenbei das Fundament, auf dem Stufe C überhaupt erst möglich ist.

B1 ⬜ CopyTrading Phase 1 — Marktdaten-Fundament

Der wichtigste Einzelposten der ganzen Roadmap. Nicht wegen CopyTrading selbst, sondern weil MarketMaking (C1) und BundleArbitrage (C2) harte Voraussetzungen darauf haben. Ohne diesen Schritt ist Stufe 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 §Phase 1

B2 🔒 CopyTrading Restposten

Blockiert durch B1 — 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 C3 (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

B3 🔒 ResolutionFarming live schalten

Blockiert durch A4b (Zielland).

Slices 0–5 sind fertig: 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 B4.

→ archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-ResolutionFarming.md

B4 🔒 AutoRedeem (On-Chain)

Blockiert durch B3. ⚠️ 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

B5 ⬜ Supervisor: Live-Key-Test

S-0 bis S-4 sind komplett (Journal, Dossiers, OpenRouter-Agent, Profile, Berichte, Counterfactual, MCP-Light). Offen ist nur der Test mit echtem OpenRouter-Key. Die geplanten Predictalytics-Werkzeuge hängen an D2.

B6 🔒 Accounting A-3 — US-Steuerschicht

Blockiert: wartet auf Antworten der CPA.

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.

Fragebogen für die Beraterin: steuer/Accounting-US-Tax-Questionnaire.md

B7 🔒 Accounting A-5 — Reconciliation

Blockiert durch B3 — 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.

---

Stufe C — Neue Strategiemodule

Erst wenn Stufe A und B stehen. Alle vier sind vollständig geplant und haben null Zeilen Code.

C1 🔒 Modul MarketMaking

Blockiert durch B1 (harte Voraussetzung: Orderbuch-Infrastruktur).

Beidseitige Limit-Orders in belohnungsberechtigten Märkten; kombiniert drei Ertragsquellen: tägliche Liquidity Rewards (USDC), Maker-Rebates und den Spread. Eigener Account (Konflikt mit CopyTrading 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

C2 🔒 Modul BundleArbitrage

Blockiert durch B1. 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 C1. 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 B4 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

C3 ⏸️ StrategieDrift-Erkennung

Zurückgestellt — nicht blockiert, aber ohne B1/B2 nur halb so wirksam.

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 B2 zusammenlegen. Ersetzt nicht die PnL-Auto-Pause — Drift ist das Frühwarnsystem, die PnL-Pause das Sicherheitsnetz.

→ archiv/umsetzungsplaene/UMSETZUNGSPLAN-StrategieDrift.md

C4 ⏸️ AI-Bewertung der Auflösequalität

Zurückgestellt. 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

---

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

D1 💤 Modul DataDriven

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

D2 💤 Predictalytics-Anbindung

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 C3 (Fingerprint-Baseline wäre von dort importierbar).

Prüfplan: pruefplaene/PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md

---

Technische Schuld (laufend)

Kein eigener Meilenstein — abzuarbeiten, wenn man ohnehin in der Nähe ist.

	Punkt	Details
T1	⬜ 15 Build-Warnungen	Alle 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
T2	⬜ TerminalLogger	Zeitzonen-Teil am 27.08.2026 erledigt (vorgezogen, weil A4a 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
T3	⬜ God-Methoden	PollLiveAccountsAsync, ProcessAccountOrderAsync splitten; duplizierte Closed-Trade-Erzeugung zentralisieren
T4	⬜ CopyTrading-Follow-ups	TradeId-Autoincrement, Dedup, Performance
T5	⬜ Barlow-Schriften	Im UI-Redesign vorgesehen, nie eingebettet

Wiederkehrend: Die Audit-Checkliste in sicherheit/SICHERHEITSKONZEPT.md §6 bei jedem Release und mindestens quartalsweise. Punkt 1 (Schwachstellen-Scan) übernimmt die CI, sobald A2 steht.

---

Abgeschlossen

Verlauf — die Detailpläne liegen im Archiv.

Vorhaben	Abgeschlossen
✅ Modularisierung (Phasen 0–6) — Core + vier Module	07–08/2026
✅ MySQL-Migration — Mongo restlos raus	07/2026
✅ CopyTrading-Rentabilitätsplan — Phase 0, 2-Fundament, 3.1, 3.3, 4.1, 4.2	07/2026
✅ Fable-Review-Fixes — Slices 0–6	07/2026
✅ Modul ResolutionFarming — Slices 0–5 (ohne Livegang)	07/2026
✅ Modul Supervisor — S-0 bis S-4	07/2026
✅ Modul Accounting — A-1, A-2, A-4	07/2026
✅ Linux-Portierung UI — WinForms → Avalonia, A1–A4	08/2026
✅ Einfenster-Shell — Mehrfenster-Launcher abgelöst	08/2026
✅ Deploymentcenter D-0–D-5 — code-seitig	08/2026
✅ Sicherheit F1–F6 — AES-GCM at-rest, Secrets bereinigt	08/2026
✅ WinForms-Ausbau (P11/L5) + LicenseLabrador-Ablösung (D-6)	22.08.2026
✅ CI-Workflow (Ausführung fehlt noch → A2)	22.08.2026

Verworfen: Watchdog und LicenseLabrador als getrennte Dienste — ersetzt durch das Deploymentcenter.

---

Archiv

archiv/ enthält die Dokumente, aus denen diese Roadmap entstanden ist. Sie sind nicht tot: 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 — dafür gilt ausschließlich diese Roadmap.

Weiterhin aktiv außerhalb des Archivs: PROJEKTSTAND.md · LEITFADEN-Avalonia-Portierung.md · LEITFADEN-CI.md · UI-SPEZIFIKATION-WinForms.md · sicherheit/ · steuer/ · pruefplaene/ · IDEENSAMMLUNG-Feldtest-2026-08.md