Entry-Raum-Gate zurück auf 0,6 (User: zu viel WARTEN)

Am selben Tag von 1,0 auf 0,6 zurück — gemischtes Regime (M15/M30 ab, M5/H1
auf) erzeugte gefühlt zu viele WARTEN-Phasen. 0,6 vs 1,0 = Frequenz-gegen-Edge,
gemessen 1,0 netto besser; User priorisiert Frequenz.

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

CLAUDE.md

@@ -222,9 +222,9 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   = späterer Einstieg, Anfang des Moves verschenkt). ⚠ Ein-Stichproben-Lauf hatte
   „1,0 besser" gezeigt — Split-Prüfung drehte das (B2!). Nebeneffekt: kürzere
   „warte auf Breakout"-Phasen.
-- **Entry-Raum-Gate (AKTIV, `[trading] entry_room_atr=1.0` — 0,6→1,0 am
-  2026-07-24, gemessen `backtest_entryroom.py` 2026-07-16):** Richtungssignal →
-  WARTEN, wenn das
+- **Entry-Raum-Gate (AKTIV, `[trading] entry_room_atr=0.6` — kurz 1,0, am selben
+  Tag zurück auf 0,6, s. u.; gemessen `backtest_entryroom.py` 2026-07-16):**
+  Richtungssignal → WARTEN, wenn das
   **Gegenlevel** (M5-Pivot in Trade-Richtung, trainingsgleich zum S/R-Auto-Close)
   näher als X×ATR_M5 liegt. Befund (seq. Sim MIT S/R-Close-Exit, Echtkosten,
   2 Halbjahre): **monoton in BEIDEN Hälften** — Raum <0,3: ØR −0,119/−0,067
@@ -236,12 +236,15 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   4 der 5 sr_closes desselben Tages waren dagegen RETTER — Exit NICHT anfassen).
   Umsetzung: `wave._room_gate` (in `refresh_market` VOR `_confirm_breakout`;
   `set_entry_room`, Grund „kein Raum: Widerstand X nur 0,4×ATR entfernt …").
-  Backtests via `_build` bleiben gate-frei (kein pb_levels-State). **0,6→1,0
-  ausgerollt (2026-07-24, „baue alles ein"):** 1,0 war von Anfang an in BEIDEN
-  Hälften besser (H1 +415/H2 +266 R); der konservative 0,6-Start diente nur der
-  Frequenz (~¾ der Signale gefiltert → deutlich mehr WARTEN). Live-Kurzcheck vor
-  dem Rollout: S/R-Closes seit 16.07. +925 € bei nur noch 28 % Klein-Closes (<5 €)
-  — Gate wirkt wie gemessen. ⚠ **P(break)-Freigabe des Gates = VERWORFEN (gemessen
+  Backtests via `_build` bleiben gate-frei (kein pb_levels-State). **0,6→1,0→0,6
+  (2026-07-24):** kurz auf 1,0 erhöht (gemessen in BEIDEN Hälften besser, H1 +415/
+  H2 +266 R; Live-Kurzcheck: S/R-Closes seit 16.07. +925 € bei nur 28 % Klein-Closes)
+  — aber der User empfand im gemischten Regime (M15/M30 ab, M5/H1 auf) **zu viel
+  WARTEN** und stellte noch am selben Tag auf 0,6 zurück. ⚠ Lehr-Fall dabei
+  festgehalten: „kein LONG trotz steigendem Kurs" lag NICHT am Raum-Gate, sondern am
+  **M30-Gegen-Trend-Filter** (M30 ab → LONG unterdrückt, gewollt); das Raum-Gate
+  mutete nur den daraus resultierenden SHORT (Support 0,09×ATR entfernt). 0,6 vs 1,0
+  ist reiner Frequenz-gegen-Edge-Kompromiss (gemessen 1,0 netto besser). ⚠ **P(break)-Freigabe des Gates = VERWORFEN (gemessen
   `backtest_entryroom_pbreak.py`, 2026-07-24):** Idee war, Raum<1,0-Signale
   durchzulassen, wenn P(break)@Entry hoch (Level bricht eh → Ertrag nicht gedeckelt).
   Das Modell TRENNT zwar auch am Entry (Freigabe-Gruppen klar besser als der Rest),

core/config.py

@@ -317,7 +317,7 @@ DEFAULT_CONFIG = {
         # 1,0 war von Anfang an in BEIDEN Hälften besser (H1 +415/H2 +266 R), Start
         # 0,6 war nur die konservative Stufe (1,0 filtert ~¾ der Signale → deutlich
         # mehr WARTEN-Phasen; gemessen trotzdem mehr Gesamtertrag).
-        "entry_room_atr": "1.0",
+        "entry_room_atr": "0.6",
         # Tageszeit-Gate: Komma-Liste der Stunden (Berlin), zu denen die Wellen-
         # Empfehlung WARTEN erzwingt. **Gemessener Default = 0–7,12,16** (Nacht-
         # Kostenfalle + 12/16 Uhr beidhälftig negativ, `backtest_hourly_split.py`).

oil_widget_config.ini.example

@@ -30,7 +30,7 @@ tf_select = heuristic
 tf_min = M5
 tf_max = M30
 breakout_k = 0.3
-entry_room_atr = 1.0
+entry_room_atr = 0.6
 dead_hours =
 auto_squeeze = true
 auto_squeeze_skip_night = true