AH-Oil-Trader/CLAUDE.md

# CLAUDE.md — Oil Trading Bot (MT5, WTI)

Projektleitfaden für Claude Code. Antworten/UI-Texte auf **Deutsch**.

> 🔄 **Pflege-Regel:** Diese Datei nach **jeder** inhaltlichen Änderung
> mitaktualisieren (geänderte Logik/Werte, neue Module/Endpoints, UI-/Alarm-
> Verhalten, Config-Schalter, Workflows, Asset-Version `v=N`). Kein separater
> Auftrag nötig — Teil jeder Aufgabe.
>
> 🧱 **5-Layer-Prozess bei jeder Änderung** (Daueregel, in dieser Reihenfolge):
> **L1** Kontext, Befunde **& Risiko/Auswirkung** (offene Befunde hier · „erst
> messen" bei Strategie · was kostet/ändert es — EUR-Risiko/Trade, reversibel?) ·
> **L2** Code-Analyse & Design (Datenquelle, *Quelle der Wahrheit*, wo lebt die
> Logik) · **L3** UI-Design (Module klar in Text **und** Grafik, auf dem geklärten
> Datenmodell) · **L4** Implementieren, Verifizieren **& Rollout** (`py_compile` ·
> JS-Klammern · Backtest/Test · Version-Bump `v=N` · Aktivierungsweg `restart_server.bat`
> · **Backup vor destruktiven Schritten**, v. a. DB) · **L5** Doku aktualisieren
> (`docs/` **und** CLAUDE.md, zuletzt).
>
> ⚖ **Layer an die Größe der Änderung skalieren** — nicht jede Aufgabe braucht alle
> 5. Strategie-Änderung = alle 5 (inkl. Backtest); reine Anzeige = L2–L5 light (kein
> Backtest); Doku-Korrektur = nur L5. Prozess soll helfen, nicht zur Bürokratie werden.
>
> 🔬 **Track B — Strategie-Lebenszyklus** (ZUSÄTZLICH zu L1–L5, für ALLES, was den
> **Edge** berührt: Signal, Risk/Sizing, Exit, Gate, Filter). Track A = L1–L5
> (Code/UI/Infra) bleibt unverändert; Track B läuft *parallel* für Strategie-Ideen:
> **B1 Hypothese + Hebel-Check** — welcher Hebel? *Signal = klein* (6× belegt: Filter
> tragen kaum → **höhere Beweislast**, im Zweifel gar nicht bauen) vs. *Sizing/Exit =
> groß* (dort liegt das Geld). · **B2 2-Stichproben-Backtest** — IMMER ≥2 Zeiträume/
> Regime, nie eine (Dead-Hour-Lektion: Std 13 war in einer Stichprobe „profitabel",
> in der zweiten Rauschen; `backtest_hourly_split.py`). · **B3 Kosten-Check** — Ø-Edge
> **netto > ~0,1×ATR** (real Spread+Komm.)? sonst raus. · **B4 Live-klein + Monitor** —
> ausrollen, dann **Live-WR/PF/Verhältnis** (Statistik-live-Kachel `stats_compact` +
> Flip-Zähler) **gegen die Backtest-Erwartung** halten; Kadenz **wöchentlich** (Termin,
> keine Stufe). · **B5 Behalten oder Verwerfen** — driftet es live weg (Regimewechsel)
> → **zurückbauen, kein Ego.** B4/B5 = die Verfall-Erkennung, die im reinen „Änderung
> machen"-Prozess fehlt (Trading ≠ Software: Edge kann verfallen).
>
> 🧾 **B0 — Handels-Checkliste (Mensch, vor jedem manuellen Trade):** (1) **nicht gegen
> das Signal** (gemessen WR 14 %); (2) **Notfall-Stop gesetzt?**; (3) **Gewinner läuft
> das Trailing** (nicht früh kappen — Ø-Verlust ≫ Ø-Gewinn ist die Kern-Leckage). Steuert
> die eigentliche Verlustquelle (diskretionäre Abweichungen), die kein Code-Layer erreicht.

## Was das ist
Algorithmischer **WTI-Öl-Trading-Bot** auf MetaTrader 5. (Brent-Umstellung am
2026-07-09 auf User-Wunsch **noch am selben Tag zurückgenommen** — falls je wieder
Brent: Pepperstone-Symbol heißt `SpotBrent`, kein „UKOIL"; breakout_k=0,3 wurde
dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
- **`server.py` + `core/engine.py`** — headless FastAPI-Web-Backend für die
  **Mobile-PWA** in `web/` (Zugang vom Handy via WireGuard, `192.168.188.100:8000`).

> Das frühere Tkinter-Widget (`oil_trading_agent.py`, `ui/`, `single_instance.py`)
> wurde **entfernt** — nur noch der Server. ⚠ Immer nur **EINE** Server-Instanz
> gegen dasselbe MT5-Terminal laufen lassen (zwei TrailingManager = Konflikt).

## Architektur (core/)
- `mt5data.py` Preis/Trend/Konto · `trader.py` Orders+SL/TP · `trailing.py`
  Trailing/Teil-Exit · `wave_rec.py` **Empfehlung** · `elliott.py` EW/FVG ·
  `tu_rating.py` TradersUnion · `agent.py` KI-Copilot
  (LLM) · `daily_levels.py` Tages-Prognose (Web) · `gaps.py` D1-Kurslücken ·
  `mailer.py` Graph-E-Mail ·
  `structure.py` Marktstruktur (M30: HH/HL/LH/LL, BOS, Regressionskanal — reine
  Anzeige, kein Signal) · `candle_logger.py` M1-Candle-Log (Daten-Sammlung → `candles_m1`) ·
  `market_hours.py` Sessions · `history.py` SQLite · `config.py` Konstanten+
  `oil_widget_config.ini`-Loader · `mt5_utils.py` globaler `mt5_lock`.
- `engine.py` = headless Motor: instanziiert die core-Objekte, fährt Loops als
  Threads, liefert `snapshot()` für `/api/snapshot` + WebSocket `/ws`.
  `_verdict()` aggregiert die Module zur **Gesamtempfehlung** (`verdict` im
  Snapshot) — Doku: `docs/gesamtempfehlung.md`.

## Harte Fakten / Stolpersteine
- **MT5 ist Windows-only** (`MetaTrader5`-Wheel). Backend läuft auf Windows neben
  dem Terminal; nur Reverse-Proxy/HTTPS könnte auf Linux/Docker.
- **Brokerzeit = UTC+3.** `deal.time`/`tick.time` immer via `_broker_offset_s()`
  bzw. Live-Offset in UTC/Lokalzeit umrechnen.
- **`mt5_lock` (global, nicht reentrant):** alle MT5-Calls darüber, mit Timeout.
  Nicht aus einem bereits-gehaltenen Lock erneut `close()` (Deadlock). ⚠ Auch
  Thread-Pool-Jobs müssen den Lock nehmen: `M15Analyzer.analyze()` läuft im
  Executor → eigener `mt5_lock`-Wrapper in `mt5data._fetch_trend_locked` (sonst
  Race). `sr.detect()` läuft inline unter dem bereits gehaltenen Lock. Ebenso:
  `mt5data.reconnect()` (shutdown/initialize) und `trader._log_open`-`delayed_log`
  (positions_get im Thread) laufen jetzt unter `mt5_lock` (waren Races).
- **Steuer:** Broker behält **WHT 26,375 %** (DE-Abgeltungst.+Soli) je Gewinn ein
  (`WHT #…`-Buchungen), erstattet via tägl. „Tax settlement". Stats sind **brutto**;
  `[trading] wht_pct` zeigt eine Netto-Schätzung.
- **Python:** `C:\Users\ah\AppData\Local\Programs\Python\Python312\python.exe`
  (hat fastapi/uvicorn/MetaTrader5). System32 fehlte mal in der PATH → Skripte
  nutzen absolute Pfade.
- **LLM-Provider (Stand aktuell):** **DeepSeek (`[deepseek]`) ist der aktive
  Copilot-Provider** (`[agent] provider=deepseek`, 2026-07-20). `api.deepseek.com`,
  Modell **`deepseek-v4-flash`** (`/models` listet flash + pro; alte Namen
  `deepseek-chat/-reasoner` gibt es NICHT mehr). ⚠ v4-flash ist ein **Reasoning-Modell**
  (content nach `reasoning_content` → `max_tokens=4000` in `_call_deepseek`, sonst leer;
  temperature 0.3 ok, schnell ~6 s). **⚠ KEINE Web-Suche** → NICHT für `daily_levels`
  nutzbar. Fallback-Kette kimi→zai→local greift, wenn der Key ausfällt.
  **Kimi/Moonshot (`[kimi]`, `kimi-k2.6`)** bleibt als Provider verfügbar. Key nur auf dem
  **internationalen Endpoint `api.moonshot.ai`** gültig (`.cn` = „Invalid
  Authentication"). Modell **`kimi-k2.6`** (`/v1/models` listet auch k2.7-code/k3;
  k3 = thinking-only). ⚠ **Zwei Fallstricke:** (1) `temperature` MUSS **1** sein
  (andere Werte → HTTP 400); (2) k2.6 ist ein **Reasoning-Modell** → schreibt
  VARIABLE ~1000–1200 `reasoning_tokens` (in `message.reasoning_content`) VOR dem
  `content` → `max_tokens` großzügig (**4000**, `_call_kimi`), sonst frisst das
  Reasoning das Budget und `content` bleibt leer (2000 war teils leer). Moonshot
  cached den System-Prompt (`cached_tokens`) → günstiger bei Wiederholung. Kimi ist
  CN-Modell → CJK-Drift möglich, vom `_has_cjk`-Retry abgedeckt.
  Frühere Option **z.ai/GLM** (`[zai]`, `glm-4.5-flash`, kostenlos) bleibt
  reaktivierbar; ⚠ GLM ist Thinking-Modell → IMMER `"thinking":{"type":"disabled"}`.
  ⚠ **`_active_provider`-Fix 2026-07-20:** zai/kimi waren vorher NICHT in der
  `avail`/`orders`-Map → `provider=zai` fiel still auf `local` (qwen) zurück (die
  `[local]`-Logzeilen!). Jetzt beide routbar. OpenAI/Gemini-Keys = kein Guthaben (429).
  - **KI-Copilot (`agent.py`):** `[agent] provider=deepseek`. CN-/lokale Modelle
    (DeepSeek, Kimi, GLM, qwen) driften ins Chinesische → `_has_cjk`-Erkennung + 1×
    Retry deckt `local`, `zai`, `kimi` UND `deepseek` ab. (alle bleiben als Provider-
    Optionen wählbar.)
  - **`daily_levels.py` bleibt auf z.ai (2026-07-20, gemessen):** Die Tagesprognose
    BRAUCHT Live-Web-Suche. DeepSeek hat keine; Kimi-Web-Suche (`$web_search`-builtin)
    läuft nur über einen Tool-Loop, ist >2 min langsam und lief im Test in `finish=length`
    (Web-Ergebnisse+Reasoning sprengen selbst 4000 Tokens → leerer Content). z.ai macht
    es in EINEM sauberen `web_search`-Call → kein Wechsel (Kontext-Feature, kein Edge).
    ⚠ **S/R-Kontext-Fix 2026-07-15:** `_tool_zones` füttert dem LLM jetzt die **echten
    M5-Pivots** (`wave.pb_levels`, geclustert, nächste 3 je Seite) statt der stale
    `[zones]`-Config — plus Prompt-Leitplanke „nutze NUR die übergebenen Level, erfinde
    keine runden Marken". Reiner Kontext-Fix (keine Strategie): macht die Kommentar-Level
    aktuell/konsistent zum Chart, macht die LLM-Einschätzung aber NICHT validierter
    (Copilot bleibt unbelegte Verdict-Stimme, Gewicht nur bei Bias).
  - **Tages-Prognose (`daily_levels.py`):** z.ai + Web-Suche, 1×/Tag 07:30 Berlin.

## Workflows / Befehle
- **Änderungen aktivieren:** `restart_server.bat` (lädt core neu). Auto-Start:
  Aufgabe `OilTradingServer` (Login, versteckt via VBS).
  ⚠ **Startet seit 2026-07-30 BEIDE Server** (User-Vorgabe): erst das
  **Hyperliquid-Dashboard** (Port 8001, versteckt via dessen `start_hidden.vbs`,
  wartet max. 10 s aufs Lauschen), dann das Oil-Backend (8000) im Vordergrund.
  **Grund + behobener Bug:** die Kill-Zeile trifft mit `*server.py*` BEIDE Prozesse —
  vorher wurde der HL-Server bei jedem MT5-Neustart still mit-erschlagen und nie wieder
  gestartet. Das riss die **Lücken in die Lead-Lag-/Order-Flow-Datensammlung** (72 h
  Spanne, aber nur 2292 Samples) UND ließ die Liquiditätslinien im Chart verschwinden.
  Fail-safe: fehlt das HL-Projekt (`..\HyperLiquid-WTI Trader`), startet nur 8000 mit
  Hinweis. Auto-Start des HL-Servers separat: Aufgabe `HyperliquidDashboard` (Login).
- **Web-Assets:** Browser cacht hart → in `web/index.html` `?v=N` **hochzählen**
  bei jeder JS/CSS-Änderung; Server sendet `Cache-Control: no-store`. Hängt der
  Handy-Cache: Inkognito oder Seite mit frischem `?xN` öffnen.
- **Empfehlungs-Edge messen:** `python backtest_signal.py [TF] [N] [K]`
  (ereignisbasiert, nutzt die echte `_build`-Logik). Ø-Edge>0 = trägt.
- **Ausführungs-Kalibrierung:** `python analyze_execution.py` — (A) echtes
  Spread-Profil je Berlin-Stunde aus dem Bar-`spread`-Feld, (B) Slippage bei
  SL-Closes, (C) MAE/MFE der Live-Trades. **Kern-Befund 2026-07-13:** Spread ist
  absolut ~konstant (0,0225), aber relativ **Ø 0,265×ATR** — die alte
  Kostenannahme 0,1×ATR war v. a. in Niedrig-Vola-Phasen ~2,5× zu optimistisch
  (erklärt Live-PF < Backtest-Erwartung). Stunden 15–17 am günstigsten (~0,13),
  **Nacht 0–7 = Kostenfalle (0,32–0,50×ATR)**. Slippage-Tail real: die −35/−54-
  Desaster hatten 0,75 Slippage ÜBER den Initial-SL hinaus (harter SL deckelt in
  schnellen Märkten nicht). MAE/MFE live: Exits validiert (nur 7 % der Verlierer
  waren je ≥1,3×ATR im Plus → Breakeven-Schwelle passt; Gewinner-MAE Median 0,28).
  ⚠ Künftige B3-Checks mit **stunden-echten Kosten** rechnen, nicht pauschal 0,1.
  (WR/PF/Verhältnis/Worst je KW, Ausrichtungs-Split mit/gegen/ohne) gegen die
  Backtest-Erwartung (WR~68 % · PF~1,3 · Verh~0,55) und flaggt Leckagen (Gegen-Signal-
  Anteil, WR-Verfall, PF<1, Einzelverlust). **Wöchentlich** laufen lassen (B4/B5).
- **Vor „fertig":** immer `python -m py_compile <datei>`; JS grob via Klammern-
  Balance prüfen (kein node im Env).
- **Konsole:** UTF-8 erzwingen (`PYTHONIOENCODING=utf-8`, `-X utf8`).
- **Uvicorn-Access-Log AUS** (`access_log=False` in `uvicorn.run`, 2026-07-22): seit
  dem 4-s-REST-Polling + WS-Push flutete `GET /api/snapshot … 200 OK` die Konsole.
  Betrifft NUR Uvicorns eigenes Zugriffs-Log, nicht die `oil.*`-Logger (eigene
  Hierarchie, `core/logger.py`, unverändert in Konsole + Datei).

## Empfehlungs- & Trade-Logik (Stand aktuell)
- **Richtung = EMA12 vs EMA50** (`wave_rec.py`), NICHT mehr ZigZag-Momentum
  (das hatte ~0 Edge). Totband (Chop→WARTEN), Anti-Überdehnung
  (`_STRETCH_MAX=3,5×ATR`), +S/R-Konfidenz, +Session-Konfidenz. (TU **entfernt** —
  s. u.)
- **Volatilitäts-Squeeze-Breakout = ADDITIVER SETUP, UMGESETZT (User-Idee
  „Breakouterkennung" 2026-07-14, gemessen `backtest_breakout_squeeze.py`):**
  struktureller Ausbruch aus einer **Kompression** (Box = Spanne der letzten `_SQ_N`=10
  abgeschlossenen M5-Bars ≤ `_SQ_MULT`=2,5×ATR) um `_SQ_K`=0,1×ATR — NICHT der
  EMA-Trend-Breakout. **2-Stichproben-positiv** (ØR **+0,227/+0,141** netto Echtkosten,
  PF 1,35/1,20, 173/413 Trades; schlägt den Ausbruch aus *beliebiger* Box −0,045/+0,161
  in BEIDEN Hälften) & **robust über Box 10–20 / k 0,1–0,2** (alle 8 Kombis positiv,
  kein Parameter-Zufall). Andere Signalklasse als die Welle → komplementär. **Umsetzung:**
  `wave._squeeze_one(highs,lows,closes,atr)` (M5). ⚡ **Erkennungs-Latenz ~5 s (Variante A,
  2026-07-21):** der Squeeze läuft auf einem EIGENEN, schnellen 60-Bar-M5-Fetch
  (`_sq_due`/`_SQ_REFRESH_S=5.0`, entkoppelt von der 15-s-TF-Ampel-Drossel) → Ausbruch wird
  ~15 s→5 s schneller erkannt, dann ~1 s Handeln (`_pos_loop`). Gleiche validierte M5-Regel,
  reine Infra (kein Backtest nötig). **Variante B (Squeeze auf M1) = OFFEN/UNBELEGT** — erst
  backtesten, wenn der M1-Logger (`candles_m1`, seit 2026-07-21) ab ~2027-01 genug History hat.
  Snapshot **`wave.squeeze {state, dir, level, box_atr}`**: `active` = Ausbruch (echtes
  Signal LONG/SHORT) · `armed` = komprimiert, Ausbruch steht bevor · None = keine
  Kompression (transient — der Ausbruch weitet die Box, Signal klärt sich selbst).
  **Verdict-Modul „Squeeze"** (`_verdict`, Gewicht 2,0, nur bei `active`; unter der
  Welle=3,0). **UI Welle-Kachel** (`#wave-squeeze`): grün/rot bei `active`
  („🚀 Squeeze-Breakout ▲ LONG @ …"), blau bei `armed` („🎯 Kompression … Ausbruch
  steht bevor"), grau sonst. ⚠ **Nur der ENTRY** — der User-Teil „Gegen-Trade schließen
  + Stop-&-Reverse" ist NICHT gebaut (nicht validiert, verdoppelt Kosten, Chop-Risiko).
  Läuft normal über SL/Trailing/Notfall-Stop. Caveats: modeste Stichprobe (Box>12 =
  12–22 Trades = Rauschen), Frequenz ~2–3/Woche → **B4-Wochenmonitor** (Live-ØR/PF
  gegen +0,14…+0,23), Runner-abhängig (43 % Treffer). Verwerfen, wenn Live wegdriftet (B5).
- **Momentum-Continuation als Auto-Setup = VERWORFEN (gemessen `backtest_momentum.py`,
  2026-07-17):** Kandidat für Autonomie (Einstieg in Richtung eines frischen
  Momentum-Schubs, mom_N kreuzt ±X×ATR; seq. Sim, Live-Exit, Echtkosten). **Fällt
  durch den 2-Stichproben-Test:** fast alle N/X in H1 negativ (−0,03…−0,22), in H2
  positiv (+0,02…+0,07) → regime-abhängig. Einzige „beide positiv"-Kombi (N=24/X=2,0)
  ist H1 **+0,002 / PF 1,00** = Breakeven-Rauschen, nicht der Squeeze-Maßstab
  (+0,14…+0,23). Grund: Momentum-Continuation IST Trendfolge — erbt die Regime-
  Anfälligkeit des Wave-Signals, kein distinkter Edge wie die Kompression→Ausbruch-
  Klasse. **Autonomie-Fazit: der Squeeze bleibt der EINZIGE validierte Auto-Entry.**
  (P(break)-Level-Bounce als Entry ist separat schon verworfen, s. „Range-Einstieg".)
- **Opening Range Breakout (ORB) als Auto-Setup = VERWORFEN (gemessen
  `backtest_orb.py`, 2026-07-17, Recherche-Kandidat):** Box = erste 15/30 min nach
  EU-Open (10:00 Brk) bzw. US-Open (16:30 Brk), Ausbruch ±0,1×ATR, one-shot, Live-
  Exit, Echtkosten. **3 von 4 Varianten kippen zwischen den Hälften** (US-Open H1
  −0,19…−0,27!); einzig EU-15min ist beidseitig positiv, aber nur ØR +0,069/+0,027
  (PF 1,11/1,04) = Rauschen unter dem Kosten-Puffer, und die Nachbar-Parameter
  kippen (keine Robustheit — beim Squeeze waren ALLE 8 Kombis positiv). ⚠ Lehrstück:
  erster Lauf zeigte EU-Open ØR +1,3/PF 10 — war ein **Selektions-Artefakt** (ATR-
  Skip statt Floor ließ in der Niedrig-Vola-H1 nur 9 Morgen durch); mit Floor
  verschwand der „Edge". Zeit-Anker ersetzt keinen Struktur-Anker.
- **ATR-Breakout-Bestätigung** (`wave._confirm_breakout`, live `[trading]
  breakout_k=0.3` — Split-validiert, s. u.; 0=aus): ein
  Richtungssignal wird **erst durchgelassen, wenn der Kurs k×ATR in
  Signalrichtung** gelaufen ist („X dynamisch"); läuft er vorher k×ATR DAGEGEN/
  Timeout → neu verankern, solange **WARTEN** (Grund „warte auf Breakout …",
  `snap.breakout`). **Stateful** (`_pend`), reset bei TF-Wechsel. Gemessen
  (`backtest_breakout.py`): hebt Ø-Edge/Trade **~2×** (+0,185→+0,36 bei k=1,0),
  Treffer 43→47 %, ~halb so viele Trades → **netto** klar besser (halbe Spread-/
  Komm.-Kosten; lohnt ab Kosten >0,037×ATR, real ~0,1×ATR). = die „Zwei-Konten-
  Hedge"-Idee des Users, auf EINEM Konto ohne doppelte Kosten. **k=0,3 seit
  2026-07-08 (Split-validiert, 80k Bars in 2 Halbjahren):** k=0,3 ist in BEIDEN
  Hälften das Beste — H1: ØR +0,119/netto +339 (0,5: +0,055/**−831**; 1,0:
  +0,046/−805 — beide netto negativ!), H2: +0,362/+4239 (0,5: +3308; 1,0: +3838).
  Grund: 0,3 filtert Fehlstarts, behält aber den besseren Einstiegspreis (höheres k
  = 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=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
  (PF 0,42/0,66!) · 0,3–0,6: −0,100/−0,059 (⚠ 79–82 % WR und trotzdem PF<1 =
  Klein-Close-Falle) · 0,6–1,0: −0,123/−0,060 · ≥1,0 bzw. „kein Gegenlevel" positiv.
  Kosten-Arithmetik, kein Signal-Timing (deshalb robust, anders als die 9 verworfenen
  Filter): Ertrag am Level gedeckelt (63 % Containment) − 0,265×ATR Kosten < 0.
  Auslöser: Live-Trades mit Sofort-/Klein-Close (0-min-Trade +0,08 direkt am Level;
  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→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),
  aber JEDE Schwelle kippt zwischen den Hälften (p≥0,5: −0,016/+0,083 · p≥0,6:
  +0,089/−0,006 · p≥0,7: +0,076/−0,029) → nicht robust, reines Distanz-Gate bleibt.
  **13. verworfener Signal-Eingriff.** (Nebenbefund: geblockte Gruppe in beiden
  Hälften klar negativ, −436/−251 ΣR — bestätigt die 1,0-Erhöhung.)
- **Mindest-Konfidenz-Gate** (`_MIN_CONF=55`): Signal < 55 % → WARTEN. Gemessen
  (`backtest_conf.py`): Band **40–54 % = negativer Edge** (−0,025), ≥55 % = +0,058;
  Gate hebt Ø-Edge ~+50 % und den Gesamtertrag (entfernt die schwachen Setups, bei
  denen zu viele Strafen gestapelt sind — typisch der Lagging-Short am Boden).
- **Signalhäufigkeit** (`backtest_dist.py`): ~57 % der Zeit LONG/SHORT, ~43 % WARTEN.
  WARTEN-Treiber: M30-Gegen-Trend (~27 % der Bars, gewollt, Edge×2) + Überdehnung
  + Totband. `_STRETCH_MAX` 2,5→**3,5** angehoben (`backtest_stretch.py`: +26 %
  Signale, Gesamtertrag steigt; ab 3,5×ATR kippt der Edge negativ).
- **Higher-TF-Gegen-Trend-Filter:** Signal wird verworfen (→WARTEN), wenn der
  übergeordnete **M30**-Trend (EMA12/50, Totband `_HTF_DEADBAND=0,15×ATR`) klar
  dagegen steht — kein Short im M30-Aufwärtstrend & umgekehrt. Nur für Basis-TF
  < M30 aktiv (`_htf_sign`, holt M30-Bars im selben `mt5_lock`). Per Backtest
  belegt: Ø-Edge ×2 (+0,012→+0,027), Treffer 52→54 %. Mess-Tool:
  `python backtest_htf_filter.py M5 M30 4000 0.15`.
- **Einstiegsqualität (nur Konfidenz/Score, NICHT Richtung):** nach gemessenem
  Edge (`backtest_pullback.py`) gestaffelt — **tiefer Pullback** (Kurs durch die
  EMA zurück, `near<0`) = bestes CRV (+15, „⭐ tiefer Pullback"); laue Zone direkt
  an der EMA (0–0,3×ATR) = schwächster Edge (−3); Trend-Momentum (1–2×ATR) +8.
  **Kein** Spitzen-Gate: ein hartes „nur an Wellenspitze"-Filter senkte den
  Gesamtertrag (−80 % Trades), darum verworfen. Konfidenz blockt NICHT das Ordern
  (nur WARTEN/Gegen-Signal tut das).
- **Multi-TF-Konfluenz (nur Konfidenz/Anzeige):** M30 **und** H1 bestätigen die
  Richtung → +12, „⭐⭐ Konfluenz M30+H1"; H1 dagegen → −8. Per Backtest belegt:
  Ø-Edge ×3,5 (+0,016 nur-M30 → +0,056 M30+H1). `_htf_sign` holt zusätzlich
  H1-Bars. Mess-Tool: `python backtest_improve.py 8000`.
- **Tageszeit-Gate = AUS geschaltet (User-Vorgabe 2026-07-22, `[trading] dead_hours=`
  leer — bewusst GEGEN die Messung).** Jetzt **config-steuerbar** (`wave.set_dead_hours`,
  Komma-Liste von Stunden; leer=aus). Gemessener Default im Code = `0,1,2,3,4,5,6,7,12,16`
  (die ini überschreibt auf leer). ⚠ 12/16 waren zuletzt am 2026-07-21
  (`backtest_hourly_split.py`) noch beidhälftig negativ — der User schaltet das Gate
  trotzdem ab. Reaktivieren = ini-Stunden eintragen. Der **EIA-Blackout (Mi 15:30–16:30)
  bleibt separat aktiv** (eigenes Event-Gate, nicht Teil des `dead_hours`). Historie/
  Messung (Gate war 11–14 → 12+16 → aus → zurück → jetzt wieder aus):
  Nach der **Echtkosten-Messung** (`backtest_realcosts.py`, Kosten = Bar-Spread/ATR
  statt pauschal 0,1×ATR — Ø real 0,265!): **Nacht 0–7 = Kostenfalle** (konstanter
  Spread ÷ niedriger Nacht-ATR = 0,32–0,50×ATR, in beiden Hälften negativ; reine
  Arithmetik) + **12/16 Uhr 3× unabhängig negativ**. Politik „0–7+12" verbessert
  BEIDE Hälften (H1 −4038→−1870, H2 +100→+1191). **Robust positiv nur 21–22 Uhr.**
  ⚠ Die „15 robusten Negativ-Stunden" NICHT blocken — in-sample-zirkulär (Overfit).
  breakout_k=0,3 auch unter Echtkosten bestätigt (H1 einziges positives k). Historie
  (Gate war 11–14, dann 12+16, dann auf User-Wunsch aus, jetzt gezielt zurück):
  - **Von 11–14 auf 12+16 umgestellt (gemessen+verifiziert, `backtest_hourly.py` +
    `backtest_hourly_split.py`, 80k M5 in 2 Halbjahren):** Netto-R je Stunde zeigt
    **12 Uhr (−0,11/−0,12) und 16 Uhr (−0,17/−0,10) in BEIDEN Hälften negativ**;
    **Std 13 kippt das Vorzeichen** (−0,048/+0,039 = Rauschen), 11/14 ~breakeven. Das
    alte Pauschal-Gate 11–14 blockte harmlose Stunden und ließ die real schlechte 16
    laufen. **Gate 12+16 schlägt 11–14 im Gesamt-Netto-R in beiden Zeiträumen**
    (H1 −1357→−1253, H2 +1562→+1799) und handelt dabei mehr Trades. Intraday-Edge
    generell dünn; **Löwenanteil in US-Session 21–22 Uhr** (+0,25/+0,49).
  - **Reversal-Ausnahme vom Gate = VERWORFEN (gemessen, `backtest_deadhour.py`):**
    Reversal in der Dead-Hour nur **+0,062×ATR brutto** (vs +0,190 außerhalb) → nach
    Kosten (~0,1×ATR) negativ. Trade-①-Gewinner war Varianz. Gate gilt auch für Reversal.
- **EIA-Blackout (kausales Event-Gate, AKTIV):** **Mittwoch 15:30–16:30 Berlin**
  (Vorlauf der EIA-Lagerdaten 16:30 = 10:30 ET, Offset ganzjährig 6 h) → hartes
  WARTEN („EIA-Blackout …"). Gemessen (`backtest_events.py`, 2 Halbjahre): dieses
  Fenster in BEIDEN Hälften netto negativ (−0,147/−0,088 vs rest) — deckt sich mit
  dem alten „16 Uhr"-Befund. eia_post/api_pre/api_post NICHT robust → nicht geblockt.
  Nur im Live-Pfad (`hour≠None`), Backtests bleiben gate-frei. Best-Practice
  „Event-Blackout" statt Pauschal-Gate.
- **Winkel-vs-EMA-Warnung (nur Konfidenz):** Regressions-Winkel der Basis-TF gegen
  die EMA-Richtung → −10 „⚠ Winkel gegen EMA (mögliche Wende)" (nachlaufende EMA!);
  dafür → +5. `backtest_angle.py`: dafür/neutral +0,055 vs dagegen +0,025; als Gate
  aber Gesamtertrag-negativ → bewusst nur Konfidenz/Warnung (Hilfe fürs manuelle
  Überspringen der Lagging-Shorts).
- **Höher-TF-Winkel-Filter (M30+H1-Winkel) = VERWORFEN (gemessen,
  `backtest_htf_angle.py`):** Signal verwerfen, wenn M30/H1-Regressionswinkel gegen
  die Richtung steht → in JEDER Schwelle/Variante **schlechter**. Die entfernten
  Signale (Short bei aufwärts-Winkel) haben **höheren** Edge (+0,04–0,05) als die
  behaltenen (+0,02) — es ist der profitable Pullback-Setup. Filter kostet ~⅔ des
  Gesamtertrags (+287→~+70). Gegen-Winkel-Shorts NICHT filtern; einzelne große
  Verluste (z. B. −37 an einem H1-Auf-Tag) sind Varianz, Schutz über Notfall-Stop/
  Sizing, nicht über Signal-Filter.
  - **Auch als Konfidenz-STRAFE verworfen (`backtest_confluence_angle.py`):** statt
    Hard-Filter den Konfluenz-Bonus streichen/Konf senken, wenn M30/H1-Winkel
    dagegen → borderline-Signale fallen unters 55-Gate. Ergebnis: in JEDER Variante
    **schlechter** (Δ −2500…−3467 R); die entfernten Gegen-Winkel-Signale haben
    ØR **+0,26…+0,32** (die BESTEN), die behaltenen +0,12. **3× gemessen** (M5-Winkel,
    Höher-TF-Winkel-Filter, Konfluenz-Strafe): „nicht gegen den Winkel shorten"
    macht den Bot IMMER schlechter. **Nicht mehr am Signal drehen** — Edge ist klein
    & varianzlastig; der Hebel ist **Sizing (risiko-basiert) + viele Trades**, nicht
    der Filter.
  - **H1-STÄRKE-Filter (nicht Winkel!) = VERWORFEN (gemessen `backtest_short_h1filter.py`,
    2 Halbjahre, 2026-07-15):** Motiviert durch Live-Befund „SHORT-Empfehlungen 31 % WR
    in Aufwärts-Regime" (LONG 62 %, SHORT 31 %, letzte 40 MIT-Trades). Idee: Signal
    verwerfen, wenn es gegen einen **starken H1-Trend** (|H1 EMA12−EMA50| > thr×ATR_H1)
    läuft. **Fällt durch:** die weggefilterten Signale flippen das Vorzeichen zwischen
    den Hälften — thr 0,5: ØR **H1 −0,198 / H2 +0,001**; thr 1,0: **−0,069 / +0,013**;
    thr 1,5: **+0,029 / −0,063**. In KEINER Schwelle robust negativ in BEIDEN → Filter
    hätte in H2 (positive/breakeven drops) **Geld gekostet**. **7× belegt: die 31 %-SHORT-
    Schwäche ist REGIME (aktueller Uptrend), kein Signalfehler** — in H2 tragen dieselben
    Gegen-H1-Shorts. Kein Filter; der Hebel bleibt Sizing + Notfall-Stop + Diskretion
    (User-WARTEN-Übersteuerungen liefen 68 % WR / +259 €).
  - **ER-Chop-Gate = VERWORFEN (gemessen, `backtest_chopgate.py`, 2 Halbjahre):**
    Signal→WARTEN wenn Efficiency Ratio der letzten N Bars < X. Chop-Signale sind NICHT
    robust schlechter — Effekt kippt: H1 Trend leicht besser (Ø-R +0,070 vs +0,053),
    H2 **umgekehrt** (Chop +0,138 vs +0,129). Gate wirft zudem ~70 % (profitables)
    Volumen weg (ΣR +2299→+836). Das Totband filtert Extrem-Chop schon (ER-0,02-Tag =
    71 % WARTEN); Rest-Signale = Varianz. **5× belegt: Signal-Filter tragen nicht.**
- **Vola-Abzug (nur Konfidenz):** hohes ATR (oberes Terzil, `_ATR_HIGH≈0,27`) =
  schwächster/negativer Edge → −8 „hohe Vola". Schwelle regime-abhängig → kein Gate.
- **Reversal-Lockout/-Persistenz = VERWORFEN (gemessen, `backtest_revlock.py`):**
  Gegen-Signale **kurz nach** einem Reversal sind sogar **besser** als normale
  (+0,072 vs +0,018 bei N≤6) → Reversal-Signale NICHT sperren/halten. Einzelne
  Verluste (Bottom-Short nach REV) sind Varianz, kein Muster.
- **Rec-Logging:** `engine._run_analysis` → `history.log_recommendation` (Throttle
  intern) füllt die `recommendations`-Tabelle (Signal/Score/Conf/Winkel/Setup) für
  Tages-Reviews (`analyze_today.py` rekonstruiert sonst aus M5-Bars).
- **Reversal-/BOUNCE-Einstieg (antizyklisch, markiertes ZWEITsignal):** **überdehnt**
  (|stretch|≥`_REVERSAL_STRETCH`=**3,0**, **entkoppelt** von Anti-Überdehnung
  `_STRETCH_MAX`=3,5) **UND** Regressions-Winkel hat gedreht → Einstieg in
  **Winkel-Richtung, gegen die EMA** (überverkauft + Winkel auf → LONG; überkauft +
  Winkel ab → SHORT). Setup `WAVE_REV_*`, Grund „🔄 Reversal"; hebt Anti-Überdehnung
  **und** M30-Filter bewusst auf. **Schwelle 3,5→3,0 gesenkt** (User wollte mehr
  Bounces; `backtest_bounce.py`): Ø-R **+0,185**, PF 1,35, Treffer 70 %, Worst −2×ATR
  (SL-gedeckelt), ~1,5× mehr Bounces als 3,5 — profitabel, aber **schwächer als
  Trend** & **regime-anfällig** (trägt in Seitwärts/Mean-Reversion, blutet in starken
  Trends). Nachrangiges, markiertes Setup. **Bounce-Status — Multi-TF** im Wave-
  Snapshot (`wave.bounce = {state, dir, tf}`): scannt **M1/M5/M15/M30** (`_bounce_one`,
  Aggregat in `refresh_market`, ~15 s-Throttle via TF-Ampel-Fetch), nimmt den
  **stärksten** (aktiv>erwartet, dann größte Überdehnung). **`expected`** = überdehnt
  (≥`_REVERSAL_STRETCH`), Winkel noch NICHT gedreht · **`active`** = + Winkel gedreht.
  `dir` LONG (überverkauft) / SHORT (überkauft), `tf` = Quelle. Frontend `#wave-bounce`
  als **„Überdehnung"-Warn-Gauge** (NICHT „Bounce/Signal"): grau „keine" · bernstein
  „⚠ überdehnt … Reaktion nach oben ↑ / nach unten ↓ möglich" · kräftiger bei
  `active` (+ TF). **Kein
  grün/rot** (kein Trade-Trigger). **Reversal-Konfidenz-Boni = GEPRÜFT & BEHALTEN
  (gemessen `backtest_revconf.py`, 2 Halbjahre, 2026-07-15):** Befund war, dass
  „starker Trend" (+10) und „⭐ tiefer Pullback" (+15) beim Reversal semantisch
  GEGEN das Signal stehen und Reversals so leichter durchs 55er-Gate kommen.
  Korrektur (Boni beim REV streichen) **fällt durch**: die dadurch rausfallenden
  Reversals kippen das Vorzeichen — H1 ØR **−0,323** (127 St., Fix ok), H2 ØR
  **+0,109/PF 1,16** (1608 St., Fix hätte die BESSEREN gekappt, WR 45 %). Nicht
  robust → Konfidenz-Berechnung bleibt. **8. verworfener Signal-Eingriff.** Die
  hohe REV-Conf-Anzeige (~75–80 %) ist also kein Gate-Fehler; wer will, liest die
  Reason-Liste („Reversal" + „hohe Vola") als Risiko-Kontext. **Gemessen (`backtest_bounce_reliability.py`):
  Richtungs-Trefferquote der „aktiv"-Anzeige ~50 % (Münzwurf), Ø-Vorlauf ~0×ATR über
  alle TF & H1-Regime → reiner Überdehnungs-Kontext, KEIN Signal.** (Die früheren
  „70 %" aus `backtest_bounce.py` waren exit-getrieben, nicht Richtungs-Vorhersage.)
- **Timeframe:** `[trading] tf_select=heuristic` → `engine._choose_tf` wählt jede
  Minute die TF mit klarstem Trend aus dem **Band `[tf_min … tf_max]`** (leichter
  Höher-TF-Bias). **Einstellung: `tf_min=M5`, `tf_max=M30`** (M1 raus: gemessen
  ~0 Edge; M30 zugelassen, damit der Bot in einem M30-Trend nicht festhängt, wenn
  M5/M15 gegen-Bouncen — sonst Patt: Long geblockt, Short fehlt). **H1 bleibt nur
  Kontext** (Filter/Konfluenz). Start-TF wird ins Band geklemmt. `agent` = LLM
  wählt; `M1..H1` = fest. Der **Agent steuert die TF nicht mehr**.
- **Positionsgröße = margin-basiert 95 % (User-Vorgabe 2026-07-28, `risk_pct=0`,
  `margin_buffer_pct=95`):** `calc_lots` setzt die Lots auf ~95 % der freien Margin.
  Verlauf 90→95→75→(1,5 % risiko, wenige Stunden am 2026-07-20)→80 %→**95 % margin
  (2026-07-28)** — der User hat die Margin-Wahl damit mehrfach bewusst getroffen (nicht
  ungefragt umstellen). ⚠ 95 % ist noch aggressiver als die 80 %-Referenz unten.
  ⚠ Aggressiv: der −95,48-€-Nacht-Trade 2026-07-20 (News-ATR → SL ~1,0 $ breit ×
  1,03 Margin-Lots ≈ 11 % Konto) ist der Referenzfall; mit `risk_pct=1.5` wären es
  ~0,15 Lots / ~−14 € gewesen (`backtest_sizing.py`: Margin-Sizing bis 36 %
  Quasi-Ruin, 1–2 % = 0 %). Risiko-Modus bleibt gebaut & abgesichert (Guards s. u.),
  Umschalten = `risk_pct=1.5`. Mechanik: `trader._send_locked`
  bestimmt **erst den SL**; bei `risk_pct>0` → risiko-basiert (`calc_lots_risk`,
  Verlust ≈ risk_pct % Equity, Margin als Deckel) = der gemessene Fix gegen die
  Verlust-Asymmetrie. **Umschalten via `[trading] risk_pct` (z. B. 1.5 = überlebbar).**
  ⚠ **Risiko-Modus-Guards (Fix 2026-07-19):** `calc_lots_risk` rundet NICHT mehr auf
  `volume_min` auf (unter Mindestlot → 0.0 statt still mehr Risiko), und
  `_send_locked` fällt bei `risk_pct>0` NICHT mehr still auf Margin-Sizing zurück
  (75 % wäre ein Vielfaches des gewollten Risikos) — der Trade wird stattdessen mit
  Fehlermeldung abgelehnt. Bei `risk_pct=0` (aktuell) unverändert margin-basiert.
  Harter Broker-SL immer mitgeschickt; adoptierte Fremd-Trades bekommen Schutz-SL.
  - **Sizing-Simulation (`backtest_sizing.py`):** 90 % Margin = Wachstums-optimal,
    ABER **36 % P(DD>80 %)** = Ruin-Risiko. Risiko 1–2 %/Trade = überlebbar (0 %
    Quasi-Ruin). Exit-Asymmetrie gemessen `backtest_exit2.py` (Live-Exit Trail 1,5
    ist OK; Problem war Sizing + manuelles Gewinner-Kappen, NICHT die Exit-Logik).
- **SL:** Band **1,8–2,2×ATR** (Ziel 2,0; `INIT_SL_MIN/MAX_ATR`). **Breakeven ab
  +1,3×ATR** (`_BREAKEVEN_ATR`; war 0,6 → 21 % Breakeven-Scratches, gemessen
  `backtest_exit.py be`: 1,3 = Plateau-Optimum → Scratch 5 %, Ø-R +15 %, kein
  Tail-Risiko). **Früh-Ausstieg = AUS** (`_ADVERSE_EXIT_ATR=0`). Trailing
  Init/Trail/Lock. **Teil-Exit AUS** (`_PARTIAL_TP_FRAC=0`, User-Vorgabe) → am TP
  wird der **komplette** Trade geschlossen (kein 50 %-Runner mehr).
  - **Früh-Ausstieg NUR bei Trades OHNE Signal-Deckung = VERWORFEN (gemessen
    `backtest_adverse_nosignal.py`, 2026-07-23, Auslöser −57,34-€-Trade: manueller
    LONG gegen WARTEN, KEIN Squeeze/Signal-Flip beteiligt):** Hypothese war, dass ein
    Adverse-Exit bei signal-ungedeckten Trades (Totband/WARTEN-Zone, B0 zeigt live
    39 % WR dort) helfen könnte, auch wenn er pauschal auf ALLE Trades schadet. **Fällt
    durch — bei JEDER Schwelle (0,5/0,75/1,0/1,5×ATR), in BEIDEN Populationen (SIG/
    NOSIG), fast durchgehend in BEIDEN Hälften negativ** (einzige Ausnahme: SIG H1
    X=1,5 knapp +11 R, aber H2 dort −46). WR bricht von ~38–43 % auf 18–26 % ein — der
    Früh-Ausstieg kappt zwar einige Trades vor dem vollen SL, schneidet aber weit öfter
    Trades ab, die sich erholt hätten; NOSIG-H2 war ohne Eingriff sogar leicht profitabel
    (ΣR +80, PF 1,15) und wird durch jede Adverse-Schwelle verschlechtert. Hypothese
    „schwächere Population profitiert eher" widerlegt. Keine Änderung.
  - **Trailing-Optimierung geprüft = KEINE Änderung (gemessen, `backtest_trailing.py`,
    2 Halbjahre, echte Phasen-Sim):** Die Live-Config (`_TRAIL_START_ATR=0,3` ·
    mult 1,5 M5 · Breakeven 1,3) hat die **beste Verlustseite** (bestes H1, Worst nur
    −1,5×ATR). Trailing trägt klar: ohne Trailing ΣR −1313/Worst −2,0 vs. Live +1777/
    Worst −1,5 (~+3000 R **und** kleinerer Einzelverlust). **Breiter ziehen** (mult
    2,0–2,5) oder **Trail später starten** (0,3→1,0) macht H1 schlechter/Worst größer;
    der frühe Trail-Start ist **netto schützend** (holt „läuft-schief"-Trades billiger
    raus). Einzige mithaltende Variante (start0,6) kippte zwischen den Läufen =
    Rauschen. → Ausschütteln ist Varianz, nicht Logikfehler.
  - **Time-Stop (AKTIV, gemessen `backtest_timestop.py`):** Position wird geschlossen,
    wenn sie nach **120 min noch in Phase „Init"** hängt (HW-Profit nie ≥0,3×ATR =
    Whipsaw-Opfer; `trailing._TIMESTOP_MIN=120`, 0=aus, `closed_by=timestop`).
    Verbessert BEIDE Hälften (H1 +98→+162, H2 +2191→+2298 R), Worst unverändert;
    kürzere Fenster (30/60 min) kippten zwischen den Hälften = Rauschen. Dank
    Phasen-Ratsche ist „Init nach 2 h" exakt „nie Trail-Start erreicht".
  - **ATR-Floor 0,12→0,06 gesenkt (gemessen, `backtest_atrfloor.py`, 2 Halbjahre):**
    Die reale Vola fiel unter den alten Floor (H1: **81 % der Signale ATR<0,12** →
    Floor band dauernd, Exit-Distanzen künstlich ~1,3–1,6× breit, dazu ~35k
    Log-Warnungen je 5-MB-Rotation). Floor 0,06 in **beiden** Hälften besser
    (H1 −153→−27 Pts, H2 +512→+554); ganz ohne Floor nur marginal besser → 0,06 als
    Schutz behalten. Floor-Warnung jetzt **gedrosselt** (max. 1×/5 min).
  - **Befund B — umgesetzt (Exit-Simulation `backtest_exit.py`, Doku
    `docs/exit-simulation.md`):** altes Band 1,2–1,5 war zu eng (MAE ~1,7×ATR,
    31–37 % Frühstopps). 2,0×ATR hebt Ø-R +32 %, PF 1,33→1,39, Frühstopps →25 %,
    Worst-Case auf 2,0×ATR gedeckelt. Breiter (3–4×ATR) wäre im Schnitt noch
    besser, aber Tail-/Drawdown-Risiko → verworfen. ⚠ Da Sizing margin-basiert
    (90 %, nicht risiko-basiert), schlägt die SL-Breite voll auf den EUR-Verlust
    durch. Qualität-abhängiger SL NICHT belegt (MAE über alle Buckets gleich).
  - **S/R-Close (am Level schließen) = pauschal 2× VERWORFEN, als GEMESSENES
    Segment aber AKTIV:** Pauschal (`backtest_srclose.py`, Echtkosten, 79k Signale)
    verdoppelt Close@Level die WR (35→67 %), verschlechtert aber PF/ΣR in BEIDEN
    Hälften (0,78→0,67 · 0,88→0,76) = Gewinner-Kappen. **ABER** (`backtest_srbreak.py`,
    47k Touches, User-Idee „P(Durchbruch)>60 % → laufen lassen"): Basisrate
    P(break)=36–37 %; das **Anlauf-Momentum trennt robust in beiden Hälften** —
    Kurs KRIECHT ans Level (letzte 6 Bars <0,3×ATR) → P(break) nur 26 %, **Close
    schlägt Laufenlassen Ø +0,12 R**; mit Schwung (≥0,3) → laufen lassen (41–43 %).
    Volumen/Touch-Zahl trennen NICHT robust.
  - **Kalibriertes P(Durchbruch)-Modell (2026-07-13, `analyze_srwaves.py` +
    `backtest_srclose_prob.py`):** Containment-Befund — **~68 % der Wellen erreichen
    das gegenüberliegende Level, davon brechen nur ~37 % durch → ~63 % prallen ab**
    (robust beide Hälften). P(break) ist **vorhersagbar & kalibriert**: Logit auf 4
    Merkmalen (Anlauf-Momentum 6/3 Bars ·d, mit-Trend, Level-Distanz), auf H1
    trainiert, auf H2 **AUC 0,71 + Kalibrierung trifft** (pred 17→21 %, 49→50 %,
    69→76 %). Dominant = 3-Bar-Beschleunigung (`_PB_W` mom3 +0,78). **R-Ertrag
    (Echtkosten):** Regel „close wenn P(break) < X" schlägt reines Trailing in BEIDEN
    Hälften massiv (+6000/+7600 R); **User-Schwelle 0,60 im Optimum-Plateau (0,50–0,60
    ~gleich), validiert.** ⚠ Impliziert Strategiewechsel: ~90 % der Level-Touches
    werden geschlossen (Trendfolger→Level-Scalper) — trägt, weil echte Kosten (0,265×
    ATR) + 63 % Containment das Laufenlassen teuer machen.
  - **S/R-Close SIGNAL-gegated („bei mit-Trend halten statt schließen") = VERWORFEN
    (gemessen `backtest_srclose_signal.py`, 2026-07-22, User-Idee):** Vorschlag war,
    den S/R-Close zu unterdrücken, solange die Empfehlung noch in Trade-Richtung zeigt
    (halten bis WARTEN). **Fällt klar durch — in BEIDEN Hälften ~−5300…−5700 R
    schlechter** als der reine P(break)-Close. Grund/Datenbeleg: ~85 % ALLER Level-
    Touches passieren, WÄHREND die (nachlaufende) EMA noch „in Richtung" zeigt
    (23,8k/20,1k von 27,8k/26,2k Touches) — genau dort HÄLT das Level aber. Diese
    Touches geschlossen = ΣR +11703/+13606, geHALTEN = nur +5978/+8347. Die
    Trend-Empfehlung lagt → sie „bestätigt" ausgerechnet am Abpraller. Das kalibrierte
    P(break)-Modell (hat „mit-Trend" als Merkmal) macht das schon richtig; es mit dem
    groben EMA-Signal zu übersteuern kostet ~⅔ des S/R-Close-Edges. **12. verworfener
    Signal-Eingriff.**
  - **Auto-Flip-Close = VERWORFEN (gemessen `backtest_flipclose.py`, 2 Halbjahre,
    sequentielle 1-Positions-Sim, 2026-07-16):** User-Taktik-Kern „Position im Plus
    automatisch schließen, wenn die Empfehlung dreht" (heute nur Alarm). KEINE Variante
    (minR 0/0,3/0,5×ATR, auch-im-Minus) hält in beiden Hälften ØR & ΣR ≥ Basis:
    H1 ΣR −278→−280…−417, H2 **+174→+119…+144** (kostet 17–32 % des Ertrags).
    Mechanik: WR steigt 43→50 %, Ø-Gewinn schrumpft = **Gewinner-Kappen** — die
    nachlaufende EMA dreht oft mitten im Pullback, der Trade wäre weitergelaufen.
    Flip bleibt **Alarm + menschliche Entscheidung** (User-Übersteuerungen 68 % WR).
    Der Rest der User-Taktik (Ziel=nächstes S/R, weiterlaufen wenn stark) IST der
    P(break)-Auto-Close; der „3 %-Margin-Anker" = EUR-Schwelle, Klasse „verliert".
  - **Mindestgewinn für den S/R-Close = VERWORFEN (gemessen `backtest_srclose_prob.py`,
    Mindestgewinn-Sektion):** „nur closen wenn ≥minR im Plus" verliert **monoton in
    BEIDEN Hälften** (minR 0,2: −444/−213 · 0,5: −1425/−854 R vs minR=0). Die vielen
    kleinen Gewinne SIND der Edge — übersprungene Klein-Closes prallen am (haltenden!)
    Level ab und enden schlechter. Kleine EUR-Beträge = Positionsgröße, kein Exit-Thema.
    2 Halbjahre, Echtkosten):** LONG an Support / SHORT an Resistance, gegated mit
    P(Level hält), Ziel = Gegenlevel — **verliert in BEIDEN Hälften** (FIX H1 −3393/
    H2 −2242, +Trailing/-nur-Trailing ebenso negativ; WR 46–53 %, PF<1). **Asymmetrie:
    P(break) taugt zum EXIT** (Trade schon mit-Trend im Plus am Gegenlevel → kassieren),
    **nicht zum ENTRY** (antizyklisch am Extrem = Münzwurf-Richtung, 6× belegt). Einstieg
    bleibt mit-Trend (Pullback). **Trailing bleibt** — nicht mehr Standard-Exit (das ist
    der S/R-Close), aber Manager für die ~10 % Durchbruch-Runner (P≥Schwelle) + Fallback
    für Trades ohne erreichbares Gegenlevel.
  - **Umsetzung:** `engine._p_break(mom6,mom3,wt,dist)` (eingebettete `_PB_MU/SD/W`);
    `wave_rec.snapshot` liefert **`pb_feats` {mom6, mom3, ema_diff, atr} — FEST aus M5**
    (aus dem ~15-s-Turn-Fetch gecacht, ATR-Floor 0,12 wie im Training). ⚠ **Bugfix
    2026-07-13:** vorher kamen die Features aus der Wave-TF (Heuristik bis M30 → mom6
    war 3-h- statt 30-min-Momentum, ATR 2–3× → P falsch skaliert) und das Level aus dem
    Misch-Set `_sr_levels` (Zonen/Gaps/Tageslevel). **2. Bugfix gleicher Tag:** die
    M15-Cluster-Level (`market.sr`, SR_MIN_TOUCHES) sind in frischen Trends oft LEER →
    Hint verschwand komplett. Jetzt **trainingsgleiche Level**: `wave.pb_levels` = rohe
    **M5-Pivots (k=3, ~300 Bars)** aus dem Turn-Fetch (M5 dafür 320 Bars tief), Highs
    in `_m5_hl` gecacht. Am Rally-Hoch gibt es für LONGs korrekt KEIN Gegenlevel →
    kein Hint (nichts zu closen). ⚠ **3. Bugfix 2026-07-15:** das Close-Level kommt
    jetzt aus **`_draw_levels`** (dieselbe geclusterte+Hysterese-Linie wie Chart &
    Dashboard) statt aus den rohen `pb_levels` — sonst feuerte die Meldung an einem
    anderen Level als die gezeichnete Linie (User: „passt nicht zusammen"). P(break)-
    Features (M5) unverändert, nur `level`/`dist` verschieben sich um Cents.
    **`_sr_close_hint`** (Anzeige ≠ Auslösung, Fix
    2026-07-14 — das 0,15×ATR_M5-Fenster ≈ 0,03 $ war als reine Anzeige unsichtbar
    klein): Hinweis erscheint ab **≤0,6×ATR Annäherung** (blaue „nähert sich"-
    Vorwarnung mit Live-P(break) + `gap_atr`); **Auslösung `close=true` nur AM Level**
    (≤0,15×ATR = gemessener Touch) und `p_break < [trading] sr_close_pbreak`
    (Code-Default 0,60, Band 0,30–0,90; **ini seit 2026-07-24 = 0,55** auf User-Wunsch —
    liegt im validierten Optimum-Plateau 0,50–0,60, Hysterese-Zone damit 50/60).
    Snapshot `sr_close_hint {level, p_break,
    at_level, gap_atr, close, confirm}`. Hinweis existiert NUR mit offener Position.
    **`confirm` = Bruch-BESTÄTIGUNGS-Preis** (Fix 2026-07-22, User-Frage nach einem
    Trade, der am Level geschlossen wurde, obwohl der Kurs „durchgebrochen" war):
    `level ± 0,5×ATR` in Trade-Richtung — **dieselbe Definition wie beim Modell-
    TRAINING** (`_BRK_ATR=0,5`/`_BRK_W=12` in `backtest_srclose_prob.py`/
    `analyze_srwaves.py`). Ein Docht, der die nackte Levelzahl nur um wenige Cent
    überschreitet, zählt NICHT als Durchbruch — reales Fallbeispiel 2026-07-22:
    Close bei Level 85,943 (P(break) 31 %), Kurs wischte auf 85,994 (< Bestätigung
    86,017 = Level+0,5×ATR) und fiel zurück → nach Modell-eigener Definition eine
    ABLEHNUNG, keine Bestätigung; die Vorhersage war korrekt. `confirm` jetzt in der
    Log-Zeile („— Bestätigung erst ab X") UND im Frontend-Hinweistext (`#pos-srhint`,
    alle 3 Zweige: Vorwarnung/Close/Laufen) sichtbar — macht den Unterschied
    „Kurs > Levelzahl" vs. „strukturell bestätigter Bruch" auf einen Blick klar.
    **Live-Prognose-Tracking (2026-07-23, User-Wunsch „mitloggen wie oft richtig/
    falsch"):** jeder frische Level-Touch (`at_level` False→True) loggt EINMAL die
    aktuelle Vorhersage (`bounce` wenn P(break)<Schwelle, sonst `break`) in die neue
    Tabelle **`pbreak_predictions`** (`history.log_pbreak_prediction`, Felder u. a.
    `predicted`, `confirm_price`, `reject_price`, `atr`). Auswertung läuft separat,
    self-throttled ~5 min im `_trend_loop` (`engine._evaluate_pbreak_predictions`):
    prüft gegen `candles_m1`, ob der Kurs binnen 60 min zuerst `confirm_price`
    (→ outcome `break`) oder `reject_price` (→ `bounce`) erreicht — **exakt dieselbe
    Definition wie beim Modell-TRAINING** (`_BRK_ATR=0,5`/`_BRK_W=12` M5-Bars=60 min).
    Kein Treffer binnen 60 min → Timeout, zählt wie im Training als `bounce`. `correct`
    = `predicted==outcome`. Broker-Zeit-Offset (`trader._broker_offset_s()`) korrekt
    berücksichtigt (`pbreak_predictions.ts` = lokale Epoch, `candles_m1.time` = rohe
    Broker-Zeit — Ausnahme, s. „Auch beachten"). Abfrage: `history.pbreak_accuracy
    (period)` bzw. `GET /api/pbreak_accuracy?period=today|week|all` (read-only, kein
    Token) → `{n, accuracy, break_accuracy, bounce_accuracy, pending, …}`. Getestet
    mit synthetischen Szenarien (break/bounce/Gegenteil-falsch/Timeout) — alle 4 exakt
    wie erwartet. **Reine Messung, kein Signal-/Exit-Eingriff** — noch keine UI-Karte
    (Datensammlung; B4-artige Auswertung später möglich, wenn genug Zeilen vorliegen).
    **Gegen-/Stop-Seiten-Anzeige `stop_approach` (2026-07-24, User-Frage „Kurs nähert
    sich Support, aber keine Durchbruchwahrscheinlichkeit angezeigt"):** Der reguläre
    `sr_close_hint` beobachtet nur das **Ziel-Level** (LONG→Resistance, SHORT→Support)
    und wirkt nur im Plus — nähert sich der Kurs dem **Gegen-/Stop-Level** (LONG→Support
    darunter, SHORT→Resistance darüber, typ. Verlust-Trade), war die App bewusst still.
    Neu: `engine._stop_approach_hint` liefert für GENAU dieses Level eine **reine
    Anzeige** von P(Durchbruch) — Break-Richtung `-d` (gegen den Trade), Feature-/
    60-s-Glättung (`_stop_pb_state`) identisch zu `_sr_close_hint`. **KEIN Auto-Close.**
    Snapshot `stop_approach {level, side, p_break, at_level, gap_atr, confirm, reject}`,
    Frontend `#pos-stophint` (grün „Level hält wahrscheinlich" bei P<50, rot „bricht
    wahrscheinlich durch" bei ≥50; nur wenn KEIN Ziel-`sr_close_hint` läuft; v=109).
    **Vorher gemessen (`backtest_pbreak_calibration.py`, 2026-07-24, Gate „erst messen,
    dann bauen"):** Das kalibrierte P(break)-Modell (auf Ziel-Seite trainiert) hält
    auch auf der **Gegen-/Stop-Seite** — AUC **0,68/0,72** out-of-sample in BEIDEN
    Hälften (≈ Ziel-Seite 0,67/0,71), im niedrigen P-Bereich sauber kalibriert (der
    praktisch wichtige „hält der Support?"-Fall). ⚠ Einzige Schwäche: im HOHEN Bereich
    (P≥0,5) GEGEN den Trend unterschätzt es die Bruch-Rate ~10–13 Pp (predicted 58 % →
    echt 71 %) — also **konservativ** (warnt eher zu wenig vor einem Bruch), kein
    Kalibrierungs-Bruch. Deshalb reine Anzeige, kein Trade-Trigger.
    **Anti-Flattern (2026-07-14, gemessen `analyze_pbreak_flicker.py`:** mom3 der
    laufenden M5-Kerze ließ P 7–15 Pp/Bar springen, Max 77 Pp; 8 % der Annäherungen
    hatten ≥2 Schwellen-Flips): (1) **P zeit-geglättet** (~60-s-EMA in `_pb_state`,
    Reset bei Level-Wechsel/flat; angezeigtes `p_break` = geglättet) · (2)
    **Hysterese ±5 Pp** um die Schwelle — close↔laufen wechselt erst bei klarem
    Durchbruch (55/65 bei Default 0,60, liegt im Optimum-Plateau 0,50–0,60).
    **Dashboard-Schalter** in der
    Position-Kachel (`#srclose-btn`, grün=AN) → `POST /api/srclose` (Toggle,
    `engine.set_sr_autoclose`); Zustand `snapshot.auto_sr_close`. **AUTO-Close (`_check_sr_close` im `_pos_loop`,
    `auto_sr_close=true`):** schließt **nur im PLUS** (`pnl>0`) wenn `close=True`, 1×/
    Ticket, wirkt bei gesperrtem Handy. **Optionaler Mindestgewinn** (`[trading]
    sr_close_min_gain` Default 0=aus · UI `#srmin-input` · `POST /api/srclose_min` ·
    `set_sr_close_min_gain` · Snapshot `sr_close_min_gain`): unter der EUR-Schwelle
    wird am Level NICHT geschlossen. ⚠ Gemessen ist OHNE besser (Verworfen-Eintrag) —
    Opt-in auf User-Wunsch, UI-Status warnt. **Automatisch auf X % des Einsatzes
    (`[trading] sr_close_min_gain_pct`) — Stand 2026-07-29 wieder AUS (`=0`, User-Wunsch
    „gewinn close und notfall stop wieder auf leer beim Eröffnen")** (Verlauf: 1,0→3,0
    am 07-23 · 0 am 07-24 früh „nichts beim Öffnen setzen" · 3,0 am 07-24 abends zurück ·
    **0 am 07-29** — gilt NUR für den Gewinn-Close, der Auto-Notfall-Stop bleibt AUS).
    Bei `pct>0` wird bei JEDER echt neuen Position
    (nicht beim Wiedererkennen nach Neustart) `sr_close_min_gain` frisch auf
    `pct% × Margin dieser Position` gesetzt (`_check_auto_close`, retry-sicher via
    `_sr_close_min_gain_armed_ticket` — Margin aus `trader.refresh()` im selben
    `_pos_loop`-Tick, jeden Tick erneut versucht bis Margin>0; persistiert via
    `_save_runtime_state`, Log „Gewinn-Close armiert … +X (N% Margin Y)"). Bei `pct=0`
    wird beim Öffnen NICHTS gesetzt — dann bleibt der manuell im UI gesetzte/gemerkte
    `sr_close_min_gain` maßgeblich. ⚠ **Umstellen auf 0 braucht Neustart:** `_sr_close_
    min_gain_pct` lebt im Speicher; solange der alte Wert (3,0) läuft, re-armt JEDER neue
    Trade erneut — die ini-Änderung greift erst nach `restart_server.bat`. Beim 0-Stellen
    zusätzlich den persistierten Alt-Wert in `runtime_state.json` nullen (`sr_close_min_gain`)
    UND `emergency_state.json` `loss` (Erb-Falle, sonst restauriert der Neustart den Alt-Wert).
    **Gate verifiziert (2026-07-23, User-Nachfrage „darf nicht schließen bevor der
    Wert erreicht wurde"):** `_check_sr_close` prüft `pnl < sr_close_min_gain → return`
    **bevor** `_sr_close_hint`/`trader.close` überhaupt aufgerufen werden — isoliert
    mit 6 synthetischen Szenarien getestet (unter/exakt-auf/über Schwelle, P(break)
    hoch trotz Profit, Schwelle aus, Verlust-Trade) → alle korrekt. **Dabei echten
    Bug gefunden & gefixt:** die 1%-Berechnung lief nur EINMALIG beim Ticket-Wechsel
    (`if ticket != self._last_pos_ticket`); war `order_calc_margin` genau in diesem
    einen Tick 0/nicht verfügbar (Broker-Race direkt nach Order-Fill), blieb
    `sr_close_min_gain` für die GESAMTE Laufzeit der Position auf dem STALEN Wert der
    vorherigen Position hängen (der Ticket-Wechsel-Zweig feuert nur 1×, keine zweite
    Chance) — im ungünstigen Fall ein zu NIEDRIGER Alt-Wert, der den Trade dann exakt
    zu früh schließt. **Fix:** neuer State `_sr_close_min_gain_armed_ticket`
    (getrennt vom Notfall-Stop/TP-Restore-Zweig) — die %-Berechnung läuft jetzt JEDEN
    `_pos_loop`-Tick erneut, bis sie für das aktuelle Ticket einmal erfolgreich war
    (Margin>0), statt nur im Ticket-Wechsel-Moment. Wiederhergestellte Positionen
    nach Neustart markieren sich sofort als „armiert" (kein Überschreiben des
    persistierten Werts) — mit Test verifiziert. Log `🎯 S/R-AUTO-CLOSE` + Telegram + Toast
    (`sr_close_count`), `closed_by=sr_close`. UI Position-Kachel: bernstein „Durchbruch
    nur X% → Bot schließt" bzw. grün „Durchbruch X% wahrscheinlich → läuft weiter".
    Abschalten `auto_sr_close=false` / `set_sr_autoclose(False)`; Schwelle via
    `sr_close_pbreak`. Kein pauschaler S/R-Close (2× verworfen) — nur mit P(break)-Gate.
  - **S/R-verankerter SL = KEIN Edge (gemessen, `backtest_sl_method.py`):**
    Pivot+Band vs. „S/R ∓ ATR/0,10-Puffer" vs. fest 2,0×ATR — **gedeckelt alle
    identisch** (Ø-R 0,196–0,201, PF 1,38–1,39, Worst −2,2×ATR): der **Band-Cap
    [1,8–2,2]×ATR dominiert**, die Verankerung ist Rauschen. Nur **ungedeckelt**
    sieht S/R besser aus (Ø-R 0,249) — aber Worst-Case **−11,4×ATR** (Kontokiller
    bei 90 %-Sizing) → verworfen. Aktuelle SL-Logik bleibt.
  - **SL-ATR-Timeframe bei Squeeze-Trades (M5-Signal, aber SL_TF fix M15) = GEPRÜFT,
    KEINE Änderung (gemessen `backtest_sl_tf_mismatch.py`, 2026-07-23, Auslöser
    −89,36-€-Nacht-Trade):** `_calc_sl_tp` sizt den Initial-SL IMMER aus M15-ATR,
    unabhängig vom Signal-TF — bei Squeeze (M5-Signal) kann das stark divergieren
    (real: M5-ATR fiel 0,29→0,10 — genau die Kompression, die den Squeeze auslöste —
    während M15-ATR noch bei ~0,36 lag → SL 0,787 statt ~0,22 bei M5-Sizing). Der
    validierte Squeeze-Backtest (`backtest_breakout_squeeze.py`) nutzt durchgehend
    M5-ATR für den SL — Live weicht hier vom Backtest ab. **2-Stichproben-Test der
    Umstellung auf M5-ATR-SL bei Squeeze-Trades: GEMISCHT** — H1 leicht besser
    (ØR +0,167 vs +0,064, ΣR +35 vs +13), H2 (größere, aktuellere Stichprobe) klar
    SCHLECHTER (WR 51 % vs 59 %, ΣR +281 vs +323) → fällt nach der beidhälftig-
    robust-Regel durch. Der breitere M15-SL kassiert gelegentlich einen vollen
    Verlust wie diese Nacht, verhindert aber mehr vorzeitige Ausstoppungen bei
    normalen Rücksetzern — netto vorteilhaft. **Keine Änderung.**
- **Inter-Market (Brent-Bestätigung / DXY-Gegenwind) = VERWORFEN (gemessen
  `backtest_intermarket.py`, 2026-07-19, letzte ungetestete Indikator-Klasse):**
  1366 Trades, seq. Sim, Live-Exit, Echtkosten, 2 Halbjahre; Buckets nach Zustand
  am Entry (Symbole: `SpotBrent`, `USDX`). **Beide Hypothesen kippen zwischen den
  Hälften:** (A) Brent-Trend dagegen H1 −0,002 vs H2 −0,187 (H1 sogar BESSER als
  „dafür"!), Brent-Mom-1h dagegen H1 **+0,311**/H2 −0,233 = Flip; (B) DXY-Gegenwind
  H1 −0,13…−0,19 (schlechter, wie vermutet) aber H2 **+0,13…+0,17 = BESSER als
  Rückenwind** — komplett invertiert, klassische Regime-Abhängigkeit (wie H1-Stärke-
  Filter/Momentum). Einzig Brent-Mom-3h ist richtungs-konsistent, aber winzig
  (Δ~0,06–0,14) und die Schwester-Varianten kippen → nach der vorab festgelegten
  Verdict-Regel (beide Hälften UND Varianten-robust) **kein Einbau**. Damit ist auch
  die letzte orthogonale Indikator-Klasse durch: **am Signal ist nichts mehr zu
  holen — Hebel bleiben Sizing/Exit/Verhalten** (nicht gegen das Signal handeln:
  live gemessen 39 % WR / −166 € vs. mit 55 % / +65 €).
  `backtest_confluence.py` — MACD/ADX-Richtung praktisch neutral, ADX-Stärke leicht
  negativ, ein MACD+ADX-Gate senkt den Edge (−78 % Trades). RSI *bestätigend* ist
  kontraproduktiv (RSI *gegen* Richtung = doppelter Edge = der Pullback-Effekt, den
  der „⭐ tiefer Pullback"-Bonus schon nutzt). Standard-Oszillatoren also nicht
  draufsatteln. Mehrquellen-Redundanz läuft bereits über die Gesamtempfehlung.
- **TradersUnion (TU) aus der Empfehlung ENTFERNT (User-Vorgabe 2026-07-06):** TU ist
  Standard-Indikator-Konsens (MA/Oszillator-Ratings einer Website) — **dieselbe Klasse
  wie MACD/ADX/RSI = kein Edge**, plus **Latenz** (5m „Strong Buy" während 4h/1d „Strong
  Sell") und **nicht backtestbar** (Live-Scrape, keine History). Floss vorher als
  Konfidenz-Faktor (`_tu_check` ±6/−8 je 5m/15m) UND als Verdict-Stimme ein — **beides
  neutralisiert** (`wave_rec._build` zieht `_tu_check` nicht mehr; `_verdict` ohne
  TU-Vote). ⚠ Nebenbefund: der Konfidenz-Pfad hatte **keinen** `_STALE_S`-Check (nur
  `trade_signal` hatte ihn) — mit der Entfernung erledigt. TU bleibt **reine Anzeige**
  (Snapshot `tu`); `_tu_check`/`_TU_*` als Code erhalten (reaktivierbar). Fetch war
  auf 5 min gedrosselt (`_TU_S=300`); **Loop seit 2026-07-19 ganz stillgelegt**
  (`_tu_loop` nicht mehr in `start()` — TU ist aus Empfehlung/Verdict/Copilot raus
  UND die Kachel ausgeblendet, der Scrape lief für niemanden; reaktivieren = Loop
  wieder in die Liste). Elliott loggt nur noch **bei Änderung** (vorher
  ~6k identische Zeilen/Logrotation).
- **Order ohne Empfehlung = bestätigbarer HINWEIS, kein Block:** Bei WARTEN/
  Gegen-Signal zeigt das Frontend einen **Bestätigungs-Dialog** („… trotzdem
  eröffnen?") — bestätigen = Trade läuft, Abbrechen = kein Trade. **Kein** hartes
  Blockieren (überschreibbar). `engine._open` blockt nicht (loggt nur).
  ⚠ **Log-Quellen-Attribution (Fix 2026-07-29):** `_open(fn, want, source)` bekommt
  jetzt eine `source` (Default `"manuell"`); der Auto-Squeeze ruft `open_long/short
  (source="auto_squeeze")`. Vorher schrieb `_open` bei JEDEM Auftrag gegen die
  Empfehlung „— vom User bestätigt" — auch bei autonomen Squeeze-Entries (der User
  fragte, ob ein Trade auto/manuell war; die Zeile log fälschlich „User"). Jetzt:
  autonome Orders → „autonom vom Auto-Squeeze eröffnet", manuelle → wie bisher. Die
  `🚀 AUTO-SQUEEZE-ENTRY`-Zeile bleibt die eindeutige Quelle der Wahrheit.
- **„Erst messen, dann umbauen":** Strategie-Änderungen per Backtest belegen, nicht
  raten. Gegen-Trend verliert; nicht bei WARTEN handeln. **Stichproben ~28 Tage** —
  ein Trend-Regime; Befunde später auf mehr/andere History gegenprüfen.
- **Wave-Auto-Trader (Dry-Run) KOMPLETT ENTFERNT (2026-07-23, Code-Review-Fund):** war
  seit Langem Verlierer (WR 29 % / PF 0,64) vs. manuelle Trades (WR 56–76 %); UI-Toggle
  bereits vorher entfernt (Dashboard-Button steuert seitdem Auto-Squeeze), lief aber
  weiter dormant bei jedem Tick mit (toter Ballast). `core/auto_trader.py` gelöscht
  (Sicherung: `.removed_backup/`), `engine.self.auto` + alle 4 Aufrufstellen
  (`_price_loop`, `_run_analysis`, `toggle_auto`, Snapshot-Keys `auto`/`min_conf`)
  sowie die tote `auto`-Referenz in `TradingAgent.__init__` entfernt, `/api/auto`
  gelöscht. `min_conf` (Frontend-Warnschwelle „Order ohne Signal") lebt jetzt als
  eigene Konstante `_MIN_CONF_DISPLAY=70` in `engine.py`. Die `intended_trades`-DB-
  Tabelle + `history.intended_*`-Methoden bleiben (historische Daten, kein Schreiber
  mehr aktiv). Manuelles Handeln bleibt der validierte Edge auf dem Wave-Signal.
  - **RE-TEST 2026-07-30 (User-Wunsch „Trades bei Empfehlung automatisch eröffnen") =
    ERNEUT VERWORFEN, gemessen `backtest_auto_signal.py`:** Auto-Entry auf dem Wave-
    Signal mit den HEUTIGEN Gates, echte `_build`-Logik (kein Nachbau), M30-/H1-Trend
    aus M5 aggregiert und in `_build` gefüttert, sequentielle 1-Positions-Sim, Live-Exit
    (SL 2,0/Trail 1,5/BE 1,3/Time-Stop 120 min), Echtkosten (Bar-Spread/ATR), 80k M5-Bars
    in 2 Halbjahren. **ALLE 8 Varianten fallen durch** (Konf-Schwelle 55/65/70/75 ×
    Nacht-Sperre an/aus): **H1 durchgehend NEGATIV** (ØR −0,076…−0,182, PF 0,78–0,90),
    **H2 durchgehend positiv** (+0,112…+0,167) → klassisches Regime-Kippen, n=718–1167
    je Hälfte (keine Stichproben-Frage). ⚠ **Kontroll-Beleg, dass es am SIGNAL liegt und
    nicht an der Sim:** der Squeeze läuft durch DIESELBE Exit-/Kosten-Maschinerie und ist
    in H1 **+0,187/PF 1,29** — die Simulation funktioniert also, nur das Wave-Signal trägt
    in H1 nicht. Deckt sich exakt mit dem Live-Dry-Run (WR 29 %/PF 0,64). Nebenbefunde:
    (a) höhere Konfidenz hilft NICHT monoton (75 schlechter als 65) — bestätigt
    `analyze_verdict_calibration.py` (conf_pct ist NICHT kalibriert, in H2 invertiert),
    ein „nur bei hoher Konfidenz"-Auto-Entry ist damit auch erledigt; (b) die Nacht-Sperre
    verbessert konsistent (H1 −0,172→−0,123), reicht aber nicht; (c) ⚠ **Methodik-Lehre:**
    ein Vorlauf mit nur 6k Bars zeigte „Konf≥65+Nacht TRÄGT" — der 80k-Lauf drehte das
    komplett (n war 60–99/Hälfte = Rauschen). **Kleine Stichprobe hätte hier zum Fehl-
    Einbau geführt.** Warum manuelle „MIT Signal"-Trades trotzdem profitabel sind
    (+118 €/WR 56 %, `analyze_entries`-Auswertung 2026-07-30): **menschliche AUSWAHL**
    unter den Signalen (Kontext/Tageszeit/Marktlage), nicht „alle nehmen" — die
    Grundgesamtheit ALLER Signale ist der Verlierer. **14. verworfener Signal-Eingriff.**
- **Auto-Signal-Entry = TROTZDEM GEBAUT auf ausdrücklichen User-Wunsch (2026-07-30,
  „probieren wir es trotzdem mal"), `[trading] auto_signal`, Default FALSE.** ⚠ **Der
  Backtest direkt darüber sagt NEIN** (H1 durchgehend negativ) — der User hat das nach
  vollständiger Information (inkl. Live-Dry-Run-Historie WR 29 %/PF 0,64) bewusst
  entschieden. Gebaut mit den **gemessen BESTEN** Parametern, nicht mit Default-Raten:
  `auto_signal_min_conf=75` (mit Nacht-Sperre H1 −0,053 = mildester Verlust, H2 +0,141
  = bestes Netto; ⚠ NICHT weil „mehr Konfidenz besser" — conf_pct ist unkalibriert, 75
  ist empirisch) und `auto_signal_skip_night=true` (verbessert JEDE Variante).
  **Mechanik** (`engine._check_auto_signal` im `_pos_loop`, 1 s, NACH den Close-Checks):
  eröffnet nur **FLAT**, nur bei `wave.signal()` LONG/SHORT mit `conf_pct ≥ min_conf`,
  **1× je Signal-Episode** (Dedup `_signal_last_sig`, re-armt bei WARTEN/Flip — nicht
  über den Preis wie beim Squeeze, weil das Signal keine Level-Marke hat); erbt die
  Squeeze-Guards: Circuit-Breaker, Nacht-Sperre, S/R-Close-Cooldown, allgemeine
  Wiedereinstiegs-Sperre. **Kein Nachkauf** bei gleichgerichteter Position, **kein
  Drehen** einer Gegen-Position (unbelegt, wie Squeeze-Reverse). Log `🎯 AUTO-SIGNAL-
  ENTRY` + Telegram, Setup-Tag `AUTOSIG_<dir>` (macht die Trades in der DB separierbar
  → B4-Monitor). Snapshot `auto_signal`/`auto_signal_min_conf`/`signal_entry_count`,
  Toggle `POST /api/autosignal` = Dashboard-Button **🎯 SIG** (bernstein statt blau,
  weil gemessen nicht tragfähig; zeigt die Schwelle an), neustart-fest via
  `runtime_state.json`. **B5-Pflicht:** Live-ØR/PF gegen die Backtest-Erwartung halten
  (H2-Regime +0,14 vs H1-Regime −0,05) — driftet es weg, **zurückbauen** (`=false`).
- **15-Minuten-Regel (`[trading] adverse_15min_atr=0.5`, AKTIV, User-Wunsch 2026-07-30
  „wenn der Trade nach 15 Minuten gegen die Richtung läuft schließe ihn"):** steht ein
  **vom BOT eröffneter** Trade 15 min nach Entry ≥ X×ATR_M5 gegen die Richtung →
  schließen (`engine._check_adverse15`, `closed_by=adverse15`, Log ⏱ + Telegram).
  ⚠ **Schwelle GEMESSEN kalibriert, NICHT die ursprüngliche Vorgabe** (`backtest_auto_
  signal.py`, 15-Min-Achse): „sobald im Minus" (0,0) ist die **SCHLECHTESTE** Variante
  (WR bricht 39→31 %, Netto-ØR −0,067 vs +0,026 ohne Regel) — sie kappt Trades, die
  sich erholt hätten. **0,5×ATR ist die beste Regel-Variante** (H1 −0,111→−0,079).
  Netto über beide Hälften bringt die Regel ~nichts (+0,001 vs +0,026 **ohne**) → sie
  ist ein **REGIME-Schutz** (hilft im schlechten Regime, kostet im guten), bewusst als
  Sicherheit akzeptiert. **2. unabhängige Bestätigung** von `backtest_adverse_nosignal.py`
  (dort fiel der Adverse-Exit bei JEDER Schwelle durch). Greift **NICHT bei manuellen
  Trades** (`_bot_open_ticket`-Marker — dort bleibt die Diskretion beim User, gemessen
  sein Vorteil) und nicht in der Startup-Schonfrist; **1× je Ticket** geprüft
  (`_adverse15_done_ticket`) genau beim 15-min-Zeitpunkt. Snapshot `adverse15_atr`/
  `adverse15_count`. 0 = aus. Mit **18 synthetischen Szenarien getestet** (9 Entry:
  Konf-Gate, Dedup, WARTEN-Re-Arm, Nachkauf, Gegen-Position, Cooldown, Toggle,
  Nacht-Sperre · 9 Adverse: über/unter Schwelle, zu früh, im Plus, SHORT-Richtung,
  manueller Trade, aus, 1×-je-Ticket, Startup-Grace) — alle korrekt.
- **Auto-Squeeze-Entry = LIVE AUTONOM (User-Vorgabe 2026-07-16, `[trading]
  auto_squeeze=true`, Default FALSE):** der Bot eröffnet **selbständig eine echte
  Order**, sobald der **gemessen-validierte** Squeeze-Ausbruch feuert (`wave.squeeze.
  state=='active'`) UND **flat** ist — NICHT auf dem Wave-Signal (das ist der
  Dry-Run-Verlierer), sondern nur auf dem 2-Stichproben-positiven Squeeze.
  `engine._check_auto_squeeze` im `_pos_loop` (1 s): **1× je Ausbruch** (Dedup über
  (dir, level); re-armt, wenn der Squeeze klärt), öffnet via `open_long/short` (→
  Trailing an, Emergency-Stop armiert 2 % beim nächsten Tick), Log `🚀 AUTO-SQUEEZE-
  ENTRY` + Telegram + Fehlschlag-Push. Snapshot `auto_squeeze`/`squeeze_entry_count`;
  Toggle `POST /api/autosqueeze` (`set_auto_squeeze`) = Dashboard-Button **🚀 BRK**
  (blau=AN, ersetzt den alten Dry-Run-AUTO-Button). **Dead-Hour-Guard = AN
  (User-Vorgabe 2026-07-24, `[trading] auto_squeeze_skip_night=true`):** der Bot
  eröffnet **nachts 0–7 Uhr KEINE** Squeeze-Trades (`_SQUEEZE_NIGHT=(0..7)`,
  `_squeeze_skip_night` → `_check_auto_squeeze` return; kein Entry UND kein Reverse).
  Doppelt begründet: (1) **gemessen** unrentabel (`backtest_realcosts.py`, Spread÷Nacht-
  ATR 0,32–0,50×ATR, beide Halbjahre negativ = Kostenfalle) und (2) **kein Trade
  soll unbeaufsichtigt nachts feuern, während der User schläft** — Auslöser: „müsste
  automatisch schließen wenn ich nicht da bin, z. B. nachts". Der Guard LÖST das,
  indem er den Trade gar nicht erst öffnet; tagsüber (User eher erreichbar) läuft der
  bestehende Auto-Close-Stack (Broker-SL 2×ATR broker-seitig + Trailing + Time-Stop +
  S/R-Close). ⚠ Historie: bis 2026-07-17 war der Guard AUS (User wollte rund um die
  Uhr), am 2026-07-24 auf User-Wunsch **zurück auf AN**. `=false` schaltet ihn wieder
  aus (dann auch nachts, unbeaufsichtigt). Einen engen Schutz-%-Stop NUR für Squeeze
  wurde bewusst NICHT gebaut (enger %-Stop unter Margin-Sizing wird vom Squeeze-
  Rauschen ausgelöst, −48,94-€-Tag — der Squeeze braucht Raum).
  **Stop-&-Reverse = AUS (Default, `[trading] auto_squeeze_reverse=false`,
  `_squeeze_reverse`; User-Vorgabe 2026-07-17):** War kurz scharf, dann abgeschaltet —
  nur der **flat-Entry ist gemessen-validiert**, der Reverse ist unbelegt, verdoppelt
  Kosten und dreht am **Ausbruch-Extrem** (real 2026-07-17 18:55: WAVE_REV_SHORT gegen
  einen News-Rally-LONG-Ausbruch bei −29,64 € geschlossen, dann LONG am Erschöpfungs-Top
  82,32 — Elliott „impulse_up/5 exhausted" im selben Moment). Bei `false` bleibt ein
  Gegen-Trade **unangetastet** (Drehen = manuelle Entscheidung); `_squeeze_last_sig`
  wird dann NICHT gesetzt → schließt der Gegen-Trade (SL/manuell), kann der flat-Entry
  auf denselben Ausbruch noch feuern. Bei `true` (historisch, reaktivierbar): läuft ein
  Trade GEGEN den Ausbruch (auch manueller/Fremd-Trade!) → sofort `close(reason=
  "squeeze_reverse")` (Log 🔄 + Telegram, Dedup `_squeeze_reverse_sig`), nächster flat-Tick
  dreht. ⚠ NICHT gemessen (der Squeeze-Backtest nahm flat-Entry an) — deshalb Default aus.
  **Exit-only-Variante („Gegen-Position beim Ausbruch schließen, OHNE Re-Entry") =
  VERWORFEN (gemessen `backtest_squeeze_exit.py`, 2026-07-22, User-Idee „Breakout
  schneller schließen"):** die sicherere Halb-Variante (nur schließen, nicht drehen)
  fällt ebenfalls durch — in BEIDEN Hälften schlechter als der Live-Exit (SL 2×ATR+Trailing):
  ΔΣR H1 −15 (immer)/−5 (nur im Minus), H2 −27/−29. Grund: der Gegen-Ausbruch ist oft ein
  Fehlausbruch/Whipsaw → die Position prallt zurück, der frühe Close kappt Trades, die
  sich erholt hätten. Der 07:38-Fall (LONG lief zum SL während SHORT-Ausbruch) war Varianz.
  **Fazit: Squeeze taugt als ENTRY (validiert), NICHT als Gegen-EXIT.** Der einzige
  Speed-Hebel bleibt die schnellere Erkennung (Variante A, ~5 s).
  **Re-Test unter Vola-Regimen = ERNEUT VERWORFEN (gemessen
  `backtest_squeeze_exit_vol.py`, 2026-07-24, User-Frage „Markt gerade sehr volatil —
  wirklich nicht profitabel?"):** Verschärfter Test mit echten SQUEEZE-Entries (statt
  EMA-Crosses), 4 Varianten (immer/nur-im-Minus/nur-Verlust>0,5×ATR), ATR-Terzil-Split
  je Hälfte + Extra-Fenster letzte ~30 Tage. Ergebnis: Effektgröße überall ~0
  (±0,002–0,005 R/Trade bei ~1150 Trades/Hälfte), **Vorzeichen kippt zwischen den
  Regimen** (MODL: H1-Hochvola −1,6 / H2-Hochvola +3,0 / letzte 30 Tage −0,3) → nach
  der vorab festgelegten Regel (beide Hälften UND Hoch-Vola-Terzil ≥ BASE) fällt JEDE
  Variante durch. **Kernbefund: Worst-Case ist in ALLEN Varianten identisch**
  (−2,33/−2,47 = SL-Deckel) — der Gegen-Squeeze-Exit reduziert das Tail-Risiko um
  exakt 0, weil bei echten schnellen Brüchen immer der SL zuerst greift; er kappt nur
  langsame Kriecher, von denen sich >50 % erholt hätten. (Methodik-Hinweis: absolute
  ØR pessimistischer als im validierten Squeeze-Backtest — Entry am Bar-Close statt
  am Level, keine Flat-Bedingung; für den Varianten-VERGLEICH neutral, da alle Exits
  denselben Entries folgen.) 3. Messung derselben Idee (Reverse · Exit-only ·
  Vola-Regime-Re-Test) — gleiche Antwort.
  **S/R-Close kappt Squeeze-Runner? = GEPRÜFT, KEINE Änderung (gemessen
  `backtest_squeeze_srclose.py`, 2026-07-24, User-Beobachtung „Squeeze wird direkt am
  nächsten S/R geschlossen"):** Der Log bestätigt, dass Auto-Squeeze-Trades regelmäßig
  vom P(break)-S/R-Auto-Close am nächsten Gegen-Level geschlossen werden (der Squeeze
  wurde mit reinem Trailing validiert, ist runner-abhängig — Verdacht: Runner gekappt).
  Direkter Vergleich NUR auf Squeeze-Entries (Box≤2,5×ATR, k=0,1): **Exit A = nur
  Trailing (validiert)** vs. **Exit B = +S/R-Close (aktuell live)** = **Wash, kein
  robuster Schaden** — H1 ØR +0,190→**+0,224** (ΣR +40→+47, B besser), H2 ØR
  +0,394→+0,377 (ΣR +290→+278, B marginal schlechter) = Δ ±0,02 R/Trade (Rauschen).
  **Warum unkritisch:** der S/R-Close ist P(break)-gegated (schließt nur wenn Level
  wahrscheinlich HÄLT, P<60 %) → echte, starke Ausbrüche haben hohe P(break) und
  laufen weiter; **PF/Runner-Tail bleiben erhalten** (H2 PF 1,58=1,58), nur die WR
  steigt (50→55 %, Abpraller früher als Klein-Gewinn kassiert). Squeeze-Trades vom
  S/R-Close auszunehmen ist also NICHT belegt. (Reaktivierbar per Toggle, falls der
  User trotzdem die Runner nie kappen will — kostet gemessen ~nichts, ist aber
  Präferenz, kein Edge.)
  **S/R-Close-Cooldown (2026-07-17, Koordinations-Fix, kein Backtest):** nach einem
  S/R-Auto-Close eröffnet der Auto-Squeeze **~3 min (`_SQUEEZE_SR_COOLDOWN_S=180`)
  nicht in GLEICHER Richtung** wieder. Grund: der S/R-Close ging von „Level hält"
  (P(break)<Schwelle) aus, ein sofortiger Gleichrichtungs-Squeeze („Level bricht") war
  der widersprüchliche 1-s-Roundtrip (LONG-Close +15 → 1 s später neuer LONG, doppelter
  Spread; real beobachtet 2026-07-17 14:17). `_check_sr_close` merkt Zeit+Richtung
  (`_sr_close_ts`/`_sr_close_dir`), der Entry-Pfad prüft sie; `_squeeze_last_sig` wird
  NICHT gesetzt → nach Ablauf feuert der Ausbruch, falls noch aktiv. **Der Reverse
  (Gegenrichtung) bleibt unberührt** — nur der Gleichrichtungs-Wiedereinstieg wird
  verzögert.
  **Allgemeine Wiedereinstiegs-Sperre nach JEDEM Close (2026-07-28, Koordinations-Fix,
  kein Backtest):** nach dem Schließen eines Trades durch **Notfall-Stop / Broker-SL /
  Time-Stop / manuell** eröffnet der Auto-Squeeze **~3 min (`_SQUEEZE_REENTRY_COOLDOWN_S=
  180`) nicht in GLEICHER Richtung** wieder. Grund: real am **2026-07-27 15:39** killte
  ein zu enger manueller −3-€-Notfall-Stop (Sub-Spread bei Margin-Sizing) den Auto-
  Squeeze-Entry #1 nach **16 s**; der Squeeze war noch `active` → sofortiger Re-Entry #2
  (Open→Instant-Close-Kaskade, doppelter Spread). `_check_auto_close` erfasst den Flat-
  Übergang (`_pos_close_ts`/`_pos_close_dir`, Richtung via `_open_pos_dir` solange offen),
  der Squeeze-Entry-Pfad prüft ihn NACH dem S/R-Cooldown; `_squeeze_last_sig` wird NICHT
  gesetzt → nach Ablauf feuert der Ausbruch, falls noch aktiv. Gegenrichtung/Reverse
  unberührt. Deckt alle Close-Arten außer dem S/R-Close ab (der hat seinen eigenen
  Marker). ⚠ Behebt das *Symptom*; der eigentliche Auslöser war der Sub-Spread-Stop
  (`emergency_min_eur=3`-Guard fängt <3 € ab, −3 € genau auf der Grenze war zulässig).
- **TF-Wechsel nicht mehr persistiert:** `engine._apply_wave_tf` merkt den
  Heuristik-TF nur im Speicher (kein `save_config` mehr) — sonst würde die
  Secrets-`ini` bei jedem Switch neu geschrieben (Kommentar-Verlust/Churn). Beim
  Neustart wählt die Heuristik den TF binnen 1 min neu.
- **Circuit Breaker (Tagesverlust-Stopp) = gebaut, aktuell AUS `[trading]
  daily_loss_limit_pct=0` (User schaltete ihn am 2026-07-27 wenige Stunden nach dem
  Einbau wieder ab). Kurz auf 8 aktiv (Überlebens-Basis, mit dem Autonomie-Ziel
  reaktiviert nach jahrelanger Ablehnung), dann `=0`. Reaktivieren = ini auf z. B. 8.**
  Mechanik bei `>0`: erreicht der **Tages-P&L
  (realisiert heute + offene Position)** −pct % der Balance, schließt der Bot die
  Position (`closed_by=circuit_breaker`) und sperrt **neue Auto-Trades bis zum
  nächsten Tag** (`_check_auto_squeeze` prüft `_circuit_halted()`). `_check_circuit_
  breaker` im `_pos_loop` (1 s, unter Startup-Grace pausiert), realisierter Tages-P&L
  ~30 s gecacht (`_day_realized_cached`), Berlin-Datum als Trip-Marker (`_circuit_
  tripped_date`) → automatischer Reset am neuen Tag. Log 🛑 + Telegram (eigener,
  nicht vom Close-Gate betroffen). Snapshot `circuit_breaker {enabled, limit_pct,
  limit_eur, day_total, tripped}`, Frontend `#circuit-banner` (rot bei ausgelöst,
  bernstein ab 60 % des Limits, v=115). ⚠ **80 %-Margin-Sizing bleibt** (User-
  Entscheidung, 3.+ Mal bestätigt; `risk_pct=0`) → der 8 %-Tagesstopp schützt v. a.
  gegen die **Verlust-Serie/-Kaskade**, NICHT vollständig gegen den Einzeltrade
  (dessen 2×ATR-SL unter 80 % Margin allein schon >8 % verlieren kann). 0 = aus.
  Mit 5 synthetischen Szenarien getestet (nicht-zu-früh · Trip+Close · kein
  Doppel-Close · aus · Auto-Squeeze-Block). ⚠ Der frühere „NICHT einbauen"-Grund
  gilt nicht mehr — Ziel hat sich zu **autonomem Handel** verschoben, und ein
  unbeaufsichtigter Agent braucht die Notbremse im Code.
- **Notfall-Stop = AUS beim Öffnen (Stand 2026-07-24, `auto_emergency_margin_pct=0`,
  `auto_emergency_pct=0`, `auto_emergency_loss=0`).** User-Vorgabe 2026-07-24: „gewinn
  close und notfall close … nicht setzen beim Eröffnen" → alle drei Auto-Arm-Modi 0,
  beim Öffnen einer Position wird KEIN Notfall-Stop gesetzt. Nur ein **manuell** im
  UI-Feld eingegebener Wert armiert (bleibt bis zum nächsten Positionswechsel).
  **⚠ Vertipper-Schutz `[trading] emergency_min_eur=3` (Fix 2026-07-27):** ein manuell
  gesetzter Notfall-Stop UNTER diesem Minimum wird als „aus" behandelt (nicht
  scharfgestellt) + Log-Warnung. Grund: ein Sub-Spread-Wert schließt den Trade
  **sofort** UND vererbt sich per `_emergency_remember` auf ALLE Folge-Trades — real
  am 2026-07-27 setzte der User versehentlich −1 € → jeder neue Trade wurde in
  Sekunden per Notfall-Close gekillt (Tickets 48504360/48504814 u. a., „sofort
  geschlossen"). Guard in `set_emergency` (greift NUR auf die manuelle Eingabe;
  die %-Auto-Arm-Pfade sind eh 0). 0 = kein Floor.
  Kurz-Historie des margin-%-Modus: 2026-07-17 komplett raus (2 % ≈ 0,76×ATR zerschoss
  die Squeeze-Trades, −48,94-€-Tag) · 2026-07-20 wenige Stunden als **3-%-GAP-NETZ
  (Balance-Basis)** mit `risk_pct=1.5` · **2026-07-23 kurz margin-basiert `=3.0`**
  (dritter Modus, ausgelöst durch zwei Notfall-Closes am selben Abend −11,20 €/−20,47 €,
  wobei die Schwelle beim ersten Trade noch auf einem händischen UI-Restwert von −5 €
  hing) · **2026-07-24 auf User-Wunsch wieder ganz AUS.** Der margin-%-Modus bleibt im
  Code (retry-sicheres Armieren via `_emergency_margin_armed_ticket`, hat Vorrang vor
  Balance-%/Fixwert wenn >0), reaktivierbar per ini. ⚠ Kopplungs-Regel (falls
  reaktiviert): unter Margin-Sizing kann ein enger %-Stop schneller greifen als der
  2×ATR-SL. Schutz-Stack aktuell: **Broker-SL 2×ATR + Trailing + Time-Stop** (der
  Auto-Notfall-Stop ist inaktiv).
  **UI-Feld** (`#emg-input`, User-Vorgabe 2026-07-22, v=105) in der Trade-Leiste
  (rot, neben Gewinn-Close), Enter blurrt nur (kein Doppel-Send/ungewolltes 0,
  gleicher Fix wie Mindestgewinn 2026-07-22) — ein am Handy gesetzter Wert
  überschreibt den Auto-Arm für den laufenden Trade und bleibt bis zum nächsten
  echten Positionswechsel maßgeblich (mit Test verifiziert). ⚠ Server-seitig: wirkt
  nur bei laufendem Server (Update-Reboot-Lücke → „Auch beachten"). Der Server
  schließt die Position
  **sofort**, sobald `P&L ≤ −Wert` (`engine._check_emergency` im `_pos_loop`, 1 s;
  wirkt auch bei gesperrtem Handy). **Auto-Arm — drei Modi (Priorität: margin-% >
  Balance-% > Fixwert):**
  (a) **NEU — % der Einsatz-Margin dieser Position (aktiv, User-Vorgabe 2026-07-23):**
  `[trading] auto_emergency_margin_pct=3.0` → Schwelle = **pct% × Margin** (dieselbe
  Margin wie beim Gewinn-Close, aus `trader.refresh()`). **Retry-sicher** (Fix
  2026-07-23, gleiches Muster wie beim Gewinn-Close): läuft NICHT nur einmalig beim
  Ticket-Wechsel, sondern jeden `_pos_loop`-Tick erneut, bis `order_calc_margin`
  einmal >0 liefert (`_emergency_margin_armed_ticket`-Retry-Schutz) — verhindert,
  dass bei einem Broker-Race im ersten Tick nach dem Öffnen dauerhaft ein stalen
  Wert der vorherigen Position hängen bleibt. Mit 4 synthetischen Szenarien
  verifiziert (sofort verfügbare Margin · verzögerte Margin/Retry · manuelles
  Überschreiben bleibt erhalten · Neustart überschreibt NICHT). Snapshot
  `emergency_margin_pct`.
  (b) **% des Kontos (Fallback, wenn margin-%=0):** `[trading] auto_emergency_pct=2.0`
  → bei jeder neuen Position wird die Schwelle auf **pct% × Balance** gesetzt
  (`_emergency_pct`, skaliert mit dem Konto; z. B. 2 % von 831 € = −16,62 € ≈
  0,4×ATR; 1× auf 1 % getestet, war zu eng → 2 %). UI-Feld zeigt im Flat-Zustand
  den dynamischen Wert (Frontend rechnet `pct%×balance`, Snapshot `emergency_pct`).
  (c) **Fixwert (Fallback, wenn beide %-Modi aus):** Schwelle = **zuletzt
  genutzter Wert** (`_emergency_remember`, Startwert `[trading] auto_emergency_loss`
  Default **10**, 0 = aus).
  Setzt der User im UI einen neuen Wert, wird der gemerkt und ab dem nächsten Trade
  übernommen. Aktiver Stop verfällt nach Auslösen UND bei Positions-Close, der
  gemerkte Wert bleibt. **Neustart-fest (Fix 2026-07-17, `emergency_state.json`):**
  Der aktive Notfall-Stop/TP wird mit dem **Ticket** persistiert (`_save/_load_emergency_
  state`, atomarer Write; bei Auto-Arm UND manuellem Set). Erkennt der Server dieselbe
  offene Position nach einem `restart_server.bat` wieder, **stellt er den persistierten
  Wert wieder her** (`_check_auto_close`: `ticket == _emergency_state_ticket` → restore,
  Log „Auto-Close wiederhergestellt") statt auf die pct-Automatik zurückzuarmieren. Grund:
  real am 2026-07-17 14:30 setzte ein Neustart bei offenem Trade die von Hand gesetzten
  −25 € auf −19,42 € (2 %) zurück → Notfall-Close bei −19,64 statt bei −25. Eine echt
  neue Position (anderes Ticket) armiert normal aus pct/Merkwert und persistiert neu.
  ⚠ **Trailing-Zustand ebenfalls neustart-fest (Fix 2026-07-29):** `emergency_state.json`
  persistiert jetzt zusätzlich `trail` (= `trail.enabled`) per-Ticket. Erkennt der Server
  dieselbe Position wieder und war das Trailing vor dem Neustart AN, **reaktiviert er es
  automatisch** (`_check_auto_close`-Restore-Zweig → `trail.toggle`, Log „Trailing
  wiederhergestellt … nach Neustart"). Grund: real am 2026-07-29 lief eine Auto-Squeeze-
  Position nach mehreren Server-Neustarts nur mit dem **Broker-SL** (Trailing/Breakeven/
  Time-Stop weg), weil `trail.enabled` nur im Speicher lebte und die Wiedererkennung
  (magic-match) es NIE reaktivierte — der User musste es von Hand einschalten. War das
  Trailing AUS (z. B. nach manuellem SL/TP via `/api/sltp` → `trail.deactivate`), bleibt
  es aus (der persistierte Zustand entscheidet — kein Überschreiben eines manuellen TP).
  Der Zustand wird bei **jeder Änderung** persistiert (Change-Detection im `_pos_loop`,
  fängt auch die Selbst-Deaktivierung des Trailings bei manueller SL/TP-Erkennung).
  **„aus"-Button schaltet auch den Auto-Arm ab** (setzt
  `_emergency_remember=0` — vorher blieb der gemerkte Wert und re-armte beim nächsten
  Trade, „aus" wirkte nur bis dahin; Bug gefixt 2026-07-07). Gilt genauso fürs Gewinn-Ziel. (Auto-Arm 1× auf manuell-only gestellt, nach Fehl-Trade
  wieder reaktiviert — echter Schutz gegen falsche Empfehlungen; Signal-Filter dagegen
  4× gemessen wirkungslos/schädlich, s. `backtest_rev_htf.py`.) `engine.set_emergency()` · `POST /api/emergency {value}` ·
  `snapshot.emergency_loss`. Das ist KEIN automatischer Circuit-Breaker, sondern
  ein manueller Hard-Stop (vom User gewünscht). **Benachrichtigung IMMER** (Ausnahme
  vom „Close-Push nur im Plus"): bei Erfolg „🚨 Notfall-Close", bei **Fehlschlag**
  „⚠ Notfall-Close FEHLGESCHLAGEN — manuell schließen!" (Schwelle bleibt dann aktiv,
  nächster Tick versucht erneut). Eigener `send_telegram`, **nicht** vom
  `pnl>0`-Gate (`history`) noch vom 5-Min-Cooldown betroffen.

## Mobile-UI (web/) & Alarme
- Aufbau: **Tab-Navigation ganz oben** (sticky: Dashboard/Logs/Statistik/**Charts**/News),
  darunter Header.
- **Design-System (`style.css`, Pass 2026-07-15, KEIN Framework — Tailwind bewusst
  verworfen wegen WireGuard/Offline + kein Node):** Tokens in `:root` — Flächen-Leiter
  `--bg < --surface-2 < --card`, `--border`/`--line`, Text `--dim`/`--bright`
  (+`--text-*`-Aliasse, waren undefiniert = Bug gefixt), Radien `--r-sm/-r/-r-lg`,
  `--shadow(-sm)`, `--mono`. **Font:** UI = System-Sans + `tabular-nums`; Zahlen-Werte
  (Kurs/PnL/Felder/Logs) = `--mono`. Karten mit Elevation-Schatten, Fokus-Ringe auf
  Feldern, Transitions auf Tabs/Buttons. Neutrale Hex-Literale → Tokens (Konsistenz).
- **Trade-Leiste** (`#trade-bar`, über der Gesamtempfehlung, nur bei offener Position,
  2026-07-15): **Laufzeit-Uhr** (2026-07-30, User-Wunsch „Uhr … wie lange diese schon
  läuft"): `trader.snapshot()` liefert `open_time` = Öffnungszeit als **echte Epoch**
  (Broker-Offset korrigiert, aus `position.time`); Frontend zeigt sie als Feld
  `#tb-dur` **und** kompakt im Kachel-Titel (`#tb-runtime`, „⏱ 1:23:45"). Der Ticker
  läuft **eigenständig 1×/s** (`_tickTradeDuration`), zählt also flüssig zwischen den
  Snapshots; ab **2 h** bernstein (Time-Stop-Nähe: 120 min in Phase „Init"). ⚠ Zwei
  Fallen beim Bau: (1) `_broker_offset_s()` liest `self.symbol`, die beim **Adoptieren**
  einer Position noch NICHT gesetzt ist → Offset 0 → Zeit lag 3 h in der Zukunft; die
  Funktion nimmt jetzt `sym` als Parameter (`_broker_offset_s(pos_sym)`). (2) Selbst-
  heilung: liegt `open_time` >60 s in der Zukunft, wird sie neu berechnet; beim Close
  auf 0 zurückgesetzt (kein stale Wert für den Folge-Trade). Berechnung nur 1× je
  Position (nicht je 1-s-Refresh). Weiter in der Zeile: Richtung (▲LONG/▼SHORT) · Lots · Einsatz · **3 Eingabefelder
  `.tb-field` (Label über Feld, rot=`.stop`/grün=`.gain`): SL · TP · Gewinn-Close
  (`#srmin-input`)** (Notfall-Close-Feld **2026-07-17 entfernt** — Notfall-Stop ganz aus).
  SL/TP: Enter/Verlassen →
  `POST /api/sltp` → setzt am Broker **und schaltet Trailing ab** (`trail.deactivate`);
  Vorbefüllung aus `position.sl/tp`, Broker-Ablehnung → Toast. Gewinn-Close
  (2026-07-15 aus der Position-Kachel hierher verschoben, User-Vorgabe — gleiches Design)
  behält ID/Handler (`/api/srclose_min`). **Auch der
  Auto-Close-Schalter** (`#srclose-btn`, jetzt `.tb-btn`-Box, AN/AUS grün/grau) sitzt in
  der Zeile. Titel „aktueller Trade läuft"; Richtung/Lots/Einsatz = Anzeige-Boxen
  (`.tb-val`), Rest editierbar — alle im selben `.tb-field`-Look. Position-Kachel hält
  nur noch `cur-near`-Warnung + `pos-srhint`. (`.emg*`/`.sr-toggle`-CSS entfernt.)
- **Charts-Tab** (`#view-charts`): **M1/M5/M15/M30/H1 untereinander**, je ein
  Candlestick-Chart mit **EMA12 (blau) + EMA50 (amber)**-Overlay und Trend-Header
  (▲/▼/→ nach EMA12-vs-EMA50 mit Totband). Framework **TradingView Lightweight
  Charts v4.2.3 — lokal vendored** (`web/lightweight-charts.standalone.production.js`,
  KEIN CDN wegen WireGuard/Offline). Daten via `GET /api/bars?tf=&n=` →
  `engine.get_bars` (OHLC+EMA+Trend unter `mt5_lock`). `app.js`: `loadCharts`/
  `renderChart`, Charts nur bei sichtbarem Tab geladen + Auto-Refresh 20 s
  (schont den Lock). Broker-Zeit (UTC+3) → UTC via `broker_utc_offset`. **Gitternetz
  dezent** (2026-07-27, User „dunkler/unauffälliger": `grid`-Farbe `#161b22`→`#10151c`,
  näher am Hintergrund `#0d1117`). **Chartmuster-Overlay (nur M30)** — s. Chartmuster-
  Kachel: die 2 stärksten M30-Muster als Trigger-/Ziel-Preislinien.
  **Regressionskanal-Overlay (nur M30, 2026-07-20):** `get_bars` liefert bei M30
  `channel {dir, mid[], upper[], lower[]}` (Arrays deckungsgleich mit den Bars,
  `structure.channel_series` — Regression über 60 abgeschl. Bars, linear über die
  volle Breite extrapoliert). Frontend zeichnet 3 LineSeries (oben/unten gestrichelt,
  Mitte gepunktet, grau). Dieselbe Kanal-Definition wie die Marktstruktur-Kachel —
  REINE Anzeige (Signalvariante gemessen verworfen, s. `backtest_structure.py`).
  **S/R-Overlay & Dashboard-Kachel = EINE Quelle** (`_draw_levels`; die Position-Kachel
  `sr-res`/`sr-sup` speist jetzt via `_dash_sr` daraus statt aus dem Misch-Set
  `_sr_levels` — vorher wichen Chart und Kachel ab, User-Feedback 2026-07-15). `_sr_levels`
  bleibt intern für Strategie/Konfidenz. **„Klebrige" Hysterese** in `_draw_levels`
  (`_draw_last`, verschärft 2026-07-21): die gezeichnete Linie **bleibt stehen, bis der
  Kurs sie WIRKLICH durchbricht** (bid > R+0,1×ATR bzw. bid < S−0,1×ATR) — ein neuer,
  näherer M5-Pivot löst KEINEN Wechsel mehr aus (das war die Zitter-Quelle: auf M5
  bilden sich laufend neue Pivots, die alte 0,25×ATR-Regel sprang darauf an). Ausnahme:
  ist die alte Linie >1,5×ATR weit weg UND ein deutlich näheres Level existiert, wird
  refresht (sonst bliebe sie irrelevant hängen). Gilt für PWA-Chart UND MQL5-CSV (eine
  Quelle).
  **Level-Auswahl nach Kursposition statt Entstehungstyp (Fix 2026-07-23, User-Frage
  „Widerstand/Support-Retest von der falschen Seite"):** vorher kam Widerstand NUR aus
  `ph` (Swing-Hochs) und Support NUR aus `pl` (Swing-Tiefs) — ein gebrochenes Level blieb
  für IMMER im falschen Topf hängen. 2 von 4 Retest-Varianten hatten dadurch NIE eine
  Durchbruchwahrscheinlichkeit: (1) Widerstand von unten ✓ funktionierte, (2) **Support-
  Retest von unten** (Kurs unter einem gebrochenen Support, nähert sich von unten wieder)
  ✗ kein Hinweis, (3) Support von oben ✓ funktionierte, (4) **Widerstand-Retest von oben**
  (Kurs über einem gebrochenen Widerstand, nähert sich von oben wieder) ✗ kein Hinweis.
  Fix: `ph`/`pl` bleiben GETRENNT geclustert (unverändert granular — ein erster Versuch,
  beide Rohpools VOR dem Clustern zusammenzulegen, erzeugte in dichten Zonen Ketten-Mega-
  Cluster durch die verdoppelte Punktdichte, >1×ATR breit, verworfen), aber NACH dem
  Clustern werden beide fertigen Linien-Listen zusammengeführt und die Wahl erfolgt rein
  per `min/max` relativ zu `bid` — nicht mehr nach Topf-Zugehörigkeit. Verifiziert: Fall 1
  bei Live-Daten (bid 90,951) und ein dichter Kontrollfall liefern exakt dieselben Level
  wie vorher (keine Regression); Fälle 2+4 (synthetische Retest-Szenarien) finden jetzt
  das nahe, vorher übersehene Level statt eines weit entfernten Ersatzlevels. Betrifft
  `_draw_levels` direkt und damit ALLE Konsumenten (PWA-Chart, MQL5-CSV, Dashboard-
  Kachel, `_sr_close_hint`/Auto-Close) — eine Quelle, ein Fix.
  **S/R-Overlay:** `get_bars` liefert `levels {res, sup}` aus **`engine._draw_levels`**
  = echte Kursstruktur (rohe M5-Pivots aus `wave.pb_levels`, geclustert ~0,5×ATR,
  **nur die NÄCHSTE je Seite = 2 Linien total, deckungsgleich mit Dashboard
  sr-res/sr-sup** — mehr Linien tauchten beim Kurslauf laufend auf/ab, User-Feedback
  2026-07-14; identisch zur Auto-Close-Logik). ⚠ Bugfix 2026-07-14: vorher
  kamen die Linien aus `_sr_levels` (stale [zones]-Config + Tageslevel + Gaps) —
  gezeichnet wurden Uralt-Level (81,24/82,64) statt aktueller Struktur. Farben
  **blau** (User-Wunsch): Widerstand #1f6feb, Support #58a6ff. **Beschriftung**
  (2026-07-14): PWA-Achsenlabel „Widerstand"/„Unterstützung" (+Nummer ab 2);
  MQL5 zusätzlich sichtbares OBJ_TEXT-Label je Linie („Widerstand 78.65",
  ~8 Kerzen vor dem rechten Rand, in Linienfarbe).
  ⚠ **Kein MT5-Terminal-Zeichnen aus Python:** das `MetaTrader5`-Paket hat KEINE
  `object_create`/`OBJ_HLINE`/`chart_*`-Funktionen (nur MQL5). S/R-Linien daher im
  PWA-Chart. **Für das Desktop-Terminal: Datei-Bridge** — `engine._write_levels_file`
  (im `_run_analysis`, ~5 s, `[trading] export_mql5_levels=true`) schreibt atomar
  `<terminal>\MQL5\Files\sr_levels.csv` (`SYM;…` / `R;preis` / `S;preis` / **`CH;<U|M|L>;
  t1;p1;t2;p2`** = Regressionskanal-Anker / **`LQ;<B|A>;preis;size;<U|D>;<1|0>`** = ECHTE
  Liquiditäts-Wand + Pfeilrichtung + Dominanz / **`LT;t1;p1;t2;p2;<U|D>`** =
  Liquiditäts-Trendlinie, s. u.); Quelle **`_draw_levels`** (S/R) +
  **`structure.channel_line`** (Kanal) + **`self.hl_walls`** (Liquidität),
  Indikator-Farben blau DodgerBlue/DeepSkyBlue, Wände grün/orangerot.
  ⚠ **Chartmuster-Linien (`PT;…`) 2026-07-30 auf User-Wunsch ENTFERNT** („entferne die
  chartmuster linien aus dem mt5" — Chart war zu voll); die Muster-Kachel + das
  PWA-Chart-Overlay bleiben unverändert, nur der MT5-Export/Indikator-Handler ist raus.
  **ECHTE Liquiditäts-Wände im MT5-Chart (User-Wunsch 2026-07-30 „zeichne mir die
  liquiditätslinien in den mt5 ein"):** `core/hl_walls.py` holt vom **HL-Dashboard**
  (`GET http://127.0.0.1:8001/api/walls`, `[trading] export_hl_walls=true`) das
  **größte L2-Orderbuch-Level je Seite** — die einzigen Linien im Chart, die NICHT aus
  Pivots geschätzt sind, sondern **tatsächlich ruhende Orders** zeigen (Pepperstone =
  Market Maker, liefert kein Buch). ⚠ **Basis-Korrektur zwingend:** HL `xyz:CL` notiert
  **~0,45 $ unter** dem CFD (anderer Kontrakt/Contango) — die Umrechnung passiert
  serverseitig im HL-Projekt (Median über 60 Snapshots), hier kommt schon
  `bid_mt5`/`ask_mt5` an; fehlt die Basis, wird NICHT gezeichnet. ⚠ **`127.0.0.1`, nicht
  `localhost`** (IPv6-Auflösung → 2066 ms statt 19–46 ms, lief in den 2-s-Timeout) und
  der HL-Endpoint liest **nur seine DB** (live-`fetch_l2_book` dauerte ~2 s = Timeout).
  **Pfeil + Liquiditäts-Trendlinie (User-Wunsch 2026-07-30, Indikator v1.13):**
  (a) Jede Wand bekommt einen **Pfeil in ihrer Wirkrichtung** (Wingdings 233/234) —
  Lesart **„die Wand HÄLT"**: Nachfrage-Wand stützt von unten (▲), Angebots-Wand
  deckelt (▼); die **größere** der beiden wird dicker gezeichnet + „<<" im Label
  (`dominant` aus dem Endpoint). ⚠ **Die Pfeilrichtung ist INTERPRETATION, nicht
  gemessen** — die Gegenthese („Liquidity Grab": der Kurs läuft ZUR Wand, um sie
  abzuräumen) ist genauso verbreitet. Welche stimmt, beantwortet `analyze_bookflow.py`
  (Frage 3) nach genug Daten; bis dahin ist der Pfeil eine Lese-Hilfe, kein Signal.
  (b) **Pinke Liquiditäts-Trendlinie** (`OBJ_TREND`, nach rechts verlängert,
  `InpShowLiqTrend`/`InpLiqTrendColor`): lineare Regression über den **volumen-
  gewichteten Wand-Schwerpunkt** `(bid_px·bid_sz + ask_px·ask_sz)/(bid_sz+ask_sz)`
  der letzten **60 min** (≥20 Punkte nötig). ⚠ Sie zeigt etwas ANDERES als eine
  Kurs-Trendlinie: **wohin das Gewicht der RUHENDEN Orders wandert**, nicht wohin der
  gehandelte Preis läuft — steigt sie, ziehen die Käufer ihre großen Gebote hoch.
  Zeiten werden im Bot in **Broker-Zeit** umgerechnet (`trader._broker_offset_s()`),
  weil MT5-Charts die brauchen; Preise sind bereits basis-korrigiert.
  Fail-safe: HL-Server aus → keine Linien, kein Fehler (Log 1×, dann still), Cache 10 s,
  Daten älter als 60 s werden verworfen. **REINE ANZEIGE** — ob HL-Buch-Signale auf den
  CFD übertragbar sind, wird gerade gemessen (`analyze_bookflow.py` im HL-Projekt,
  Datensammlung seit 2026-07-30, Urteil in ~2 Wochen). Der Indikator
  **`mql5/SR_Levels.mq5`** (**v1.12** — `LQ`-Handler: dick gestrichelt + Größen-Label
  „Liquidität NACHFRAGE/ANGEBOT <kontrakte>", `InpShowWalls`/`InpWallBidColor`/
  `InpWallAskColor`; PT-Handler entfernt; in `MQL5\Indicators\`, **braucht
  `OnCalculate` als No-op** sonst Compile-Error, F7-kompilieren, auf den Chart ziehen)
  liest die S/R-Linien per Timer (OBJ_HLINE) UND den **M30-Regressionskanal als 3
  diagonale Trendlinien** (OBJ_TREND, nach rechts verlängert, oben/unten gestrichelt/
  Mitte gepunktet grau; `InpShowChannel`/`InpChanColor`, Default an) — Anker in
  Broker-Zeit (= Server-Zeit im Terminal), zeichnet **nur bei Datei-Änderung neu**
  (Inhalts-Cache `g_last` gegen Flackern). Der Kanal ist dieselbe M30-Definition wie
  PWA-Overlay + Marktstruktur-Kachel; ⚠ nach dem Update den Indikator **neu F7-
  kompilieren** (v1.10). Die dynamische Handels-Range (`DrawRange`, Hoch/Tief
  der letzten `InpRangeBars` Kerzen) ist **per Default AUS** (`InpShowRange=false`,
  User-Wunsch 2026-07-14) — bei Bedarf über die Indikator-Eingaben aktivierbar. (Die
  statischen `[zones]`-Config werden NICHT mehr in die CSV geschrieben — waren stale
  WTI-Level, füllten den Chart.)
  **Architektur bewusst: Python = Gehirn (Analyse/Strategie/PWA/News/LLM/Reports),
  MQL5 = nur dünne Zeichen-Schicht.** Kein Full-Rewrite in MQL5 (PWA/Backtests/
  Integrationen wären dort nicht/kaum machbar). **Sym-Zeile:** Symbol links · rechts `hdr-clock`
  (**Srv = Broker-Wallclock** aus `market.server_time` via `getUTC*`, **Lok** =
  Browser) + **Session** (`#session`; zeigt 21–22 Uhr lokal „🕘 PRIME-TIME" —
  gemessen die stärksten Stunden — und bei Headline-Burst „📰 NEWS-STURM"/„viele
  News" aus `news.storm_state()` → Snapshot `news_storm` {level: normal/elevated/
  storm, fresh, base_per_h}; Headline-Rate letzte Stunde vs Basisrate, Basis-Fenster
  min. 6 h verankert. Beides reine Anzeige) + Verbindungspunkt. Darunter Balance ·
  **Tag P/L** · Equity. **Kein** Bid/Ask/Spread (Kurs steht in der Position-Kachel,
  färbt sich nahe S/R). **Tag P/L** (`day-pl`) = realisiert heute
  (`stats_overview("today")`) + offene Position; grün/rot
  (`day_pl{realized,open,total}` im Snapshot).
- **Gesamtempfehlung** (`#card-verdict`, ganz oben): grafische Aggregation aller
  Module — Konfidenz-Ring (conic-gradient = `conf_pct`), Bias-Balken mit Nadel
  (SHORT↔LONG) und Modul-Chips (Welle/M30/H1/KI/Elliott/**Squeeze**, je grün/rot/grau; **TU
  entfernt**). ⚠ **Bias-Fix 2026-07-15:** stimmberechtigt nur Module MIT Aussage —
  Squeeze (nur `active`), Elliott (nur mit Ziel), KI (nur mit Bias) haben sonst
  **Gewicht 0** (vorher dämpfte das fast immer neutrale Squeeze-w=2,0 die Nadel
  permanent ~×0,8); `agree/total` zählt nur noch die ANDEREN stimmberechtigten
  Module (Welle zählte sich selbst mit). Formel/Details: `docs/gesamtempfehlung.md`.
  Headline = **validierte Welle** (steuert Order) + **Zeitebene** (`verdict.tf`,
  z. B. „▲ LONG · M5" — TF, für die die Empfehlung gilt); Rest = nur Konsens-Anzeige.
  Backend `engine._verdict` → `verdict` im Snapshot; Render `renderVerdict`
  (`app.js`). Details: `docs/gesamtempfehlung.md`.
  **⚠ Konfidenz ist NICHT kalibriert (gemessen `analyze_verdict_calibration.py`,
  2026-07-24, „Gesamtempfehlung verbessern"-Paket):** conf_pct gegen Forward-Return
  (2 h, ×ATR, 1604 gesampelte Signale aus `recommendations`, 2 Hälften) — H1 (Mai–Jun)
  perfekt monoton (conf 85–100: WR 68 %/ØR +1,13; <55 klar negativ), **H2 (Jun–Jul)
  komplett INVERTIERT** (conf 85–100: WR 40 %/ØR −0,90; mittlere Bins besser). Hohe
  Konf = starker Trend + Konfluenz — im Chop-/Hochvola-Regime sind genau das die
  Überdehnungen vor der Wende. **Konsequenzen:** conf-Anzeige NICHT als P(Erfolg)
  aufwerten; **Konfidenz-Sizing-Idee VERWORFEN** (hätte in H2 die schlechtesten
  Signale am größten gesized); Ring bleibt, was er ist (Score-Aggregat). Copilot-Bias
  in derselben Messung nicht robust prädiktiv (n klein bzw. ØR ~0) — für die
  datenbasierte Entscheidung (behalten/Gewicht/raus wie TU) loggt jetzt
  **`verdict_votes`** (neue DB-Tabelle, `history.log_verdict_votes`, 1×/60 s aus
  `_run_analysis`: headline/conf/bias/tf + Modul-Votes Welle/M30/H1/KI(+w)/
  Elliott(+w)/Squeeze + news_score) — Auswertung nach ein paar Wochen analog
  `analyze_verdict_calibration.py`.
  **Live-Kosten-Chip (2026-07-24):** Snapshot `cost_ratio` = (ask−bid)/ATR_M5
  (`pb_feats.atr`, Floor 0,06) → in der `vd-consensus`-Zeile „Kosten 0,14×ATR ✅
  günstig / · normal / ⚠ teuer" (Schwellen 0,20/0,32 aus `backtest_realcosts.py`:
  Ø 0,265, Nacht 0,32–0,50 = Falle, 15–17 Uhr ~0,13). Reine Info — die ehrliche
  Alternative zum abgeschalteten Dead-Hours-Gate.
  **Ausrichtungs-Split im Order-Dialog (2026-07-24, Verhaltens-Hebel/B0):** Der
  „trotzdem eröffnen?"-Dialog zeigt jetzt die EIGENEN Zahlen aus der DB
  (`history.alignment_stats(40)` → Snapshot `alignment`, Engine-Cache ~120 s):
  „📊 Deine Trades OHNE Signal: 42 % Trefferquote · −423 € (n36) / Mit Signal: …"
  (Gruppen <5 Trades werden ausgeblendet). Real bei Einbau: 36 der letzten 40
  Trades liefen OHNE Signal-Deckung mit −423 € — exakt die dokumentierte
  Kern-Leckage, jetzt im Moment der Entscheidung sichtbar.
  **News-Konflikt-Chip (2026-07-24, Auslöser 23.07.: zwei Shorts gegen einen
  +0,98-Sentiment-Burst):** Snapshot `news_sentiment` (Score −1..+1 aus
  `news.sentiment`); Frontend `#news-conflict` (Meldungen-Karte, bernstein) warnt
  bei |Score|≥0,5 gegen offene Position bzw. aktives Signal („📰 News-Flow stark
  bullisch (+0,98) — steht gegen deine SHORT-Position"). Reiner Kontext —
  Prädiktivität unbelegt (Kalibrier-Messung: H2 nur n=4/6); dafür wird
  `recommendations.news_score` seit 2026-07-24 wieder BEFÜLLT (war auf None
  degradiert) → in ein paar Monaten messbar.
- **Karten** (Dashboard, von oben): Gesamtempfehlung · **Meldungen** · Marktstruktur ·
  KI-Copilot · Letzte Trades · Kurslücken · **Statistik (live) ganz unten**.
  (Tagesziele-Kachel **entfernt** 2026-07-13. **Welle-Karte komplett entfernt
  2026-07-15** — TF-Ampel wanderte in die Gesamtempfehlung, die Wellen-Meldungen
  [Squeeze/Überdehnung/Setup/Lauf/Gründe] in die **„Meldungen"-Karte** (`#card-pos`,
  ex-„Position"); das Wave-Signal ist eh die Verdict-Headline. **Trailing-Karte
  ausgeblendet 2026-07-22** — `#card-trail.hidden` per CSS, User-Vorgabe; Backend/
  Trailing-Logik + Snapshot-Felder `trail.*` unverändert aktiv, nur die Anzeige raus,
  wieder einblendbar durch Entfernen der `hidden`-Klasse in `index.html`.)
- **Auto-Squeeze-Monitor (B4)** (`#sqm-box`, oben im **Statistik-Tab**, 2026-07-20):
  zwei Blöcke — **Entry-Edge · Mechanik** (`engine.squeeze_monitor` rechnet die Squeeze-
  Regel mit Live-Params auf ~30 Tagen M5 NEU, Backtest-Exit → **isoliert den Einstieg**,
  ØR/PF gegen Erwartung **+0,14…+0,23 · PF>1**) und **Live-Trades · echt** (SQUEEZE_*-
  Trades aus der DB, Gesamtsystem inkl. realer Exits: n/WR/Ø-Gew/-Verl/Verhältnis/ΣEUR/
  Tag-Nacht; ØR-Näherung via SL-Distanz). Verdict-Badge (trägt/dünn/**driftet→B5**) aus
  der Mechanik. **Kernaussage der Ansicht:** klaffen Mechanik (Edge lebt) und Live
  (echtes Geld) auseinander → es liegt am **Exit/Verhalten, nicht am Signal** (real
  2026-07-20: Mechanik ØR **+0,414**/PF 1,64, Live ØR −0,07/−2,41 € — der alte Notfall-
  Stop + Nacht-Trades fraßen den Edge, jetzt behoben → sollte konvergieren). Endpoint
  `/api/squeeze_monitor` (Cache 60 s), lädt beim Öffnen des Statistik-Tabs (`loadStats`).
- **Statistik-live-Kachel** (`#card-stats-live`): kompakt Woche + Gesamt —
  Trades, WR, PF, Ø-Gewinn/-Verlust, **Verhältnis** (Øgew/Øverl, <1 = Verlust-
  Schiefe), PnL. Quelle `engine._compact_stats` → `snapshot.stats_compact`. Zum
  objektiven Verfolgen der Stichprobe (statt Bauchgefühl pro Einzeltrade).
  **TradersUnion- und Elliott/FVG-
  Einzelkacheln ausgeblendet.** Elliott/FVG fließt weiter in die Gesamtempfehlung
  (`_verdict`); **TU ist ganz raus aus Empfehlung, Verdict UND KI-Copilot-Kontext**
  (`agent._tool_market` ohne `tradersunion`/`tu_consensus` — war die letzte Hintertür,
  da der Copilot eine Verdict-Stimme ist; nur noch Snapshot-Anzeige).
- **TF-Wende-Ampel** (`#wave-turns`, jetzt IN der Gesamtempfehlung): Chips
  **M1/M5/M15/M30/H1** (H1 neu 2026-07-15 — im `turn_data`-Fetch, aber NICHT im
  Bounce-Scan, der bleibt M1–M30), je grün(auf)/rot(ab) nach **EMA12/50-Stand**;
  **frische Kreuzung (≤3 Bars)** blinkt + zeigt ⟳ + Richtungspfeil + Bars-seit-Wende.
  Quelle: `wave.tf_turns`
  (Backend `WaveRecommender._turn_state` mit **Totband** `_TREND_DEADBAND×ATR` →
  kein Geblinke bei seitwärts laufenden EMAs). 4-TF-Fetch ist **gedrosselt (~15 s)**
  via `_turn_due` (spart Lock-Zeit; letzter Stand in `_last_tf_turns` gehalten).
  REINE Anzeige — ändert die Empfehlung NICHT.
- **Marktstruktur-Kachel** (`#card-structure`, 2026-07-20, User-Idee „Pro-Chart-
  Setup-Erkennung"): zeigt die Price-Action-Struktur auf **M30** — Swing-Folge
  **HH/HL/LH/LL** (Chips grün=bullisch/rot=bärisch), letzter **BOS** (Break of
  Structure, Richtung + gebrochenes Level + Bars her) und den **Regressionskanal**
  (Richtung + Position des Kurses im Kanal 0–100 % als Balken+Punkt). Quelle
  `core/structure.py` (`MarketStructure`, Pivots k=3, Kanal = LS-Regression über 60
  Bars ± max. Abweichung, ~30 s gedrosselt im Trend-Loop unter `mt5_lock`), Snapshot
  `structure`. **REINE ANZEIGE — kein Trade-Trigger, kein Verdict-Gewicht, KEINE
  Prognose/Pfeil.** **Signalvariante DIREKT gemessen & VERWORFEN (`backtest_structure.py`,
  2026-07-20, 60k M30-Bars/5 J, 2 Halbjahre, dieselbe structure.py-Logik kausal):**
  ALLE Varianten in BEIDEN Hälften negativ — (A) Kanal-Pullback „Kauf am unteren
  Kanaldrittel/Demand-Zone" = der orange Pfeil: ØR −0,05…−0,11, PF<1, WR 40–43 %
  (der Kanalrand HÄLT nicht zuverlässig — antizyklisch am Extrem = Münzwurf, P(break)-
  Klasse); (A2) +Swing-Filter (HH/HL) macht es nicht besser (−0,06/−0,07); (B) BOS-
  Continuation = breakeven-negativ (−0,011/−0,005, Momentum-Klasse). Damit ist auch
  die Struktur-Idee empirisch durch — die Kachel bleibt Ist-Zustand-Anzeige (wie
  TF-Ampel/Squeeze), steuert nichts.
- **Chart-Muster (Doppeltop/-boden) als Signal = VERWORFEN (gemessen `backtest_doubletop.py`,
  2026-07-20, User-Idee „Mustererkennung SKS/Doppeltop"):** das am saubersten mechanisch
  definierbare Umkehrmuster (2 ~gleiche Swing-Pivots + Nackenlinien-Bruch, aus derselben
  Pivot-Erkennung; Einstieg beim Bruch, Live-Exit, 60k M30-Bars, 2 Halbjahre). ALLE
  Toleranzen (0,3/0,6/1,0×ATR) fallen durch: WR nur 40–45 %, ØR −0,01…−0,15, PF<1;
  die einzige leicht positive Zelle (H1 tol 0,3 +0,044) kippt in H2 auf −0,150 = Rauschen/
  Regime, kein Edge. Deckt sich mit der schwachen Empirie (Lo/Mamaysky/Wang 2000: Effekt
  klein & kaum handelbar; NY Fed: SKS nicht profitabel; out-of-sample schwach) UND der
  Struktur-Klasse (Muster = Swings+Trendlinien = die gerade verworfene Klasse). **11.
  verworfener Signal-Eingriff — am Signal ist nichts zu holen.**
- **Volume Profile / „Liquiditätslinien" (POC/HVN/LVN, Value Area) = VERWORFEN
  (gemessen `backtest_volume_profile.py`, 2026-07-30, User-Frage „System zur besseren
  Vorhersage — Liquiditätsnachfragelinien / wahrsch. Verkaufslinie?"):** Getestet, WEIL
  es die einzige Klasse mit einer **anderen Datenquelle** war (nicht „wo war ein Docht"
  = Pivots/Swings, sondern **wo wurde tatsächlich gehandelt** = Volumen) — SMC/ICT-
  „Order Blocks"/Liquidity-Linien selbst sind strukturell Pivot-Zonen und damit dieselbe
  5× verworfene Klasse. Aufbau: feste Preis-Bins 0,05 $, rollierendes 24-h-Fenster
  (288 M5-Bars), Bar-Volumen (`tick_volume` — CFD liefert `real_volume=0`) gleichmäßig
  über [low, high], Value Area 70 %; 80k M5-Bars, 2 Halbjahre, Live-Exit + Echtkosten.
  **Ergebnis: nichts trägt.** Am eindeutigsten fällt genau die *Kern-Idee* durch:
  **Reversion am POC („der Kurs prallt an der Liquiditätslinie ab") ist in BEIDEN
  Hälften negativ** (ØR −0,178/−0,121, PF 0,79/0,84, n≈400 je Hälfte) — der POC hält
  NICHT. HVN-Reversion kippt (−0,067/+0,044), LVN-Momentum ist Breakeven-Rauschen
  (−0,031/+0,003). **Informations-Test (Teil 1, Forward-Return 2 h ohne Exit/Kosten,
  relativ zur `mid`-Baseline gelesen — H1 war Abwärts-, H2 Aufwärts-Regime, absolute
  Werte sind daher Drift-verzerrt):** KEIN Bucket weicht konsistent ab — LVN H1 −0,11
  / H2 +0,09 relativ, HVN H1 +0,08 / H2 −0,06 → beide kippen. **Tiefere Einsicht: die
  Volume-Profile-Position ist ein TREND-PROXY, keine unabhängige Information**
  („außerhalb Value Area" = Ausbruch läuft = folgt dem Regime: H2 +0,304 vs +0,092 in
  VA, H1 umgekehrt −0,122 vs −0,057) — sie erbt damit exakt die Regime-Anfälligkeit von
  Momentum/Struktur. **15. verworfener Signal-Eingriff.** ⚠ Was BLEIBT: das bereits
  validierte **P(break)-Modell** ist die einzige belegt-prädiktive „Liquiditäts"-Aussage
  im Projekt (AUC 0,71 out-of-sample, kalibriert; ~63 % der Level-Touches prallen ab) —
  und auch das trägt nur als **EXIT**, nicht als Entry. Einzige noch ungetestete Klasse
  wäre **echter Order-Flow/L2-Orderbuch** (Pepperstone = Market Maker, liefert keins;
  Hyperliquid hätte `l2Book` — bräuchte erst wochenlange Datensammlung UND einen Beleg,
  dass HL-Orderbuch-Signale auf den CFD übertragbar sind).
- **Chartmuster-Kachel `#card-patterns` (`core/patterns.py`, 2026-07-27, User-Idee
  „Visuelle Muster-Erkennung"): REINE ANZEIGE, KEIN Signal.** Erkennt mechanisch aus
  den M30-Swing-Pivots (k=3, wie `structure.py`): **Doppeltop/-boden, Kopf-Schulter/
  inverse SKS, Tasse+Henkel/invers (heuristisch), auf-/absteigendes + symmetrisches
  Dreieck.** Je Muster: Richtung (bull/bear/neutral), Nackenlinie/Trigger, Measured-
  Move-Ziel, Status (bildet sich / bestätigt / ungültig→raus), Güte (Extrem-Symmetrie),
  Bars-her. Refresh ~30 s im Trend-Loop unter `mt5_lock`; Snapshot `patterns
  {patterns[], atr, cur}`. **Nur AKTIVE, kursnahe Muster** (2026-07-27, `_detect`-Filter):
  abgearbeitete Muster (Ziel bereits erreicht) UND zu weit entfernte (`_MAX_DIST_ATR=5,0`,
  Trigger >5×ATR vom Kurs) werden ausgeblendet — sonst zeigte die Kachel alte, nicht mehr
  handelbare Muster. **Grafische Darstellung (2026-07-27, User „grafisch darstellen"):**
  (a) Muster-Karte zeigt je Item eine **kompakte SVG-Skizze** der Form (`_patternSvg`,
  viewBox 56×32, farbcodiert grün/rot/grau) — Form auf einen Blick; (b) im **Charts-Tab
  (M30)** werden die **2 stärksten Muster als Preislinien** gezeichnet: Trigger = kräftige
  Linie (grün bull/rot bear, Label „▶ bestätigt"/„◌ bildet sich"), Ziel = gepunktete Linie
  gleicher Farbe. Dazu liefert `get_bars` bei M30 jetzt `patterns` (aus `patterns.snapshot`).
  Frontend zeigt Karte + Disclaimer „kein Signal". ⚠ **Signal-
  Einfluss ERST nach Backtest** (`backtest_patterns.py`, noch zu bauen) — die
  Muster-KLASSE ist bereits 2× als Signal verworfen (`backtest_doubletop.py` oben +
  `backtest_structure.py`), also **hohe Beweislast**; die Kachel macht das Muster nur
  sichtbar (was ein Kommentator meint), steuert nichts. v2-Kandidaten (Flags/Wimpel,
  Rechteck, Rundung) dokumentiert, noch nicht gebaut. Web-Recherche (strike.money,
  IG, Axi): Umkehr (Doppel-, SKS, Rundung) vs. Fortsetzung (Dreieck, Flag, Tasse);
  Kursziel stets = Muster-Höhe ab Ausbruch projiziert — überall mit dem Caveat
  „keine Garantie, nur Indikation".
  **Backtest gebaut & gemessen (`backtest_patterns.py`, 2026-07-27, 80k M30, 2
  Halbjahre, Einstieg beim Trigger-Bruch, Live-Exit+Echtkosten):** Mehrere Typen sehen
  ØR-positiv in BEIDEN Hälften aus (Doppeltop +0,43/+0,23 · Tasse +0,35/+0,26 · inv.
  Tasse +0,36/+0,58 · aufst. Dreieck +0,16/+0,10). ⚠ **ABER das ist ein Exit-Artefakt,
  KEIN Muster-Edge:** die **Ziel-Trefferquote (Measured-Move vor SL) ist nur 13–38 %**
  — die eigene Muster-Prognose trifft also in ~⅔ der Fälle NICHT. Der positive ØR
  kommt vom **Trailing-Exit auf einem Momentum-Bruch** (Trigger-Bruch = Breakout, und
  Breakout+Trailing hat generisch Edge — s. Squeeze), nicht von der Muster-Vorhersage.
  Deckt sich mit `backtest_doubletop.py` (dort mit Ziel-/Fix-Exit → negativ) — der
  Unterschied ist NUR der Exit. **Fazit: NICHT reif für Signal-Einfluss** — es fehlt
  die Kontrolle „generischer Breakout + gleicher Exit" (isoliert den Muster-Beitrag,
  wie Squeeze vs. beliebige Box); ohne die ist „Muster wirkt" nicht belegt. Muster
  bleiben **reine Anzeige**. Ziel%-Spalte = der ehrliche Muster-Check (13–38 % = Muster
  sagen den Kursverlauf kaum voraus).
- **Kurslücken-Kachel** (`#card-gaps`): offene D1-Gaps des laufenden Jahres
  (`gaps.GapAnalyzer`, Refresh ~10 min im Trend-Loop unter `mt5_lock`). Je Gap:
  Richtung, Zone, Fill-Level, Abstand zum Kurs. Die **Fill-Level fließen als
  S/R-Magnete in `_sr_levels`** → damit in die Wellen-Konfidenz (`set_sr_context`,
  `_SR_BONUS`/`_SR_PENALTY`), Close-Alarme und Verdict-Kontext — und so indirekt in
  den **Autotrader** (der auf die Welle hört). **Keine** eigene Handelsrichtung.
  Snapshot `gaps`. Mess-/Einzeltool: `find_gaps.py`.
  - **Gap-Magnet als Handelssignal = VERWORFEN (gemessen, `backtest_gaps.py`):**
    Signale WEG vom nächsten offenen Gap haben **+0,094** Ø-Edge, ZUM Gap nur
    **+0,014** — der Magnet zieht NICHT (das Gap blieb offen, weil der Trend von
    ihm weglief). „Richtung Gap handeln" wäre schädlich; „weg" ist nur
    Trendbestätigung (macht die Welle schon). Gaps bleiben reiner Kontext.
- **Tagesziele — Dashboard-Kachel ENTFERNT (2026-07-13):** Das Frontend zeigt die
  Web-Prognose nicht mehr. Das Modul `daily_levels` läuft **unverändert weiter**: die
  Level fließen als **S/R-Kandidaten** in `_sr_levels` (Anzeige/Close/Verdict-Kontext)
  und in den 07:30-Tagesreport. `snapshot.daily_levels` bleibt befüllt (nur ohne UI).
- **Täglicher Report** (07:30 Berlin, `engine._send_daily_report`): Web-Prognose +
  **Vortags-Bilanz** (`stats_overview("yesterday")`) → **Telegram-Push** + **E-Mail**
  (via `mailer.send_graph_mail`, `[graph]`-Creds, Absender `[graph] sender`=
  mailagent@hocks.eu). Empfänger: `[graph] report_to` (kommagetrennt, Default
  `trading@hocks.eu, axel@hocks.eu`). Ersetzt `scripts/send_daily_report.ps1` (das
  hier nie lief — Microsoft.Graph-PS-Modul fehlt; Python nutzt Graph-REST direkt).
  ⚠ Graph/Exchange-Zustellung kann **mehrere Minuten verzögert** sein (202 = nur
  angenommen). Fail-safe: kein Provider/Graph → Report übersprungen. **Versand-Status
  persistiert** (`report_state.json`, `_load/_save_report_state`) — vorher schickte
  jeder Server-Neustart nach 07:30 den Report ERNEUT (real 3× am 07.07.); gilt für
  Tages- UND Wochenreport.
- **B4-Wochenreport (automatisch, `engine._send_weekly_report`):** **montags ab 07:30
  Berlin, 1×/Woche** (gleicher `_daily_loop`, `_weekly_last_run`=(ISO-Jahr,KW)) →
  **E-Mail + Telegram**. Ruft `weekly_review.build_report(m5=…)` (Live-Stats vs.
  Backtest-Erwartung, Leckage-Flags — Track B/B4) und schickt es als `<pre>` (Betreff
  „Oil Wochenreport (B4) — KW…", Empfänger = `[graph] report_to`). **Squeeze-Breakout-
  B4-Monitor** (`_squeeze_section`): rechnet die Squeeze-Regel mit den Live-Params auf
  den letzten ~30 Tagen M5 NEU (mechanischer Setup → Live-Perf. = Neuberechnung, keine
  Trade-Attribution nötig) und hält ØR/PF gegen +0,14…+0,23. M5-Bars holt die Engine
  unter `mt5_lock` und reicht sie durch (`build_report(m5=…)`; standalone lädt via
  `_fetch_m5`, schließt MT5 nur bei Eigen-Init). Fail-safe wie der Tagesreport.
  Manuell jederzeit: `python weekly_review.py`.
- **Position-Kachel zeigt SL/TP + Einsatz** (`pos-sl`/`pos-margin`;
  `trader.snapshot()` liefert `sl`/`tp`/`margin`). **Kopfzeile der Kachel**
  (`.pos-top`, 2026-07-15, User-Vorgabe): **Kurs · G/V** in EINER Zeile (18-px).
  Das G/V (`#pnl`) zeigt **NUR NETTO** (Brutto entfernt, kein „n."-Präfix): bei
  Gewinn P&L × (1 − `[trading] wht_pct`/100) = abzgl. WHT-Quellensteuer, bei Verlust
  unverändert (keine Steuer). Snapshot `wht_pct`; Tooltip nennt den Satz. Swap ist
  bereits im P&L (`trader.pnl = profit + swap`), Kommission beim Standard-Konto 0.
  Einsatz/SL/TP/Richtung stehen in der Trade-Leiste, S/R im Chart (aus der Kachel
  entfernt); `emg-lbl`-Beschriftungen ausgeblendet (Felder self-labeln via
  Platzhalter/Button-Text). Fehlender SL → rot „⚠ kein SL
  gesetzt!". „Einsatz" = gebundene Margin (`order_calc_margin`). **Notfall-Stop-
  Feld** (`#emg-input` + setzen/aus): manueller Verlust-Wert → Server schließt
  sofort (s. „Notfall-Stop"). Feld wird mit aktivem bzw. gemerktem Wert
  (`emergency_loss`/`emergency_remember`) **vorbefüllt** (außer beim Tippen);
  **Enter/„Go"** löst „setzen" wie der Button aus. Status `#emg-state`: „aktiv:
  schließt bei −…" (rot) bzw. „vorgemerkt −… (aktiv beim Öffnen)". **Gewinn-Feld
  („Gewinn mitnehmen bei") aus dem Dashboard ENTFERNT (User-Vorgabe 2026-07-14)** —
  das Backend bleibt vollständig erhalten (`engine.set_takeprofit`, kombinierter
  `_check_auto_close`, `POST /api/takeprofit`, Telegram „💰 Gewinn mitgenommen",
  Config `[trading] auto_takeprofit` Default 0=aus), ist ohne UI aber schlafend;
  der P(break)-S/R-Auto-Close übernimmt die Gewinnmitnahme-Rolle.
- **Blinken:** LONG/SHORT-Button blinkt bei jeder Richtungs-Empfehlung (nicht mehr
  an 70 % gekoppelt). **Ton bei Empfehlung** (`beepRecommendation`): **sofort beim
  Signal-Wechsel** (WARTEN→LONG/SHORT oder Flip, 3-s-Flacker-Schutz) **+ Erinnerungs-
  Ton alle 30 s** (`_REC_REBEEP_MS`), solange der Button blinkt — **nur wenn flat**
  (keine Position). LONG = aufsteigend, SHORT = absteigend (unterscheidbar vom
  Close-Alarm). Audio erst nach 1× Nutzer-Tap aktiv — ist es noch gesperrt, zeigt
  ein einmaliger Toast „🔇 Ton gesperrt — einmal tippen". Kein Ton bei offener
  Position. **Mute-Button** (`#mute-btn`, 🔊/🔇 rechts in der Tab-Leiste) schaltet
  ALLE Töne (Gate in `_tone` + beiden beep-Funktionen), persistiert via
  `localStorage("oil_muted")`. **CLOSE blinkt + Ton NUR wenn `pnl > sr_close_min_gain`**
  (Feld leer/0 → `pnl>0` wie bisher; deckt sich mit dem Auto-Close-Gate — unter der
  Schwelle schließt der Bot ohnehin nicht, also auch kein Alarm; Frontend `gainOK`,
  gilt für Flip-Close UND S/R-Close-Blink/Ton). Der Telegram-Flip-Push (`_check_close_
  alert`, Backend) bleibt bei `pnl>0`. **Flip-Close** = Signal-Flip gegen die Position.
  **S/R-Ziel-Close-Hinweis
  ENTFERNT** (stupste zum verfrühten Gewinner-Kappen → Verlust-Schiefe; Gewinner
  führt das Trailing). Bei Verlust-Trade: kein Close-Alarm. **Jeder echte Auslöser
  loggt** `🔔 Flip-Close-Alarm #N` + Zähler `snapshot.close_alert_count` (zum
  objektiven Nachzählen, statt aus Trades/Recs zu rekonstruieren). Engine: `_check_close_alert` (Telegram max.
  **1×/5 min**, `_CLOSE_ALERT_COOLDOWN_S` — kein Spam, wenn der Kurs ums Level
  pendelt). ⚠ Cooldown ist **ticket-basiert** (`_close_alert_ticket`): Reset NUR
  bei echter neuer Position; ein kurz flackerndes Ticket (transient leeres
  `positions_get`) setzt den Cooldown NICHT mehr zurück (war die Spam-Ursache).
  Frontend: `flipClose || srTarget`. Kein Auto-Close an S/R (Backtest).
- **Trade-Abschluss-Telegram ENTFERNT** (`history.log_trade_close` sendet kein
  Telegram mehr; Import bereinigt). Close-bezogene Telegrams kommen jetzt **nur
  noch** aus der Engine: **🔔 CLOSE-Signal** (echter Signal-Flip, `_check_close_
  alert`) + **🚨 Notfall-Close / 💰 Gewinn-Close** (armierter Auto-Close,
  `_check_auto_close`). Frontend-Blink/Ton weiterhin nur bei Flip im Plus.
- **Order-Bestätigungen:** Kein hartes Blockieren mehr. Eröffnen bei WARTEN/Gegen-
  Signal → **Hinweis-Dialog „trotzdem eröffnen?"** (überschreibbar). CLOSE bei
  **negativem** P&L → Sicherheitsabfrage; im Plus/Breakeven direkt. Sonst keine
  Token-Dialoge (`require_token=false`). Audio braucht 1× Nutzer-Tap.
- Asset-Version aktuell **v=119** (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` —
  die wurden zuerst übersehen, weil das erste Bump-Skript nur `font-size` erfasste)
  + Chart-`fontSize` in `app.js`. Bei künftigen globalen Font-Änderungen die
  Shorthand nicht vergessen.

## Web-API (server.py)
`GET /api/snapshot` (inkl. `verdict`-Aggregat) `/api/health` `/api/logs` `/api/stats` `/api/news` `/api/bars?tf=&n=` (Charts, read-only) `/api/squeeze_monitor` (B4-Monitor, read-only, Engine-Cache 60 s) · `WS /ws` ·
`POST /api/order|auto|trail|emergency|takeprofit|sltp|srclose|srclose_min|autosqueeze|autosignal|auth/check`.
`/api/sltp {sl,tp}` = manuelles SL/TP der offenen Position → `engine.set_sltp` →
`trader.modify_sltp` (TRADE_ACTION_SLTP, prüft Seite/Mindestabstand) **und deaktiviert
das Trailing** (`trail.deactivate` — sonst zöge es SL/TP beim nächsten Tick zurück,
User-Vorgabe). ⚠ **Extern-Erkennung (Fix 2026-07-17):** Setzt der User SL/TP **direkt
im MT5-Terminal** (nicht über die App), greift `deactivate()` nicht — das Trailing
überschrieb die Handeingabe (real: TP 90,000 → 81,484). `trailing._do_modify` vergleicht
jetzt den Broker-SL/TP mit dem **zuletzt selbst gesetzten** (`_last_sl/_last_tp`, tol =
Modify-Schwellwert): weicht er ab → **Trailing schaltet sich ab, Handeingabe bleibt
stehen** (Log „Manuelle SL/TP-Änderung erkannt"). `_last_sl/_last_tp` werden bei
Aktivierung genullt (kein Altwert-Fehlalarm); Erkennung erst ab dem 2. Modify. Token via `[web] api_token`; bei
`require_token=false` ist die Token-Pflicht aus (Zugang nur via WireGuard).
- **Snapshot-Cache:** `/api/snapshot` UND `/ws` liefern `engine.snapshot_cached()`
  (TTL `_SNAP_TTL_S=0,8 s`) — EIN berechneter Snapshot wird über alle Geräte
  geteilt, SQLite/Verdict-Last bleibt unabhängig von der Client-Anzahl.
- **WS-Wakeup nach Sperrbildschirm/Hintergrund (Fix 2026-07-22, User-Meldung „G/V
  großer Lag"):** Backend-Pipeline ist schnell (`_pos_loop` 1 s · Snapshot-Cache
  0,8 s · WS-Push 1 s; gemessen: MT5-Lock-Last selbst im Worst-Case nur ~25 ms,
  0 Lock-Timeouts/`_pos_loop`-Fehler im Log) — die Ursache lag im **Frontend**:
  mobile Browser pausieren WS+Timer beim Sperren/Backgrounding, ohne
  `visibilitychange`-Handling zeigte die Seite bis zu einem zufälligen Reconnect
  den STALEN Stand (Minuten alt). Fix: `visibilitychange`/`pageshow`/`focus`-Listener
  (`_wakeRefresh` in `app.js`) holen beim Zurückkommen sofort einen frischen
  REST-Snapshot UND bauen die WS-Verbindung hart neu auf (statt auf den evtl.
  hängenden alten Socket zu warten).
  **REST-Polling als Sicherheitsnetz (2026-07-22, User-Wunsch „JSON-Feed"):**
  zusätzlich zum WS-Push pollt `app.js` alle `POLL_MS=4000` ms `/api/snapshot` —
  fängt den Fall auf, dass der WS still hängt (kein `onclose`, keine Zustellung
  mehr, z. B. schwaches WireGuard-Signal) OHNE auf einen Reconnect zu warten;
  pausiert bei `document.hidden` (Akku/Daten). **`lastTs`-Dedup** (`_applySnapshot`,
  vergleicht `engine.snapshot_cached().ts` — dieselbe Quelle für WS UND REST):
  nur die jeweils NEUERE Quelle rendert → kein Flackern/Doppel-Render, wenn beide
  fast gleichzeitig eintreffen. Alle Snapshot-Konsumenten (initialer Load,
  Wake-Refresh, Poll, WS) laufen jetzt über `_applySnapshot` statt direkt `render`.
  v=108. `GET /api/snapshot` ist ohnehin öffentlich/token-frei nutzbar — externe
  Tools (Shortcuts, Home Assistant, …) können ihn direkt pollen.

## Auch beachten
- **Startup-Schonfrist gegen Sofort-Close nach Neustart (User-Vorgabe 2026-07-20,
  `[trading] startup_close_grace_s=60`):** In den ersten 60 s nach Bot-Start schließt
  der Bot **keinen laufenden Trade selbst** — gilt für **S/R-Close** (`_check_sr_close`),
  **Notfall-Stop/Gewinn-Ziel** (`_check_auto_close`, Armieren läuft weiter, nur der Close
  ist gesperrt), **Time-Stop** (`trailing`, via `set_no_close_until`) und **Auto-Squeeze-
  Reverse**. Grund: nach `restart_server.bat` sind Preis/ATR/P(break)/Level für einen
  Moment instabil → ein adoptierter Trade, der gerade in S/R-Close- oder Notfall-Nähe
  liegt, würde sonst in der ersten Sekunde auf halb-initialisierten Daten gekappt.
  Engine setzt `_no_autoclose_until = start + grace`, `_in_startup_grace()` gated die
  drei `_pos_loop`-Checks; die Trailing-Instanz bekommt denselben Stichtag. ⚠ Der
  **Broker-SL (2×ATR) bleibt unberührt** — er läuft am Broker, kann NICHT verzögert
  werden (dort ist auch keine Verzögerung erwünscht: ein Stop-Loss muss greifen). 0 = aus.
- **Update-Reboot-Lücke (Root-Cause der Nacht 2026-07-20, −95,48 €):** Windows
  Update rebootete 01:30 (MoUsoCoreWorker/TrustedInstaller, 2×), der Server-Task
  `OilTradingServer` hat nur einen **Logon-Trigger** → Server+MT5 down bis zum
  Login 07:42; Time-Stop/S/R-Close/Notfall-Stop liefen nicht, nur der **Broker-SL**
  (broker-seitig!) schützte. **Fix:** WU-Policy `AUOptions=4, Tag=Sa, 03:00`
  (HKLM\...\WindowsUpdate\AU — Reboots nur noch Samstag früh, Markt zu); Standby/
  Hibernate AC+DC=0. ⚠ Offen: nach einem Sa-Reboot startet der Server erst beim
  nächsten Login — **Auto-Logon (netplwiz) wäre die letzte Lücke** (So-Nacht-Open),
  braucht das Windows-Passwort des Users. Server-seitige Schutzschichten sind nur
  so gut wie die PC-Laufzeit.
- **UI-Einstellungen neustart-fest (`runtime_state.json`, 2026-07-19):** App-gesetzte
  Werte — 🚀-BRK-Toggle (`auto_squeeze`), Auto-Close-Schalter (`auto_sr_close`),
  Gewinn-Close-Mindestgewinn (`sr_close_min_gain`) — werden bei jedem `set_*` atomar
  persistiert (`_load/_save_runtime_state`) und überschreiben beim Start die
  ini-Defaults (nur vorhandene Keys). ⚠ **`set_sr_close_min_gain` vergaß den `_save`
  bis 2026-07-22** (Bug, jetzt gefixt) — der am Handy gesetzte Mindestgewinn überlebte
  Änderungen nicht sauber; zusätzlich schickte Enter auf leerem Feld ungewollt 0
  (`change`+`keydown` doppelt → Enter blurrt jetzt nur, `srclose_min`-Endpoint loggt `[WEB]`).
- **Log-Hygiene:** Trail-DEBUG-Zeile (`Trail: profit=…`) auf **1×/30 s gedrosselt**
  (2026-07-19; vorher ~28k Zeilen je Rotation → 5×5 MB deckten nur ~2 Tage Forensik).
- **DB-Guard:** `history.log_trade_open` verwirft 0-Lot-/Preis-lose Einträge
  (Reconcile-Artefakte; 6 Alt-Zeilen am 2026-07-19 bereinigt, Backup
  `oil_widget_history.db.bak-2026-07-19`).
- Persönliches Auto-Memory unter `C:\Users\ah\.claude\projects\…\memory\`
  (Beobachtungen/Feedback) ergänzt diese Datei.
- `oil_widget_config.ini` enthält **Live-Secrets** (Keys/Token) — nicht ins
  Repo/Logs leaken.
- **DB** `oil_widget_history.db` (trades · intended_trades · recommendations · **candles_m1** · **pbreak_predictions** · **verdict_votes**).
  Vor jedem Eingriff Backup (`*.bak-<datum>`); Zeitspalten sind lokale Epoch
  (Broker-Offset bereits korrigiert) — **AUSNAHME `candles_m1.time` = ROHE Broker-Zeit
  (UTC+3)**, deckungsgleich mit `copy_rates`.
- **M1-Candle-Logger (`core/candle_logger.py`, 2026-07-21, Daten-Sammlung, kein
  Strategie-Eingriff):** schreibt abgeschlossene M1-Kerzen (OHLC + Spread-in-Preis +
  tick_volume + symbol) nach `candles_m1` (PK `time`, INSERT OR IGNORE = dedupliziert,
  self-healing). `engine.candles.log(sym)` im Trend-Loop, self-throttled ~55 s; erster
  Lauf backfillt ~3000 Bars, danach die letzten 180. **Warum:** Broker-M1-History rollt
  weg (kurz); M1 ist die Master-Auflösung → aus M1 jede höhere TF exakt aggregierbar.
  ⚠ Ticks/Echtzeit bewusst NICHT geloggt (~85k/Tag = 30M/Jahr, kein Bedarf — Strategien
  sind M5+, Slippage aus echten Fills gemessen). ~370k Bars/Jahr = vernachlässigbar.