Eine Roadmap statt fuenfzehn Plandokumente; Altbestand ins Archiv

Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei
Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils
wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle.

docs/ROADMAP.md (neu):
- Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf.
  Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die
  Voraussetzung fuer die naechste.
- Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst
  zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen
  wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern.
- Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen,
  Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten.
- Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag:
  CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und
  BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken
  aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen
  bauen statt doppelt.

Archiv (docs/archiv/):
- 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung).
  Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und
  Begruendungen - eingefroren ist nur ihr Status.
- archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu.

Verweise nachgezogen - der eigentliche Aufwand:
- 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene
  tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte
  Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/.
- 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene
  (csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen.
- Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/,
  Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen.
- Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen.

PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap.
Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT.

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

docs/archiv/konzepte/KONZEPT-Modul-Accounting.md

@@ -0,0 +1,272 @@
+# Konzept: Modul „Accounting" (Steuer-/Buchhaltungs-Reporting aller Live-Accounts)
+
+> Stand: 2026-07-14
+> Ziel: Vollständige, **unabhängig von unserer Trading-DB** erhobene, buchhalterisch korrekte
+> Erfassung ALLER Transaktionen aller Live-Polymarket-Accounts. Periodische (meist monatliche),
+> vor einer Steuerbehörde nachvollziehbare Abrechnungen — je einzelnem Account ODER über alle
+> Accounts, für frei wählbare Zeiträume. BWA-artige Kennzahlen-Übersicht in der UI. Export als
+> CSV und PDF.
+> Reihenfolge: unabhängig, jederzeit baubar (kein Live-Trading nötig — rein lesende API-Abrufe).
+> **Kein Handel; reines Ingest-/Reporting-Modul.**
+>
+> **Entscheidungen Richard (2026-07-14):**
+> - Währung: **USDC nativ + USD + EUR** (jede Transaktion in allen drei ausgewiesen).
+> - Abrechnung: neutrale prüfbare Aufstellung **UND** konkrete **US-Steuerberechnung** — Zielland
+>   **USA, Florida LLC** (Florida ohne State Income Tax → nur Federal). Als dokumentierte, vom CPA
+>   prüfbare Rechenschicht, **nicht als Steuerberatung** (Disclaimer, §4a).
+> - Umfang v1: **inkl. On-Chain-Ein-/Auszahlungen** von Anfang an (vollständige Kapitalsicht).
+
+---
+
+## 0. Leitprinzipien
+
+1. **Unabhängige Quelle = Polymarket, NICHT unsere DB.** Das Modul erhebt die Buchungsgrundlage
+   ausschließlich über eigene, regelmäßige Abrufe direkt bei Polymarket und speichert sie roh +
+   normalisiert in eigenen Tabellen. Unsere eigenen Trade-Logs (Copytrading/ResolutionFarming/Core)
+   werden **nur** für den optionalen Abgleich (§7) herangezogen, **nie** als Buchungsgrundlage.
+2. **Nachvollziehbarkeit / Audit.** Jeder Buchungssatz führt auf einen konkreten, prüfbaren Nachweis
+   zurück (Transaktions-Hash, Activity-/Trade-ID, Abruf-Zeitpunkt, Rohdaten-Snapshot). Der Roh-Ingest
+   ist **unveränderlich (append-only)**; Abrechnungen sind daraus **reproduzierbar** ableitbar.
+3. **Zwei Ebenen: neutraler Ledger + prüfbare US-Steuerschicht.** Unten liegt eine vollständige,
+   länderneutrale Transaktions-/Ledger-Aufstellung + Kennzahlen (belastbare Basis). Darauf setzt eine
+   **konfigurierbare, dokumentierte US-Steuer-Rechenschicht** (Florida LLC, §4a) — mit klaren, im
+   Export ausgewiesenen Annahmen, **die der US-CPA prüft/bestätigt**. Das Tool rechnet; es berät nicht
+   (Disclaimer, §4a). Der neutrale Ledger bleibt auch bei anderer steuerlicher Einordnung gültig.
+4. **Lesend / idempotent.** Keine Orders, keine On-Chain-Writes. Überlappende Wiederholungs-Abrufe
+   dürfen **nichts doppelt buchen** (stabile Idempotenz-Schlüssel, Upsert statt Insert).
+
+---
+
+## 1. Architektur-Einbettung
+
+Neues Projekt `src/PolyTrader.Modules.Accounting/` als `IPolyTraderModule`
+(`Name = "Accounting"`, `DbPrefix = "acc_"`), Registrierung in `Program.cs`. Referenziert nur den
+Core. Eigener `AccountingDbContext` (acc_-Tabellen), eigene UI (ein Fenster mit Tabs), eigene
+Settings-Sektion.
+
+- Nutzt den bestehenden `PolymarketApiService` (Data-API `/activity`, `/positions`,
+  `GetUsdcBalanceAsync(wallet)`) und für On-Chain-Ein-/Auszahlungen die vorhandene Alchemy-Anbindung.
+- Betrifft ALLE Live-Accounts (aus `TradingState.Accounts` bzw. `IAccountRepository`; `!IsDemo`,
+  mit gesetzter `WalletAddress`).
+- **Hinweis Ist-Stand:** `PolymarketApiService.GetTraderActivityAsync` filtert heute hart auf
+  `type=TRADE`. Fürs Accounting brauchen wir ALLE Activity-Typen → entweder den Filter parametrisieren
+  oder eine eigene, accounting-spezifische Abruf-Methode (schlanker, ohne Copytrading-Annahmen).
+
+---
+
+## 2. Datenbeschaffung (der Kern: der unabhängige Abruf)
+
+### 2.1 Ledger-Quellen bei Polymarket
+- **Data-API `/activity?user=<wallet>`** = primäres Kontobuch. Enthält (Feldnamen/Typen bei Umsetzung
+  zwingend aus https://docs.polymarket.com verifizieren) u. a.:
+  - `TRADE` (BUY/SELL-Fills): Preis, Size, USDC, Fee, Token/Market, txHash, Timestamp, Side.
+  - `REDEEM` (Resolution-Auszahlung: Gewinner-Shares → USDC).
+  - `SPLIT` / `MERGE` / `CONVERSION` (CTF-/NegRisk-Operationen; meist geldneutral, aber bestandsrelevant).
+  - `REWARD` (Liquidity Rewards) / Maker-Rebates — Einnahmen.
+- **On-Chain USDC-Ein-/Auszahlungen** (Deposits/Withdrawals ins/aus dem Wallet): sind **nicht** Teil
+  der Trading-Activity. Quelle: Polygon/Alchemy (ERC-20-Transfer-Logs USDC ↔ Wallet).
+  - **Adresse ist vorhanden:** Polymarket nutzt **Gnosis-Safe-Proxy-Wallets** — genau die Adresse, die
+    wir bereits als `AccountState.WalletAddress` für Balance- und Activity-Abrufe verwenden. Sie ist
+    also die Watch-Adresse für USDC-Transfers (keine zusätzliche Beschaffung nötig).
+  - **Die eigentliche Arbeit ist die Klassifikation:** Die USDC-Transfers des Safes enthalten SOWOHL
+    trading-interne Bewegungen (Safe ↔ Polymarket-Contracts: CTF/Exchange/NegRisk — bereits in `/activity`
+    als Trades/Redeems erfasst) ALS AUCH echte Ein-/Auszahlungen (Safe ↔ EXTERNE Adressen). Nur letztere
+    sind Deposits/Withdrawals. Klassifikation über eine **Whitelist der Polymarket-System-Contracts**
+    (die CTF-Adresse `0x4D97…6045` liegt bereits im Code — Exchange/NegRisk-Adapter/USDC ergänzen, aus
+    docs verifizieren). Alternativ als Kreuzprobe: ΔSafe-Balance − Σ(interne Activity) = externe Netto-Ein-/Auszahlung.
+  - ⚠️ Gnosis-Safe-Nuance: Transfers laufen ggf. als Safe-`execTransaction`; die ERC-20-Transfer-Logs
+    (from/to = Safe) bleiben aber die maßgebliche, prüfbare Quelle.
+- **Balance-Anker**: `GetUsdcBalanceAsync(wallet)` je Abruf als Kontrollpunkt (End-Saldo Soll-Ist).
+
+### 2.2 Vollständigkeit & Idempotenz
+- **Backfill + Inkrementell**: Erstlauf lädt die volle Historie je Account (paginiert, `offset`/`limit`;
+  Rate-Limits beachten — Activity 1000/10 s, Positions 150/10 s, bereits im ApiService limitiert).
+  Danach nur neue Ereignisse ab dem letzten bekannten Zeitpunkt, mit Sicherheits-**Lookback-Überlappung**
+  gegen API-Lag.
+- **Idempotenz-Schlüssel** je Buchungssatz: stabile Kombination `txHash + logIndex/assetId + type`
+  → überlappende Abrufe buchen nicht doppelt (Unique-Constraint + Upsert).
+- **Lückenerkennung**: Timestamp-Kontinuität + Seiten-Vollständigkeit prüfen; fehlende Bereiche gezielt
+  nachladen und markieren.
+- **Rohdaten-Snapshot**: die JSON-Rohantwort je Abruf-Batch speichern (Nachweis + Reproduzierbarkeit),
+  zusätzlich zu den normalisierten Sätzen.
+
+### 2.3 Abruf-Steuerung
+- `AccountingIngestJob : BackgroundService` (JobManager-registriert, manuell triggerbar), Intervall
+  konfigurierbar (z. B. stündlich inkrementell, täglich Voll-Reconcile). Nutzt die bestehenden
+  Rate-Limiter des `PolymarketApiService`.
+
+---
+
+## 3. Persistenz (acc_-Tabellen, append-only Ledger)
+
+| Tabelle | Inhalt |
+|---|---|
+| `acc_ledger` | Normalisierte, **unveränderliche** Buchungssätze: AccountId, EventType (TRADE_BUY/TRADE_SELL/REDEEM/REWARD/FEE/SPLIT/MERGE/DEPOSIT/WITHDRAWAL), Timestamp, TokenId/Market, Outcome, Size, PriceUsdc, GrossUsdc, FeeUsdc, NetUsdc, TxHash, LogIndex, Source, IngestBatchId, **IdempotencyKey (unique)** |
+| `acc_ingest_runs` | Abruf-Protokoll: AccountId, Von/Bis, Start/Ende, #Sätze, Ok/Fehler, Balance-Anker (Soll-Ist) |
+| `acc_raw` | Rohdaten-Snapshots (JSON) je Batch (Nachweis) |
+| `acc_fx_rates` | (falls Fiat, §10.1) amtliche Tages-FX-Kurse (z. B. USD→EUR) je Datum |
+| `acc_statements` (optional) | Erzeugte Periodenabrechnungen (Metadaten + Daten-Hash) für Versionierung/Reproduzierbarkeit |
+
+Autoincrement-PKs (Lehre aus dem CopyTrading-`TradeId`-Problem), Unique-Index auf `IdempotencyKey`,
+Indizes auf `(AccountId, Timestamp)`.
+
+---
+
+## 4. Buchhaltungs-Logik (pure, testbar) — `AccountingEngine`
+
+Wie bei den anderen Modulen liegt die geldkritische Logik pur und unit-getestet in `Logic/`:
+- **Klassifikation** roher Activity → Buchungssatz-Typ + Vorzeichen (Einnahme/Ausgabe). Rein/testbar.
+- **Periodenabrechnung** (Zeitraum × Account bzw. alle): aggregiert die Ledger-Sätze zu:
+  Anfangssaldo, Einlagen, Entnahmen, Handelsvolumen, realisierte Gewinne/Verluste, Fees, Rewards,
+  Netto-Ergebnis, Endsaldo — mit **Soll-Ist gegen den Balance-Anker** (Abweichung = Vollständigkeits-Signal).
+- **Realisierung / Kostenbasis**: Gewinn/Verlust wird bei SELL/REDEEM realisiert; Kostenbasis je
+  Position per **FIFO** (US-Norm für Krypto/Property; Specific-ID als Option, §10.5) — Lot-Matching der
+  BUYs zu jeder Veräußerung, inkl. Haltefristen (short/long term). Pure/testbar. Offene Positionen zum
+  Periodenende optional als **Mark-to-Market** ausweisen, aber getrennt vom realisierten Ergebnis.
+- **Währung/FX**: jede Transaktion in **USDC (nativ), USD und EUR**. Umrechnung je Transaktionsdatum:
+  USDC→USD (Stablecoin, Annahme 1:1 als USD-Äquivalent — im Export dokumentiert; realer USDC/USD-Kurs
+  optional) und USD→EUR über amtliche Tageskurse (EZB), versioniert in `acc_fx_rates`.
+
+---
+
+## 4a. US-Steuer-Rechenschicht (Florida LLC) — konfigurierbar, CPA-prüfbar
+
+> ⚠️ **Kein Steuerrat.** Diese Schicht rechnet Zahlen nach **dokumentierten, konfigurierbaren
+> Annahmen** aus und weist diese im Export offen aus. Die steuerliche Einordnung von
+> Prediction-Market-/Event-Contract-Erträgen in den USA ist **nicht eindeutig geklärt**. Der Output
+> ist zur **Prüfung/Bestätigung durch einen US-CPA/Steuerberater** gedacht, nicht als endgültige
+> Steuererklärung. Jede Annahme ist im PDF/CSV dokumentiert und in den Settings umstellbar.
+
+**Rahmen (Defaults, alle in Settings umstellbar):**
+- **Entität:** Florida LLC. Florida erhebt **keine State Income Tax** → nur **Federal**. LLC-Typ
+  (single-member = disregarded → Schedule C/D im 1040; vs. multi-member = Partnership 1065 + K-1)
+  bestimmt nur die Ziel-Formulare, **nicht** die Gewinnermittlung (§10.7).
+- **Einordnung (Default-Annahme):** jede Position = **Property-Disposition** → realisierter Gewinn/
+  Verlust je Veräußerung (SELL/REDEEM) im **Form-8949/Schedule-D-Stil**: Proceeds (USD), Cost Basis
+  (USD), Holding Period (short/long), Gain/Loss. Alternative Einordnungen (ordinary income, gambling,
+  §1256) als umstellbare Annahme vorgesehen — Auswahl trifft der CPA (§10.4).
+- **USDC:** als **USD-Äquivalent (1:1)** behandelt; USDC-Käufe/-Verkäufe gelten nicht separat als
+  steuerbares Krypto-Event (dokumentierte Vereinfachung; abschaltbar).
+- **Kostenbasis:** **FIFO** (Default) oder Specific-ID; Lot-genau, mit Haltefristen.
+- **Wash-Sale:** Default-Annahme „nicht anwendbar" auf Event-Contracts/Krypto (Stand 2026) — als
+  Schalter, da Rechtslage im Fluss.
+
+**Output der Steuerschicht:**
+- **Form-8949-artige Veräußerungsliste** je Account/Zeitraum (Description, Acquired, Sold, Proceeds,
+  Cost Basis, Gain/Loss, Short/Long) — CSV + PDF.
+- **Schedule-D-artige Zusammenfassung** (kurz-/langfristig, Summen) je Account und aggregiert über die LLC.
+- Vollständige **Methodik-/Annahmen-Seite** im Export (Reproduzierbarkeit + Prüfbarkeit).
+
+Die Rechenlogik (FIFO-Lot-Matching, Haltefrist, Gain/Loss, FX-Umrechnung je Datum) liegt **pur und
+unit-getestet** in `Logic/` (z. B. `UsTaxEngine`), getrennt vom neutralen Ledger.
+
+---
+
+## 5. UI (WinForms, ein Fenster mit Tabs — Muster wie ResolutionFarming)
+
+- **Übersicht / BWA**: Kennzahlen-Kacheln für den gewählten Zeitraum + Account(s): Netto-Ergebnis,
+  Handelsvolumen, Fees, Rewards, Einlagen/Entnahmen, Endsaldo, realisiert vs. offen; Monats-/Perioden-Vergleich.
+- **Ledger**: filterbare Transaktionsliste inkl. Nachweisspalten (txHash etc.).
+- **Steuer (US)**: Form-8949-artige Veräußerungsliste + Schedule-D-Zusammenfassung je Account/alle,
+  mit ausgewiesenen Annahmen (FIFO, Einordnung, USDC=USD). Werte in USD (und EUR).
+- **Abrechnungen / Export**: Zeitraum-Picker (Monats-Presets + frei), Account-Auswahl (einzeln / alle),
+  Währungswahl (USDC/USD/EUR), Buttons „CSV" und „PDF".
+- **Abruf / Status**: Ingest-Läufe, Vollständigkeits-/Lücken-Status, Balance-Soll-Ist, manueller Trigger.
+
+---
+
+## 6. Export (CSV + PDF)
+
+- **CSV**: vollständiger Ledger + Aggregat je Abrechnung (maschinen-/prüfbar).
+- **PDF**: formatierte Abrechnung — Kopf (Account, Wallet, Zeitraum, Erstellungsdatum), Aggregat-Tabelle,
+  Transaktionsliste, Methodik-/Nachweis-Hinweis. Library **PDFsharp/MigraDoc (MIT)** — echte,
+  bedingungslose MIT-Lizenz ohne Umsatzschwelle; MigraDoc eignet sich für tabellarische
+  Abrechnungen/Berichte. (QuestPDF bewusst NICHT: dessen „Community"-Lizenz ist kostenlos nur unter
+  1 Mio USD Jahresumsatz — für eine handelnde LLC ein Lizenzrisiko. Siehe §10.1.)
+- **Reproduzierbarkeit**: jeder Export trägt Zeitraum, Datenstand (letzter Ingest), Zeilenzahl und einen
+  Daten-Hash → gleiche Eingabe ⇒ identische Abrechnung (wichtig für die Prüfbarkeit).
+
+---
+
+## 7. Abgleich mit eigener Trade-DB (niedrige Priorität)
+
+Gegenüberstellung Polymarket-Ledger ↔ unsere Modul-/Core-Trade-Logs je Account/Zeitraum: fehlende/
+zusätzliche Trades, Preis-/Size-/Fee-Abweichungen, PnL-Differenzen. Rein analytisch — findet
+Sync-/Buchungsfehler unserer Trading-Seite. Bericht in der UI + Export.
+
+---
+
+## 8. Phasen & Akzeptanzkriterien
+
+- **A-1 Ingest (read-only), inkl. Ein-/Auszahlungen:** Modul + acc_-Persistenz + Activity-Ingest
+  (ALLE Typen) + On-Chain-USDC-Deposits/Withdrawals + Backfill/Inkrement + Idempotenz + Ingest-Status-UI.
+  **Akzeptanz:** volle Historie eines Live-Accounts vollständig & doppelfrei; Balance-Anker Soll-Ist ≈ 0
+  (inkl. Ein-/Auszahlungen).
+  **✅ UMGESETZT (2026-07-20, Commit folgt):** `PolyTrader.Modules.Accounting` (acc_-Präfix). Pure
+  `AccountingClassifier` (Typ/Vorzeichen/Idempotenz-Key; intern↔extern-Transfer-Trennung via
+  System-Contract-Whitelist). `AccountingDbContext` (acc_ledger append-only + Unique-Idempotency,
+  acc_ingest_runs, acc_raw; Migration `InitialAccounting` angewendet). `AccountingIngestService`
+  (BackgroundService, testbarer `IngestAccountAsync`: idempotenter Upsert + Balance-Anker-Δ +
+  Backfill/Inkrement mit Lookback). Quellen hinter Interfaces (`IActivitySource`/`ITransferSource`/
+  `IBalanceAnchorSource`) mit **Null-Stubs** — offline lauffähig; **Live-Abruf (Polymarket /activity
+  ALLE Typen, Alchemy-USDC-Transfers, GetUsdcBalanceAsync) + System-Contract-Whitelist ist Zielland-
+  Arbeit.** UI (designerfähig): Tabs Ledger + Abruf/Status mit manuellem Backfill/Inkrement. 12 Tests.
+- **A-2 Abrechnung + Übersicht + FX:** `AccountingEngine` + BWA-UI + Periodenabrechnung je Account/alle,
+  Werte in USDC/USD/EUR (Tageskurse in `acc_fx_rates`). **Akzeptanz:** Monatsabrechnung stimmt gegen
+  Balance-Anker; Kennzahlen plausibel; FX nachvollziehbar.
+  **✅ UMGESETZT (2026-07-20):** `AccountingEngine` (pur): `BuildStatement` (Anfangs-/Endsaldo,
+  Ein-/Auszahlungen, Handelsvolumen, Redeems, Rewards, Fees, Netto-Handelsergebnis Cash-Basis exkl.
+  Ein-/Auszahlungen; Invariante Endsaldo−Anfang = Ergebnis+Einz.−Ausz.) + `BuildMonthlyBreakdown`
+  (verkettete Monats-Anfangssalden). `FxConverter` (pur, USDC≈USD-1:1-Annahme dokumentiert; USD→EUR
+  über `acc_fx_rates`, Nearest-on-or-before). `CsvExporter` (pur, RFC-4180, kulturinvariant).
+  `AccountingReportService` (Abrechnung + Währungs-View USDC/USD/EUR). UI-Tab „Übersicht/BWA"
+  (designerfähig): KPI-Kacheln + Monatsvergleich + Zeitraum-/Konto-/Währungswahl + CSV-Export. +6 Tests.
+  **Offen für Zielland:** EZB-Kurs-Ingest (acc_fx_rates füllen) → dann ist EUR verfügbar (USDC/USD sofort).
+- **A-3 US-Steuerschicht:** `UsTaxEngine` (FIFO-Lot-Matching, Haltefristen, Gain/Loss) + Form-8949-/
+  Schedule-D-Ansicht + Annahmen-Dokumentation. **Akzeptanz:** Summe realisierter Gain/Loss stimmt gegen
+  die neutrale Abrechnung; Annahmen ausgewiesen.
+- **A-4 Export:** CSV + PDF (Abrechnung, Ledger, Form-8949/Schedule-D) mit Zeitraum-/Account-/Währungswahl.
+  **Akzeptanz:** vollständig, reproduzierbar, prüfbar.
+- **A-5 Reconciliation (niedrig):** Abgleich mit eigener DB.
+
+Die geldkritische Logik (Klassifikation, Aggregation, Realisierung, FX) ist von Anfang an pur +
+unit-getestet; Ingest/Export werden über Interfaces (Activity-Quelle, PDF-Writer) testbar gehalten —
+wie bei ResolutionFarming die Live-Anbindung hinter Interfaces liegt.
+
+---
+
+## 9. Risiken & Gegenmaßnahmen
+
+| Risiko | Gegenmaßnahme |
+|---|---|
+| Unvollständige API-Historie / Pagination-Lücken | Balance-Anker-Soll-Ist als Vollständigkeits-Wächter; Lückenerkennung + Nachlad; Rohdaten-Snapshots |
+| API-Feld-/Endpoint-Änderungen | Rohdaten speichern; Normalisierung entkoppelt; Feldnamen bei Umsetzung aus docs verifizieren |
+| Doppelbuchung bei überlappenden Abrufen | strikte Idempotenz-Schlüssel + Upsert |
+| Steuerliche Fehlinterpretation | bewusst neutrale, vollständige Aufstellung statt Steuerberechnung; Methodik im Export dokumentiert |
+| FX-Korrektheit | amtliche Tageskurse (z. B. EZB) versioniert in `acc_fx_rates` |
+| Falsche Wallet-Adresse (Proxy vs. Signer) für Deposits | Adress-/Transfer-Semantik je Account verifizieren |
+
+---
+
+## 10. Entscheidungen & offene Punkte
+
+**Entschieden (2026-07-14):**
+- ✅ **Währung:** USDC nativ + USD + EUR (Tageskurse EZB, USDC≈USD dokumentiert).
+- ✅ **Abrechnung:** neutraler Ledger **+** US-Steuerschicht (Florida LLC), als CPA-prüfbare Rechenschicht.
+- ✅ **Umfang v1:** inkl. On-Chain-Ein-/Auszahlungen.
+- ✅ **Kostenbasis:** FIFO (US-Norm), Specific-ID als Option.
+
+**Noch offen / vom CPA zu bestätigen:**
+1. ✅ **PDF-Library: PDFsharp/MigraDoc (MIT)** — nach Rückfrage bewusst statt QuestPDF: QuestPDFs
+   „Community MIT"-Lizenz ist nur unter 1 Mio USD Jahresumsatz kostenlos (darüber Professional/
+   Enterprise kostenpflichtig) → für eine handelnde LLC ein Lizenzrisiko. PDFsharp/MigraDoc ist echte
+   MIT ohne Schwelle.
+2. **Steuerliche Einordnung (Default-Annahme):** Property-Disposition (Form 8949/Schedule D, Default) vs.
+   ordinary income vs. gambling vs. §1256 — vom US-CPA bestätigen lassen; im Tool umstellbar.
+3. **LLC-Typ:** single-member (disregarded) vs. multi-member (Partnership 1065/K-1) — bestimmt nur die
+   Ziel-Formulare/Darstellung, nicht die Gewinnermittlung.
+4. **USDC=USD-Annahme & Wash-Sale-Schalter:** Defaults gesetzt (1:1; Wash-Sale n/a) — vom CPA bestätigen.
+5. ✅ **Proxy-Wallets: geklärt.** Der Gnosis-Safe (= vorhandene `WalletAddress`) ist die Watch-Adresse;
+   zu bauen ist die **Transfer-Klassifikation** intern (Polymarket-Contracts) vs. extern (Deposit/Withdrawal)
+   über eine System-Contract-Whitelist (CTF-Adresse bereits im Code; Exchange/NegRisk/USDC ergänzen).
+6. **FX-Quelle & USDC/USD:** EZB-Tageskurse für USD→EUR; USDC→USD als 1:1 (Default) oder realer Kurs?

docs/archiv/konzepte/KONZEPT-Modul-DataDriven.md

@@ -0,0 +1,129 @@
+# Konzept: Eigenes datengetriebenes Trading-Modul („DataDriven")
+
+> Stand: 2026-07-11
+> Status: KONZEPT (noch kein Umsetzungsplan). Ziel: ein Strategiemodul, das eigene
+> Handelsentscheidungen aus externen Datenquellen ableitet — je Marktkategorie eine
+> eigene Datenquelle + ein eigenes Fair-Value-Modell. Die Datenanbindung wird so
+> gebaut, dass das ResolutionFarming sie mitnutzen kann (State-aware-Filter, C-S2).
+
+---
+
+## 1. Grundidee
+
+Alle bisherigen Module leiten Signale von ANDEREN ab (Master-Trades, Marktpreise).
+DataDriven dreht das um: **Wir berechnen aus Rohdaten eine eigene faire
+Wahrscheinlichkeit** und handeln nur, wenn der Marktpreis deutlich davon abweicht:
+
+```
+FairValue(Markt) aus Datenquelle → Vergleich mit Marktpreis (Bid/Ask)
+→ |FairValue − Preis| > MinEdge (nach Fees) → Order (Maker bevorzugt) → Halten bis Resolution/Ziel
+```
+
+Der Edge kommt nicht aus Geschwindigkeit, sondern daraus, die **Daten besser/
+konsequenter auszuwerten als der Durchschnitts-Teilnehmer** der jeweiligen Kategorie.
+Deshalb ist die Kategorien-Wahl die wichtigste Entscheidung dieses Moduls.
+
+## 2. Architektur (fügt sich in die bestehende Modul-Landschaft)
+
+```
+PolyTrader.Modules.DataDriven (IPolyTraderModule, DbPrefix dd_)
+│
+├── Core-Beitrag (geteilt, auch für ResolutionFarming nutzbar):
+│     IMarketStateProvider          // je Kategorie: liefert konservative
+│     {                             // Wahrscheinlichkeits-Schätzung + Zustand
+│        bool Supports(MarketData m);
+│        Task<MarketStateEstimate?> EstimateAsync(MarketData m, CancellationToken ct);
+│     }
+│     record MarketStateEstimate(decimal ProbLowerBound, decimal ProbUpperBound,
+│                                string StateSummary, DateTime AsOf, string Source);
+│
+├── Provider (je Kategorie ein Adapter, einzeln aktivierbar):
+│     WeatherStateProvider          // Open-Meteo/NOAA-Modelläufe
+│     SportsScoreStateProvider      // Live-Scores (z. B. API-Football)
+│     CryptoStrikeStateProvider     // Binance-Spot + realisierte Volatilität
+│     MacroStateProvider            // Nowcasts/Konsensdaten (CPI, Zinsen)
+│
+├── Services:
+│     DdScannerService              // Märkte je aktiver Kategorie laden, FairValue
+│                                   // berechnen, Kandidaten mit Edge persistieren
+│     DdExecutionService            // Sizing/Limits (Muster: FarmingRiskEngine/
+│                                   // Planner wiederverwenden!), Maker-first
+│     DdPositionMonitorService      // Re-Evaluation offener Positionen: dreht der
+│                                   // FairValue, wird der Exit geprüft (Leiter-Muster)
+│
+└── Persistenz: dd_settings / dd_candidates / dd_positions / dd_closed_trades
+      (Kopie des bewährten rf_-Schemas; Autoincrement-IDs, Kalibrierungs-Historie)
+```
+
+**Wichtige Wiederverwendung:** Risk-Engine, Execution-Planner, Fill-Modell,
+Resolution-Monitor und UI-Aufbau des ResolutionFarming sind fast 1:1 übertragbar —
+DataDriven ist strukturell „ResolutionFarming mit eigener Signalquelle statt
+Preisband-Scan". Der Unterschied: DataDriven darf auch UNTER 0.90 kaufen (überall,
+wo FairValue ≫ Preis) und optional vor der Resolution verkaufen, wenn der Edge
+realisiert ist (Preis hat FairValue erreicht → Kapitalumschlag).
+
+**ResolutionFarming-Synergie (C-S2):** Sobald ein `IMarketStateProvider` für eine
+Kategorie existiert, nutzt ihn auch der RF-Scanner: Ein Preis-Dip wird nicht mehr
+pauschal gemieden (Momentum-Filter), sondern gegen `ProbLowerBound` geprüft —
+Richards 5:1-in-Minute-80-Beispiel wird damit zur Kaufgelegenheit statt zum Reject.
+
+## 3. Kategorien-Bewertung: Wo lohnt sich ein eigenes Modell?
+
+Bewertung nach: Datenlage (frei/billig verfügbar?), Modell-Komplexität,
+Bot-Konkurrenz (Stand 2026), Fee-Satz, Kapitalbindung.
+
+| Kategorie | Datenquelle (Kosten) | Modell | Bot-Konkurrenz | Fee | Bindung | Urteil |
+|---|---|---|---|---|---|---|
+| **Wetter (Tages-Märkte: Temperatur/Niederschlag je Stadt)** | Open-Meteo/NOAA/ECMWF-Läufe (kostenlos) | Modell-Konsens vs. Marktpreis; Update-Lag nutzen | **moderat, wachsend** — Edges von ~10 Pp (2023) auf ~3 Pp (2026) komprimiert, aber vorhanden; dünne Bücher, wenig Retail | 1,25 % | Stunden–Tage | ✅ **Bester Einstieg** |
+| **Wetter (Saison: Hurrikane, Rekorde)** | wie oben + NHC | aufwendiger | gering (Kapital-Lockup schreckt ab) | 1,25 % | Wochen–Monate | ⚠️ später (Bindung) |
+| **Sport pre-game (kleinere Ligen)** | API-Football o. ä. (~20–30 $/Mon.) | Elo-/Quotenvergleich vs. Buchmacher-Konsens | groß in Top-Ligen, **moderat in Nebenligen** | 0,75 % | Stunden–Tage | ✅ zweiter Kandidat |
+| **Sport live (State-Provider)** | wie oben, Live-Scores | Score+Restzeit → P(Sieg), konservative Untergrenze | hoch (Latenz-Bots) — aber wir brauchen nur EINEN Fill unter FairValue, nicht den schnellsten | 0,75 % | Minuten–Stunden | ✅ als RF-Filter; als eigene Strategie nur eng begrenzt |
+| **Krypto-Strikes (Wochen/Monat: „BTC über X am Y")** | Binance-WSS (kostenlos) | Distanz zum Strike + realisierte Vol → P | hoch bei 15-min/Stunde, **moderat bei Wochen-Strikes** | 1,8 % ⚠️ | Tage–Wochen | ⚠️ Fee frisst viel; nur bei großem Modell-Edge |
+| **Makro (CPI, Zinsentscheide)** | Cleveland-Fed-Nowcast, Konsens-Schätzungen (frei) | Nowcast vs. Marktpreis | moderat, aber informierte Gegenseite | 1,5 % | Tage–Wochen | ⚠️ Nische, wenige Märkte |
+| **Politik-Longtail (Nicht-Headline)** | Polls/Aggregatoren | Poll-Modell | gering im Long Tail | 1,0 % | Wochen+ | ⚠️ Bindung + Resolution-Risiko |
+| **Kultur/Awards/Mentions** | Box-Office-Daten teils frei; sonst dünn | schwach | **gering** | 1,25–1,56 % | variabel | ❌ Resolution-Risiko (AI-Rater Pflicht), Datenlage schlecht |
+| Krypto 15-min/1h Up-Down | Binance | Latenz | **extrem** (Sub-100-ms-Bots) | 1,8 % | Minuten | ❌ nicht unser Spiel |
+
+**Antwort auf „nicht geflutete Kategorien":** Am wenigsten Bot-dominiert sind 2026
+(a) **Wetter** — dünne Bücher, Nischenwissen (Stations-Regeln, Modell-Läufe), Retail
+meidet die Kategorie; (b) **Long-Tail-/Nebenliga-Sport pre-game**; (c) **Makro-
+Nischen** und (d) Long-Tail-Politik. Geflutet sind: Krypto-Kurzfrist, Top-Sport
+in-play, Headline-Elections, Arbitrage/NegRisk-Rebalancing. Faustregel: Bots meiden
+Kapitalbindung und Nischenwissen — genau dort liegt unser Fenster.
+
+## 4. Empfohlener Aufbau-Pfad
+
+1. **Phase DD-0:** `IMarketStateProvider`-Contract in Core + Modul-Skelett
+   (rf_-Schema kopieren). Kein Provider aktiv.
+2. **Phase DD-1 (Wetter, read-only):** WeatherStateProvider (Open-Meteo, tägliche
+   Temperatur-Märkte 2–3 US-Städte). Scanner läuft wochenlang read-only:
+   FairValue vs. Marktpreis loggen → **misst den real verbliebenen Edge, bevor
+   irgendetwas gehandelt wird** (dasselbe Kalibrierungs-Gate-Prinzip wie RF).
+3. **Phase DD-2:** Demo-Execution (Planner/Fill-Modell aus RF), 4 Wochen.
+4. **Phase DD-3:** SportsScoreStateProvider — zuerst NUR als RF-Filter (C-S2:
+   Dip-Freigabe bei klarer Führung), erst danach als eigene DD-Strategie.
+5. **Phase DD-4:** Live klein (eigener Account, wie bei RF), dann weitere Provider
+   nach gemessenem Edge.
+
+## 5. Risiken dieses Moduls (ehrlich)
+
+1. **Modell-Risiko ersetzt Master-Risiko:** Ein Bug/Bias im Fair-Value-Modell
+   produziert systematisch falsche Trades. Gegenmittel: read-only-Messphase je
+   Provider (DD-1-Prinzip), konservative Untergrenzen statt Punktschätzern.
+2. **Edge-Kompression:** Der Wetter-Edge ist dokumentiert am Schrumpfen (10→3 Pp).
+   Read-only-Messung VOR jedem Livegang, und die Bereitschaft, eine Kategorie
+   wieder abzuschalten, wenn die Messung < MinEdge zeigt.
+3. **Regel-Fallen:** Wetter-Märkte lösen nach exakten Stations-Regeln auf — der
+   AI-Auflösequalitäts-Rater (separater Plan) und das genaue Lesen der Regeln
+   je Markt-Serie sind Pflicht (welche Station, welche Rundung, welcher Zeitraum).
+4. **Aufwand:** Jede Kategorie ist ein eigenes kleines Forschungsprojekt. Deshalb:
+   strikt eine Kategorie nach der anderen, jede mit eigenem Go/No-Go-Gate.
+
+## 6. Quellen (Kategorien-/Konkurrenz-Einschätzung)
+
+- Polymarket Weather/Climate-Kategorieübersichten (Volumen/Marktzahl):
+  https://polymarket.com/predictions/weather, https://polymarket.com/predictions/climate
+- Weather-Bot-Funktionsweise & Edge-Kompression 2023→2026:
+  https://laikalabs.ai/prediction-markets/polymarket-weather-trading-bot
+- Markt-Mikrostruktur/Tiefe Wetter-Märkte: https://polymart.app/blog/polymarket-weather-markets,
+  https://polymarkets.co.il/en/guide/weather-guide/

docs/archiv/konzepte/KONZEPT-Modul-Supervisor.md

@@ -0,0 +1,206 @@
+# Konzept: Modul „Supervisor" (KI-gestützte Handels-Analyse & Forensik)
+
+> Stand: 2026-07-16
+> Ziel: ALLES, was PolyTrader getan (und bewusst NICHT getan) hat, auf einfachem Wege detailliert
+> analysierbar machen — Logs, DB-Einträge und das echte Geschehen auf der Plattform — und die Analyse
+> durch ein KI-Modell (OpenRouter) durchführen lassen: Warum hat ein Trade funktioniert? Warum nicht?
+> Woran lag es?
+> **Leitidee: Erst das Datenfundament, dann die KI.** Ein Modell kann nur erklären, was aufgezeichnet
+> wurde. Die Analyse ist maximal so gut wie die Rekonstruierbarkeit unserer Entscheidungen.
+
+---
+
+## 0. Datenlage-Audit: Was haben wir, was fehlt?
+
+### Vorhanden ✅
+| Quelle | Inhalt | Qualität für Analyse |
+|---|---|---|
+| `core_trade_log` (TradeRecord) | abgeschlossene Trades aller Module | gut (strukturiert), aber nur das ERGEBNIS |
+| Modul-Logs (`mod_copytrading_closed_trades`, `rf_*`) | Modul-Details inkl. Fees, SourceTrader, Cluster | gut |
+| Terminal-/Datei-Logs (`/Logs`, Freitext) | Verlauf inkl. `TradeReasoning` (Begründungen) | schlecht maschinenlesbar: Freitext, deutsch, ohne IDs |
+| `rf_candidates` | Scanner-Entscheidungen inkl. Reject-Grund | **Vorbild!** genau das Muster, das wir überall brauchen |
+| geplant: `acc_ledger` (Accounting-Modul) | unabhängige Plattform-Ground-Truth je Wallet | schließt „echtes Geschehen auf der Plattform" |
+
+### Fehlend ❌ (die eigentlichen Lücken)
+1. **Entscheidungsjournal** — der größte Gap. Jede Engine-Entscheidung (BUY/SELL ausgeführt, abgelehnt,
+   übersprungen) existiert nur als Freitext-Log. Nicht abfragbar („zeig alle MaxBuyPrice-Rejects der
+   Woche"), nicht mit dem späteren Marktausgang verknüpfbar („was WÄRE aus den Rejects geworden?" —
+   das ist die halbe Strategie-Kalibrierung!).
+2. **Order-Lifecycle nicht persistiert** — Platzierungsversuche, CLOB-Responses, Cancels, Leiter-Stufen
+   (Preis je Stufe, Wartezeiten, Floor-Erreichung) stehen nur im Log. Für „warum schlechter Fill?"
+   brauchen wir die Kette als Daten.
+3. **Korrelation** — es gibt keine `SignalId`, die Signal → Entscheidung(en) → Order(s) → ClosedTrade
+   verbindet. Ohne sie ist jedes „Dossier" Handarbeit über Zeitstempel.
+4. **Markt-Kontext zum Entscheidungszeitpunkt** — mindestens Signalpreis vs. erzielter Preis vs.
+   Zeitversatz (Latenz!); mit Phase 1 (Orderbuch) auch Spread/Tiefe. Ohne Kontext kann niemand
+   beurteilen, ob eine Entscheidung RICHTIG war — nur ob sie gut AUSGING.
+5. **Strukturierte Logs** — zusätzlich zum Text ein JSONL-Sink (Timestamp, Level, Source, CorrelationId,
+   Message, Data), damit Logs filterbar/parsebar sind statt grep-über-Freitext.
+
+---
+
+## 1. Frage 1 — Aufbereitung: das „Trade-Dossier" als zentrale Einheit
+
+**S-0: Datenfundament (Core, nützt sofort auch OHNE KI — z. B. beim Zielland-Debugging):**
+- `core_decision_journal`: eine Zeile je Entscheidung. Felder: `SignalId`, Timestamp, Modul, AccountId,
+  TokenId, Side, Decision (Executed/Rejected/Skipped/Deferred), **ReasonCode (Enum!)** (z. B.
+  `MaxBuyPriceExceeded`, `PartialSellBelowThreshold`, `ExitPendingSkip`, `SpamBlock`, `BudgetExhausted`,
+  `BelowPolymarketMinimum`, …), Kontext-Zahlen (SignalPreis, Limitwert, verfügbares Budget, …) als
+  kompaktes JSON, Freitext wie bisher zusätzlich.
+  → Die bestehenden ~20 `TradeReasoning`-Stellen bleiben, schreiben aber ZUSÄTZLICH strukturiert.
+- `core_order_events`: Order-Lifecycle (Placed/Rejected/Cancelled/LadderStep/Filled) mit Preisen,
+  CLOB-Response, `SignalId`.
+- `SignalId` (GUID) im `CopySignal`/RF-Flow erzeugen und bis in `ClosedTrade`/`TradeRecord` durchreichen.
+- **JSONL-Log-Sink** (TerminalLogger erweitert): eine JSON-Zeile je Event (`ts`, `level`, `source`,
+  `correlationId`, `message`, optional `data`). JSONL statt JSON-Array: append-fähig, streambar,
+  zeilenweise filterbar — das KI-freundliche UND effiziente Format. Übergang: zunächst Dual-Sink
+  (Text + JSONL), Text-Sink später abschaltbar, sobald der Log Viewer etabliert ist.
+- **Log Viewer im Terminal-Fenster** (zweiter Tab neben der Live-Anzeige): lädt die JSONL-Dateien und
+  bereitet sie menschenlesbar auf — Filter nach Datum/Level/Quelle/Text und **CorrelationId
+  („zeig mir alles zu diesem Signal")**; Klick auf eine SignalId springt zur kompletten Kette. Damit
+  ist das effiziente Speicherformat für Menschen genauso zugänglich wie heute der Freitext.
+
+**S-1: Dossier-Generator (pur, testbar):** Für einen Trade / ein abgelehntes Signal alles zusammensetzen:
+Signal → Journal-Einträge → Order-Events → Fill/Leiter-Verlauf → ClosedTrade/RF-Position →
+`acc_ledger`-Einträge (Plattform-Wahrheit!) → Log-Ausschnitt (Zeitfenster+CorrelationId) → Marktdaten.
+Ausgabe als JSON (fürs Modell) und Markdown (für Menschen). Dazu Perioden-Reports über `TradeAnalytics`.
+
+---
+
+## 2. Frage 2 — WIE analysieren: OpenRouter-Agent mit Read-only-Tool-Registry
+
+**v1: Agent IM Prozess (kein separater MCP-Server nötig).** Wir kontrollieren beide Seiten — ein
+Function-Calling-Loop gegen OpenRouter (Chat Completions + Tools) ist in C# klein und ohne neue
+Abhängigkeit machbar (HttpClient + System.Text.Json). Der Agent bekommt:
+
+1. **System-Kontext:** ein kuratiertes, versioniertes Dokument `docs/analyse/ARCHITEKTUR-KONTEXT.md`
+   („So funktioniert PolyTrader": Module, Entscheidungswege, Reason-Codes, Limits, Leiter-Mechanik,
+   bekannte Eigenheiten). KEIN Code-Dump — destilliertes Verhalten. Wird bei Änderungen am Geld-Pfad
+   mitgepflegt (Checkliste).
+2. **Read-only-Tools** (Registry im Supervisor-Modul):
+   - `query_trades(filter)` — Core-Trade-Log
+   - `query_decisions(filter)` — Entscheidungsjournal (inkl. Rejects!)
+   - `get_dossier(signalId | tokenId+account)` — das komplette Dossier
+   - `read_logs(zeitraum, level, correlationId, textfilter)` — JSONL-Logs
+   - `get_ledger(account, zeitraum)` + `get_ledger_diff(...)` — Plattform vs. eigene DB (Accounting)
+   - `get_kpis(scope)` — TradeAnalytics
+   - `get_architecture_context()` — das Kontext-Dokument
+   - **Predictalytics-Tools** (`query_predictalytics_*`): historische Trade-Daten fremder Trader,
+     Master-Historien, Markt-Statistiken aus unserem Predictalytics-Tool (dessen API wir ohnehin
+     integrieren). Analytisch besonders wertvoll: **„schlechtes Signal" von „schlechter Ausführung"
+     trennen** — z. B. Master-Fill vs. unser Fill (Latenzkosten) oder unser Ergebnis vs. das anderer
+     Trader im selben Markt (Benchmark). Architektur: `IPredictalyticsClient` im **Core** (auch
+     Trading-Module nutzen ihn später, z. B. Master-Auswahl/AI-Rating); der Supervisor konsumiert ihn
+     nur read-only. Eigener Egress-Eintrag (unsere eigene API, aber dokumentiert).
+   **Hart: KEIN Tool kann handeln, canceln oder schreiben.** Der Supervisor ist Beobachter.
+
+**Analyse-Modi:**
+- **Einzeltrade-Forensik:** „Erkläre Trade X" → Dossier → Modell begründet mit Daten.
+- **Batch-/Muster-Analyse:** „Alle Verlierer der letzten 14 Tage → gemeinsame Faktoren?" (Kategorie?
+  Uhrzeit? Master? Preisband? Latenz? Leiter-Floor-Fälle?)
+- **Counterfactual:** „Was wurde abgelehnt und wie ist der Markt ausgegangen?" (Journal × Resolution).
+- **Reconciliation-Anomalien:** DB ↔ Plattform-Differenzen erklären lassen.
+- **Täglicher Supervisor-Bericht** (später): Kurzfassung via Threema.
+
+**MCP-Server-Light: ja, aber als Phase S-4.** Dieselbe Tool-Registry zusätzlich über einen lokalen
+MCP-Endpoint exponieren → dann können auch externe Clients (Claude Code/Desktop) direkt gegen die
+laufende App analysieren. Architektonisch nur ein zweiter Transport über dieselben Tools — deshalb
+lohnt es, die Registry von Anfang an transport-agnostisch zu bauen.
+
+---
+
+## 3. Frage 3 — Core- oder Modulebene? Hybrid.
+
+- **Datenfundament = Core.** Journal, Order-Events, SignalId, JSONL sind Core-Contracts (wie der
+  generische Trade-Log heute); alle Module schreiben hinein (Dual-Write-Muster existiert bereits).
+- **Analyse = modulübergreifend.** Profitabilität ist eine Frage über Module/Accounts hinweg — genau
+  wie das Dashboard.
+- **Modul-Spezifisches via Contract:** Core definiert `IAnalysisContextSource` (liefert z. B.
+  RF-Kandidaten-Kontext oder Copytrading-Master-Kontext zu einem Dossier); Module registrieren
+  Implementierungen per DI; der Supervisor konsumiert alle. So bleibt „Module kennen einander nicht"
+  gewahrt (beide Seiten referenzieren nur den Core).
+
+## 4. Frage 4 — Unterbringung: eigenes Modul „Supervisor"
+
+`src/PolyTrader.Modules.Supervisor/` als `IPolyTraderModule` (`Name="Supervisor"`, `DbPrefix="sup_"`),
+Registrierung in `Program.cs`, referenziert nur den Core. Eigenes Fenster (Muster RF/Copytrading):
+- Tab **Analyse** (Chat mit dem Agenten, Tool-Aufrufe sichtbar/expandierbar — Nachvollziehbarkeit!)
+- Tab **Dossier-Browser** (Trade/Signal auswählen → Dossier ansehen, auch ohne KI)
+- Tab **Berichte** (gespeicherte Analysen/Tagesberichte, `sup_reports`)
+- Tab **Settings** (API-Key, Modellwahl je Aufgabe, Kosten-/Tokenbudget, Bericht-Zeitplan)
+
+Warum Modul statt Core-Fenster: passt ins etablierte Muster (eigene Persistenz `sup_reports`/
+`sup_conversations`, eigene Settings, eigener Launcher-Button), hält die KI-Abhängigkeit aus dem Core
+heraus und ist einzeln abschaltbar.
+
+## 4a. Supervisor-„Team": Profile statt getrennter Agenten
+
+Die Idee (technischer Supervisor + je Modul ein Strategie-Supervisor) ist richtig — aber als
+**Profile über EINER gemeinsamen Infrastruktur**, nicht als getrennte Agenten/Fenster/Prozesse:
+
+| Profil | Fokus | Tools (Subset) | Kontext |
+|---|---|---|---|
+| **Technik-Supervisor** | Fehler-/Warning-Muster in Logs, Job-Health, API-Ausfälle, Latenzen, Reconciliation-Differenzen — KEINE Strategie-Meinung | read_logs, get_ledger_diff, query_order_events | Architektur-Doku |
+| **CopyTrading-Supervisor** | Master-Qualität vs. Ausführungsqualität, Leiter-Verhalten, Reject-Muster | query_decisions, get_dossier, Predictalytics (Master-Historie) | + CopyTrading-Kontextabschnitt |
+| **ResolutionFarming-Supervisor** | Kalibrierung (Winrate je Preisband vs. Erwartung), Cluster-Risiken, Scanner-Rejects | query_decisions, rf-Kontext, get_kpis | + RF-Kontextabschnitt |
+| *(später)* **Chef-Supervisor** | fasst die Einzelberichte zusammen | die Berichte der anderen | Gesamtsicht |
+
+Ein Profil = System-Prompt + Tool-Subset + Zeitplan + Modellwahl. Gleiche Registry, gleicher Agent-
+Runner, gleiche UI (Profil-Auswahl im Analyse-Tab; Berichte je Profil). Modul-Wissen kommt über die
+`IAnalysisContextSource`-Registrierung der Module — ein neues Modul bringt seinen Supervisor-Kontext
+selbst mit, ohne dass der Supervisor es kennt.
+
+**Bewusst NICHT (v1):** Agent-zu-Agent-Orchestrierung/Diskussionen — teuer, schwer debugbar, wenig
+Mehrwert. Profile laufen unabhängig (on-demand oder per Zeitplan); der „Chef" liest nur deren Berichte.
+
+## 5. API-Key: ja, getrennt
+
+**Separater OpenRouter-Key für den Supervisor** (getrennt von künftigen Trading-Modul-Keys wie dem
+AI-Markt-Rating):
+1. **Kostenzuordnung** — Forensik-Sessions können tokenintensiv werden; sauber getrennt sichtbar.
+2. **Spend-Limits je Key** bei OpenRouter → ein Analyse-Amok kann nie das Trading-Budget fressen (und umgekehrt).
+3. **Unabhängige Rotation/Sperrung** (Incident-Response, siehe Sicherheitskonzept).
+4. **Modellwahl je Aufgabe:** Routineberichte mit günstigem Modell, Tiefen-Forensik mit starkem Modell — je Aufgabe konfigurierbar.
+
+**Ablage:** beide Keys über die vorhandene `SecretProtection` (F1-Mechanik) verschlüsselt — nicht im
+Klartext in DB/Config.
+
+## 6. Sicherheit (Verzahnung mit docs/sicherheit)
+
+- **OpenRouter = NEUER externer Datenempfänger.** Bewusste Erweiterung der Egress-Allowlist (§5.3 im
+  Sicherheitskonzept) + Dokumentation dort. Es verlassen uns: Trade-/Entscheidungs-/Log-Daten (Wallet-
+  Adressen sind ohnehin öffentlich on-chain). **Redaction-Schicht vor dem Versand:** niemals Secrets/
+  Keys/Connection-Strings in Tool-Antworten (Log-Reader filtert Muster; Secrets stehen per F6-Prüfung
+  ohnehin nicht in Logs — Doppelboden bleibt).
+- **Read-only by design:** kein Order-/Schreib-Tool. Damit ist auch Prompt-Injection über Fremdtexte
+  (Marktfragen in Dossiers) auf „falsche Analyse" begrenzt, kann aber nie handeln.
+- Tool-Aufrufe des Agenten werden geloggt (sup_-Tabelle) — der Supervisor ist selbst auditierbar.
+
+## 7. Phasen
+
+- **S-0 Datenfundament (Core):** `core_decision_journal` + ReasonCode-Enum + `SignalId`-Durchreichung +
+  `core_order_events` + JSONL-Sink + **Log Viewer im Terminal**. Engine/Leiter/Monitor/RF schreiben
+  strukturiert. Pure Logik + Tests; Migrationen offline. **Sofortnutzen ohne KI** (abfragbare Rejects,
+  Log-Forensik per CorrelationId, Zielland-Debugging).
+- **S-1 Dossier:** Generator (pur, testbar) + Dossier-Browser-UI (Modul-Skelett Supervisor).
+- **S-2 Agent:** OpenRouter-Client, Tool-Registry (read-only, transport-agnostisch), Analyse-Chat-Tab
+  mit **Profil-Auswahl** (zunächst 1 Profil „Allgemein"), Architektur-Kontext-Dokument.
+- **S-3 Team & Berichte:** Technik-/Modul-Supervisor-Profile, Batch-Analysen, Counterfactual-Report,
+  täglicher Threema-Bericht; `IPredictalyticsClient` (Core) + Predictalytics-Tools.
+- **S-4 MCP-Light (optional):** Tool-Registry zusätzlich als lokaler MCP-Server für externe Clients.
+
+## 8. Offene Entscheidungen (Richard)
+
+1. **Start mit S-0 sofort?** (Empfehlung: ja — nützt auch ohne KI und VOR dem Live-Start; alles
+   Weitere baut darauf.)
+2. Counterfactual-Tracking („was wäre aus Rejects geworden") von Anfang an im Journal vorsehen
+   (Resolution-Nachverfolgung abgelehnter Signale) oder später?
+3. Modellwahl-Defaults (günstig vs. stark) und Tokenbudget/Monat für den Supervisor.
+4. Tagesbericht via Threema gewünscht (S-3)?
+5. Text-Log-Sink nach Etablierung des Log Viewers abschalten (nur noch JSONL) oder dauerhaft dual?
+6. Predictalytics-API: Auth/Key-Mechanik und welche Endpoints der Supervisor bekommt (read-only-Subset).
+
+## Ergänzungen Richard (2026-07-16, eingearbeitet)
+- ✅ Predictalytics-Daten als Analyse-Quelle (§2, `IPredictalyticsClient` im Core, S-3).
+- ✅ Supervisor-„Team" — als Profile über einer Infrastruktur statt getrennter Agenten (§4a).
+- ✅ Reasoning/Logs KI-freundlich als JSONL + menschenlesbarer Log Viewer im Terminal (§1, S-0).