PolyTraderSharp/docs/PROJEKTSTAND.md

Projektstand PolyTrader

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.

---

1. Kurzfassung

PolyTrader ist eine modulare Trading- und Analyse-Suite für Polymarket: ein schlanker Core und vier eigenständige Module, dazu eine plattformneutrale Avalonia-Oberfläche.

Projekte	7 (Core, 4 Module, Avalonia-App, Tests) — alle auf net10.0
Plattform	Windows und Linux. Seit dem 22.08.2026 kein net10.0-windows mehr im Repo; Linux-Publish verifiziert
Produktivcode	~27.100 LOC, davon Core ~8.000, CopyTrading ~7.700, UI ~4.900
Tests	476, alle grün (~5.700 LOC)
Build	0 Fehler, 15 Warnungen (alle im Avalonia-Projekt, siehe §5.3)
Sicherheit	0 anfällige Pakete über alle 7 Projekte, inkl. transitiver
Datenbank	MySQL über EF Core / Pomelo. Mongo und SQLite vollständig entfernt

Der große Bogen ist geschlossen. Aus dem monolithischen WinForms-Copytrader ist ein modulares, plattformneutrales System geworden. Was noch offen ist, teilt sich sauber in zwei Gruppen: Dinge, die nur im Zielland mit echtem Geld abgenommen werden können, und bewusst zurückgestellte Neuentwicklung.

---

2. Architektur

PolyTrader.Core          Host, Persistenz (EF/MySQL), Settings, Jobs, Logging,
                         CLOB-Client, Streaming, Security, Deploymentcenter-Anbindung
   │
   ├── Modules.CopyTrading        Master-Trader spiegeln
   ├── Modules.ResolutionFarming  Favoriten nahe Auflösung
   ├── Modules.Supervisor         KI-gestützte Handelsanalyse (OpenRouter)
   └── Modules.Accounting         Unabhängige Buchhaltung aller Live-Accounts
   │
PolyTrader.App.Avalonia  Einfenster-Shell mit Seitenleiste

Leitprinzip, das gehalten hat: Der Core kennt keine Module. Module registrieren sich über IPolyTraderModule und liefern ihre Ansichten über einen toolkit-neutralen UI-Contract — deshalb war der Wechsel von WinForms nach Avalonia überhaupt möglich, ohne die Fachlogik anzufassen.

---

3. Modul-Stand

Modul	Stand	Offen
CopyTrading	Produktiv nutzbar. Rentabilitätsplan und alle Review-Fixes umgesetzt	CLOB-User-/Market-WSS-Kanal + Orderbuch-Check, Partial-Fill-Verdrahtung, echte fee_rate_bps — alles live-gebunden
ResolutionFarming	Slices 0–5 fertig: Logik, Persistenz, Scanner, UI, Demo-Execution, Monitor	Live-Anbindung und On-Chain-Redeem
Supervisor	S-0 bis S-4 komplett: Journal, Dossiers, OpenRouter-Agent, Profile, Berichte, Counterfactual	Predictalytics-Werkzeuge (API existiert noch nicht), Live-Key-Test
Accounting	A-1 Ingest, A-2 Abrechnung/BWA/FX und A-4 Export (CSV + PDF) sind gebaut	A-3 US-Steuerschicht fehlt vollständig — kein UsTaxEngine, kein Form-8949/Schedule-D

---

4. Abgeschlossen

• Modularisierung (Phasen 0–6) — Core + vier Module, kein Monolith mehr
• MySQL-Migration — Mongo restlos raus, core_/mod_-Schema, Migration über --migrate-json / --verify-mysql gelaufen
• Linux-Portierung, UI-Teil — WinForms vollständig nach Avalonia portiert (A1–A4), LiveCharts2 statt ScottPlot, kategorisierter SettingsEditor statt PropertyGrid
• Einfenster-Shell — Mehrfenster-Launcher durch eine Shell mit Seitenleiste ersetzt
• Deploymentcenter-Integration (D-0 bis D-5) — Lizenz, Watchdog, Fehler-Reporting, Auslieferung und Erstinstallation, code-seitig
• Sicherheit F1–F6 — AES-GCM at-rest für Keys über POLYTRADER_MASTER_KEY, keine Secrets in Argumenten oder Logs
• WinForms-Ausbau (P11/L5) und LicenseLabrador-Ablösung (D-6) — 22.08.2026

---

5. Offen

5.1 Blockiert durch Live-Betrieb / Zielland

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
Keine CI	Weder .github/workflows noch .gitea/workflows — es existiert keinerlei Automatisierung. Build und Tests laufen ausschließlich von Hand. Der größte strukturelle Mangel
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)

---

6. Der Frühjahrsputz vom 22.08.2026

Zwei Commits: dd8da3f sicherte den unversionierten Arbeitsstand (58 Dateien: die Deploymentcenter-Integration und die Einfenster-Shell lagen uncommittet im Arbeitsbaum), bf8048b räumte auf.

Entfernt — 124 Dateien, 10.619 Zeilen weniger:

• Das WinForms-Projekt samt Ui/, Models/, Licensing/, services/, Properties/, Resources/icons/, Program.cs, favicon.ico und PolyTrader.App.csproj
• LicenseLabrador.Client aus lib/nuget und dem Quellen-Mapping
• agentspace/ (30 Dateien: WinForms-Designer-Patcher, fix_mongo.py, Wegwerfskripte)
• Ideen-fuer-Mittwoch.txt, das Root-appsettings.json (Duplikat), lokal MongoDB/, data.db und eine .bak-Datei

Beim Aufräumen aufgefallen und mitbehoben:

• Der Rückfall-Tag winforms-final lag nur lokal und war nicht auf dem Server — genau die Sicherung, auf die sich die Doku als Fallback beruft. Jetzt gepusht.
• Die Avalonia-App band ihre PNG-Symbole aus dem Repo-Root ein (..\..\Resources\*.png) und hätte sie beim Ausbau verloren. Sie liegen jetzt in src/PolyTrader.App.Avalonia/Assets/; der avares://-Pfad blieb gleich.

Bewusst nicht entfernt, obwohl Pläne es nahelegten:

• Newtonsoft.Json im Core ist kein toter Ballast, sondern ein Sicherheits-Pin: Nethereum 6.1.0 würde sonst transitiv auf 11.0.2 auflösen (GHSA-5crp-9r3c-p9vr).
• Die Watchdog*-Felder in ServerSettings. Schnitt D-6 verlangte ihre Entfernung, aber D-1 hatte sie zuvor auf die Deploymentcenter-API umgewidmet. Sie sind in Gebrauch; ein Entfernen wäre ein Rückschritt gewesen.
• Resources/*.png — siehe oben.

Gesucht und nicht gefunden: toter Code. Eine Prüfung aller 285 Typen in src/ gegen ihre Verwendung ergab keinen einzigen verwaisten Typ. Die scheinbaren Treffer waren EF-Design-Time-Factories und Migrationen (per Reflection genutzt) sowie Null-Stubs, die über DI registriert sind. Auch leere catch {}-Blöcke: keine.

Doku nachgezogen: Der Modularisierungsplan führte die Phasen 3–6 als „IN ARBEIT" beziehungsweise offen, obwohl sie seit Wochen erledigt waren — die Häkchen sind jetzt am Code nachgeprüft gesetzt. Der Watchdog/LicenseLabrador-Plan ist als abgelöst gekennzeichnet, ANALYSE-Linux-Portierung.md steht auf Revision 6.

---

7. Doku-Landkarte

Dokument	Rolle
PROJEKTSTAND.md	Dieses Dokument — Einstieg und Gesamtüberblick
ANALYSE-Linux-Portierung.md	Rahmen der Linux-Fähigkeit, Fahrplan P1–P11 / L1–L5
LEITFADEN-Avalonia-Portierung.md	Arbeitsregeln für die Oberfläche. Vor jeder UI-Arbeit lesen
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

Abgelöst, nur noch Verlauf: UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md

---

8. Empfohlene nächste Schritte

1. A5 durchklicken — die Oberfläche mit echten Daten abnehmen. Blockiert nichts technisch, ist aber die letzte offene Zusage der UI-Portierung.
2. CI aufsetzen — der größte strukturelle Mangel. Ein Workflow, der dotnet build und dotnet test auf Linux fährt, hätte den plattformneutralen Zustand von allein gehalten.
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.