From a866c9cec72641cf9898ca638016c936918e3b59 Mon Sep 17 00:00:00 2001 From: Axel Hocks Date: Tue, 11 Aug 2026 22:18:59 +0200 Subject: [PATCH] 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 --- CLAUDE.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 9c5aa1c..a9c6c1f 100644 --- a/CLAUDE.md +++ b/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