# Predictalytics — Roadmap > Angelegt am **2026-08-23**. Führt zusammen, was vorher über neun Plandokumente verstreut > lag. Jeder Punkt hier ist gegen den Code geprüft — was schon umgesetzt war, steht nicht > mehr drin. > > **Ist-Stand des Projekts:** [`STATUS.md`](STATUS.md). > **Die alten Dokumente** liegen vollständig unter [`docs/archiv/`](docs/archiv/) und > werden nicht mehr gepflegt. Sie bleiben als Begründungs- und Detailquelle: wo ein Punkt > unten knapp bleibt, steht die ausführliche Herleitung dort. Die Verweise sind jeweils > angegeben. ## Legende | | Bedeutung | |---|---| | 🔴 | Dringend — sollte vor allem anderen passieren | | 🟢 | Eingeplant — wird als Nächstes abgearbeitet | | 🟡 | Backlog — gewollt, aber noch nicht terminiert | | 💡 | **Konzept — bewusst nicht eingeplant.** Idee ist durchdacht und aufgehoben, die Umsetzung ist nicht beschlossen | | 👤 | Liegt beim Nutzer, nicht am Code (SQL, Kontoverwaltung, Entscheidungen) | | ❌ | Bewusst verworfen — nicht wieder aufgreifen ohne neuen Anlass | Innerhalb der Stufen ist die Reihenfolge gedacht, aber nicht bindend. Zwischen den Stufen schon: jede baut auf der vorigen auf. --- ## Stufe 0 — Sofort ### 0.1 🔴 👤 OpenRouter-API-Key zurückziehen und neu ausstellen `src/Predictalytics.Api/appsettings.json` enthält einen **echten** Schlüssel im Klartext, versioniert seit Commit `7045002` und damit auf dem Gitea-Server. 1. Schlüssel bei OpenRouter widerrufen, neuen ausstellen. 2. Neuen Schlüssel **nicht** in die Datei schreiben, sondern als Umgebungsvariable `OpenRouter__ApiKey` setzen. `WebApplication.CreateBuilder` liest Umgebungsvariablen mit Vorrang vor `appsettings.json` — dafür ist keine Codeänderung nötig. 3. Erst danach den Platzhalter in `appsettings.json` leeren. Den Wert nur aus der Datei zu löschen genügt nicht: der Git-Verlauf behält ihn. Deshalb führt an Schritt 1 kein Weg vorbei. > Herkunft: [`archiv/UMSETZUNGSPLAN.md`](docs/archiv/UMSETZUNGSPLAN.md) B2 — dort noch als „kein akuter Risikofall" eingestuft, was > sich als falsch herausgestellt hat. --- ## Stufe 1 — Aufräumen abschließen ### 1.1 🟢 `feature/linux-net10` nach `main` bringen `main` steht neun Commits zurück und kennt weder die Avalonia-Shell noch die Deploymentcenter-Anbindung. Alle Feature-Zweige sind in `feature/linux-net10` aufgegangen. Danach löschbar (lokal und auf origin): ``` copy-portfolio edge-freshness fingerprint-drift-foundation insider-follow-feed integration smart-money-comovement smart-money-graph ui-ranglisten-showcases ops-watchdog-license fix-event-description-truncation ``` ### 1.2 🟡 Acht Nullable-Warnungen beheben `TradeRepository.cs:94-102` (6×), `PolymarketProvider.cs:357`, `TraderAnalyticsWorker.cs:152`. Bestehen seit Längerem und sind kein Aufräumen, sondern Logikarbeit — jede will einzeln angesehen werden, ob `null` dort auftreten kann. ### 1.3 🟡 Startup-Backfill entschärfen `PredictalyticsHost.cs:116` lädt bei **jedem Start** alle Märkte samt Event in den Speicher, um Kategorien neu abzuleiten. Bei wachsendem Bestand belastet das die Startzeit spürbar. Entweder auf Märkte mit `Category = Other` einschränken, oder einmalig laufen lassen und über ein Flag abschalten. --- ## Stufe 2 — Portierung abschließen Der Code ist plattformneutral gebaut, aber **auf keinem Linux-System je ausgeführt worden**. Bis das nachgeholt ist, ist „läuft unter Linux" eine Annahme. > Details zu allen Punkten: [`docs/archiv/PLAN-Linux-Portierung.md`](docs/archiv/PLAN-Linux-Portierung.md), > Abschnitte 7 und 8. ### 2.1 🟢 Erstlauf und Verifikation unter Linux Die Reihenfolge ist bewusst so: erst beweisen, dass es läuft, dann Deployment bauen. - [ ] Shell auf einem Linux-Desktop starten — alle Schaltflächen, Menüs, Persistenz der Einstellungen - [ ] Derselbe Build mit `--headless` auf einem Server ohne X11: Start, Lizenz aus der Konfiguration, sauberer Stopp per SIGTERM - [ ] Worker-Dauerlauf ≥ 24 h gegen die **Dev-DB**, Logvergleich mit einem Windows-Lauf - [ ] Lauf unter `LANG=de_DE.UTF-8` — Volumina, Preise, PnL gegen die Windows-Referenz prüfen (Kultur-Fallen) - [ ] Web-UI vollständig durchklicken — case-sensitive Assets sind unter Linux ein echtes Risiko - [ ] Lizenz: Erstaktivierung, Neustart aus dem Cache, Offline-Gnadenfrist, Revalidierung - [ ] Watchdog-Heartbeats erscheinen am Deployment Center - [ ] EF-Migrationen von Null gegen die Dev-DB - [ ] Egress-Kanäle, falls genutzt (`SourceIp` verhält sich unter Linux anders) ### 2.2 🟢 Deployment und CI - [ ] `dotnet publish -r linux-x64` und `-r win-x64`; bei self-contained das Trimming-Verhalten von Avalonia beachten - [ ] Linux-Systemabhängigkeiten dokumentieren: `libx11-6`, `libice6`, `libsm6`, `libfontconfig1`, `libharfbuzz0b`, Monospace-Schriften - [ ] systemd-Unit bzw. Dockerfile für den Headless-Betrieb — es existiert bereits `J:\Softwareprojekte\dockerCompose`, vermutlich anknüpfbar - [ ] Reverse Proxy (nginx/Caddy) mit TLS vor Kestrel - [ ] Secrets unter Linux: EnvironmentFile mit `0600` statt Klartext in `settings.json` - [ ] CI: Build + Test auf Linux **und** Windows - [ ] `docs/BETRIEB-Deploymentcenter.md` um den Linux-Betrieb ergänzen --- ## Stufe 3 — Analytik schärfen ### 3.1 🟢 Strategie-Klassifikation reparieren (ehemals A4) Der größte fachliche Rückstand. `StrategyType` entsteht aus genau zwei Signalen — `avgSize > 10000` ergibt `Whale`, `hedgingRate > 30` ergibt `Hedger`, sonst `Bot` oder `Unknown`. Deshalb landet der **Großteil der Trader strukturell auf `Unknown`**, was den Wert der Einstufung gegen null gehen lässt. Erschwerend: die Logik steht **doppelt** da und die beiden Schreiber überschreiben einander — `AnalyticsService.cs:418` und `ScoringService.cs:89`. - [ ] Zuerst die Doppelung auflösen: **ein** Ort, der `StrategyType` bestimmt - [ ] Vorhandene, bereits berechnete Signale einspeisen statt neue zu erheben: `StrategyMetricsCalculator` (Kategorie-Konzentration, Conviction-Edge), `TraderTraitCalculator` (Traits), `FingerprintSnapshotService` (Kategorie-Mix über Zeit) - [ ] Ergänzend, falls nötig: Verteilung der Haltedauern, Anteil später vs. früher Einstiege im Marktleben, Varianz der Ordergrößen - [ ] Prüfen, ob ein Einzel-Enum reicht oder ob Mehrfachsignale danebengehören (Enum als Primär-Tag, Zusatzsignale als eigene Felder) - [ ] Abnahme: der Anteil `Unknown` ist deutlich gesunken > Herkunft: [`docs/archiv/UMSETZUNGSPLAN.md`](docs/archiv/UMSETZUNGSPLAN.md) A4. ### 3.2 🟡 `CopytradingBacktestHarness` anschließen oder verwerfen 123 Zeilen fertig implementierter Latenz-Sweep (0/10/30/60 s) samt `BacktestResult`, per DI registriert — und **von niemandem aufgerufen**. Der Sweep würde beziffern, wie viel Alpha ein Nachahmer bei welcher Verzögerung verliert; das passt genau zum Zweck des Projekts. Entscheidung nötig: an einen Endpunkt und die Trader-Detailseite hängen, oder ersatzlos löschen. Der jetzige Zustand — gepflegt, aber wirkungslos — ist die schlechteste Variante. ### 3.3 🟡 Track-Record-Länge in den Copyability-Score Der Score besteht heute aus Alpha-Verfall (70 %) und Sizing-Konsistenz (30 %). Die ursprünglich geplante vierte Komponente — Länge und Konsistenz des Track Records — fehlt. Ein Trader mit drei glücklichen Märkten bekommt denselben Score wie einer mit dreihundert. > Herkunft: [`archiv/UMSETZUNGSPLAN.md`](docs/archiv/UMSETZUNGSPLAN.md) A5, letzter Unterpunkt. ### 3.4 🟡 Edge-Freshness und Strategie-Drift ins Ranking Beide Kennzahlen existieren, erscheinen aber nur auf der Detailseite und in Alarmen. In der Rangliste — dort, wo ausgewählt wird — spielen sie keine Rolle. Ein Master mit abgestandener Edge steht weiterhin oben. ### 3.5 🟡 Co-Movement-Graph vorberechnen `GET /api/co-movement/graph` rechnet bei jedem Aufruf. Für die Netzwerkansicht ist das träge und belastet die DB unnötig. In den `ScoringAndAlertsWorker` verlagern und das Ergebnis ablegen. ### 3.6 🟡 Restpunkte aus der Kategorie-Erkennung - [ ] Gezielt fehlende Event-Tags nachladen für Märkte, die getrackte Trader gehandelt haben ([`archiv/FIXPLAN-TODO.md`](docs/archiv/FIXPLAN-TODO.md) F5) — der tägliche Sync geschlossener Märkte deckt den Fall inzwischen weitgehend ab, die Lücke ist klein - [ ] Zwei fehlende Tests (F6): Event-Tag-Vererbung und Offline-Backfill ### 3.7 🟡 Sortierpfeile in der Trader-Tabelle Die Tabellenköpfe zeigen statisch `↕`, auch in der aktiven Sortierspalte. Reine Politik, war schon im UI-Plan als „Optional" markiert. --- ## Stufe 4 — Datenhaushalt Alles hier läuft über SQL, das **der Nutzer selbst** gegen die Datenbank fährt. Wir liefern die Anweisungen, führen sie aber nicht aus. > Details: [`docs/archiv/FIXPLAN-G-Speicher.md`](docs/archiv/FIXPLAN-G-Speicher.md) (Anhang) > und [`docs/archiv/UMSETZUNGSPLAN.md`](docs/archiv/UMSETZUNGSPLAN.md) C3. ### 4.1 👤 🟡 Einmalige DB-Optimierungen - [ ] Spaltentypen verkleinern: `TransactionHash`, `MarketId`, `AssetId` sind Hex-/Dezimalstrings in überbreiten Feldern - [ ] InnoDB-Kompression (`ROW_FORMAT=COMPRESSED`) für `Trades` — schneller Zugewinn, geringes Risiko - [ ] Partitionierung von `Trades` nach Monat (`ExecutedAt`) prüfen — erlaubt späteres Verwerfen ganzer Partitionen ### 4.2 👤 💡 Materialitätsschwelle für Mikro-Trades Trades unterhalb eines Betrags (Vorschlag: $0,50) unabhängig vom Retention-Fenster verwerfen. Durchdacht, aber nicht beschlossen — die Schwelle verändert die PnL-Rechnung leicht, und der Gewinn ist ungewiss, bis 4.1 gemessen ist. ### 4.3 👤 💡 Frischer Datenbank-Neustart Die alte Überlegung, die Produktivdatenbank leer neu aufzusetzen und über die Worker neu zu befüllen (Rohdaten sind über `/activity` jederzeit nachladbar). **Nicht beschlossen.** Falls er kommt, gehört er ans Ende von Stufe 3, nicht davor — sonst laufen Analytik-Änderungen und Datenumzug gleichzeitig. Vorgelagerter Bestätigungs-Check: stichprobenartig prüfen, wie weit `/activity` für ein lange aktives Wallet tatsächlich zurückreicht. ### 4.4 💡 65 Migrationsdateien zusammenfassen 32 Migrationen ergeben 65 Dateien und rund 37.000 Zeilen. Eine neue Baseline wäre übersichtlicher, kostet aber die Schemahistorie und ist gegen eine laufende Produktivdatenbank heikel. Nur sinnvoll im Zuge von 4.3. --- ## Stufe 5 — Ingest skalieren Erst angehen, wenn Rate-Limits tatsächlich drücken. Die wirksamsten Maßnahmen sind bereits umgesetzt (Ingest-Tiering, Egress-Kanäle, Kurzzeit-Cache). > Details: [`docs/archiv/PLAN-DatenIngest-Skalierung.md`](docs/archiv/PLAN-DatenIngest-Skalierung.md). ### 5.1 💡 Historische Massendaten aus der Blockchain statt über REST Der größte ungenutzte Hebel. Polymarket-Trades sind On-Chain-Events auf Polygon; für Backfill und Deep-Resync — die teuersten REST-Verbraucher — ist `/activity` die falsche Quelle. Ein GraphQL-Aufruf gegen einen Subgraph (The Graph / Goldsky) liefert tausende Fills eines Wallets auf einmal. Skizze: `IHistoricalTradeSource` neben den REST-Provider stellen, Deep-Resync zieht darüber. **Nicht eingeplant**, weil erst zu evaluieren ist, ob ein brauchbarer Subgraph existiert und wie vollständig er ist. ### 5.2 🟡 Markt-Stammdaten aggressiv cachen Metadaten (Frage, Kategorie, Outcomes, `ConditionId`↔`TokenId`) ändern sich nie — einmal ziehen, lang halten; nur Volumen, Liquidität und Auflösung periodisch aktualisieren. Teilweise erledigt: geschlossene Märkte werden nur noch einmal täglich synchronisiert. ### 5.3 🟡 Egress-Kanäle: Betriebsreste Die Mechanik steht (Round-Robin, Cooldown nach drei Fehlschlägen, Limiter je Kanal). Was im Ingest-Plan noch danebensteht: - [ ] Health-Statistik je Kanal — Erfolgsquote, 429-Rate, Latenz. Heute gibt es nur einen Fehlerzähler: tote Kanäle werden pausiert, aber nicht ausgewertet - [ ] Bei eigenen IPs prüfen, ob es echte getrennte Egress-IPs sind (multi-homed) und nicht NAT hinter derselben öffentlichen Adresse — sonst bringt die Aufteilung nichts - [ ] Regressionsschutz: die MySQL-Verbindung darf **nie** über den Egress-Pool oder einen Proxy laufen - [ ] Grob unplausible Provider-Antworten abfangen (z. B. Preis außerhalb 0–1) ### 5.4 ❌ Header- und User-Agent-Rotation Im Ingest-Plan bewusst als „standardmäßig AUS" eingeordnet. Rotation zur Verschleierung gegenüber Polymarket ist gegen deren Interesse gerichtet und riskiert die Sperrung genau des Zugangs, auf dem das Projekt aufsetzt. Der ehrliche Weg ist, die Nachfrage zu senken (5.1, 5.2) und legitime Kanäle zu erhöhen (bereits umgesetzt). --- ## Stufe 6 — Monetarisierung vorbereiten Nur relevant, falls aus dem internen Werkzeug ein Produkt werden soll. **Bislang eine Idee, keine Entscheidung.** Die Vorarbeit (Read/Control-Trennung, `/api/capabilities`, CORS-Whitelist) ist im Zuge der Portierung ohnehin schon passiert. > Details: [`docs/archiv/PLAN-Architektur-WebUI-Backend.md`](docs/archiv/PLAN-Architektur-WebUI-Backend.md). ### 6.1 💡 Datenbank für eine öffentliche Schicht vorbereiten - **Read-Endpunkte auf versteckte Writes und Provider-Aufrufe prüfen.** Der Read/Control-Split steht, aber ob jeder einzelne Read-Endpunkt frei von Schreibzugriffen ist, wurde nie systematisch geprüft — besonders der Deep-Dive-Pfad. Vor einem öffentlichen Host nachzuholen, sonst wird die read-only Verbindung im Betrieb Fehler werfen - Read-only DB-Benutzer auf der Analyse-DB (nur `SELECT`) — 👤 der Nutzer führt die Grants aus - Schema-Kopplung dokumentieren: liest eine öffentliche Schicht direkt mit, wird das DB-Schema zur **Vertragsfläche**. Views als Puffer erwägen, damit interne Umbauten die öffentliche Sicht nicht brechen. Billig und jederzeit vorziehbar, auch wenn 6.2 nie kommt. ### 6.2 💡 Öffentlicher Host Eigenes Projekt `Predictalytics.PublicApi`: registriert nur die Read-Endpunkte, dazu Konten/Authentifizierung in einer **getrennten** User-DB, Rate-Limits und Kontingente pro Konto, Mandantensicht (Kunde sieht seine Watchlist, nicht das ganze Universum), liefert dasselbe SPA aus. **Nicht-Ziele, die dabei gelten** — ❌ kein Zugriff der öffentlichen Schicht auf Core-Prozess, lokale API oder Steuerendpunkte; ❌ kein Schreibzugriff auf die Analyse-DB; ❌ keine Kunden-Authentifizierung nachträglich in die lokale Vollschicht bauen; ❌ Read-Endpunkte machen keine Provider-Aufrufe und keine Writes. --- ## Anhang — bewusst nicht auf der Roadmap Geprüft und mit Absicht ausgelassen. Nicht versehentlich wieder aufnehmen: | Was | Warum | |---|---| | `AzuroProvider` löschen | Platzhalter mit `IsImplemented => false`, wird sauber übersprungen. Kostet nichts, markiert den Ausbaupfad. | | `Providers/Limitless/` löschen | Voll implementierter zweiter Marktplatz, `IsImplemented => true`. Wird nur nicht bespielt — Löschen wäre Funktionsverlust. | | `wwwroot/landing.html`, `docs.html` | Marketing-Seiten mit Preis-Abschnitt, vom Dashboard nicht verlinkt. Gehören zu Stufe 6. | | Kaltarchiv außerhalb der DB | Verworfen: Rohdaten sind über die Polymarket-API jederzeit nachladbar, ein Archiv wäre reine Zusatzlast. | | EF Core auf 10 heben | Blockiert: Pomelo hat keinen EF-10-Provider und pinnt Relational hart auf `[9.0.0, 9.0.999]`. Vor einem Versuch prüfen, ob Pomelo nachgezogen hat. |