S/R-Auto-Close wieder an (User-Entscheidung)

Die Funktion existierte und stand seit 06.08. auf false; der
Config-Waechter flaggte das durchgehend. Entscheidend ist die
Unterscheidung: der PAUSCHALE S/R-Close ist 2x verworfen
(Gewinner-Kappen), der P(break)-GEGATETE ist positiv (H1 +357 R,
H2 +1.418 R gegen reines Trailing).

Live kontrafaktisch nachgerechnet ueber 43 Trades ab dem
Nachtrainieren (31.07.): IST +2.171,72 EUR gegen HALTEN mit dem
kanonischen Exit +1.820,91 EUR = +350,81 EUR zugunsten sr_close,
besser in 27 von 43 Faellen. Das kehrt analyze_manual_close.py
(04.08., -530 EUR) um - jene Messung lief auf dem alten Modell.

Die 100 % Trefferquote der sr_close-Statistik ist keine Leistung,
sondern Konstruktion: geschlossen wird nur im Plus.

Vorbehalte: n=43 in einem Regime, EUR-Faktor geschaetzt, das
P(break)-Modell ist live fehlkalibriert (14,3 Pp) und das Gate
gatet kaum (94-97 % aller Beruehrungen).

Alle drei Stellen angeglichen (Snapshot, runtime_state.json, ini) -
sonst bliebe dieselbe latente Inkonsistenz, durch die auto_squeeze
unbemerkt aus war.

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

CLAUDE.md

@@ -5353,6 +5353,43 @@ nicht führbar — und Schritt 4 ist der EINZIGE belastbare Nachweis, dass neuer
 Python-Code läuft. Jetzt mit **Punktpfaden**; ein Feld mit Wert `None` zählt als
 vorhanden (geprüft wird der Schlüssel, nicht der Inhalt).
 
+### ✅ S/R-AUTO-CLOSE WIEDER AN (User-Entscheidung 2026-08-11)
+
+Frage war: „sollten wir Trades bei einem S/R-Bounce automatisch schliessen?"
+⚠ Die Funktion existierte bereits und stand seit dem 06.08. auf `false`; der
+Config-Waechter flaggte die Abweichung durchgehend.
+⚠⚠ **Entscheidend ist die Unterscheidung:** der **pauschale** S/R-Close ist
+**2× verworfen** (Trefferquote 35→67 %, aber PF/ΣR in beiden Haelften schlechter
+= Gewinner-Kappen); der **P(break)-gegatete** ist positiv (H1 +357 R, H2 +1.418 R
+gegen reines Trailing, `backtest_pbreak_rvalue.py`).
+
+✅ **LIVE KONTRAFAKTISCH NACHGERECHNET (43 Trades ab dem Nachtrainieren 31.07.):**
+| | |
+|---|---|
+| IST (sr_close) | **+2.171,72 €** |
+| HALTEN (kanonischer Exit ab demselben Einstieg) | +1.820,91 € |
+| **Differenz** | **+350,81 €**, besser in **27 von 43** Faellen (63 %) |
+⚠⚠ **Die 100-%-Trefferquote der sr_close-Statistik ist KEIN Befund, sondern
+Konstruktion** — `_check_sr_close` schliesst ausschliesslich im Plus (`pnl>0`).
+Aussagekraeftig ist allein der Vergleich oben.
+✅ **Das kehrt `analyze_manual_close.py` (04.08.) um** (dort war sr_close −530 €
+schlechter) — jene Messung lief auf dem **alten** Modell, vor dem Nachtrainieren.
+⚠ **Vorbehalte:** n=43 in EINEM Regime · EUR-Faktor 87,6 geschaetzt · das
+P(break)-Modell ist live **fehlkalibriert** (14,3 Pp zu niedrig, AUC unentschieden
+bei 87 entkoppelten Vorhersagen) · und das Gate **gatet kaum** (schliesst 94–97 %
+aller Beruehrungen, ist also nah an der pauschalen Variante). Dass es trotzdem
+besser abschneidet, spricht dafuer, dass es den besseren **Moment** waehlt, nicht
+die besseren Level.
+✅ Eingeschaltet ueber `POST /api/srclose`; **alle drei Stellen angeglichen**
+(Snapshot · `runtime_state.json` · ini) — sonst bliebe dieselbe latente
+Inkonsistenz, durch die `auto_squeeze` unbemerkt aus war. Backup
+`oil_widget_config.ini.bak-2026-08-11-srclose`.
+⚠ Beim Einschalten stand eine Position bei −55,62 € — der Auto-Close greift nur
+im Plus, hatte also keinen Sofort-Effekt.
+⚠ **Nicht verwechseln:** `auto_squeeze` wurde am selben Tag um **14:10 vom User
+ueber das Dashboard wieder AUSgeschaltet** (`[WEB] Auto-Squeeze-Entry AUS`) —
+die Herkunfts-Kennzeichnung im Log (eingebaut 02.08.) hat das eindeutig belegt.
+
 ### ⚠ ENTRY-DIALOG ENTFERNT (User-Vorgabe 2026-08-11, v=163)
 
 „Entferne auch die Warnung beim Eröffnen von Trades." LONG/SHORT feuern jetzt