# 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/archiv/umsetzungsplaene/UMSETZUNGSPLAN-AutoRedeem.md`](./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`](../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.