Squeeze-Trades bekommen den SL aus M5-ATR (User-Entscheidung), TP unveraendert

trader._calc_sl_tp bekommt die ATR-Zeitebene als Parameter (Default SL_TF =
M15); _send/_send_locked/open_long/open_short und place_stop reichen sie durch.
Gesetzt wird sie an genau zwei Stellen: engine._open bei source="auto_squeeze"
und _manage_squeeze_pending bei quelle="squeeze". Manuelle Trades und
Auto-Signal bleiben bei M15.

Grundlage backtest_sl_basis.py: auf Squeeze-Entries ist der Ertrag zwischen
beiden Basen ein Wash (alle Varianten innerhalb eines Standardfehlers), der
Worst-Case sinkt aber von -8,83 auf -2,44 xATR_M5 = Faktor 3. Auf der
Wellen-Population ist der weite M15-SL in BEIDEN Haelften besser - deshalb
bewusst keine globale Umstellung.

Die Multiplikatoren (1,8-2,2 xATR) sind nicht angefasst, nur die Zeitebene.

TP bewusst NICHT betroffen (User: "nur fuer SL, der TP soll mit dem Runner
mitwachsen"). Geprueft statt angenommen: der von _calc_sl_tp zurueckgegebene TP
wird von KEINEM Aufrufer gesendet, beide setzen nur req["sl"]. Das Ziel
verwaltet trailing.py dynamisch (3,5 x ATR der Wellen-Zeitebene). Warnkommentar
im Code, warum der TP dort nicht mit in die Order darf.

4 Szenarien getestet. Dabei eigene Fehlannahme korrigiert: ohne Pivot greift der
1,2-%-Fallback, der beim M15 vom MINDEST-Deckel aufgeweitet wird - die
2,2x-Obergrenze wird dort gar nicht erreicht.

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

CLAUDE.md

@@ -1211,7 +1211,30 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   Eine saubere Umsetzung wäre **quellen-abhängig** (`_calc_sl_tp` nutzt M5-ATR nur
   bei `source="auto_squeeze"`) — strukturell begründet (Breakout- gegen
   Pullback-Einstieg haben verschiedene Nachlauf-Dynamik), nicht data-mined.
-  **Nicht gebaut** — die Entscheidung über Tail-Risiko gehört dem User.
+  ✅✅ **GEBAUT & LIVE (2026-08-05, User-Entscheidung „für Squeeze-Trades: ja").**
+  `trader._calc_sl_tp(sym, otype, entry, atr_tf=None)` bekommt die ATR-Zeitebene als
+  Parameter (Default `SL_TF` = M15); `_send`/`_send_locked`/`open_long`/`open_short`
+  und `place_stop` reichen sie durch. Gesetzt wird sie an genau zwei Stellen:
+  `engine._open` (`source == "auto_squeeze"` → M5) und `_manage_squeeze_pending`
+  (`quelle == "squeeze"` → M5). **Alles andere — manuelle Trades, Auto-Signal —
+  bleibt unverändert bei M15.**
+  ⚠ **Die Multiplikatoren sind NICHT angefasst** (1,8–2,2×ATR): nur die Zeitebene
+  wechselt, aus der der ATR kommt. Der Log macht es sichtbar („… ATR aus M5").
+  ⚠⚠ **DER TP IST BEWUSST NICHT BETROFFEN** (User-Vorgabe: „nur für SL, der TP soll
+  mit dem Runner mitwachsen"). Geprüft statt angenommen: der von `_calc_sl_tp`
+  zurückgegebene TP wird von **KEINEM** Aufrufer gesendet — `_send_locked` und
+  `place_stop` setzen ausschliesslich `req["sl"]`. Das Ziel verwaltet
+  `core/trailing.py` dynamisch (`_TP_INIT_ATR`=3,5 × ATR der **Wellen**-Zeitebene)
+  und zieht es mit dem Lauf nach. Ein Warnkommentar im Code hält fest, warum der TP
+  dort nicht mit in die Order darf: er wäre sonst an die SL-Breite gekoppelt und
+  würde genau die Runner kappen, von denen der Squeeze lebt (43 % Treffer, Ertrag
+  im Tail).
+  Mit 4 Szenarien getestet (M5 kappt auf 2,2×ATR_M5=0,66 · M15 greift auf den
+  Mindest-Deckel 1,8×ATR=0,99 · M5 enger als M15 · SHORT spiegelbildlich).
+  ⚠ Beim Testen eine eigene Fehlannahme korrigiert: ohne Pivot greift der
+  1,2-%-Fallback, der beim M15 vom **Mindest**-Deckel aufgeweitet wird — die
+  2,2×-Obergrenze wird dort gar nicht erreicht.
+  Zurück: die beiden `mt5.TIMEFRAME_M5`-Zuweisungen in `engine.py` auf `None`.
   ⚠ Das reproduziert NICHT `backtest_sl_tf_mismatch.py` (23.07., dort war M5 in H2
   schlechter): dort wurde am Bar-Close eingestiegen, hier am Level. Der
   Einstiegspreis hat den Befund gedreht.