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/`](./archiv/) und
bleiben die **Bauanleitungen**; maßgeblich für *Status und Reihenfolge* ist ab jetzt nur noch
dieses Dokument.

> **Arbeitsteilung:** Was **ist** → [PROJEKTSTAND.md](./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`](../.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](./UI-SPEZIFIKATION-WinForms.md) oder ein Arbeitsbaum des Tags:

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

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

### A2 ⏸️ CI-Runner registrieren — pausiert

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.

> **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](./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](./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`](../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](./pruefplaene/PRUEFPLAN-Linux-Betrieb.md)**
— Schritt-für-Schritt-Protokoll mit erwarteten Ergebnissen, zum Abarbeiten auf der Test-VM.

### 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](./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](./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](./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](./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](./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](./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](./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](./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](./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](./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](./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 | Stempelt mit `DateTime.Now` statt der konfigurierten `AppTimeZone`. Auf einem UTC-Linuxserver passen die Logdatei-Grenzen nicht zur angezeigten Uhrzeit. Zusammen mit der Umstellung auf `Microsoft.Extensions.Logging` erledigen — **bei A4a nachweisbar** |
| **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](./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/`](./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](./PROJEKTSTAND.md) ·
[LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md) ·
[LEITFADEN-CI.md](./LEITFADEN-CI.md) ·
[UI-SPEZIFIKATION-WinForms.md](./UI-SPEZIFIKATION-WinForms.md) ·
[sicherheit/](./sicherheit/) · [steuer/](./steuer/) · [pruefplaene/](./pruefplaene/) ·
[IDEENSAMMLUNG-Feldtest-2026-08.md](./IDEENSAMMLUNG-Feldtest-2026-08.md)