Ideensammlung Feldtest 2026-08 angelegt (Beobachtungen aus dem Praxiseinsatz)

Laufende Sammlung von Richards Beobachtungen beim Einsatz von PolyTrader, je Punkt
Beobachtung -> Befund (im Code geprueft) -> Ansatz, mit stabilen IDs (L-1, ACC-1 ...)
als Referenz fuer spaetere Umsetzungs-Chats. Hier wird bewusst NICHT umgesetzt.

Querschnitts-Erkenntnis: ACC-1, RF-1 und teilweise CT-3 haben dieselbe Ursache -
Module wurden mit Null-Stubs statt echter Datenquellen fertiggestellt und mit
"Zielland" zurueckgestellt. Zielland-gebunden ist aber nur das Schreiben (Orders,
Signing, On-Chain-Tx); Lesen (Data-/Gamma-API, Alchemy-Logs, Balance) ist es nicht.
Loest die abgearbeitete Liste Ideen-fuer-Mittwoch.txt ab.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/IDEENSAMMLUNG-Feldtest-2026-08.md

@@ -0,0 +1,305 @@
+# 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`](src/PolyTrader.Modules.Accounting/AccountingModule.cs)
+sind alle drei Ingest-Quellen als Null-Stubs registriert:
+
+```csharp
+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`](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**
+(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`](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,
+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/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md`](docs/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`](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).
+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.