breakout_k mit vollem Live-Gate-Stack gemessen

Nachgeholt, was in der Vollpruefung offen blieb: die ungegatete Messung zeigte
k=0,5/0,8/1,0 besser als den Live-Wert 0,3 - aber ohne min_conf, HTF-Filter und
Entry-Raum. backtest_breakout_gated.py schliesst die Luecke mit den ECHTEN
Methoden (_build, _confirm_breakout-Mechanik, _room_gate mit kausalen M5-Pivots).

  k=0,0  H1 -0,173/-193   H2 +0,003/  +7
  k=0,2  H1 -0,185/-149   H2 -0,012/ -16
  k=0,3  H1 -0,160/-122   H2 -0,036/ -47   (LIVE)
  k=0,5  H1 -0,127/ -85   H2 -0,041/ -47
  k=0,8  H1 -0,101/ -54   H2 -0,012/ -11
  k=1,0  H1 -0,096/ -45   H2 -0,016/ -12

Bestaetigt: k=0,5/0,8/1,0 schlagen 0,3 in BEIDEN Haelften, die Nachbarn halten
mit, und die OR verbessert sich in H1 monoton - also nicht nur
Handelsvermeidung. Die vorab fixierte Regel ist erfuellt.

TROTZDEM keine Umstellung empfohlen, und der Grund ist kein Messfehler sondern
eine Zweckfrage: alle Werte bleiben negativ (PF 0,70-1,01), das Gate begrenzt
Schaden statt Edge zu erzeugen; der Auto-Signal-Pfad ist ohnehin aus, das Signal
ist ein Vorschlag fuer den Menschen, und dessen gemessener Vorteil entstand auf
der k=0,3-Population; k=0,8 kuerzt die Empfehlungen um ~39 % und treibt den
WARTEN-Anteil weiter hoch, der mit 93 % ohnehin im Fokus steht.

Zwei benannte Abweichungen der Simulation:
- _confirm_breakout misst seinen Timeout mit time.time() gegen 3600 s. Im
  Bar-Loop vergeht keine Wall-Clock-Zeit, der Timeout wuerde nie feuern. 3600 s
  sind auf M5 exakt 12 Bars, so wird gezaehlt. Merke: jede time.time()-Messung
  im Live-Code ist in einer Bar-Simulation stumm.
- hour=None, weil die EIA-Pruefung in _build ueber datetime.now(_BERLIN) laeuft -
  mit Bar-Stunde wuerde ein Lauf am Mittwoch 15:30-16:30 alle Bars blocken.

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

CLAUDE.md

@@ -2837,6 +2837,44 @@ reine Handelsvermeidung noch ein echter Bestwert; (c) gemessen wurde das
 davor. **Nächster Schritt wäre eine GEGATETE Neumessung**, bevor ein Live-Gate
 angefasst wird, das 63 % der WARTEN-Zustände erzeugt.
 
+**Phase 2a-II — die GEGATETE Messung, nachgeholt (`backtest_breakout_gated.py`):**
+Voller Live-Stack über die ECHTEN Methoden — `_build` (Totband · M30-Filter ·
+Anti-Überdehnung · Winkel · min_conf 55 · Reversal AUS), Breakout-Bestätigung
+1:1 aus `_confirm_breakout`, `_room_gate` mit echten kausalen M5-Pivots.
+| k | H1 ØR / ΣR | H2 ØR / ΣR |
+|---|---|---|
+| 0,0 (Gate aus) | −0,173 / −193 | +0,003 / +7 |
+| 0,2 | −0,185 / −149 | −0,012 / −16 |
+| **0,3 (LIVE)** | **−0,160 / −122** | **−0,036 / −47** |
+| 0,5 | −0,127 / −85 | −0,041 / −47 |
+| 0,8 | −0,101 / −54 | −0,012 / −11 |
+| 1,0 | −0,096 / −45 | −0,016 / −12 |
+**Bestätigt: k=0,5/0,8/1,0 schlagen 0,3 in BEIDEN Hälften**, die Nachbarn halten
+mit (0,8 und 1,0 nebeneinander) — die vorab fixierte Regel ist erfüllt. Auch die
+ØR verbessert sich in H1 monoton (−0,185 → −0,096), es ist also nicht nur
+Handelsvermeidung.
+⚠ **TROTZDEM keine Umstellung empfohlen — der Grund ist kein Messfehler, sondern
+eine Zweckfrage:** (a) **alle** Werte bleiben negativ (PF 0,70–1,01); das Gate
+begrenzt Schaden, es erzeugt keinen Edge. (b) Der Auto-Signal-Pfad ist ohnehin
+AUS — das Signal ist ein **Vorschlag für den Menschen**, und dessen gemessener
+Vorteil (+118 €/WR 56 % bei MIT-Signal-Trades) entstand auf der **k=0,3-Population**.
+(c) k=0,8 kürzt die Empfehlungen um **~39 %** (H1 n=766 → 531) und treibt den
+WARTEN-Anteil weiter hoch — der steht mit 93 % live ohnehin schon im Fokus, und
+`breakout_pending` ist bereits die Ursache von 63 % aller Blocks.
+**Vor einer Änderung ist zu klären, WOFÜR das Signal da ist:** als mechanischer
+Auto-Entry wäre k=0,8 die belegte Wahl; als Auswahl-Angebot für den Menschen ist
+weniger Auswahl nicht automatisch besser. Die Zahlen liegen vor, die Entscheidung
+ist eine Nutzungs-, keine Messfrage.
+⚠ **Zwei benannte Abweichungen der Simulation** (beide unvermeidbar):
+(1) `_confirm_breakout` misst seinen Timeout mit `time.time()` gegen
+`_breakout_timeout_s`=3600 s — in einem Bar-Loop vergeht keine Wall-Clock-Zeit,
+der Timeout würde NIE feuern. 3600 s sind auf M5 exakt **12 Bars**, so wird hier
+gezählt. **Merke: jede `time.time()`-Messung im Live-Code ist in einer
+Bar-Simulation stumm.** (2) `hour=None`, weil die EIA-Prüfung in `_build` über
+`datetime.now(_BERLIN)` läuft — mit Bar-Stunde würde ein Lauf am Mittwoch
+15:30–16:30 **alle** Bars blocken. `dead_hours` ist live leer, es fehlt also nur
+das EIA-Fenster.
+
 **Phase 2b — verworfene Modelle bei vollen Bars nachgefahren: ALLE bleiben verworfen.**
 14 Klassen, keine einzige kippt ins Positive:
 | Klasse | Ergebnis |