# 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.
