Richard/PolyTraderSharp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Paralleles WebGUI mit Kestrel, Token-Sicherung und SSE-Logs implementiert

Browse Source
This commit is contained in:
Richard
2026-09-07 21:55:51 +02:00
parent 28b3aedec7
commit 10f928eb4e
36 changed files with 3114 additions and 266 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ROADMAP.md
+371 -256
View File
@@ -1,180 +1,208 @@
# Roadmap PolyTrader
# 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.
**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** → dieses Dokument.
> 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.
---
## 0. Wie diese Roadmap zu lesen ist
## Wie die Reihenfolge gemeint 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.
**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. **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.
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).
---
## 1. Überblick
<!-- dc:roadmap stand=2026-08-30T12:21Z items=44 projekt=polytrader -->
| | Vorhaben | Status | Stufe |
<!-- ERZEUGT - nicht von Hand aendern. Dieser Block wird bei jedem Lauf von
`php cli/roadmap.php --write` ueberschrieben. Der Zustand wird im
Deploymentcenter gepflegt, nicht hier. Prosa gehoert AUSSERHALB der
Marker - dort bleibt sie unberuehrt. -->
### 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 |
|---|---|---|---|
| **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 |
| #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 | — |
<!-- /dc:roadmap -->
---
## Stufe A — Abnahme & Fundament
# Begründungen
*Alles, was zwischen „gebaut" und „im Betrieb bewährt" steht. Nichts davon ist neue Entwicklung;
es ist die Ernte der Arbeit der letzten Monate.*
*Nicht jedes Vorhaben braucht eine Herleitung — die meisten sind eine Zeile wert und mehr
nicht. Hier steht, was mehr wert ist.*
### A1 ⬜ Abnahme der Oberfläche (A5)
## A — Abnahme und Fundament
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.
*Alles, was zwischen „gebaut" und „im Betrieb bewährt" steht. Nichts davon ist neue
Entwicklung; es ist die Ernte der Arbeit der letzten Monate.*
**Vorgehen:** App starten, jedes Fenster öffnen. Zum Vergleich mit der alten Oberfläche dient
### [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 (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
**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 (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.
**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 ab jetzt im **Bugtracker** (Items #50–#57), nicht mehr in Befundberichten.
**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** — aber es ist die letzte offene Zusage der UI-Portierung.
Regeln für Nacharbeiten: [LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md).
Blockiert nichts, ist aber die letzte offene Zusage der UI-Portierung. Regeln für
Nacharbeiten: [LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md).
### A2 ⏸️ CI-Runner registrieren — pausiert
### [A] #136 — Deploymentcenter live abnehmen
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
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 (Watchdog-Secrets rotieren, UTC/`NOW()`-Mix).
Sicherheits-Auflagen von selbst — siehe #174.
→ [archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md)
### A4a ⬜ Linux-Betrieb auf einer Test-VM
### [A] #137 — 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.
**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.
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.
**Teilergebnis vom 26.08.2026 →
[BEFUND-Linux-Betrieb-2026-08-26.md](./pruefplaene/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`.
✅ **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
@@ -184,51 +212,106 @@ Neustartschleife im Zehn-Sekunden-Takt ergeben. Jetzt verständlicher Abbruch mi
✅ **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.
`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.
**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`.
**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 **A1**
**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.
**Testumgebung dauerhaft nutzbar:** [TESTUMGEBUNG-Linux-VM.md](./TESTUMGEBUNG-Linux-VM.md)
beschreibt Zugang und Konventionen für **alle** Projekte (eigene Datenbank je Projekt, eigenes
Dienstkonto, Aufräumregeln).
→ 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)
### A4b 🔒 Feldtest im Zielland
### [A] #138 — Feldtest im Zielland
*Blockiert durch A3 und A4a.*
**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.
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.
### A5 🔒 Master-Key setzen, Zugänge rotieren
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.
*Blockiert durch A4b (braucht das Zielsystem).*
### [A] #139 — Master-Key setzen, Zugänge rotieren
`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.
**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)
---
## Stufe B — Bestehende Module scharf schalten
## 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. Diese Stufe schließt die Lücke — und liefert nebenbei das Fundament, auf dem
Stufe C überhaupt erst möglich ist.*
Datenquellen. Dieser Bereich schließt die Lücke — und liefert nebenbei das Fundament, auf dem
Bereich C überhaupt erst möglich ist.*
### B1 ⬜ CopyTrading Phase 1 — Marktdaten-Fundament
### [B] #142 — 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.
**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 |
|---|---|
@@ -236,38 +319,39 @@ Schritt ist Stufe C nicht baubar.
| **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.
**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
### [B] #144 — CopyTrading Restposten
*Blockiert durch B1 — alle drei hängen an echten Fill-Daten.*
**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 **C3 (StrategieDrift)** zusammenlegen — die Sniper-Metrik ist ein
⚠️ 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
### B3 🔒 ResolutionFarming live schalten
### [B] #145 — ResolutionFarming live schalten
*Blockiert durch A4b (Zielland).*
**Auslöser: sobald #138 abgeschlossen ist** — es braucht das 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.
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)
### B4 🔒 AutoRedeem (On-Chain)
### [B] #146 — AutoRedeem (On-Chain)
*Blockiert durch B3.* ⚠️ **Höchste Kritikalitätsstufe** — On-Chain-Signing mit echten Private Keys.
**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.
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 |
|---|---|
@@ -280,42 +364,38 @@ Direktaufruf — Module erkennen einlösbare Positionen, der Core löst ein.
→ [archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md)
### B5 ⬜ Supervisor: Live-Key-Test
### [B] #147 — Accounting A-3: US-Steuerschicht
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.*
**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.
A-2 (Abrechnung/BWA/FX) und A-4 (CSV+PDF-Export) sind fertig (#167).
Fragebogen für die Beraterin: [steuer/Accounting-US-Tax-Questionnaire.md](./steuer/Accounting-US-Tax-Questionnaire.md)
Fragebogen: [steuer/Accounting-US-Tax-Questionnaire.md](./steuer/Accounting-US-Tax-Questionnaire.md)
### B7 🔒 Accounting A-5 — Reconciliation
### [B] #148 — Accounting A-5: Reconciliation
*Blockiert durch B3 — sinnvoll erst mit echten Live-Daten.*
**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.
aber der eigentliche Prüfwert des Moduls: **Abweichungen zwischen beiden Quellen sind das
Signal.**
---
## Stufe C — Neue Strategiemodule
## C — Neue Strategiemodule
*Erst wenn Stufe A und B stehen. Alle vier sind vollständig geplant und haben null Zeilen Code.*
*Erst wenn A und B stehen. Alle vier sind vollständig geplant und haben null Zeilen Code.*
### C1 🔒 Modul MarketMaking
### [C] #149 — Modul MarketMaking
*Blockiert durch B1 (harte Voraussetzung: Orderbuch-Infrastruktur).*
**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** (Konflikt
mit CopyTrading vermeiden).
tägliche Liquidity Rewards (USDC), Maker-Rebates und den Spread. **Eigener Account**, um den
Konflikt mit CopyTrading zu vermeiden.
| Phase | Inhalt |
|---|---|
@@ -325,8 +405,8 @@ mit CopyTrading vermeiden).
| 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.
**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
@@ -334,76 +414,84 @@ schlechter und halbiert den Lerneffekt).
→ [archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-MarketMaking.md](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-Modul-MarketMaking.md)
### C2 🔒 Modul BundleArbitrage
### [C] #150 — Modul BundleArbitrage
*Blockiert durch B1. Startet bewusst als reines **Mess-Modul**.*
**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 C1. Deshalb: erst messen, dann entscheiden.
> 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 B4 als **ein** Core-Baustein bauen |
| 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)
### C3 ⏸️ StrategieDrift-Erkennung
### [C] #151 — StrategieDrift-Erkennung
*Zurückgestellt — nicht blockiert, aber ohne B1/B2 nur halb so wirksam.*
**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.
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.
⚠️ **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)
### C4 ⏸️ AI-Bewertung der Auflösequalität
### [C] #152 — AI-Bewertung der Auflösequalität
*Zurückgestellt.* Core-Baustein, kein eigenes Modul.
**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.
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.
**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
## 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.*
*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
### [D] #153 — 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).
**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:**
@@ -413,76 +501,103 @@ später Sport-Spielstände).
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
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
### [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 C3 (Fingerprint-Baseline wäre von dort importierbar).
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)
---
## Technische Schuld (laufend)
## T — Technische Schuld
*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 |
### [T] #155 — 15 Build-Warnungen im Avalonia-Projekt
**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.
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.
---
## Abgeschlossen
## H — Verlauf
*Verlauf — die Detailpläne liegen im Archiv.*
*Was abgeschlossen ist, steht im erzeugten Block. Hier steht nur, was eine Begründung braucht.*
| 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 |
### [H] #174 — Watchdog und LicenseLabrador als getrennte Dienste
**Verworfen:** Watchdog und LicenseLabrador als getrennte Dienste — ersetzt durch das
Deploymentcenter.
**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. 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.
[`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)