Gesamtpruefung 2026-08-11: drei Defekte behoben

Zweiter vollstaendiger Durchlauf nach docs/review-prompt.md.

BEFUND 1: rec_outcomes war seit dem Einbau (06.08.) still tot - 0
Zeilen in 5 Tagen. _run_analysis las s.get("pb_feats"), aber s ist der
MT5Data-Snapshot; pb_feats lebt im Wave-Snapshot. _atr also immer 0,0
und die Schreibbedingung nie erfuellt. Kein NameError (ruff sieht
nichts), und das umgebende except loggt auf DEBUG. Aufgefallen nur,
weil die Tabelle mit 0 Zeilen neben ihren Schwestern stand.
Generalisiert als measurement_reminder.telemetrie_puls(): jede
Telemetrie-Tabelle muss einen Puls haben. Erster Lauf meldet genau
diesen Fund, alle uebrigen gruen.

BEFUND 2: der Divergenz-Waechter war selbst driftend. Abschnitt A
verglich gegen 43 % WARTEN - seit 05.08. ausdruecklich ungueltig (das
misst _build allein); richtig sind 80,5 %. Und entry_room galt als
"live-only", obwohl es seit 04./05.08. modelliert wird.
A: +50,8 Pp Warnung -> +13,3 Pp OK. B: 63,9 % -> 5,0 %.

BEFUND 3: P(break) ist wieder kalibriert (Delta -1,7 Pp nach +14,3 Pp
am 07.08.) - stuetzt den Schluss, dass die gewanderte Basisrate ein
Zeitraum-Effekt war.

Sauber: alle Standardpruefungen, 0 fehlende Frontend-IDs, mt5_lock,
Broker-Zeit, Race-Klasse. Performance: Snapshot-Median 15,9 ms, alle
heissen Abfragen ueber Index - keine Optimierung noetig.

Kein toter Code geloescht: die vermeintlich verwaisten Snapshot-Felder
sind Diagnose-Oberflaeche (vier davon heute zur Deploy-Verifikation
benutzt).

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

CLAUDE.md

@@ -6161,6 +6161,80 @@ Neumessung. Sie bleiben unverändert und reproduzierbar; wo ihre Schlussfolgerun
 relevant wird, gehört sie live-treu **neu gerechnet** (Muster:
 `backtest_auto_signal_norev.py`).
 
+## Gesamtprüfung 2026-08-11 (nach `docs/review-prompt.md`)
+
+Zweiter vollständiger Durchlauf. **Drei echte Defekte**, alle behoben; keine
+Strategie-Änderung.
+
+⚠⚠ **BEFUND 1 — `rec_outcomes` war seit dem Einbau (06.08.) STILL TOT: 0 Zeilen
+in 5 Tagen.** `engine._run_analysis` las `s.get("pb_feats")` — `s` ist aber der
+**MT5Data**-Snapshot (Preis/Trend/Konto); `pb_feats` lebt im **Wave**-Snapshot.
+Ergebnis: `_atr` immer 0,0 → die Schreibbedingung `_atr > 0` nie erfüllt.
+✅ **Live belegt:** `market` hat **kein** `pb_feats`, `wave` hat es (ATR 0,12).
+⚠ **Warum keine Prüfung es fing:** es ist **kein** `NameError` (ruff F821 sieht
+nichts), sondern ein falsches dict — syntaktisch einwandfrei. Und das umgebende
+`except` loggt auf **DEBUG**, der Logger steht auf INFO. Exakt die Fehlerklasse,
+vor der der `wave_snap`-Fallstrick vom 04.08. schon einmal gewarnt hat.
+✅ Aufgefallen NUR, weil die Tabelle in Durchgang 4 mit 0 Zeilen **neben ihren
+Schwestern** stand (`m15_states` 3.143 · `cone_checks` 263 ·
+`pbreak_predictions` 3.775). Damit hat die Selbst-Kalibrierung der Empfehlung
+fünf Tage lang nichts gemessen.
+✅✅ **GENERALISIERT: `measurement_reminder.telemetrie_puls()`** — jede
+Telemetrie-Tabelle muss einen PULS haben; schweigt eine, während die anderen
+schreiben, ist der Logger tot. 7 Tabellen überwacht, Toleranz Faktor 20 der
+erwarteten Kadenz (ein Wächter, der oft warnt, wird ignoriert). ⚠
+`candles_m1.time` ist ROHE Brokerzeit → Offset abgezogen, sonst 3 h Fehlalarm.
+**Erster Lauf meldet genau diesen einen Fund**, alle übrigen grün.
+
+⚠⚠ **BEFUND 2 — DER DIVERGENZ-WÄCHTER WAR SELBST DRIFTEND.** Er verglich
+Abschnitt A gegen **43 % WARTEN** — ein Maßstab, den CLAUDE.md seit dem
+**2026-08-05 ausdrücklich für ungültig erklärt** (`backtest_dist.py` misst
+`_build` ALLEIN, ohne Breakout-Bestätigung und Entry-Raum-Gate; mit vollem
+Live-Stack sind es **80,5 %**). Zusätzlich zählte er `entry_room` als
+„live-only", obwohl es seit dem 04./05.08. in `backtest_breakout_gated.py` mit
+dem **echten** `_room_gate` modelliert wird.
+| | vorher | nachher |
+|---|---|---|
+| A) Abweichung WARTEN | **+50,8 Pp ⚠** | **+13,3 Pp OK** |
+| B) „Nur-Live-Gates" | **63,9 %** | **5,0 %** |
+Der Wächter behauptete also einen Deployment-Drift, den es dort nicht gibt —
+und „ein Wächter, der immer warnt, wird ignoriert" ist die eigene Lehre vom
+02.08. (damals für die Modell-Epochen, hier für die Konstanten).
+
+✅ **BEFUND 3 — P(break) ist wieder kalibriert.** Δ **−1,7 Pp** (Vorhersage
+40,4 %, real 38,7 %, n=106 entkoppelt) nach **+14,3 Pp** am 07.08. Das stützt
+den damaligen Schluss, dass die „gewanderte Basisrate" ein **Zeitraum-Effekt**
+war, kein Modellversagen.
+
+**Sauber (keine Befunde):** `check_nfalle` · `ruff F821` · 53 Tests ·
+`node --check` · **0 fehlende Frontend-IDs** von 93 · der einzige Thread-Aufruf
+von `refresh_market` nimmt `mt5_lock` selbst · alle `.time`-Nutzungen sind
+Vergleiche unter Broker-Zeiten oder die dokumentierte `candles_m1`-Ausnahme ·
+die 3 Ticket-Wechsel-Blöcke haben ihre Retry-Wächter · TF-Churn Median 23 min.
+
+**Performance:** Snapshot-Median **15,9 ms** (p90 19,4), gegen 13 ms am 02.08. —
+der Zuwachs deckt sich mit den seither gebauten Feldern und liegt weit unter dem
+1-s-Budget. Alle heißen Abfragen laufen über einen Index (`recommendations`
+1,2 ms · `candles_m1` über den PRIMARY KEY 1,9 ms · `trades` 0,1 ms).
+**Keine Optimierung nötig** — Micro-Tuning ohne Messung wäre hier wertlos.
+
+⚠ **Toter Code: keine Löschempfehlung.** 13 Snapshot-Felder haben keinen Leser
+in `app.js` — davon habe ich am selben Tag **vier** benutzt, um Deployments zu
+verifizieren (`close_notify_min`, `squeeze_pending`, `squeeze_night_hours`,
+`squeeze_max_chase_atr`). Der Snapshot ist die **Diagnose-Oberfläche** und laut
+`tools/deploy.py` Schritt 4 der einzige belastbare Beweis, dass neuer Code
+läuft — sie zu entfernen würde die Verifikation kaputtmachen. Einzig
+`cost_ratio` ist ein echter Waise (speiste den Kosten-Chip in `vd-consensus`,
+den es nicht mehr gibt); er kostet eine Division und bleibt.
+⚠ **Bekannt und unverändert:** 47 Backtests haben eine eigene Exit-Kopie (36
+nutzen `core/exit_model`), `_atr_series` existiert in **86** Dateien. Umstellen
+verletzt die Migrations-Regel — ihre publizierten Zahlen würden sich
+verschieben. Alle 2026-08-11 neu gebauten Skripte nutzen den geteilten Kern.
+⚠ **Benannt, nicht geändert:** `auto_squeeze` steht in `runtime_state.json` auf
+`false`, in der ini auf `true`. Verhalten ist korrekt (runtime gewinnt), der
+Zustand aber irreführend — wird `runtime_state.json` gelöscht, schaltet sich der
+autonome Einstieg wieder ein. **User-Entscheidung vom 11.08., 14:10.**
+
 ## Gesamtprüfung 2026-08-02 (nach `docs/review-prompt.md`)
 
 Erster vollständiger Durchlauf des Review-Prompts. **Keine Strategie-Änderung** — alle