Telegram bei gruener M15-Karte (m15_alert) + Tests verschmutzen nicht mehr das Log

User: "wenn es eine Empfehlung gibt (gruen), schicke eine Telegram-Nachricht."
engine._check_m15_alert, direkt hinter _log_m15_state -- dieselbe Quelle wie
Anzeige und Selbstmessung, damit die drei nicht auseinanderlaufen koennen.

DIE ENTPRELLUNG IST DER GANZE BAU. Roh springt die Karte 85x/Tag auf gruen
(m15_states, 3 Tage nach der Hysterese vom 12.08.) -- das waere Spam. Alle
Stufen an den echten Daten kalibriert, nicht geraten:

  nur Flanke                          85,0/Tag
  + Level & Richtung als Schluessel   23,7/Tag
  + 30 min Mindestabstand             13,3/Tag
  + Fenster 8-20 Uhr (Default)         7,7/Tag
  (Vergleich: Close-Meldung ab 50 EUR  2,4-6,1/Tag)

Nach 4 h darf dasselbe Level erneut melden, sonst verschweigt der Alert ein
Setup, das den ganzen Tag wiederkommt.

Der Text sagt ausdruecklich, dass es KEINE Prognose ist: die Karte automatisch
zu handeln faellt gemessen durch (backtest_m15_auto.py: OeR -0,162/-0,094). Die
Meldung ist ein Hinweis zum Hinsehen fuer den Menschen (+3,20 EUR/Lot ueber 146
Trades). Die P(break)-Formulierung ist wortgleich zu Karte und Chart (v1.35).

13 Tests, Schwerpunkt auf dem was NICHT gesendet werden darf. Mutationsprobe in
vier Zweige, alle gefangen.
DIE PROBE HAT EIN TESTLOCH AUFGEDECKT: das Entfernen der Flankenerkennung liess
zunaechst ALLE Tests gruen, weil Cooldown und 4-h-Schluessel dasselbe abfangen.
Zwei Schutzschichten, die sich maskieren -- dasselbe Muster wie beim Fill-Dedup.
Geschlossen durch test_flankenerkennung_ISOLIERT.

NEBENBEFUND, behoben: Tests schrieben ins Produktions-Log (ueber 150
M15-Alert-Zeilen + Close-Push #4711 aus test_close_buchung). Ich hielt die
Entprellung deshalb zuerst fuer live defekt. conftest.py entfernt den
FileHandler des oil-Loggers jetzt fuer die Sitzung -- vierte Grundregel der
Suite. Verifiziert: Log-Groesse vor und nach einem Komplettlauf identisch.

Live verifiziert: seit dem Serverstart genau 1 Alert trotz mehrfachem
gruen/gelb-Wechsel. 85 Tests gruen.

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

CLAUDE.md

@@ -5730,6 +5730,56 @@ je anfasst, gehört diese Zelle nachgemessen, nicht die gestaffelte.
 dokumentierten Squeeze-Kontrollwert (+0,124/+0,292) nicht. Belastbar ist allein
 der **relative** Vergleich — alle Varianten laufen auf derselben Entry-Liste.
 
+### ✅ TELEGRAM BEI GRÜNER M15-KARTE (2026-08-14, `[telegram] m15_alert`)
+
+User: „wenn es eine Empfehlung gibt (grün), schicke eine Telegram-Nachricht."
+`engine._check_m15_alert`, aufgerufen direkt hinter `_log_m15_state` — **dieselbe
+Quelle** wie Anzeige und Selbstmessung, damit die drei nicht auseinanderlaufen
+können (die Divergenz-Falle, die am 12.08. schon einmal zugeschlagen hat).
+
+⚠⚠ **DIE ENTPRELLUNG IST DER GANZE BAU, nicht ein Detail.** Roh springt die
+Karte **85× am Tag** auf grün (`m15_states`, 3 Tage nach der Hysterese vom
+12.08.) — das wäre Spam und damit nach zwei Tagen stummgeschaltet. Alle Stufen
+sind an den echten Daten kalibriert, nicht geraten:
+| Stufe | Meldungen/Tag |
+|---|---|
+| nur Flanke | **85,0** |
+| + Level & Richtung als Schlüssel | 23,7 |
+| + 30 min Mindestabstand | 13,3 |
+| **+ Fenster 8–20 Uhr (Default)** | **7,7** |
+| *(Vergleich: Close-Meldung ab 50 €)* | *2,4–6,1* |
+⚠ Nach 4 h (`_ALERT_NEU_S`) darf dasselbe Level erneut melden — sonst
+verschweigt der Alert ein Setup, das den ganzen Tag wiederkommt.
+Schalter: `m15_alert` (true) · `m15_alert_cooldown_min` (30) ·
+`m15_alert_hours` (8-20). Backup `oil_widget_config.ini.bak-2026-08-14-m15alert`.
+
+⚠⚠ **DER TEXT SAGT AUSDRÜCKLICH, DASS ES KEINE PROGNOSE IST.** Die Karte
+automatisch zu handeln fällt gemessen durch (`backtest_m15_auto.py`, 13.08.:
+ØR −0,162/−0,094, KI ohne Null, schlechter als die HTF-Richtung UND als ihr
+eigenes Gegenteil). Die Meldung ist ein **Hinweis zum Hinsehen** für den
+Menschen, dessen Auswahl-Vorteil unabhängig belegt ist (+3,20 €/Lot über 146
+Trades) — und sie schreibt das in die Nachricht. Die P(break)-Formulierung ist
+**wortgleich** zu Karte und Chart (v1.35-Fix).
+✅ **13 Tests** (`tests/test_m15_alert.py`), Schwerpunkt auf dem, was NICHT
+gesendet werden darf. **Mutationsprobe in vier Zweige** — alle gefangen.
+⚠⚠ **Die Probe hat ein echtes TESTLOCH aufgedeckt:** das Entfernen der
+Flankenerkennung liess zunächst **alle** Tests grün, weil Cooldown und
+4-h-Schlüssel dasselbe mit abfangen. Zwei Schutzschichten, die sich gegenseitig
+maskieren — dasselbe Muster wie beim Fill-Dedup. Geschlossen durch
+`test_flankenerkennung_ISOLIERT` (Cooldown aus, Level wandert je Tick).
+✅ Live verifiziert: seit dem Serverstart **genau 1 Alert**, obwohl die Karte
+seitdem mehrfach grün↔gelb gewechselt hat.
+
+**⚠⚠ NEBENBEFUND — TESTS SCHRIEBEN INS PRODUKTIONS-LOG (behoben).** Nach den
+Testläufen standen **über 150** `📨 M15-Alert`-Zeilen in `oil_widget.log`, dazu
+`Close-Push #4711` mit dem synthetischen Ticket aus `test_close_buchung.py`. Ich
+habe daraufhin zuerst geglaubt, die Entprellung sei live defekt, und musste die
+Herkunft an der Level-Folge (82.00, 82.01, …) nachweisen. In einem Projekt,
+dessen Forensik am Log hängt (18-h-Copilot-Ausfall, stille Fehlbuchung), sind
+erfundene Zeilen ein echtes Risiko. `tests/conftest.py` entfernt den
+`FileHandler` des `oil`-Loggers jetzt für die Sitzung — **vierte Grundregel der
+Suite.** Verifiziert: Log-Größe vor und nach einem Komplettlauf **identisch**.
+
 ### ✅ S/R-AUTO-CLOSE WIEDER AN (User-Entscheidung 2026-08-11)
 
 Frage war: „sollten wir Trades bei einem S/R-Bounce automatisch schliessen?"