RichardandClaude Opus 5
6218a04fe4
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>
5.4 KiB
5.4 KiB
Umsetzungsplan: Strategie-Drift-Erkennung für Master-Trader (B-S2)
Stand: 2026-07-11 Ziel: Verhaltens-Änderungen eines Masters erkennen, BEVOR sie sich im Copy-PnL niederschlagen. Die bestehende Auto-Pause (Copy-PnL-basiert) ist ein nachlaufender Indikator — bei 95-¢-Tradern sieht man den Schaden erst nach mehreren Verlusten. Verhalten läuft dem PnL voraus: Ein Wetter-Bot, der plötzlich Politik-Longshots kauft, hat die Strategie gewechselt, lange bevor die Verluste messbar sind. Modul: PolyTrader.Modules.CopyTrading (baut auf vorhandenem MasterTraderAnalyticsJob auf).
1. Der Verhaltens-Fingerprint
Je Master werden zwei Fenster verglichen: Referenz (30 Tage bzw. die von
Predictalytics gelieferte Baseline) vs. aktuell (7 Tage). Datenquelle: die
Activity-/History-Daten, die der MasterTraderAnalyticsJob bereits lädt
(mod_copytrading_mt_history + Data-API-Activity; für Preisband/Größe die
Activity-Items — Felder existieren in den bereits geparsten JSONs).
Fingerprint-Metriken (pure Klasse Logic/TraderFingerprint.cs, voll unit-getestet):
| Metrik | Definition | Drift-Beispiel |
|---|---|---|
TradesPerWeek |
Trade-Frequenz | Bot-Betreiber wechselt von 40 auf 400/Woche |
CategoryMix |
Einsatz-Anteil je Kategorie (Vektor) | Wetter-Bot kauft plötzlich Politik |
PriceBandMix |
Einsatz-Anteil je Einstiegs-Preisband (10-¢-Bänder) | Favoriten-Halter kauft Longshots |
MedianHoldHours |
Median Haltedauer (Kauf→Close/Resolution) | Halter wird Day-Trader |
SellRatio |
Anteil aktiv verkaufter Positionen | „Stur-Halter" beginnt zu verkaufen |
SizeP90Rel |
90. Perzentil Positionsgröße relativ zur Referenz | Martingale-/Tilt-Muster |
Drift-Score
Pro Metrik eine normierte Abweichung (für Anteils-Vektoren: L1-Distanz / 2 → 0..1;
für Skalare: |akt − ref| / max(ref, ε) gekappt auf 1). Gesamt:
DriftScore = gewichtete Summe (Default-Gewichte: CategoryMix 0.3, PriceBandMix 0.25,
SellRatio 0.2, TradesPerWeek 0.1, MedianHoldHours 0.1, SizeP90Rel 0.05)
Schwellen (global in CopyTradingState, per PropertyGrid änderbar, mit
[Description]): DriftWarnScore (Default 0.25) und DriftPauseScore (Default 0.5).
Mindeststichprobe: unter 10 Trades im 7-Tage-Fenster keine Bewertung (Rauschen).
2. Aktionen bei Drift
| Stufe | Bedingung | Aktion |
|---|---|---|
| Beobachten | Score < Warn | nichts; Score in UI-Spalte sichtbar |
| Warnen | Warn ≤ Score < Pause | Threema-Meldung mit den 2 größten Abweichungen („Kategorie-Mix: Wetter 90→40 %, Politik 0→45 %"); Master in UI gelb |
| Neu-Trades pausieren | Score ≥ Pause UND AutoPauseEnabled |
NEUE BUYs dieses Masters aussetzen (DriftPaused-Flag auf TrackedTrader, Engine-Check im BUY-Pfad analog ExitPending); offene Positionen + SELL-Handling laufen normal weiter; Threema; Reaktivierung manuell |
Bewusst: Drift pausiert nur Neu-Käufe — es verkauft nichts. Bestehende Positionen sind Sache der normalen Exit-Mechanik (Halter: Resolution).
3. Umsetzung
Slice D-1: Pure Logik + Persistenz
Logic/TraderFingerprint.cs:Compute(IEnumerable<TradeObservation>)→ Fingerprint;Drift(reference, current)→ Score + Top-Abweichungen. Unit-Tests (Vektor-Distanzen, Mindeststichprobe, Rand: leere Referenz).TrackedTrader: FelderFingerprintBaselineJson(Referenz, von Predictalytics importierbar ODER selbst aus 30 Tagen berechnet),DriftScore,DriftPaused,DriftDetail(Kurztext) + Migration.MasterTraderHistoryRecorderweitern um die dafür nötigen Felder (EntryPrice-Band, Kategorie, Size, Haltedauer), sofern noch nicht vorhanden — beim History-Download mit befüllen (Daten sind in den API-Antworten enthalten).
Slice D-2: Job-Integration
- Im
MasterTraderAnalyticsJobnach dem History-Download: Fingerprint aktuell (7 T) vs. Referenz (30 T bzw. BaselineJson) → Score, Aktionen gemäß Tabelle. - Frequenz: Der Job läuft 12-stündlich — für Drift zu träge. Leichten Stunden-Tick ergänzen (nur Fingerprint-Neuberechnung aus bereits geladenen History-Daten, KEINE zusätzlichen API-Calls; die 12-h-Läufe aktualisieren die Rohdaten).
- Referenz-Handhabung: Baseline wird NICHT automatisch nachgezogen, solange eine Warnung/Pause aktiv ist (sonst „lernt" die Referenz die Drift). Nach manueller Entwarnung: Baseline auf aktuelles 30-T-Fenster zurücksetzen (Button in UI).
Slice D-3: Engine + UI
- Engine-BUY-Pfad:
DriftPaused-Check (analogIsActive), TradeReasoning-Log. MastersTradersView: Spalten DriftScore (mit Ampelfarbe) + DriftDetail; Kontextmenü „Drift entwarnen + Baseline zurücksetzen".
4. Akzeptanzkriterien
- Unit-Tests: konstruierte Drift-Szenarien (Kategorie-Wechsel, Frequenz-Explosion, Longshot-Umstieg) erzeugen erwartete Scores; stabile Master bleiben < Warn.
- Simulierter Kategorie-Wechsel in Testdaten führt zu
DriftPaused+ Engine verweigert Neu-BUY mit nachvollziehbarem Log. - Kein zusätzlicher Data-API-Traffic durch den Stunden-Tick (nur DB/RAM).
- Threema-Meldungen enthalten die konkreten Top-Abweichungen, nicht nur den Score.
5. Abgrenzung
- Ersetzt NICHT die PnL-Auto-Pause (Phase 3.3, bleibt) — Drift ist das Frühwarnsystem, PnL-Pause das Sicherheitsnetz.
- Sniper-Metriken (Plan Phase 3.2, Median-Haltezeit via Activity-Pagination) sind ein Spezialfall dieses Fingerprints — bei Umsetzung zusammenlegen statt doppelt bauen.