M15-Karte "Setup-Bereitschaft" gebaut - Ersatz der Gesamtempfehlung (v=153)

Nach drei negativen M15-Messungen (Squeeze-Einstieg, VWAP-Baender, Exit-ATR)
steht fest: auf M15 traegt keine Richtungsquelle. Gebaut ist deshalb bewusst
KEINE Empfehlung, sondern eine sequenzielle Gate-Kette:

  [1 HTF-BIAS M30/H1] -> [2 KOSTEN Spread/ATR_M15] -> [3 LEVEL & KEGEL]
  -> Order AM LEVEL

Der Unterschied zur alten Karte ist grundsaetzlich: dort wurden Stimmen zu einem
Bias VERRECHNET (gemessen 48-51 % Treffer), hier muss jedes Gate EINZELN
passieren. Ein gefallenes Gate laesst sich nicht durch ein anderes ausgleichen.

Nur belegte Bausteine: HTF-Trend (einziger robuster Filter, Edge x2), Kosten
(M15 gemessen 0,104 gegen M5 0,193), naechstes stehendes Level + P(break),
Kegel (out-of-sample kalibriert, 80-%-Band trifft 77 %), Veto (-6,60 EUR/Lot).

Status-Banner: SETUP BEREIT / WARTEN AUF LEVEL / KEIN TRADE. Es bestaetigt
ausdruecklich auch das NICHT-Handeln - die gemessene Kern-Leckage sind
diskretionaere Abweichungen.

Die Order-Buttons werden BEWUSST NICHT gesperrt (gegen den Vorschlag
"ausgrauen"): hartes Blockieren wurde im Projekt verworfen, und
User-Uebersteuerungen liefen gemessen 68 % WR.

Umsetzung: engine._m15_setup() setzt nur zusammen, was der Snapshot ohnehin
erzeugt. Neu gerechnet wird allein das M15-Kosten-Verhaeltnis und P(break) fuer
das naechste Level. Dafuer veroeffentlicht wave_rec jetzt tf_atr (ADDITIV) - der
ATR je Zeitebene wurde im Turn-Fetch laengst berechnet, war aber nirgends
abrufbar.

P(break)-Merkmale bleiben auf M5 (Modell ist darauf trainiert, Fix 2026-07-13).

Mit 5 Szenarien getestet (alles passt, Bias uneinig, Kosten teuer, Level zu
weit, Kaltstart ohne ATR_M15 -> kein Absturz), live verifiziert ueber
deploy.py --feld m15_setup.

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

CLAUDE.md

@@ -4182,7 +4182,7 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   („⚠ die Welle (steuert die Order) schweigt").
   Live gegengerechnet, beide Zeilen erscheinen wie beabsichtigt.
   ⚠ Reine Anzeige — an Gewichten, Gates und Order-Logik ist nichts geändert.
-- Asset-Version aktuell **v=151** (in `web/index.html` hochzählen, siehe Workflows).
+- Asset-Version aktuell **v=153** (in `web/index.html` hochzählen, siehe Workflows).
   Schriftgrößen 2026-07-24 global **+4px** (2× je +2px auf User-Wunsch; Body-Basis
   14→18px). ⚠ Betrifft in `style.css` sowohl `font-size:Npx` (71×) ALS AUCH die
   `font:<weight> Npx/…`-**Shorthand** (3×: `.ms-chip`/`.ms-bos-lbl`/`.sqm-badge` —
@@ -4942,6 +4942,45 @@ Modell schliesst keine Trades.
 „die Rangfolge ist kaputt" ist **nicht** belegt; belegt ist nur die
 Basisraten-/Kalibrierungslücke.
 
+## ✅ M15-KARTE „SETUP-BEREITSCHAFT" GEBAUT (2026-08-08, v=153) — Ersatz der Gesamtempfehlung
+
+Nach dem Entfernen der Gesamtempfehlung und drei negativen M15-Messungen
+(Squeeze-Einstieg, VWAP-Bänder, Exit-ATR) steht fest: **auf M15 trägt keine
+Richtungsquelle.** Gebaut ist deshalb bewusst **keine Empfehlung**, sondern eine
+**sequenzielle Gate-Kette** nach dem Schema des Users:
+```
+[① HTF-BIAS M30/H1] → [② KOSTEN Spread/ATR_M15] → [③ LEVEL & KEGEL] → Order AM LEVEL
+```
+⚠ **Der Unterschied zur alten Karte ist grundsätzlich**: dort wurden Stimmen zu
+einem Bias **verrechnet** (gemessen 48–51 % Treffer über 1.071 Episoden), hier
+muss jedes Gate **einzeln** passieren. Ein gefallenes Gate lässt sich nicht durch
+ein anderes ausgleichen.
+
+**Nur BELEGTE Bausteine:** ① HTF-Trend (einziger robuster Filter, Edge ×2) ·
+② Kosten (M15 gemessen **0,104** gegen M5 0,193 — hier gewinnt M15 wirklich) ·
+③ nächstes STEHENDES Level aus `_draw_levels` + P(break) · ④ Kegel
+(out-of-sample kalibriert, 80 %-Band trifft 77 %) · ⑤ Veto (gegen das Signal
+−6,60 €/Lot, beidhälftig).
+**Status-Banner:** 🟢 SETUP BEREIT @ Level · 🟡 WARTEN AUF LEVEL · 🔴 KEIN TRADE.
+⚠ Das Banner bestätigt ausdrücklich auch das **Nicht**-Handeln — die gemessene
+Kern-Leckage sind diskretionäre Abweichungen, nicht verpasste Gelegenheiten.
+⚠⚠ **Die Order-Buttons werden BEWUSST NICHT gesperrt** (gegen den Vorschlag
+„ausgrauen"): hartes Blockieren wurde im Projekt verworfen, und
+User-Übersteuerungen liefen gemessen **68 % WR**. Sichtbar machen, nicht
+bevormunden.
+
+**Umsetzung:** `engine._m15_setup()` setzt nur zusammen, was der Snapshot ohnehin
+erzeugt; NEU gerechnet wird allein das M15-Kosten-Verhältnis und P(break) für das
+nächste Level. ⚠ Dafür veröffentlicht `wave_rec` jetzt **`tf_atr`** (ADDITIV) —
+der ATR je Zeitebene wurde im Turn-Fetch längst berechnet, war aber nirgends
+abrufbar; ihn neu zu holen wäre ein zweiter MT5-Fetch für vorhandene Zahlen
+(derselbe Fehler wie beim Konsens-Pfeil).
+⚠ P(break)-Merkmale bleiben auf **M5** — das Modell ist darauf trainiert (Fix
+2026-07-13); auf M15 umzustellen würde es falsch skalieren.
+Mit **5 Szenarien getestet** (alles passt · Bias uneinig · Kosten teuer · Level
+zu weit · Kaltstart ohne ATR_M15 → kein Absturz), live verifiziert über
+`deploy.py --feld m15_setup`.
+
 ## ⚠⚠ EXIT-ABSTAND AUS M15-ATR = FÄLLT DURCH (2026-08-08)
 
 Zweiter Teil der M15-Idee: M5-Einstieg behalten, nur den EXIT gröber führen.