PolyTraderSharp/docs/IDEENSAMMLUNG-Feldtest-2026-08.md

Ideensammlung Feldtest (ab 2026-08-03)

Zweck: Laufende Sammlung von Richards Beobachtungen beim praktischen Einsatz von PolyTrader. Hier wird NICHT umgesetzt — die Umsetzung erfolgt in späteren Chats, ggf. über mehrere Sitzungen, dann jeweils als eigener Umsetzungsplan/Slice.

Aufbau je Punkt: Beobachtung (was Richard sieht) → Befund (was der Code hergibt, geprüft) → Ansatz (Richtung der Lösung). Die IDs (L-1, ACC-2 …) sind stabil und dienen als Referenz in den späteren Umsetzungs-Chats.

Die alte Liste Ideen-fuer-Mittwoch.txt ist abgearbeitet (UI-Slice 5 + Watchdog-Plan

• ClawdDotNet-Übernahme) und wird von diesem Dokument abgelöst.

---

Status-Legende

Kürzel	Bedeutung
🟥	Fehler / funktioniert nicht wie erwartet
🟧	funktioniert, aber unbrauchbar/unfertig
🟦	reine Verbesserung / Komfort
❓	offene Frage an Richard, vor Umsetzung klären

---

A. Launcher & Launcher-Dashboard

L-1 🟦 Menüleiste im Launcher entfernen, Toolstrip behalten

Beobachtung: Der Launcher zeigt sowohl MenuStrip als auch ToolStrip. Im Launcher wird der MenuStrip nicht gebraucht — die Icon-Leiste (ToolStrip) reicht. Befund: Die Fenster-Menüleiste wird zentral von der Shell in alle Fenster injiziert (Commit 25f0d34 „Fenster-Menue auf ALLEN Fenstern (zentrale Shell-Injektion)", Ui/ShellUiHost.cs). Der Launcher muss also von der Injektion ausgenommen werden — das ist eine Ausnahme in der Shell, kein Löschen im Designer. Ansatz: Opt-out-Flag am Shell-Host (z. B. RegisterShellMenu(form, includeMenu:false)) oder Sonderfall „Host-Fenster" in ShellUiHost. ToolStrip bleibt unangetastet.

L-2 🟧 Launcher-Dashboard ist rudimentär und starr

Beobachtung: Die Felder/Kacheln lassen sich weder verschieben noch in der Größe ändern. Das Launcher-Dashboard soll eine schnelle Gesamtübersicht bieten — klar abzugrenzen vom „richtigen" Dashboard (eigenes Fenster mit Tradehistorie, Charts, KPIs). Befund: Ui/LauncherWidgetsPanel.cs + Ui/LauncherForm.Designer.cs; die Widgets sind fest platziert (Commit 3c8ea35 „Launcher-Live-Widgets"). Ansatz: Kachel-/Widget-Layout mit veränderbarer Größe und Anordnung, Layout je Nutzer persistiert (z. B. in server_settings.xml oder eigener core_ui_layout-Tabelle). Optionen: SplitContainer-Raster (einfach, designerfähig, Größen persistierbar) vs. echtes Dock-/Widget-Panel (mächtiger, aber mehr Aufwand — und die UI-Designer-Regel verlangt weiterhin partial + .Designer.cs).

L-3 🟦 Dashboard-Kacheln als Sprungmarken (Drill-down)

Beobachtung: Ein Klick auf eine Kachel soll direkt in die zugehörige Tiefenansicht springen:

• Warnungen → Terminal
• KI-Bericht / Supervisor → Supervisor-Fenster
• Analyse → Analyse-/Dashboard-Fenster
• (analog für alle weiteren Kacheln)

Ansatz: Jede Kachel bekommt eine TargetViewId (die Shell kennt bereits ModuleView.Id wie accounting.main, resolutionfarming.main) und öffnet/fokussiert das Fenster über den IModuleUiHost. Der Mechanismus existiert schon — es fehlt nur die Verdrahtung an den Kacheln.

L-4 🟦 Design des Launchers grundlegend überarbeiten

Beobachtung: Optik insgesamt überarbeitungsbedürftig. Ansatz: Vor der Umsetzung Zielbild festlegen (Farbschema, Kachel-Raster, Typografie, Icon-Sprache). Sinnvoll als eigener Slice nach L-2, damit nicht zweimal gebaut wird. → siehe ❓F-1.

---

B. Accounting-Modul

ACC-1 🟥 Alles zeigt 0 — auch mit Zeitraum ab 01.12.2025 und allen Live-Konten

Beobachtung: Zeitraum bis 01.12.25 zurückgesetzt, alle Live-Kunden ausgewählt → überall Null. Es müssen aber Daten da sein: beide hinterlegten Live-Accounts haben 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 sind alle drei Ingest-Quellen als Null-Stubs registriert:

services.AddSingleton<IActivitySource, NullActivitySource>();
services.AddSingleton<ITransferSource, NullTransferSource>();
services.AddSingleton<IBalanceAnchorSource, NullBalanceAnchorSource>();

NullActivitySource.GetActivityAsync gibt konstant ein leeres Array zurück (Services/IngestSources.cs:36-51). 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 (Polymarket Data-API /activity, Alchemy ERC-20-Transfer-Logs, USDC-Balance). Lesen ist keine Handelstätigkeit und geht von hier aus. Ansatz: Slice „Accounting Live-Quellen (read-only)":

1. PolymarketActivitySource gegen die Data-API (/activity, alle Typen, paginiert, Rohschnappschuss speichern).
2. AlchemyTransferSource über die vorhandene Alchemy-Anbindung (ERC-20-USDC-Logs).
3. BalanceAnchorSource über das bestehende GetUsdcBalanceAsync.
4. AccountingSystemContracts befüllen (CTF liegt im Core; Exchange/NegRisk-Adapter/ USDC ergänzen und gegen docs.polymarket.com verifizieren, nicht aus dem Kopf).
5. Backfill-Lauf über die volle Historie ab Account-Eröffnung.

ACC-2 🟧 UI verschweigt, dass keine Datenquelle angebunden ist

Beobachtung: Man sieht nur Nullen und hält es für einen Rechenfehler. Ansatz: Statusanzeige im Accounting-Fenster: je Quelle „angebunden / Stub", Zeitpunkt + Ergebnis des letzten Ingest-Laufs (acc_ingest_runs existiert bereits), und bei Stub ein deutlicher Hinweisbalken statt stiller Nullen. Gilt sinngemäß auch für RF (siehe RF-1) — am besten als einheitliches Muster für alle Module mit Null-Quellen.

---

C. Settings

SET-1 ❓/🟦 Fehlen Settings im Settings-Fenster?

Beobachtung: Gefühl, dass einige Einstellungen im Settings-Menü gar nicht auftauchen. Auftrag: JSON prüfen. Befund (geprüft):

• appsettings.json enthält nur Database:MySqlConnectionString (Wert in der gitignorierten appsettings.Local.json) und die Logging:LogLevel-Sektion. Beides ist in der UI nicht editierbar.
• Die alten Mongo-Exporte MongoDB/PolyTraderDB.accounts.json habe ich Feld für Feld gegen die heutigen Modelle geprüft: alle 25 Felder sind abgedeckt — allgemeine Daten in AccountState (Core-Settings-Fenster), Handels-Limits in CopyTradingAccountSettings (CopyTrading-Modul-Fenster). Aus dieser JSON fehlt nichts.
• Nicht im Settings-Fenster erreichbar sind dagegen die Modul-Settings: RfSettings (ResolutionFarming, 15 Felder — liegt im RF-Fenster, Tab „Settings"), Supervisor-Einstellungen, sowie DB-Connection und Log-Level.

Ansatz / zu entscheiden: Wollen wir ein zentrales Settings-Fenster mit Baum (Core / CopyTrading / RF / Accounting / Supervisor), oder bleibt es bei „Modul-Settings im Modul-Fenster"? Zusätzlich unabhängig davon sinnvoll: DB-Verbindung und Log-Level in der UI pflegbar machen (mit Verbindungstest). → siehe ❓F-2.

---

D. Backup

BAK-1 ❓ Backup-Funktion im UI würdigen (Tab + Serverjob)

Beobachtung: „Unsere tolle neue Backup-Funktion" hat weder einen eigenen Tab noch eigene Serverjobs. Befund (geprüft): Im gesamten Repository findet sich keine Backup-Implementierung — Backup kommt nur in Kommentaren/Regeln vor (.agents/rules/clob.md: „vor Änderungen Backup anlegen"), in .gitignore, in Konzeptdokumenten und in agentspace/analytics/export_db.py. Auch die Git-Historie enthält keinen Backup-Commit. Offene Frage: Meinst du (a) ein Backup, das du außerhalb von PolyTrader eingerichtet hast (z. B. MySQL-Dump per Aufgabenplanung), (b) etwas im Watchdog-/ LicenseLabrador-Projekt, oder (c) soll die Funktion überhaupt erst gebaut werden? Je nach Antwort ist das „UI anbinden" oder „von Grund auf bauen". → ❓F-3

Ansatz (falls neu zu bauen): Core-Service BackupService (mysqldump + Config-Dateien

• master.key-Hinweis), registriert im JobManager (→ JOB-2), eigener Settings-Bereich (Zielpfad, Aufbewahrung/Rotation, Zeitplan), UI-Tab mit Backup-Liste, „Jetzt sichern" und Restore-Hinweis. Achtung: Ein Backup, das Wallet-Keys enthält, ist selbst ein Secret — Verschlüsselung und Ablageort gehören ins Sicherheitskonzept.

---

E. Serverjobs

JOB-1 🟦 Split-View mit Historie/Fehlern je Job

Beobachtung: Das Serverjob-Fenster besteht nur aus einem DataGrid mit den Jobs. Gewünscht: Splitter, unten ein zweites Grid oder eine RichTextBox mit Historie des oben ausgewählten Jobs — z. B. beim „Threema Webhook Listener": wann lief er zuletzt, 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) 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, Fehlerdetails) — Ringpuffer im Speicher (letzte N je Job) plus optional Persistenz in core_job_runs für längere Historie. Jobs melden ihr Ergebnis am Ende jedes Laufs. UI: SplitContainer, oben Jobs, unten Historie + Detail-Text (analog TERM-1).

JOB-2 🟧 Job-Liste ist unvollständig (und teils fragwürdig)

Beobachtung: Einige Jobs erscheinen sinnlos, andere fehlen. Befund (geprüft): Nur 5 Jobs registrieren sich beim JobManager:

registriert	Herkunft
Market Data Sync	Core
Threema Webhook Listener	Core
Trader Analytics	CopyTrading
MasterTrader History	CopyTrading
MySQL Transaction Log	CopyTrading

Tatsächlich laufen aber ~20 Hintergrunddienste. Nicht in der Job-Liste sichtbar sind u. a.:

• Core: MullvadVpnService, WatchdogHeartbeatService, StartupHydrationService
• CopyTrading: TraderMonitorService, CopyTradingEngine, SellLadderService, AlchemyWebsocketService, PolymarketWssClient, StartupOrderReconciliationService
• ResolutionFarming: MarketScannerService, FarmingExecutionService, FarmingResolutionMonitorService
• Accounting: AccountingIngestService (im Konzept ausdrücklich als „JobManager-registriert, manuell triggerbar" vorgesehen — ist es aber nicht)
• Supervisor: DailyReportService, CounterfactualJob, McpLightServer

Ansatz: Einheitliche Regel „jeder BackgroundService registriert sich mit Name, Intervall, Aktiv-Schalter und Manual-Trigger", Gruppierung nach Modul im Grid, Unterscheidung Job (zyklisch, triggerbar) vs. Dauerdienst (WSS-Listener — hier ist „Nächster Lauf" sinnlos, dafür „Verbunden seit"/„Reconnects" interessant). Beim Durchgehen mit dir klären, welche der 5 bestehenden Einträge du für überflüssig hältst.

---

F. CopyTrading

CT-1 🟦 Status „Markt beendet" bei offenen Trades

Beobachtung: Im Tab „Offene Trades" fehlt eine Anzeige, ob der Markt bereits beendet/aufgelöst ist. Ansatz: Statusspalte mit klarer Semantik: offen / Markt geschlossen (noch nicht aufgelöst) / aufgelöst — gewonnen / aufgelöst — verloren / eingelöst. Datenquelle: Resolution-Erkennung im TraderMonitorService. Farbcodierung analog zum bestehenden Zeilen-Coloring aus Slice 3.

CT-2 🟦 Filter im Tab „Offene Trades"

Beobachtung: Filter wie im Tab „Geschlossene Trades" — z. B. „nur Positionen im Gewinn", „Markt gewonnen, aber Position noch nicht geschlossen". Ansatz: Filterleiste wiederverwenden (Slice 3 hat die Filter für geschlossene Trades bereits gebaut), Prädikate für PnL-Vorzeichen und Marktstatus (baut auf CT-1 auf).

CT-3 🟥/🟦 Button „Alle beendeten Märkte schließen" (Gewinne einlösen)

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/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 in Dokumenten. Im TraderMonitorService steht laut Plan noch der auskommentierte Python-Redeem-Block. Ansatz: Phase RD-1 lässt sich vollständig ohne Live-API bauen (Queue-Tabelle, Interface, Modul-Schalter, „bereit zum Redeem"-Liste im UI) — das gibt dir sofort die Übersicht und den Button als „manuell markieren". RD-2 (read-only On-Chain-Checks) ist ebenfalls von hier machbar. Erst RD-3/RD-4 (echte Tx mit Private Key) sind Zielland-Arbeit und unterliegen .agents/rules/clob.md in verschärfter Form.

---

G. ResolutionFarming

RF-1 🟥 Kandidaten-Auslesen jetzt schon möglich machen

Beobachtung: Handeln geht mangels Zielland nicht — aber Kandidaten auslesen 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 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). Die eigentliche Bewertungskette (Filter, FarmingRiskEngine, FarmingFillModel) ist fertig und unit-getestet — ihr fehlt nur der Input. Ansatz: GammaFarmingMarketSource gegen die öffentliche Gamma-API + CLOB-Orderbuch (beides read-only, kein Handel, kein Signing). Danach liefert der Scanner echte Kandidaten in rf_candidates, und der Kandidaten-Tab wird zum echten Prüfinstrument für die Filter-Parameter (RfSettings: Preisband, Kategorie-Whitelist, Min-Edge …) — bevor im Zielland Geld fließt. Analog MarketResolutionSource gegen die Data-API, damit auch der Auflösungs-Monitor real testbar wird.

---

H. Terminal / Log Viewer

TERM-1 🟦 Log-Grid an Bildschirmgröße anpassen + Detail-Ansicht

Beobachtung: Im Log Viewer sind die Einträge schlecht lesbar, besonders die Message-Spalte. Gewünscht: Grid füllt die Bildschirmbreite, und darunter (kleiner, per Splitter) eine RichTextBox, die den ausgewählten Eintrag vollständig ausschreibt — damit auch lange Fehler-/Stacktrace-Einträge problemlos lesbar sind. Ansatz: SplitContainer (oben Grid, unten RichTextBox), Message-Spalte auf Fill mit sinnvollen Mindestbreiten der übrigen Spalten, Spaltenbreiten persistieren. Detailbereich zeigt den kompletten JSONL-Datensatz menschenlesbar formatiert (Zeitstempel, Level, CID, Message, Exception, Kontextfelder) — das JSONL-Format aus Supervisor S-0c liefert die Felder bereits. Kopieren-Funktion aus dem bestehenden Terminal-Kontextmenü wiederverwenden. Gleiches Muster wie JOB-1 — sollte einmal gebaut und zweimal verwendet werden.

---

I. Offene Fragen an Richard

ID	Frage
❓F-1	Launcher-Design (L-4): Gibt es ein Zielbild/Vorbild (Screenshot, Farbschema)? Und beim Dashboard-Layout (L-2): reicht ein verschiebbarer Splitter-Raster, oder willst du frei platzierbare Kacheln per Drag & Drop?
❓F-2	Settings (SET-1): Zentrales Settings-Fenster mit Modulbaum, oder Modul-Settings weiterhin im jeweiligen Modul-Fenster?
❓F-3	Backup (BAK-1): Was genau meinst du mit „unserer neuen Backup-Funktion"? Im Repository existiert keine — ist sie außerhalb von PolyTrader eingerichtet, steckt sie in einem der Fremdprojekte, oder soll sie neu gebaut werden?
❓F-4	Serverjobs (JOB-2): Welche der 5 aktuell gelisteten Jobs empfindest du als sinnlos?

---

J. Querschnitts-Erkenntnis

Drei der gemeldeten „Bugs" (ACC-1, RF-1, teilweise CT-3) haben dieselbe Ursache: Module wurden mit Null-Stubs statt echter Datenquellen fertiggestellt und mit der Begründung „Zielland" zurückgestellt. Dabei ist nur das Schreiben (Orders, Signing, On-Chain-Tx) zielland-gebunden — Lesen (Data-API, Gamma-API, Alchemy-Logs, Balance-Abfragen) ist es nicht.

Vorschlag für die Umsetzungsreihenfolge: ein gemeinsamer Slice „Read-only-Quellen scharfschalten" (ACC-1 + RF-1 + RD-2) bringt am meisten — er macht Accounting und ResolutionFarming jetzt prüfbar, statt erst im Zielland. Danach die UI-Themen (L-1…L-4, JOB-1, TERM-1), die teilweise dasselbe Split-View-Muster brauchen.