Systemzustand in den Tagesreport - der fehlende letzte Meter

Selbstaendige Empfehlung nach der Gesamtpruefung, vom User beauftragt.

Befund: die Erkennung funktioniert, die Zustellung nicht. Sieben
Waechter, jeder nach einem eigenen Vorfall gebaut, jeder funktioniert -
und trotzdem blieben diese Woche sechs Zustaende tagelang unbemerkt,
vier davon waren bereits erkannt.

Belegt an den Marker-Dateien: cfg_auto_sr_close traegt 06.08. 18:10,
cfg_auto_squeeze sogar 02.08. Der Config-Waechter meldet je Schluessel
genau einmal und schweigt danach fuer immer. auto_sr_close war damit
fuenf Tage aus - gemessen +350,81 EUR ueber 43 Trades. Ursache ist ein
Kategorienfehler: die Marker-Logik behandelt einen Dauerzustand wie ein
Einmal-Ereignis.

Gebaut: engine._system_status() als Block im Tagesreport (07:30,
Telegram + E-Mail) - der einzige Kanal, der nachweislich jeden Tag
ankommt. Saubere Trennung: Popup = "etwas Neues", Report = "so steht
es gerade". Reine Anzeige.

- telemetrie_puls() liegt in core/history.py, beide Nutzer rufen
  dieselbe Funktion (Skripte importieren core, nie umgekehrt)
- measurement_reminder wird lazy und gekapselt importiert; ein
  Fehlschlag wird sichtbar gemeldet statt still verschluckt
- tests/test_system_status.py: 7 Tests, Schwerpunkt Ausfallpfade -
  der Report darf an dieser Zeile nie scheitern

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

CLAUDE.md

@@ -6161,6 +6161,61 @@ 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`).
 
+## ✅✅ SYSTEMZUSTAND IM TAGESREPORT (2026-08-11) — der fehlende letzte Meter
+
+**Selbständige Empfehlung nach der Gesamtprüfung, vom User beauftragt.**
+
+⚠⚠ **DER BEFUND: die Erkennung funktioniert, die ZUSTELLUNG nicht.** Das Projekt
+hat sieben Wächter, jeden nach einem eigenen Vorfall gebaut — und jeder tut, was
+er soll. Trotzdem blieben allein in dieser Woche **sechs** Zustände tagelang
+unbemerkt, **vier davon waren bereits erkannt**:
+| Vorfall | unbemerkt | erkannt? |
+|---|---|---|
+| `auto_sr_close` aus | **5 Tage** | ✅ 1× gemeldet, dann Marker → Stille |
+| `auto_squeeze` aus | seit 11.08. | ✅ — Marker von **02.08.** → **gar keine** Meldung |
+| `rec_outcomes` tot | **5 Tage** | ❌ (Puls-Wächter heute gebaut) |
+| Telegram still | **4 Tage** | ❌ |
+| Divergenz-Wächter Dauerwarnung | **6 Tage** | er *war* der Wächter |
+| `squeeze_entry_gap` 8/12 | seit 05.08. | ✅ „sammelt noch" |
+
+✅ **BELEGT AN DEN MARKER-DATEIEN:** `cfg_auto_sr_close` trägt **06.08. 18:10**,
+`cfg_auto_squeeze` trägt **02.08. 18:00**. Der Config-Wächter meldet je Schlüssel
+**genau einmal** und schweigt danach für immer. `auto_sr_close` war damit fünf
+Tage aus — und wurde am 11.08. mit **+350,81 € über 43 Trades** gemessen
+(grob 150–300 € entgangener Wert, je nach Vergleichbarkeit der Bedingungen).
+⚠⚠ **Die Ursache ist ein Kategorienfehler:** die Marker-Logik behandelt einen
+**Dauerzustand** wie ein **Einmal-Ereignis**.
+
+✅ **GEBAUT: `engine._system_status()` → Block im Tagesreport (07:30, Telegram +
+E-Mail).** Der Report ist der einzige Kanal, der nachweislich **jeden Tag**
+ankommt (Telegram-Log lückenlos `ok`); der Popup verstummt nach dem ersten Mal.
+**Saubere Trennung: Popup = „etwas Neues ist passiert", Tagesreport = „so steht
+das System gerade".**
+Realer erster Block:
+```
+⚙ Systemzustand:
+  Automatik: BRK aus · SIG aus · S/R-Close AN · Flip aus
+  ⚠ Puls: rec_outcomes: 0 Zeilen — Logger hat NIE geschrieben
+  ⚠ Config: auto_squeeze steht auf 'false' (validiert: 'true')
+  Messungen: pbreak_accuracy_v2 143/350 · squeeze_b5 11/20 · squeeze_entry_gap 8/12
+```
+⚠ **Reine Anzeige** — es wird nichts geschaltet und nichts entschieden.
+⚠ **`measurement_reminder` wird LAZY und GEKAPSELT importiert** (1×/Tag, nicht im
+Live-Pfad): ein Auswertungs-Skript gehört NICHT in den Live-Abhängigkeitsgraphen
+— derselbe Fehler wie der `backtest_breakout_squeeze`-Import. Ein Fehlschlag wird
+**sichtbar** gemeldet, nicht still verschluckt (ein fehlender Block sähe aus wie
+„alles gut" — exakt die Klasse, die `rec_outcomes` fünf Tage verbarg).
+✅ **`telemetrie_puls()` liegt in `core/history.py`** (DB-Schicht), **beide**
+Nutzer rufen dieselbe Funktion — Skripte importieren `core`, nie umgekehrt.
+✅ **7 Tests** (`tests/test_system_status.py`), Schwerpunkt auf den **Ausfallpfaden**:
+ein Report, der wegen der Statuszeile gar nicht ankommt, wäre schlimmer als keine
+Statuszeile. Geprüft: kein Befund wird ausdrücklich bestätigt · ein Puls-Fehler
+wird gemeldet statt verschluckt · ohne `history` kein Absturz · die Methode wirft
+**nie** und liefert immer mindestens eine Zeile · die Puls-Tabellenliste ist
+vollständig.
+⚠ **Verifikation der Zustellung steht aus** — sie erfolgt mit dem Report am
+nächsten Morgen um 07:30. Die Bausteine sind einzeln live gegengeprüft.
+
 ## Gesamtprüfung 2026-08-11 (nach `docs/review-prompt.md`)
 
 Zweiter vollständiger Durchlauf. **Drei echte Defekte**, alle behoben; keine