From 73ad37c5ac1479bc7825ea4562ff77d6a714c1c7 Mon Sep 17 00:00:00 2001 From: Richard Date: Tue, 4 Aug 2026 09:04:24 +0200 Subject: [PATCH] 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 --- docs/IDEENSAMMLUNG-Feldtest-2026-08.md | 305 +++++++++++++++++++++++++ 1 file changed, 305 insertions(+) create mode 100644 docs/IDEENSAMMLUNG-Feldtest-2026-08.md diff --git a/docs/IDEENSAMMLUNG-Feldtest-2026-08.md b/docs/IDEENSAMMLUNG-Feldtest-2026-08.md new file mode 100644 index 0000000..fefc373 --- /dev/null +++ b/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(); +services.AddSingleton(); +services.AddSingleton(); +``` + +`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` — **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.