Eine Roadmap statt fuenfzehn Plandokumente; Altbestand ins Archiv
Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle. docs/ROADMAP.md (neu): - Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf. Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die Voraussetzung fuer die naechste. - Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern. - Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen, Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten. - Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag: CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen bauen statt doppelt. Archiv (docs/archiv/): - 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung). Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und Begruendungen - eingefroren ist nur ihr Status. - archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu. Verweise nachgezogen - der eigentliche Aufwand: - 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/. - 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene (csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen. - Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/, Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen. - Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen. PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap. Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Richard
@@ -1,4 +1,4 @@
|
||||
<Project>
|
||||
<Project>
|
||||
|
||||
<!--
|
||||
Eine Versionsnummer für alle Projekte der Solution.
|
||||
@@ -14,7 +14,7 @@
|
||||
die sonst früher oder später auseinanderlaufen.
|
||||
|
||||
Hochzählen bei jedem Release, siehe
|
||||
docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md (D-4).
|
||||
docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md (D-4).
|
||||
-->
|
||||
<PropertyGroup>
|
||||
<Version>0.1.0</Version>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"_comment": "Kopie als packager.config.json in diesem Ordner anlegen und ausfuellen. packager.config.json ist per .gitignore ausgeschlossen. Alternativ ueber Umgebungsvariablen: DC_FTP_HOST, DC_FTP_PORT, DC_FTP_USER, DC_FTP_PASS, DC_API_URL, DC_TOKEN. Siehe docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-4.",
|
||||
"_comment": "Kopie als packager.config.json in diesem Ordner anlegen und ausfuellen. packager.config.json ist per .gitignore ausgeschlossen. Alternativ ueber Umgebungsvariablen: DC_FTP_HOST, DC_FTP_PORT, DC_FTP_USER, DC_FTP_PASS, DC_API_URL, DC_TOKEN. Siehe docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-4.",
|
||||
|
||||
"ftpHost": "ftp.example.com",
|
||||
"ftpPort": 21,
|
||||
|
||||
@@ -77,7 +77,7 @@ zweimal gebaut wird. → siehe ❓F-1.
|
||||
Trades aus einer früheren PolyTrader-Version on-chain stehen. Auch „Konto abrufen"
|
||||
für das Testkonto liefert nichts.
|
||||
**Befund (geprüft):** Kein Rechen-Bug — es kommen **gar keine Daten** rein.
|
||||
In [`AccountingModule.cs:43-45`](src/PolyTrader.Modules.Accounting/AccountingModule.cs)
|
||||
In [`AccountingModule.cs:43-45`](../src/PolyTrader.Modules.Accounting/AccountingModule.cs)
|
||||
sind alle drei Ingest-Quellen als Null-Stubs registriert:
|
||||
|
||||
```csharp
|
||||
@@ -87,7 +87,7 @@ services.AddSingleton<IBalanceAnchorSource, NullBalanceAnchorSource>();
|
||||
```
|
||||
|
||||
`NullActivitySource.GetActivityAsync` gibt konstant ein leeres Array zurück
|
||||
([`Services/IngestSources.cs:36-51`](src/PolyTrader.Modules.Accounting/Services/IngestSources.cs)).
|
||||
([`Services/IngestSources.cs:36-51`](../src/PolyTrader.Modules.Accounting/Services/IngestSources.cs)).
|
||||
Der Ingest bucht daher „korrekt nichts" — der Ledger bleibt leer, folglich ist jede
|
||||
Auswertung 0. Das war bewusst so (A-1 = Fundament, Live-Quellen „im Zielland").
|
||||
**Wichtig:** Die Begründung „Zielland" trägt hier nicht — Accounting **liest nur**
|
||||
@@ -167,7 +167,7 @@ oben ausgewählten Jobs** — z. B. beim „Threema Webhook Listener": wann lief
|
||||
je Aufruf eine Kurzinfo (wurden Nachrichten abgerufen? Fehler?). So sieht man auf einen
|
||||
Blick, ob die Jobs überhaupt laufen.
|
||||
**Befund:** `Ui/Views/JobsView.cs` bindet schlicht `jobManager.Jobs` ans Grid.
|
||||
`JobManager` ([`Services/JobManager.cs`](src/PolyTrader.Core/Services/JobManager.cs)) ist
|
||||
`JobManager` ([`Services/JobManager.cs`](../src/PolyTrader.Core/Services/JobManager.cs)) ist
|
||||
eine reine `BindingList<JobStatusRow>` — **es gibt keinerlei Lauf-Historie**, nur den
|
||||
aktuellen Status. Die Historie muss also erst entstehen.
|
||||
**Ansatz:** `JobRunEntry` (JobName, Start, Dauer, Ergebnis Ok/Warn/Fehler, Kurztext,
|
||||
@@ -227,7 +227,7 @@ Trades bereits gebaut), Prädikate für PnL-Vorzeichen und Marktstatus (baut auf
|
||||
**Beobachtung:** Ein Button, der alle beendeten Märkte einlöst. Frage: Wie ist der
|
||||
Stand der Redeem-Integration?
|
||||
**Befund (geprüft):** **Nicht implementiert.** Es existiert ein durchdachter Plan
|
||||
([`docs/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md`](docs/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md),
|
||||
([`docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md`](./archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md),
|
||||
Stand 11.07.2026) mit Queue-Architektur, Modul-Schaltern und 4 Phasen (RD-1 … RD-4) —
|
||||
aber im Code gibt es weder `IRedeemQueue` noch `OnChainCtfService` noch die Tabelle
|
||||
`core_redeem_queue`. Grep über das gesamte Repo findet diese Begriffe **ausschließlich
|
||||
@@ -248,7 +248,7 @@ und unterliegen `.agents/rules/clob.md` in verschärfter Form.
|
||||
müsste jetzt schon funktionieren, um zu sehen, ob und wie die Erkennung läuft. Tut es
|
||||
offenbar nicht.
|
||||
**Befund (geprüft):** Gleiche Ursache wie ACC-1. In
|
||||
[`ResolutionFarmingModule.cs:41`](src/PolyTrader.Modules.ResolutionFarming/ResolutionFarmingModule.cs)
|
||||
[`ResolutionFarmingModule.cs:41`](../src/PolyTrader.Modules.ResolutionFarming/ResolutionFarmingModule.cs)
|
||||
ist `IFarmingMarketSource` auf `NullFarmingMarketSource` gesetzt → der `MarketScannerService`
|
||||
läuft, bekommt aber nie Märkte und produziert „korrekt keine Kandidaten". Ebenso ist
|
||||
`IMarketResolutionSource` auf `NullMarketResolutionSource` gesetzt (nichts löst je auf).
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Stand:** 13.08.2026 (A1–A4 abgehakt, Deploymentcenter-Hinweis) · **Zielgruppe:** KI-Agent, der die UI-Portierung fortsetzt
|
||||
**Vorgänger-Dokumente:** [`UI-SPEZIFIKATION-WinForms.md`](UI-SPEZIFIKATION-WinForms.md) (wie die alte
|
||||
Oberfläche aussah), [`ANALYSE-Linux-Portierung.md`](ANALYSE-Linux-Portierung.md) (Gesamtplan)
|
||||
Oberfläche aussah), [`ANALYSE-Linux-Portierung.md`](./archiv/ANALYSE-Linux-Portierung.md) (Gesamtplan)
|
||||
|
||||
---
|
||||
|
||||
@@ -42,7 +42,7 @@ etwas Dynamisches brauchst (Menüeinträge, Formularfelder), dann so:
|
||||
- Das **Datenmodell** liefert eine Liste (`ObservableCollection<T>`)
|
||||
- Das **XAML** beschreibt über `ItemsControl` + `DataTemplate`, wie ein Element aussieht
|
||||
|
||||
Vorbilder im Code: [`Controls/WindowMenuBar.axaml`](../src/PolyTrader.App.Avalonia/Controls/WindowMenuBar.axaml)
|
||||
Vorbilder im Code: `Controls/WindowMenuBar.axaml` (am 22.08.2026 entfernt, siehe Tag `winforms-final`)
|
||||
und [`Controls/SettingsEditor.axaml`](../src/PolyTrader.App.Avalonia/Controls/SettingsEditor.axaml).
|
||||
|
||||
### 1.2 Keine festen Farben
|
||||
|
||||
+21
-54
@@ -3,8 +3,9 @@
|
||||
**Stand: 22.08.2026** · erstellt beim Frühjahrsputz, alle Angaben am Code nachgeprüft
|
||||
(nicht aus Plandokumenten übernommen — mehrere davon waren veraltet).
|
||||
|
||||
> Dieses Dokument ist der Einstiegspunkt: Was existiert, was ist fertig, was ist offen und
|
||||
> warum. Die Detailpläne unter `umsetzungsplaene/` bleiben maßgeblich für das *Wie*.
|
||||
> **Arbeitsteilung:** Dieses Dokument beschreibt, was **ist** — Architektur, Kennzahlen,
|
||||
> Modul-Stand. Was **kommt**, steht in der [ROADMAP.md](./ROADMAP.md). Die Detailpläne im
|
||||
> [Archiv](./archiv/) bleiben maßgeblich für das *Wie*.
|
||||
|
||||
---
|
||||
|
||||
@@ -81,44 +82,18 @@ die Fachlogik anzufassen.
|
||||
|
||||
## 5. Offen
|
||||
|
||||
### 5.1 Blockiert durch Live-Betrieb / Zielland
|
||||
**Steht vollständig in der [ROADMAP.md](./ROADMAP.md).** Dort sind alle Vorhaben nach Stufen
|
||||
geordnet, mit Blockern und Begründungen — dieses Dokument beschreibt den *Ist*-Zustand, die
|
||||
Roadmap den Weg nach vorn. Kurz zusammengefasst:
|
||||
|
||||
Diese Punkte sind **nicht** liegengeblieben — sie lassen sich am Schreibtisch nicht
|
||||
abschließen, weil sie echtes Geld, echte Marktdaten oder den Zielserver brauchen.
|
||||
|
||||
| Punkt | Was fehlt |
|
||||
|---|---|
|
||||
| **A5 — Abnahme der Oberfläche** | Jedes Fenster mit echten Daten durchklicken: Spaltenbreiten, Umbrüche, Splitter, KPI-Kacheln. Vergleich gegen einen Worktree des Tags `winforms-final` |
|
||||
| **Deploymentcenter live** | Abnahme von D-1/D-2 (Watchdog, Lizenz), Live-Abnahme von D-5 (Erstinstallation). Serverseitig fehlen: Release-Signierschlüssel und Installationskonto |
|
||||
| **Alte Dienste abschalten** | `watchdog.mhdf.de` und `license.mhdf.de` — erst **nach** der Live-Abnahme, sonst fehlt die Rückfallebene |
|
||||
| **Master-Key im Zielland** | Master-Key setzen und Bestandsdaten migrieren; Alchemy- und Mullvad-Zugänge rotieren |
|
||||
| **Modul-Livegang** | CopyTrading-WSS-Kanäle, ResolutionFarming-Anbindung und On-Chain-Redeem (siehe §3) |
|
||||
| **systemd / Feldtest** | Unit liegt unter `deploy/polytrader.service`, ist aber nicht im Betrieb erprobt |
|
||||
|
||||
### 5.2 Geplant, aber bewusst nicht gebaut
|
||||
|
||||
Vollständige Pläne, **null Zeilen Code** — jederzeit startbar, nichts davon blockiert
|
||||
etwas anderes:
|
||||
|
||||
| Vorhaben | Art |
|
||||
|---|---|
|
||||
| **Modul MarketMaking** | Liquidity Rewards + Spread. Setzt das Orderbuch-Fundament aus CopyTrading Phase 1 voraus |
|
||||
| **Modul BundleArbitrage** | Preissummen-Anomalien. Startet bewusst als reines Mess-Modul |
|
||||
| **Modul DataDriven** | Konzept, noch kein Umsetzungsplan |
|
||||
| **StrategieDrift** | Verhaltensänderung eines Masters erkennen, bevor das PnL es zeigt |
|
||||
| **AI-Auflösequalität** | LLM bewertet je Markt das Resolution-Risiko als Entry-Gate |
|
||||
| **AutoRedeem** | On-Chain-Auto-Redeem, modulweise schaltbar. Höchste Kritikalitätsstufe |
|
||||
| **Accounting A-3** | US-Steuerschicht (FIFO-Lot-Matching, Form 8949, Schedule D) |
|
||||
|
||||
### 5.3 Technische Restposten
|
||||
|
||||
| Punkt | Details |
|
||||
|---|---|
|
||||
| **CI: Workflow da, Runner fehlt** | [`.gitea/workflows/ci.yml`](../.gitea/workflows/ci.yml) ist angelegt (Build + 476 Tests + Linux-Publish auf Linux, dazu Wächter gegen windows-spezifische Rückfälle, versionierte Secrets und anfällige Pakete). **Auf der Gitea-Instanz ist aber kein Runner registriert** — geprüft auf Repo-, Benutzer- und Instanzebene. Bis der Runner steht, läuft der Workflow nicht. Einrichtung: [LEITFADEN-CI.md](./LEITFADEN-CI.md) §3 |
|
||||
| **15 Build-Warnungen** | Alle im Avalonia-Projekt: 13 × `CS8618` (Felder in Fenster-Konstruktoren), 1 × `CS8848` (Vorrang bei `switch`), 1 × `CS8602` (möglicher Nullverweis in `PdfExporter.cs:40`). Die letzten beiden sind einen Blick wert |
|
||||
| **TerminalLogger** | Stempelt mit `DateTime.Now` statt der konfigurierten `AppTimeZone`. Auf einem UTC-Linuxserver passen Logdatei-Grenzen nicht zur angezeigten Uhrzeit. Umstellung auf `Microsoft.Extensions.Logging` steht ohnehin aus |
|
||||
| **God-Methoden** | `PollLiveAccountsAsync`, `ProcessAccountOrderAsync`; duplizierte Closed-Trade-Erzeugung (Phase 7) |
|
||||
| **Aufgeschobene Follow-ups** | TradeId-Autoincrement, Dedup, Performance (aus dem CopyTrading-Plan) |
|
||||
- **Stufe A — Abnahme & Fundament:** A5-Abnahme der Oberfläche, CI-Runner, Deploymentcenter
|
||||
live, systemd/Feldtest, Master-Key im Zielland
|
||||
- **Stufe B — Module scharf schalten:** CopyTrading Phase 1 (Marktdaten-Fundament, der
|
||||
wichtigste Einzelposten), ResolutionFarming live, AutoRedeem, Accounting A-3/A-5
|
||||
- **Stufe C — Neue Strategiemodule:** MarketMaking, BundleArbitrage (beide hängen an
|
||||
CopyTrading Phase 1), StrategieDrift und AI-Auflösequalität (zurückgestellt)
|
||||
- **Stufe D — Nicht beschlossen:** DataDriven, Predictalytics-Anbindung
|
||||
- **Technische Schuld:** 15 Build-Warnungen, TerminalLogger/Zeitzone, God-Methoden
|
||||
|
||||
---
|
||||
|
||||
@@ -170,13 +145,12 @@ gekennzeichnet, `ANALYSE-Linux-Portierung.md` steht auf Revision 6.
|
||||
|
||||
| Dokument | Rolle |
|
||||
|---|---|
|
||||
| `PROJEKTSTAND.md` | **Dieses Dokument** — Einstieg und Gesamtüberblick |
|
||||
| `ANALYSE-Linux-Portierung.md` | Rahmen der Linux-Fähigkeit, Fahrplan P1–P11 / L1–L5 |
|
||||
| `ROADMAP.md` | **Das Steuerungsdokument** — alle Vorhaben, Status, Reihenfolge |
|
||||
| `PROJEKTSTAND.md` | **Dieses Dokument** — der Ist-Zustand: Architektur, Kennzahlen, Modul-Stand |
|
||||
| `archiv/` | Die Detailpläne, aus denen die Roadmap entstand. Weiterhin die Bauanleitungen |
|
||||
| `LEITFADEN-Avalonia-Portierung.md` | Arbeitsregeln für die Oberfläche. **Vor jeder UI-Arbeit lesen** |
|
||||
| `LEITFADEN-CI.md` | Was die CI prüft und wie der Gitea-Runner eingerichtet wird |
|
||||
| `UI-SPEZIFIKATION-WinForms.md` | Beschreibung der alten Oberfläche — Vergleichsvorlage für A5 |
|
||||
| `umsetzungsplaene/` | Detailpläne je Vorhaben |
|
||||
| `konzepte/` | Vorhaben ohne Umsetzungsplan |
|
||||
| `sicherheit/SICHERHEITSKONZEPT.md` | Konzept + **wiederkehrende Audit-Checkliste**. Die offenen Kästchen dort sind eine Vorlage, keine Rückstände |
|
||||
| `IDEENSAMMLUNG-Feldtest-2026-08.md` | Beobachtungen aus dem laufenden Einsatz. Nur sammeln |
|
||||
| `.agents/rules/clob.md` | Regeln für alles, was Geld bewegt |
|
||||
@@ -185,15 +159,8 @@ gekennzeichnet, `ANALYSE-Linux-Portierung.md` steht auf Revision 6.
|
||||
|
||||
---
|
||||
|
||||
## 8. Empfohlene nächste Schritte
|
||||
## 8. Wie es weitergeht
|
||||
|
||||
1. **A5 durchklicken** — die Oberfläche mit echten Daten abnehmen. Blockiert nichts
|
||||
technisch, ist aber die letzte offene Zusage der UI-Portierung.
|
||||
2. **CI scharf schalten** — der Workflow liegt, es fehlt nur der Runner (etwa 10 Minuten,
|
||||
siehe [LEITFADEN-CI.md](./LEITFADEN-CI.md) §3). Erst dann hält der plattformneutrale
|
||||
Zustand von allein; bis dahin ist er nur eine Momentaufnahme.
|
||||
3. **Deploymentcenter live abnehmen** — danach können die Altdienste abgeschaltet werden,
|
||||
womit zwei Sicherheits-Auflagen von selbst entfallen.
|
||||
4. **Erst dann neue Module.** MarketMaking und BundleArbitrage sind fertig geplant und
|
||||
warten — aber Neuentwicklung vor der Abnahme des Bestehenden vergrößert nur die Menge
|
||||
an ungeprüftem Code.
|
||||
Die Reihenfolge steht in der **[ROADMAP.md](./ROADMAP.md)**. Die kürzeste Fassung: erst die
|
||||
Abnahmen aus Stufe A abschließen (dort steckt fertige Arbeit, die nur noch bestätigt werden
|
||||
muss), dann CopyTrading Phase 1 — daran hängen beide geplanten Strategiemodule.
|
||||
|
||||
+44
-37
@@ -1,49 +1,56 @@
|
||||
# Doku (Predictalytics / PolyTraderSharp)
|
||||
|
||||
Zentrale Ablage für Konzepte, Umsetzungspläne, Ideen und Fach-/Business-Dokumente — nach Typ in
|
||||
Unterordnern organisiert. Code-gekoppelte Umsetzungspläne bleiben bewusst in **diesem** Repo (statt in
|
||||
einem separaten Docs-Repo), damit „Plan → umsetzende Commits" nachvollziehbar bleibt.
|
||||
Zentrale Ablage für Roadmap, Leitfäden, Fach- und Business-Dokumente. Code-gekoppelte Pläne
|
||||
bleiben bewusst in **diesem** Repo (statt in einem separaten Docs-Repo), damit
|
||||
„Plan → umsetzende Commits" nachvollziehbar bleibt.
|
||||
|
||||
## Wo anfangen?
|
||||
|
||||
**[PROJEKTSTAND.md](./PROJEKTSTAND.md)** — Gesamtüberblick: was existiert, was fertig ist,
|
||||
was offen ist und warum. Der Einstiegspunkt für alle, die den Stand wissen wollen, ohne sich
|
||||
durch die Detailpläne zu lesen.
|
||||
| | |
|
||||
|---|---|
|
||||
| **[ROADMAP.md](./ROADMAP.md)** | **Das Steuerungsdokument.** Alle Vorhaben, Status, Reihenfolge — was als Nächstes zu tun ist und was bewusst liegen bleibt |
|
||||
| **[PROJEKTSTAND.md](./PROJEKTSTAND.md)** | Der Ist-Zustand: Architektur, Kennzahlen, Modul-Stand |
|
||||
|
||||
Daneben liegen im Wurzelverzeichnis dieses Ordners drei querschnittliche Dokumente:
|
||||
`ANALYSE-Linux-Portierung.md` (Rahmen und Fahrplan der Plattformneutralität),
|
||||
`LEITFADEN-Avalonia-Portierung.md` (**Arbeitsregeln — vor jeder UI-Arbeit lesen**),
|
||||
`LEITFADEN-CI.md` (was die CI prüft und wie der Gitea-Runner eingerichtet wird) und
|
||||
`UI-SPEZIFIKATION-WinForms.md` (Beschreibung der abgelösten Oberfläche, Vergleichsvorlage
|
||||
für die Abnahme A5).
|
||||
Kurzformel: **PROJEKTSTAND = was ist. ROADMAP = was kommt.**
|
||||
|
||||
## Leitfäden (vor der Arbeit lesen)
|
||||
|
||||
- **[LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md)** — Arbeitsregeln für
|
||||
die Oberfläche. **Vor jeder UI-Arbeit lesen**: Layout ist deklarativ, keine festen Farben,
|
||||
Module bleiben frei von Avalonia.
|
||||
- **[LEITFADEN-CI.md](./LEITFADEN-CI.md)** — was die CI prüft und wie der Gitea-Runner
|
||||
eingerichtet wird.
|
||||
- **[`.agents/rules/clob.md`](../.agents/rules/clob.md)** — verbindlich für alles, was Geld bewegt.
|
||||
|
||||
## Struktur
|
||||
|
||||
- **`konzepte/`** — Konzepte für neue Module/Features (das „Warum" und „Was", vor der Umsetzung).
|
||||
- `KONZEPT-Modul-Accounting.md` — Buchhaltungs-/Steuer-Reporting-Modul (unabhängiger Polymarket-Abruf, BWA, CSV/PDF, US-Steuer Florida LLC).
|
||||
- `KONZEPT-Modul-DataDriven.md`
|
||||
- **`umsetzungsplaene/`** — konkrete, slice-weise Implementationspläne (das „Wie"), oft mit `file:line`-Bezügen und Fortschritt.
|
||||
- `UMSETZUNGSPLAN-Modularisierung.md` — Umbau Copytrader → Core + Module.
|
||||
- `UMSETZUNGSPLAN-CopyTrading-Verbesserungen.md` — Rentabilitäts-/Fable-Plan Copytrading.
|
||||
- `UMSETZUNGSPLAN-Fable-Review-Fixes.md` — Fable-Code-Review-Fixes (Slices 0–6 + Tests).
|
||||
- `UMSETZUNGSPLAN-Modul-ResolutionFarming.md` — Strategiemodul ResolutionFarming.
|
||||
- `UMSETZUNGSPLAN-Modul-MarketMaking.md` — Strategiemodul MarketMaking (Phase-1-blockiert).
|
||||
- `UMSETZUNGSPLAN-Modul-BundleArbitrage.md` — Strategiemodul BundleArbitrage (Phase-1-blockiert).
|
||||
- `UMSETZUNGSPLAN-AutoRedeem.md`, `UMSETZUNGSPLAN-AI-Aufloesequalitaet.md`, `UMSETZUNGSPLAN-StrategieDrift.md`
|
||||
- `UMSETZUNGSPLAN-Deploymentcenter-Integration.md` — Lizenz, Watchdog, Fehler-Reporting und
|
||||
Auslieferung über das Deploymentcenter (P3c).
|
||||
- ⛔ `UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md` — **abgelöst** durch den
|
||||
Deploymentcenter-Plan, bleibt nur als Verlaufsdokument liegen.
|
||||
- **`ideen/`** — frühe Ideen/Explorationen, bevor sie zu einem Konzept oder Umsetzungsplan reifen.
|
||||
- **`pruefplaene/`** — Prüf-/Validierungspläne.
|
||||
- `PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md` — Master-Trader-Auswahl (separates Predictalytics-Projekt).
|
||||
- **`steuer/`** — Steuer-/Buchhaltungs-Fachdokumente & Vorlagen (auch zum Weitergeben an Berater).
|
||||
- **[`archiv/`](./archiv/)** — die Umsetzungspläne und Konzepte, aus denen die Roadmap
|
||||
zusammengeführt wurde. **Nicht tot:** weiterhin die Bauanleitungen mit Code-Bezügen,
|
||||
Akzeptanzkriterien und Begründungen. Nur der *Status* darin ist eingefroren — dafür gilt
|
||||
ausschließlich die Roadmap. Details in [`archiv/README.md`](./archiv/README.md).
|
||||
- **[`sicherheit/`](./sicherheit/)** — Sicherheitskonzept und die wiederkehrende
|
||||
Audit-Checkliste. Die offenen Kästchen in Abschnitt 6 sind eine **Vorlage für jedes Release**,
|
||||
kein Rückstand.
|
||||
- **[`steuer/`](./steuer/)** — Steuer-/Buchhaltungs-Fachdokumente und Vorlagen, auch zum
|
||||
Weitergeben an Berater.
|
||||
- `Accounting-US-Tax-Questionnaire.md` — Fragebogen (EN) für die US-Steuerberaterin (Florida LLC).
|
||||
- **`sicherheit/`** — Sicherheitskonzept und die wiederkehrende Audit-Checkliste.
|
||||
- `SICHERHEITSKONZEPT.md` — die offenen Kästchen in Abschnitt 6 sind eine **Vorlage für jedes
|
||||
Release**, kein Rückstand.
|
||||
- **[`pruefplaene/`](./pruefplaene/)** — Prüf-/Validierungspläne.
|
||||
- `PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md` — Master-Trader-Auswahl (separates
|
||||
Predictalytics-Projekt).
|
||||
- **`ideen/`** — frühe Ideen, bevor sie zu einem Konzept reifen.
|
||||
- **[UI-SPEZIFIKATION-WinForms.md](./UI-SPEZIFIKATION-WinForms.md)** — Beschreibung der
|
||||
abgelösten Oberfläche. Vergleichsvorlage für die Abnahme A5.
|
||||
- **[IDEENSAMMLUNG-Feldtest-2026-08.md](./IDEENSAMMLUNG-Feldtest-2026-08.md)** — Beobachtungen
|
||||
aus dem laufenden Einsatz. Nur sammeln, Umsetzung später.
|
||||
|
||||
## Konventionen
|
||||
- Neue Konzepte: `KONZEPT-*.md` → `konzepte/`. Neue Umsetzungspläne: `UMSETZUNGSPLAN-*.md` → `umsetzungsplaene/`.
|
||||
- Übergreifende/an Externe weitergebbare Dokumente können später in ein eigenes `Predictalytics-Docs`-Repo
|
||||
ausgelagert werden (Ordner rausziehen genügt) — für jetzt bewusst hier gebündelt.
|
||||
|
||||
- **Eine Statusquelle.** Fortschritt wird ausschließlich in der Roadmap gepflegt, nirgends sonst.
|
||||
Bis zum 22.08.2026 stand der Status in einem Dutzend Dokumenten — mehrere davon waren
|
||||
wochenlang falsch.
|
||||
- **Plandokument und Code wandern im selben Commit.** Wer etwas abhakt, committet die Roadmap mit.
|
||||
- Neue Detailpläne: `UMSETZUNGSPLAN-*.md` → `archiv/umsetzungsplaene/`, und in der Roadmap
|
||||
verlinken. Neue Konzepte analog nach `archiv/konzepte/`.
|
||||
- Übergreifende, an Externe weitergebbare Dokumente können später in ein eigenes
|
||||
`Predictalytics-Docs`-Repo ausgelagert werden (Ordner rausziehen genügt) — für jetzt bewusst
|
||||
hier gebündelt.
|
||||
|
||||
+405
@@ -0,0 +1,405 @@
|
||||
# Roadmap PolyTrader
|
||||
|
||||
**Stand: 23.08.2026** · 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 |
|
||||
| **A4** | systemd + Feldtest im Zielland | 🔒 A3 | A |
|
||||
| **A5** | Master-Key setzen, Zugänge rotieren | 🔒 A4 | A |
|
||||
| **B1** | CopyTrading Phase 1 — Marktdaten-Fundament | ⬜ | B |
|
||||
| **B2** | CopyTrading Restposten | 🔒 B1 | B |
|
||||
| **B3** | ResolutionFarming live schalten | 🔒 A4 | 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
|
||||
|
||||
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.
|
||||
|
||||
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. Einrichtung in **[LEITFADEN-CI.md](./LEITFADEN-CI.md) §3**
|
||||
(~10 Minuten). Der Runner gehört auf den Gitea-Host, nicht auf den Arbeitsrechner — sonst prüft
|
||||
niemand, wenn der Rechner aus 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)
|
||||
|
||||
### A4 🔒 systemd + Feldtest im Zielland
|
||||
|
||||
*Blockiert durch A3.*
|
||||
|
||||
Die Unit liegt unter [`deploy/polytrader.service`](../deploy/polytrader.service), ist aber nie im
|
||||
Betrieb gelaufen. `--headless` existiert bereits in `Program.cs`. Dazu: Logrotate, Zeitzone
|
||||
prüfen, Neustart-Verhalten.
|
||||
|
||||
### A5 🔒 Master-Key setzen, Zugänge rotieren
|
||||
|
||||
*Blockiert durch A4 (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 A4 (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 — **spätestens bei A4** |
|
||||
| **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)
|
||||
@@ -470,7 +470,7 @@ Rückversicherung im Tag `winforms-final`. Der aktuelle Engpass ist nicht mehr d
|
||||
| ~~**L0b**~~ | ~~Threema-Ausbau + `INotificationSink`~~ | — | ✅ **erledigt** – 36 Dateien raus, 448 Tests grün, 8 Warnungen weniger |
|
||||
| ~~**L1a**~~ | ~~Tag `winforms-final` + P1 (Core/Module entkoppeln) + P4 (PDF)~~ | — | ✅ **erledigt** – Core, 4 Module und Testprojekt sind `net8.0`; alle sechs publishen für linux-x64 ohne Windows-Pakete; 442 Tests grün |
|
||||
| **L1b** | P0 ✅ + P2 ✅ + P3 (Mullvad, Dateirechte) + **P3c (Deploymentcenter)** | 2–4 PT | P0/P2 erledigt (Spike wurde zur vollen Portierung; Zeitzone konfigurierbar). **Offen: P3c — steht als Nächstes an** und ersetzt Lizenzverwaltung, Watchdog und Error-Reporting grundlegend. |
|
||||
| **L2** | ~~Headless-Einstiegspunkt~~ ✅ + systemd + Feldtest im Zielland | 2–4 PT | `--headless` existiert ([`App.Avalonia/Program.cs:41`](../src/PolyTrader.App.Avalonia/Program.cs)). Offen: systemd-Unit + Feldtest. **Trading läuft headless auf Linux.** ⭐ Meilenstein |
|
||||
| **L2** | ~~Headless-Einstiegspunkt~~ ✅ + systemd + Feldtest im Zielland | 2–4 PT | `--headless` existiert ([`App.Avalonia/Program.cs:41`](../../src/PolyTrader.App.Avalonia/Program.cs)). Offen: systemd-Unit + Feldtest. **Trading läuft headless auf Linux.** ⭐ Meilenstein |
|
||||
| ~~**L3**~~ | ~~P5 + P6 + P7 (Charts, Shell, Core-Views)~~ | — | ✅ **erledigt** – Avalonia-Grundgerüst (`cd59e5c`), Dashboard mit LiveCharts2 (`0b8728b`), Settings (`4ba8149`), Terminal (`929fa20`), Dunkelmodus (`487ea44`) |
|
||||
| **L4** | ~~P8 (Modul-Fenster)~~ ✅ + P9 (**CI**) | 2–4 PT | Modul-Fenster portiert (`669676a`), Restlücken A1–A4 geschlossen (`7f0b05e`), 450 Tests grün. **Offen: es gibt keinerlei CI-Konfiguration** – weder `.github/workflows` noch `.gitea/workflows`. |
|
||||
| ~~**L5**~~ | ~~P11 – WinForms endgültig aus dem Build entfernen~~ | — | ✅ **erledigt am 22.08.2026** (Frühjahrsputz). Vorgezogen vor die A5-Abnahme, weil der Rückfall-Tag `winforms-final` auf dem Server gesichert ist und A5 auch gegen einen Worktree dieses Tags geprüft werden kann. Ergebnis: 91 Dateien und ~4.500 LOC Designer-Code weg, Build-Warnungen von 23 auf 15 gesunken, `LicenseLabrador.Client` mit ausgebaut (D-6). |
|
||||
@@ -0,0 +1,61 @@
|
||||
# Archiv
|
||||
|
||||
**Angelegt am 23.08.2026.** Hier liegen die Dokumente, aus denen
|
||||
[ROADMAP.md](../ROADMAP.md) zusammengeführt wurde.
|
||||
|
||||
## Diese Dokumente sind nicht tot
|
||||
|
||||
Sie bleiben die **Bauanleitungen**. Wer ein Vorhaben aus der Roadmap umsetzt, findet hier die
|
||||
Details, die in einer Roadmap keinen Platz haben: Code-Bezüge mit `datei:zeile`,
|
||||
Akzeptanzkriterien je Phase, Risikotabellen mit Gegenmaßnahmen, Datenmodelle und vor allem die
|
||||
**Begründungen** — warum eine Entscheidung so und nicht anders getroffen wurde.
|
||||
|
||||
Was hier **nicht** mehr gilt, ist der **Status**. Fortschrittsangaben, Häkchen und
|
||||
„offen/erledigt"-Vermerke in diesen Dateien sind eingefroren. Maßgeblich ist allein die Roadmap.
|
||||
|
||||
> Das ist kein theoretisches Risiko: Bis zum 22.08.2026 wies der Modularisierungsplan die
|
||||
> Phasen 3–6 als „IN ARBEIT" aus, obwohl die MySQL-Migration und die Modultrennung seit Wochen
|
||||
> fertig waren. Genau deshalb gibt es jetzt nur noch **eine** Statusquelle.
|
||||
|
||||
## Inhalt
|
||||
|
||||
### `umsetzungsplaene/`
|
||||
|
||||
| Datei | Roadmap-Bezug |
|
||||
|---|---|
|
||||
| `UMSETZUNGSPLAN-Modularisierung.md` | ✅ abgeschlossen (Phasen 0–6) |
|
||||
| `UMSETZUNGSPLAN-CopyTrading-Verbesserungen.md` | teils ✅, **Phase 1 ist B1** — der wichtigste offene Posten |
|
||||
| `UMSETZUNGSPLAN-Fable-Review-Fixes.md` | ✅ abgeschlossen (Slices 0–6) |
|
||||
| `UMSETZUNGSPLAN-Modul-ResolutionFarming.md` | Slices 0–5 ✅, Livegang ist **B3** |
|
||||
| `UMSETZUNGSPLAN-Deploymentcenter-Integration.md` | D-0–D-6 ✅ code-seitig, Live-Abnahme ist **A3** |
|
||||
| `UMSETZUNGSPLAN-AutoRedeem.md` | **B4** |
|
||||
| `UMSETZUNGSPLAN-Modul-MarketMaking.md` | **C1** |
|
||||
| `UMSETZUNGSPLAN-Modul-BundleArbitrage.md` | **C2** |
|
||||
| `UMSETZUNGSPLAN-StrategieDrift.md` | **C3** (zurückgestellt) |
|
||||
| `UMSETZUNGSPLAN-AI-Aufloesequalitaet.md` | **C4** (zurückgestellt) |
|
||||
| `UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md` | ⛔ **abgelöst** — nicht umsetzen |
|
||||
|
||||
### `konzepte/`
|
||||
|
||||
| Datei | Roadmap-Bezug |
|
||||
|---|---|
|
||||
| `KONZEPT-Modul-Accounting.md` | A-1/A-2/A-4 ✅, A-3 ist **B6**, A-5 ist **B7** |
|
||||
| `KONZEPT-Modul-Supervisor.md` | S-0–S-4 ✅, Live-Key-Test ist **B5** |
|
||||
| `KONZEPT-Modul-DataDriven.md` | **D1** — nicht beschlossen, es gibt keinen Umsetzungsplan |
|
||||
|
||||
### Einzeldokument
|
||||
|
||||
`ANALYSE-Linux-Portierung.md` — Analyse und Fahrplan der Linux-Fähigkeit (P1–P11, L1–L5).
|
||||
Fachlich weiterhin lesenswert: die Bestandsaufnahme, welcher Code portabel war und warum. Der
|
||||
Fahrplan selbst ist abgearbeitet bis auf CI (**A2**) und systemd/Feldtest (**A4**).
|
||||
|
||||
## Ein Hinweis zu Dateiverweisen
|
||||
|
||||
Manche Dokumente verlinken auf Dateien, die es nicht mehr gibt — vor allem der abgelöste
|
||||
Watchdog-Plan, der auf `Ui/`, `Program.cs` und `Licensing/` der WinForms-Anwendung zeigt. Diese
|
||||
Verweise wurden entschärft (Klartext statt Link). Der zugehörige Code liegt im Git-Tag
|
||||
`winforms-final`:
|
||||
|
||||
```bash
|
||||
git worktree add ../polytrader-winforms winforms-final
|
||||
```
|
||||
+11
-11
@@ -323,7 +323,7 @@ selbst so benannt („bewusst nicht Teil dieses Commits"), deckt sich mit unsere
|
||||
|
||||
### D-1 · Watchdog auf die Deploymentcenter-API umstellen ✅ ERLEDIGT (14.08.2026)
|
||||
|
||||
Umgesetzt in [WatchdogHeartbeatService.cs](../../src/PolyTrader.Core/Services/WatchdogHeartbeatService.cs).
|
||||
Umgesetzt in [WatchdogHeartbeatService.cs](../../../src/PolyTrader.Core/Services/WatchdogHeartbeatService.cs).
|
||||
Abweichung von der ursprünglichen Planung: **kein neues Konfigurationsschema.** `ServerSettings`
|
||||
(XML, Live-Reload, maskierte Token-Eingabe – bereits erprobte Mechanik) bleibt die Quelle für
|
||||
`WatchdogUrl`/`WatchdogToken`/`WatchdogSource`/`WatchdogInstance`/`WatchdogIntervalSeconds`; nur
|
||||
@@ -361,9 +361,9 @@ ProjectSlug, Channel, Feature-Schalter).
|
||||
|
||||
### D-2 · Lizenz auf das Deploymentcenter umstellen ✅ ERLEDIGT (15.08.2026)
|
||||
|
||||
Umgesetzt in [Licensing/LicenseGate.cs](../../src/PolyTrader.App.Avalonia/Licensing/LicenseGate.cs),
|
||||
[Licensing/LicenseCli.cs](../../src/PolyTrader.App.Avalonia/Licensing/LicenseCli.cs) und den neuen
|
||||
Lizenz-Schaltflächen in [SettingsWindow.axaml(.cs)](../../src/PolyTrader.App.Avalonia/Views/SettingsWindow.axaml).
|
||||
Umgesetzt in [Licensing/LicenseGate.cs](../../../src/PolyTrader.App.Avalonia/Licensing/LicenseGate.cs),
|
||||
[Licensing/LicenseCli.cs](../../../src/PolyTrader.App.Avalonia/Licensing/LicenseCli.cs) und den neuen
|
||||
Lizenz-Schaltflächen in [SettingsWindow.axaml(.cs)](../../../src/PolyTrader.App.Avalonia/Views/SettingsWindow.axaml).
|
||||
Zwei Abweichungen von der ursprünglichen Planung, beide vereinfachend:
|
||||
|
||||
- **Kein eigenes `ILicensePrompt`, kein eigener modaler Lizenzdialog.** Für die GUI wird die
|
||||
@@ -428,8 +428,8 @@ Alchemy-Listener) aus dieser Sitzung heraus zu öffnen; das bleibt Richards manu
|
||||
|
||||
### D-3 · Fehler-Reporting ✅ ERLEDIGT (17.08.2026)
|
||||
|
||||
Umgesetzt in [DeploymentcenterErrorReporter.cs](../../src/PolyTrader.Core/Services/DeploymentcenterErrorReporter.cs)
|
||||
und [SecretRedactor.cs](../../src/PolyTrader.Core/Security/SecretRedactor.cs) (die
|
||||
Umgesetzt in [DeploymentcenterErrorReporter.cs](../../../src/PolyTrader.Core/Services/DeploymentcenterErrorReporter.cs)
|
||||
und [SecretRedactor.cs](../../../src/PolyTrader.Core/Security/SecretRedactor.cs) (die
|
||||
Secret-Muster-Prüfung aus `WatchdogHeartbeatService.Sanitize` wurde dorthin ausgelagert, damit
|
||||
Heartbeat-Meldung — kurz, einzeilig — und Stacktrace — lang, mehrzeilig — dieselbe Musterprüfung,
|
||||
aber unterschiedliche Kürzungsregeln bekommen, ohne Code zu verdoppeln).
|
||||
@@ -558,7 +558,7 @@ unverändert weiter und erzeugt **keine** Fehlerschleife.
|
||||
|
||||
**Umgesetzt (Schritte 1 und 3 der ursprünglichen Planung):**
|
||||
|
||||
- Update-Prüfung beim Start in [LauncherWindow.axaml(.cs)](../../src/PolyTrader.App.Avalonia/Views/LauncherWindow.axaml):
|
||||
- Update-Prüfung beim Start in [LauncherWindow.axaml(.cs)](../../../src/PolyTrader.App.Avalonia/Views/LauncherWindow.axaml):
|
||||
fire-and-forget, nur aktiv bei `Deploymentcenter:UpdateCheckEnabled` (Vorgabe `false`), nutzt
|
||||
`ReleaseCredentials.FromLicenseKey(...)` mit dem entschlüsselten `ServerSettings.LicenseKey`.
|
||||
Ein gefundenes Update erscheint als Banner (Version, Changelog, `is_critical`-Hinweis) mit
|
||||
@@ -656,7 +656,7 @@ Diese Ausgabe muss **leer** sein.
|
||||
|
||||
**Umgesetzt:**
|
||||
|
||||
- [setup.json](../../src/PolyTrader.App.Avalonia/setup.json) im App-Projekt (per `CopyToOutputDirectory`
|
||||
- [setup.json](../../../src/PolyTrader.App.Avalonia/setup.json) im App-Projekt (per `CopyToOutputDirectory`
|
||||
im Publish-Paket) mit zwei Zielen: `appsettings.json` (Deploymentcenter-Block: `BaseUrl` via
|
||||
`detect:baseurl`, `ProjectSlug` via `detect:project`, `Channel`, `Token` via `provision` mit den
|
||||
Scopes `watchdog:ping`+`bugtracker:report`) und `appsettings.Local.json` (`Database:MySqlConnectionString`
|
||||
@@ -668,16 +668,16 @@ Diese Ausgabe muss **leer** sein.
|
||||
über das Einstellungsfenster — beide sind seit D-1/D-2 genau dafür gebaut (maskierte
|
||||
Eingabe-Buttons, sofort wirksam ohne Neustart). Im `setup.json`-Kommentar dokumentiert, damit das
|
||||
nicht als vergessenes Feld missverstanden wird.
|
||||
- **Master-Key-Erzeugung (D-10)** in [MasterKeyResolver.cs](../../src/PolyTrader.Core/Security/MasterKeyResolver.cs)
|
||||
- **Master-Key-Erzeugung (D-10)** in [MasterKeyResolver.cs](../../../src/PolyTrader.Core/Security/MasterKeyResolver.cs)
|
||||
(neu, testbar in `PolyTrader.Core` statt direkt in `Program.cs` verdrahtet) + gemeinsamer
|
||||
[FilePermissions.cs](../../src/PolyTrader.Core/Security/FilePermissions.cs)-Helfer (ersetzt die
|
||||
[FilePermissions.cs](../../../src/PolyTrader.Core/Security/FilePermissions.cs)-Helfer (ersetzt die
|
||||
bisher in `SettingsWindow.axaml.cs` duplizierte `RestrictToOwner`-Logik). Reihenfolge:
|
||||
Umgebungsvariable → vorhandene Datei → **nur wenn beides fehlt** neu erzeugen. 8 Tests, u.a.
|
||||
explizit „ein zweiter/dritter Aufruf erzeugt niemals neu" und „ein fehlgeschlagener Schreibversuch
|
||||
wirft nie, sondern warnt". Live geprüft: frisches Verzeichnis ohne `master.key` →
|
||||
`--smoke-ui`-Lauf erzeugt die Datei mit der erwarteten Log-Meldung, `SecretProtection` aktiviert
|
||||
sich sofort danach in derselben Sitzung.
|
||||
- [polytrader.service](../../deploy/polytrader.service) (systemd-Unit-Vorlage) löst **D-11**: setzt
|
||||
- [polytrader.service](../../../deploy/polytrader.service) (systemd-Unit-Vorlage) löst **D-11**: setzt
|
||||
`WorkingDirectory` ausdrücklich auf das Installationsverzeichnis, mit Begründung im Kommentar
|
||||
(sonst laden `server_settings.xml`, relativ zum Arbeitsverzeichnis, und `master.key`, relativ zu
|
||||
`AppContext.BaseDirectory`, aus unterschiedlichen Orten). `SIGTERM` mit 45 s Frist für den
|
||||
+6
-6
@@ -200,8 +200,8 @@ Nachrichtenflut untergeht.
|
||||
|
||||
### B.1 Slice W-A — Heartbeat-Grundgerüst ✅ ERLEDIGT (29.07.2026)
|
||||
|
||||
Umgesetzt in [WatchdogHeartbeatService.cs](../../src/PolyTrader.Core/Services/WatchdogHeartbeatService.cs)
|
||||
mit 21 Tests in [WatchdogHeartbeatTests.cs](../../tests/PolyTrader.Tests/WatchdogHeartbeatTests.cs).
|
||||
Umgesetzt in [WatchdogHeartbeatService.cs](../../../src/PolyTrader.Core/Services/WatchdogHeartbeatService.cs)
|
||||
mit 21 Tests in [WatchdogHeartbeatTests.cs](../../../tests/PolyTrader.Tests/WatchdogHeartbeatTests.cs).
|
||||
Abweichungen und Ergänzungen gegenüber der Planung unten:
|
||||
|
||||
- **TLS-Zwang implementiert:** `TryBuildEndpoint` akzeptiert nur `https://`; `http://` ausschließlich
|
||||
@@ -318,10 +318,10 @@ und die Fremdprojekt-Auflagen (Watchdog-Secrets rotieren, UTC/NOW(), `self_ping`
|
||||
|
||||
### B.4 Slice L-A — Lizenzprüfung beim Start ✅ ERLEDIGT (31.07.2026)
|
||||
|
||||
Umgesetzt in [Licensing/LicenseGate.cs](../../Licensing/LicenseGate.cs), Startdialog in
|
||||
[Ui/LicenseDialog.cs](../../Ui/LicenseDialog.cs) (+`.Designer.cs`), Verdrahtung in
|
||||
[Program.cs](../../Program.cs), Schlüssel-/Statusfeld in
|
||||
[ServerSettings.cs](../../src/PolyTrader.Core/Models/ServerSettings.cs). Abweichungen und
|
||||
Umgesetzt in `Licensing/LicenseGate.cs`, Startdialog in
|
||||
`Ui/LicenseDialog.cs` (+`.Designer.cs`), Verdrahtung in
|
||||
`Program.cs`, Schlüssel-/Statusfeld in
|
||||
[ServerSettings.cs](../../../src/PolyTrader.Core/Models/ServerSettings.cs). Abweichungen und
|
||||
Ergänzungen gegenüber der ursprünglichen Planung unten:
|
||||
|
||||
- **Ort:** `LicenseGate` liegt im **App-Projekt** (`PolyTraderSharp.Licensing`), nicht in Core.
|
||||
+1
-1
@@ -6,7 +6,7 @@ Aktuell genau eines: `Deploymentcenter.Client` (Lizenz, Watchdog, Fehler-Reporti
|
||||
> Bis zum 22.08.2026 lag hier zusätzlich `LicenseLabrador.Client`. Das Paket ist mit dem
|
||||
> Ausbau der WinForms-Anwendung entfernt worden — Lizenzprüfung und Heartbeat laufen
|
||||
> vollständig über das Deploymentcenter (siehe
|
||||
> `docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md`, Schnitt D-6).
|
||||
> `docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md`, Schnitt D-6).
|
||||
> Der letzte Stand mit LicenseLabrador liegt im Git-Tag `winforms-final`.
|
||||
|
||||
## Warum ein Paket und keine Projektreferenz?
|
||||
|
||||
@@ -11,7 +11,7 @@ namespace PolyTrader.App.Avalonia.Licensing
|
||||
/// <summary>
|
||||
/// Lizenz-Torwächter für den Programmstart (D-2). Ersetzt den früheren, gegen
|
||||
/// <c>LicenseLabrador.Client</c> gebauten <c>Licensing/LicenseGate.cs</c> im WinForms-Projekt
|
||||
/// (siehe docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md) – dort läuft
|
||||
/// (siehe docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md) – dort läuft
|
||||
/// ohnehin keine Lizenzprüfung, weil Avalonia die tatsächlich benutzte Anwendung ist.
|
||||
///
|
||||
/// **Grundsatz unverändert:** kein <see cref="Environment.Exit(int)"/> bei ungültiger Lizenz. Ein
|
||||
|
||||
@@ -200,7 +200,7 @@ namespace PolyTrader.App.Avalonia
|
||||
// D-1: erster "checks"-Eintrag - beweist die Mechanik mit einem real
|
||||
// verfügbaren Signal. db/market_feed folgen, sobald die jeweiligen Dienste
|
||||
// ein Gesundheitssignal nach außen geben (siehe
|
||||
// docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, D-1).
|
||||
// docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, D-1).
|
||||
var vpn = sp.GetRequiredService<MullvadVpnService>();
|
||||
var serverSettings = sp.GetRequiredService<ServerSettings>();
|
||||
watchdog.RegisterCheck("vpn", () => serverSettings.VpnEnabled
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"_comment": "Gelesen vom Deploymentcenter-Installer (update-agent --action install / --action configure). Siehe docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-5. Fragt NUR ab, was hier noch fehlt: Watchdog-Aktivierung und Lizenzschlüssel liegen bewusst NICHT hier, sondern bleiben Post-Install-Schritte über das Einstellungsfenster (server_settings.xml, maskierte Eingabe, Live-Reload) - setup.json kann nur json/env schreiben, unser server_settings.xml ist XML.",
|
||||
"_comment": "Gelesen vom Deploymentcenter-Installer (update-agent --action install / --action configure). Siehe docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-5. Fragt NUR ab, was hier noch fehlt: Watchdog-Aktivierung und Lizenzschlüssel liegen bewusst NICHT hier, sondern bleiben Post-Install-Schritte über das Einstellungsfenster (server_settings.xml, maskierte Eingabe, Live-Reload) - setup.json kann nur json/env schreiben, unser server_settings.xml ist XML.",
|
||||
|
||||
"schema": 1,
|
||||
"displayName": "PolyTrader",
|
||||
|
||||
@@ -6,7 +6,7 @@ namespace PolyTrader.Core.Configuration
|
||||
///
|
||||
/// Ersetzt die bisherigen Einzeldienste Watchdog (watchdog.mhdf.de) und LicenseLabrador
|
||||
/// (license.mhdf.de) durch einen gemeinsamen Gegenüber. Siehe
|
||||
/// docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md.
|
||||
/// docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md.
|
||||
///
|
||||
/// <c>Token</c> und <c>LicenseKey</c> sind Geheimnisse und gehören NICHT in die versionierte
|
||||
/// <c>appsettings.json</c> - dort stehen nur die leeren Platzhalter mit Kommentar, die echten
|
||||
|
||||
@@ -62,7 +62,7 @@ namespace PolyTraderSharp.Models
|
||||
/// Eine Zeile im Entscheidungsjournal (core_decision_journal): JEDE Handelsentscheidung –
|
||||
/// ausgeführt, abgelehnt oder übersprungen – strukturiert und abfragbar. Grundlage für
|
||||
/// Supervisor-Analysen („warum (nicht) gehandelt?") und Counterfactual-Auswertungen
|
||||
/// (MarketSlug/EndDate sind dafür bewusst enthalten). Siehe docs/konzepte/KONZEPT-Modul-Supervisor.md.
|
||||
/// (MarketSlug/EndDate sind dafür bewusst enthalten). Siehe docs/archiv/konzepte/KONZEPT-Modul-Supervisor.md.
|
||||
/// </summary>
|
||||
public class DecisionRecord
|
||||
{
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
<PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" Version="8.0.0" />
|
||||
<PackageReference Include="Nethereum.Web3" Version="6.1.0" />
|
||||
<!-- Deploymentcenter-Integration (Lizenz, Watchdog, Fehler-Reporting, Updates) - siehe
|
||||
docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md. Lokales Paket in
|
||||
docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md. Lokales Paket in
|
||||
lib/nuget, keine Projektreferenz ins Nachbar-Repo (PolyTrader muss ohne das
|
||||
Schwester-Repo bauen, siehe lib/nuget/README.md). Erzeugt beim Bauen zusätzlich die
|
||||
Klasse PolyTrader.Core.BuildInfo (Version, Git-Commit, Build-Datum) über
|
||||
|
||||
@@ -22,7 +22,7 @@ namespace PolyTraderSharp.Services
|
||||
///
|
||||
/// **Umstellung 14.08.2026:** Ersetzt den eigenständigen Watchdog-Dienst (watchdog.mhdf.de) und
|
||||
/// LicenseLabrador durch das Deploymentcenter (siehe
|
||||
/// docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-1). Endpunkte
|
||||
/// docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-1). Endpunkte
|
||||
/// sind jetzt <c>/api/watchdog/v1/ping</c> und <c>/api/watchdog/v1/event</c>, Auth-Header
|
||||
/// <c>Authorization: Bearer</c> statt <c>X-Watchdog-Key</c>. <see cref="ServerSettings.WatchdogUrl"/>
|
||||
/// und <see cref="ServerSettings.WatchdogToken"/> zeigen ab jetzt auf das Deploymentcenter statt
|
||||
|
||||
@@ -13,7 +13,7 @@ namespace PolyTrader.Modules.Accounting
|
||||
/// <summary>
|
||||
/// Modul „Accounting": vollständige, von unserer Trading-DB UNABHÄNGIGE, buchhalterisch korrekte
|
||||
/// Erfassung aller Transaktionen der Live-Accounts (direkte Polymarket-/On-Chain-Abrufe → append-only
|
||||
/// Ledger). Reines Ingest-/Reporting-Modul, KEIN Handel. Konzept: docs/konzepte/KONZEPT-Modul-Accounting.md.
|
||||
/// Ledger). Reines Ingest-/Reporting-Modul, KEIN Handel. Konzept: docs/archiv/konzepte/KONZEPT-Modul-Accounting.md.
|
||||
///
|
||||
/// A-1 (dieser Slice): Modul + acc_-Persistenz + pure Klassifikation + idempotenter Ingest hinter
|
||||
/// Interfaces (Null-Quellen offline; Live-Abruf im Zielland) + Ledger-/Status-UI. A-2 Abrechnung/BWA/FX,
|
||||
|
||||
@@ -9,7 +9,7 @@ using PolyTrader.Modules.Supervisor.Services;
|
||||
namespace PolyTrader.Modules.Supervisor
|
||||
{
|
||||
/// <summary>
|
||||
/// Supervisor-Modul (docs/konzepte/KONZEPT-Modul-Supervisor.md): Analyse/Forensik über ALLE
|
||||
/// Supervisor-Modul (docs/archiv/konzepte/KONZEPT-Modul-Supervisor.md): Analyse/Forensik über ALLE
|
||||
/// Module — strikt read-only (kein Handel). S-1: Dossier-Browser über Entscheidungsjournal,
|
||||
/// Order-Events, Trade-Log und JSONL-Logs. S-2 (OpenRouter-Agent + Tool-Registry), S-3
|
||||
/// (Profile/Berichte/Counterfactual/Predictalytics) und S-4 (MCP-Light) folgen.
|
||||
|
||||
Reference in New Issue
Block a user