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/IDEENSAMMLUNG-Feldtest-2026-08.md

@@ -77,7 +77,7 @@ zweimal gebaut wird. → siehe ❓F-1.
 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)
+In [`AccountingModule.cs:43-45`](../src/PolyTrader.Modules.Accounting/AccountingModule.cs)
 sind alle drei Ingest-Quellen als Null-Stubs registriert:
 
 ```csharp
@@ -87,7 +87,7 @@ 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)).
+([`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**
@@ -167,7 +167,7 @@ oben ausgewählten Jobs** — z. B. beim „Threema Webhook Listener": wann lief
 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
+`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,
@@ -227,7 +227,7 @@ Trades bereits gebaut), Prädikate für PnL-Vorzeichen und Marktstatus (baut auf
 **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),
+([`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
@@ -248,7 +248,7 @@ und unterliegen `.agents/rules/clob.md` in verschärfter Form.
 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)
+[`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).