## Ergebnis

Die v77-Paper-Strecke ist grundsätzlich fail-closed aufgebaut, aber aktuell nur für **zwei hart codierte Kandidaten** ausgelegt. Mehrere neue Kandidaten sollten nicht lediglich in die Supervisor-Liste aufgenommen werden; dafür fehlen noch zentrale Identitäts-, Isolations- und Integritätssicherungen.

### Ist-Architektur

- **Strategie/Runtime**
  - Zulässige IDs und Richtung sind statisch in `SUPPORTED` hinterlegt:  
    `src/tools/v77_trend_retest_runtime.py:29-35`.
  - Zusätzlich erzeugt `build_intent()` wieder hart codierte Strategie-IDs:  
    `src/strategies/trend_retest_anti_chase_v2.py:97-137`.
  - Jeder Kandidat schreibt direkt nach  
    `runtime/experiments/<strategy_id>/`:
    - `state.json`
    - `signal_journal.jsonl`
    - `trade_journal.jsonl`
    - `runtime_health.jsonl`
    - `bot.pid`
  - State wird atomar per Temp-Datei ersetzt; JSONL-Appends und PID-Datei sind dagegen nicht gegen parallele Writer geschützt.
  - Paper-Sicherheit ist zweistufig:
    - Runtime verweigert drei explizit aktive Live-/Signed-Flags: `v77_trend_retest_runtime.py:65-73`.
    - Supervisor startet mit `paper=true`, allen Live-/Signed-Flags `false`:  
      `ctb_v77_paper_supervisor.py:47-56`.
  - Die Runtime verlangt jedoch nicht ausdrücklich `CTB_PAPER_TRADING=true`; sie blockiert nur aktive Live-Flags.

- **Supervisor**
  - Liegt außerhalb des Repositories unter  
    `~/.hermes/scripts/ctb_v77_paper_supervisor.py`.
  - Kandidaten und Coins sind hart codiert: Zeilen 15–19.
  - Prozessvalidierung prüft PID, Modul, exakte Strategie-ID und Umgebungsflags: Zeilen 22–41.
  - Bei jeder als unsicher/unauffindbar bewerteten PID wird sofort ein neuer Prozess gestartet: Zeilen 107–110.
  - Danach wird je Kandidat der Promotion Report erneuert und eine One-shot-Markierung gespeichert.
  - Es gibt derzeit:
    - keinen Start-Lock,
    - keine Prüfung der PID-Startzeit,
    - keine Heartbeat-Frischeprüfung,
    - keine Begrenzung paralleler Instanzen,
    - keinen fail-closed Zustand „Prozesslage unklar“.
  - Dadurch können überlappende Supervisor-Läufe oder eine verlorene PID-Datei doppelte Writer starten.

- **Promotion Reporting**
  - `src/tools/v77_promotion_report.py` liest nur das jeweilige Kandidatenverzeichnis und filtert nach `strategy_version`.
  - Positive Eigenschaften:
    - 50 abgeschlossene Lifecycles,
    - drei profitable Wochen,
    - Gesamt- und Last-30-PF,
    - Netto-PnL,
    - Leave-one-coin-out,
    - Konzentrationsgrenze,
    - eindeutige Entry-Fenster,
    - keine Proxy-Daten,
    - Stop-Abdeckung,
    - keine offenen Positionen.
  - Report bleibt ausdrücklich nicht ausführungsberechtigt: Zeilen 117–122.
  - Schwächen:
    - keine Validierung von `strategy_id` gegen das Verzeichnis,
    - Entries und Exits werden nicht zu eindeutigen Lifecycles gepaart,
    - doppelte Exits könnten mitzählen,
    - ungültige JSONL-Zeilen werden still übersprungen,
    - defektes `state.json` wird wie leerer State behandelt und kann somit „keine offenen Positionen“ ergeben,
    - keine Runtime-/Heartbeat-Frische oder Datenqualitätsquote,
    - keine Mindestverteilung abgeschlossener Trades je Coin,
    - kein Drawdown-/Loss-Streak-Gate.
  - Der allgemeine `paper_scorecard_report.py` erwartet überwiegend  
    `Tradeanalyse/trade_journal.jsonl`; v77 schreibt direkt in den Kandidatenordner. Damit existieren aktuell zwei nicht vollständig kompatible Reporting-Pfade.

- **Tests**
  - Vorhanden:
    - Richtungs- und Featuretests,
    - Paper-Flag-Verweigerung,
    - Fake-Market-Data-Scan,
    - TP1/Positionsmanagement,
    - leere und positive Promotion-Fixtures.
  - Nicht vorhanden:
    - Tests für `ctb_v77_paper_supervisor.py`,
    - Mehrkandidaten-Isolation,
    - parallele Supervisor-Aufrufe,
    - PID-/Heartbeat-Races,
    - Cross-Candidate-Journal-Verunreinigung,
    - defekte oder doppelte Lifecycles,
    - vollständige Flag-Matrix einschließlich fehlendem/false `CTB_PAPER_TRADING`.

### Aktueller Zustand

Beide bestehenden Reports sind weiterhin **nicht promotion-fähig**:

- `candidate_v77_trend_retest_anti_chase_long`: 0 Entries, 0 Exits.
- `research_v77_bear_trend_retest_short`: 0 Entries, 0 Exits.
- Die Runtime-Health-Journale zeigen erfolgreiche Scans mit vier geladenen Coins und weiterhin:
  - `paper_trading=true`
  - `live_order_allowed=false`
  - `mainnet_signed_action=false`
- Die Signale werden momentan vollständig durch Strategie-, TradingView- und Confluence-Gates blockiert.

## Minimaler sicherer Integrationsplan

1. **Eine versionierte Kandidaten-Registry im Repository einführen**
   - Pro Kandidat mindestens:
     - `strategy_id`
     - `side`
     - `strategy_version`
     - Konfigurations-/Parameter-Fingerprint
     - Coins
     - `paper_only=true`
     - Runtime- und Reportertyp
   - Runtime, Intent-Erzeugung, Supervisor und Reporter müssen dieselbe Registry verwenden.
   - Keine frei übergebbaren IDs und kein bloßes Ergänzen der Supervisor-Tuple.

2. **Runtime auf Kandidatenidentität härten**
   - `build_intent()` muss die erwartete `strategy_id` aus dem validierten Candidate-Spec übernehmen.
   - Beim Start zwingend verlangen:
     - `CTB_PAPER_TRADING=true`
     - alle Live-/Order-/Signed-Flags exakt `false`.
   - Candidate-ID, Version und Config-Fingerprint in State sowie jedem Journal-Datensatz persistieren.
   - Jeder Kandidat behält ein eigenes Runtime-Verzeichnis; keine geteilten State- oder Journals.

3. **Supervisor vor Erweiterung absichern**
   - Supervisorlogik in ein testbares Repo-Modul verschieben; das Hermes-Skript bleibt nur dünner Launcher.
   - Pro Kandidat atomarer Lock.
   - PID plus `/proc/<pid>/stat`-Startzeit und frischen Runtime-Heartbeat prüfen.
   - Bei unklarer Prozesslage **nicht neu starten**, sondern Warnung ausgeben.
   - Startkommando und Environment vollständig aus der validierten Registry ableiten.
   - Bestehende Cron-/Prozesskonfiguration zunächst unverändert lassen.

4. **Promotion Report kandidatenfest machen**
   - Erwartete Strategie-ID, Version und Config-Fingerprint als Pflichtparameter.
   - Nur vollständig gepaarte, einmalige Entry→final Exit-Lifecycles zählen.
   - Teil-Exits nicht als geschlossene Lifecycles zählen.
   - Ungültige, fremde oder doppelte Zeilen als Integritätsblocker ausweisen.
   - Defekter/fehlender State, stale Health oder aktive/unklare Prozesse blockieren Promotion.
   - Report weiterhin ausschließlich als „manueller Vorschlag“ ausgeben; niemals Execution Grant.

5. **Neue Kandidaten gestaffelt aufnehmen**
   - Zuerst Registry und Tests mit deaktivierten Kandidaten.
   - Danach manueller Einzelscan je Kandidat in temporärem Runtime-Root.
   - Erst nach erfolgreicher Isolation und Reportprüfung Kandidaten für Supervisor-Beobachtung freigeben.
   - Keine gleichzeitige Änderung an Cron, Live-Modus oder Promotion-Gates.

## Erforderliche Teststellen

- **Strategie/Registry**
  - eindeutige IDs und Verzeichnisse,
  - korrekte Richtung und Parameter je Kandidat,
  - Intent enthält exakt die Candidate-ID,
  - unbekannte/deaktivierte Kandidaten werden verweigert.

- **Paper-Sicherheit**
  - parametrischer Test für jedes Live-/Signed-Flag,
  - Kombinationen mehrerer Flags,
  - `CTB_PAPER_TRADING` fehlt oder ist `false`,
  - Nachweis, dass kein Live-Executor oder Signed-Client aufgerufen wird.

- **Runtime-Isolation**
  - drei Kandidaten mit gleichem Datenfenster schreiben in getrennte Verzeichnisse,
  - Restart/Resume behält nur eigenen State,
  - Duplicate-Window-Schutz pro Kandidat,
  - paralleler Writer wird verhindert.

- **Supervisor**
  - gesunder Prozess → kein Start,
  - tote PID → genau ein Start,
  - falsche ID oder unsichere Flags → Warnung, kein blinder Doppelstart,
  - fehlender/staler Heartbeat,
  - zwei gleichzeitige Supervisor-Aufrufe → höchstens eine Instanz,
  - Reportfehler beeinflusst keine anderen Kandidaten,
  - Alert-Zustände `false→true`, `true→true`, `true→false`.

- **Promotion Report**
  - fremde Candidate-ID oder Version,
  - Config-Fingerprint-Wechsel,
  - doppelte Exits und fehlende Entries,
  - Partial Exit plus finaler Exit,
  - beschädigte/trunkierte JSONL-Zeile,
  - beschädigter State,
  - offene Positionen,
  - stale Runtime,
  - Gate-Grenzwerte bei 49/50 und 29/30 Lifecycles,
  - Kandidatenberichte bleiben gegenseitig vollständig isoliert.

- **Reporting-Integration**
  - Entweder v77-Adapter für die allgemeine Scorecard testen oder v77 dort ausdrücklich ausschließen und nur den Promotion Report als kanonisch dokumentieren.

## Hauptrisiken

1. **Doppelte Prozesse und Journal-Korruption** durch fehlende Locks/PID-Races.
2. **Falsche Attribution** durch hart codierte Intent-IDs und Reports ohne `strategy_id`-Validierung.
3. **Falsch-positive Promotion** durch doppelte/unpaarige Exits, still übersprungene JSON-Fehler oder defekten State.
4. **Statistische Vermischung** bei wiederverwendeter `strategy_version` trotz geänderter Kandidatenparameter.
5. **Reporting-Fragmentierung** zwischen v77-Direktjournals und `Tradeanalyse/`-Scorecard-Pfad.
6. **Ressourcen-/API-Last** wächst linear mit Kandidaten, da jeder Prozess separat identische OHLCV/L2-Daten abruft.
7. **Zu geringe Trade-Frequenz**: Die bestehenden Kandidaten haben trotz gesunder Scans noch keine Entries; weitere streng gefilterte Kandidaten könnten lange keine belastbare Stichprobe erzeugen.

## Read-only-Nachweis

- Keine Dateien erstellt oder verändert.
- Keine Cronjobs oder Prozesse geändert.
- Keine Tests ausgeführt, da Pytest Cache-/Artefaktdateien erzeugen könnte.
- Git-Arbeitsbaum war sauber; Branch ist gegenüber Remote um einen Commit voraus.