M15-Karte: Flacker-Ursache gemessen, Hysterese + EINE Quelle (v=165)

Die Karte wechselte den Zustand alle 12 Sekunden (~1.030/Tag) - der
Grund, warum ihre Selbstmessung so stark geclustert war.

Mein erster Verdacht (das Level im Wechsel-Schluessel) war falsch.
Ausgezaehlt ueber 3.525 Zeilen: status 32,9 %, lesart 32,7 %,
level allein nur 7,6 %. Das Level zu entfernen braechte 3.525 -> 3.248,
also nichts. Der Zustand selbst zappelt: gap <= 0,5 und das 45/55-Band
von P(break) sind stetige Groessen um ihre Schwelle.

Das Projekt hatte die Loesung schon (analyze_pbreak_flicker.py, 14.07.:
Hysterese +-5 Pp) - die Karte umging sie, weil sie P(break) selbst neu
rechnet. Jetzt dieselbe Hysterese auf beide Schwellen: Status gruen ab
0,50 / zurueck erst ueber 0,60; Lesart gerichtet ab 40/60 / zurueck
erst innerhalb 45/55. Simuliert: 64 % weniger Wechsel.

Zweiter, groesserer Befund: Status und Lesart wurden an DREI Stellen
unabhaengig gebildet und wichen bereits ab - der Logger kannte den
"kein Veto"-Fall des Frontends nicht, protokollierte also einen
anderen Zustand als angezeigt wurde. Jetzt eine Quelle: _m15_setup
liefert status/lesart/nah im Snapshot, Logger und Frontend lesen sie.

Die alten 3.525 Zeilen sind mit den neuen nicht vergleichbar; die
Selbstmessung beginnt faktisch neu (Stichtag 12.08.). Kein Verlust -
sie liess vorher ohnehin kein Urteil zu.

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

CLAUDE.md

@@ -6161,6 +6161,49 @@ Neumessung. Sie bleiben unverändert und reproduzierbar; wo ihre Schlussfolgerun
 relevant wird, gehört sie live-treu **neu gerechnet** (Muster:
 `backtest_auto_signal_norev.py`).
 
+## ⚠⚠ DAS FLACKERN DER M15-KARTE — Ursache gemessen, Hysterese eingebaut (2026-08-12)
+
+Die Karte wechselte den Zustand **alle 12 Sekunden** (~1.030/Tag). Das ist der
+Grund, warum ihre Selbstmessung so stark geclustert war (roh 60 %, entkoppelt
+53 %).
+
+⚠⚠ **MEIN ERSTER VERDACHT WAR FALSCH — und die Messung war schnell.** Ich hatte
+das Level im Wechsel-Schlüssel (`round(level, 3)`) im Verdacht. Ausgezählt über
+3.525 Zeilen:
+| Was ändert sich zwischen zwei Zeilen? | Anteil |
+|---|---|
+| **`status`** | 32,9 % |
+| **`lesart`** | 32,7 % |
+| lesart+level | 20,3 % |
+| **level allein** | **7,6 %** |
+Das Level aus dem Schlüssel zu nehmen brächte 3.525 → 3.248 Zeilen — praktisch
+nichts. **Der Zustand selbst zappelt**: `gap ≤ 0,5` und das 45/55-Band von
+P(break) sind stetige Grössen, die um ihre Schwelle pendeln.
+
+✅ **Das Projekt hatte die Lösung schon** (`analyze_pbreak_flicker.py`, 14.07.:
+Zeit-Glättung + **Hysterese ±5 Pp**). Die Karte umging sie, weil sie P(break)
+selbst neu rechnet. Jetzt dieselbe Hysterese auf beide Schwellen:
+· **Status**: grün ab `gap ≤ 0,50`, zurück auf gelb erst **über 0,60**
+· **Lesart**: gerichtet erst ausserhalb **40/60**, zurück auf „unklar" erst
+  innerhalb **45/55**
+Simuliert an 4.000 Ticks direkt auf den Schwellen: **3.084 → 1.103 Wechsel
+= 64 % weniger.**
+
+⚠⚠ **ZWEITER, GRÖSSERER BEFUND: Status und Lesart wurden an DREI Stellen
+unabhängig gebildet** — Frontend, `_log_m15_state` und die Karte selbst. **Sie
+wichen bereits ab**: der Logger kannte den „kein Veto"-Fall des Frontends nicht,
+hat also einen anderen Zustand protokolliert als angezeigt wurde. Genau die
+Divergenz-Falle, die im Projekt schon dreimal zugeschlagen hat (`sim_run` in ≥6
+Skripten · der nachgebaute Level-Cluster · das fünfte Exit-Modell).
+✅ Jetzt **EINE Quelle**: `_m15_setup` liefert `status`/`lesart`/`nah` im
+Snapshot, Logger und Frontend lesen sie. Anzeige und Messung können nicht mehr
+auseinanderlaufen.
+
+⚠ **Die alten 3.525 Zeilen sind mit den neuen NICHT vergleichbar** — sie wurden
+unter dem flackernden Regime geschrieben. Die Selbstmessung beginnt faktisch neu;
+das ist kein Verlust, weil sie vorher ohnehin kein Urteil zuliess (KI enthielt
+die 50). Stichtag: 12.08.
+
 ## ⚠⚠ DIE M15-KARTE HAT SICH ZUM ERSTEN MAL SELBST GEMESSEN (2026-08-12)
 
 Anlass: User-Frage „könntest du mir auch eine **M5** · Setup-Bereitschaft bauen?