Gewinn-Close & Notfall-Stop nicht mehr beim Öffnen setzen

sr_close_min_gain_pct und auto_emergency_margin_pct auf 0 (User-Vorgabe): beim
Eröffnen einer Position wird nichts mehr automatisch armiert, nur manuell im UI
gesetzte Werte greifen. Mechanik bleibt im Code (reaktivierbar via ini).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Axel Hocks
2026-07-24 17:56:49 +02:00
co-authored by Claude Opus 4.8
parent 4bc7679ba3
commit d9eafe32f7
3 changed files with 40 additions and 41 deletions
+27 -29
View File
@@ -593,16 +593,17 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
`set_sr_close_min_gain` · Snapshot `sr_close_min_gain`): unter der EUR-Schwelle
wird am Level NICHT geschlossen. ⚠ Gemessen ist OHNE besser (Verworfen-Eintrag) —
Opt-in auf User-Wunsch, UI-Status warnt. **Automatisch auf X % des Einsatzes
(User-Vorgabe 2026-07-23, `[trading] sr_close_min_gain_pct=3.0`, 1%→3% am selben
Tag nachgezogen zusammen mit dem margin-%-Notfall-Stop, s. u.):** bei JEDER
echt neuen Position (nicht beim Wiedererkennen nach Neustart) wird `sr_close_
min_gain` frisch auf `pct% × Margin dieser Position` gesetzt (`_check_auto_close`,
Margin kommt aus `trader.refresh()` unmittelbar davor im selben `_pos_loop`-Tick) —
überschreibt den manuell gemerkten Wert, persistiert via `_save_runtime_state`.
0 = aus (dann bleibt der manuell gesetzte/gemerkte Wert maßgeblich wie vorher).
⚠ Gleiche Kopplungs-Regel wie beim festen Mindestgewinn: skaliert nur die Größe
desselben bereits gemessen-suboptimalen Mechanismus, kein neuer Risikotyp. Log
„Auto-Close armiert …" (getrennt) + „Gewinn-Close armiert … +X (3% Margin Y)".
(`[trading] sr_close_min_gain_pct`) — Stand 2026-07-24 AUF 0 = AUS (User-Vorgabe
„gewinn close … nicht setzen beim Eröffnen"; war kurz 1,0→3,0 am 2026-07-23).**
Bei `pct>0` wird bei JEDER echt neuen Position (nicht beim Wiedererkennen nach
Neustart) `sr_close_min_gain` frisch auf `pct% × Margin dieser Position` gesetzt
(`_check_auto_close`, Margin aus `trader.refresh()` im selben `_pos_loop`-Tick,
persistiert via `_save_runtime_state`, Log „Gewinn-Close armiert … +X (N% Margin
Y)"). Bei `pct=0` (aktuell) wird beim Öffnen NICHTS gesetzt — es bleibt der
manuell im UI gesetzte/gemerkte `sr_close_min_gain` (Default 0). ⚠ Beim Abschalten
2026-07-24 auch den persistierten Alt-Wert in `runtime_state.json` auf 0 gesetzt
(stand auf 17,17 vom letzten 3%-Auto-Set), sonst hätte ihn jeder neue Trade als
festen Mindestgewinn geerbt. Mechanik im Code erhalten (reaktivierbar via ini).
**Gate verifiziert (2026-07-23, User-Nachfrage „darf nicht schließen bevor der
Wert erreicht wurde"):** `_check_sr_close` prüft `pnl < sr_close_min_gain → return`
**bevor** `_sr_close_hint`/`trader.close` überhaupt aufgerufen werden — isoliert
@@ -753,25 +754,22 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
Neustart wählt die Heuristik den TF binnen 1 min neu.
- **Kein automatischer Tagesverlust-Schalter (Circuit Breaker):** vom User
abgelehnt — NICHT einbauen. Bei 90 %-Margin-Sizing bleibt Drawdown-Risiko hoch.
- **Notfall-Stop = AKTIV als margin-%-Modus (User-Vorgabe 2026-07-23,
`[trading] auto_emergency_margin_pct=3.0`).** Kurz-Historie: 2026-07-17 komplett
raus (2 % ≈ 0,76×ATR zerschoss die Squeeze-Trades, 48,94-€-Tag) · 2026-07-20
wenige Stunden als **3-%-GAP-NETZ (Balance-Basis)** zusammen mit `risk_pct=1.5` ·
mit der Rückkehr zu **Margin-Sizing 80 %** am selben Tag wieder aus (`auto_
emergency_pct=0`) · **2026-07-23 neu aktiviert, diesmal margin-basiert**
(`auto_emergency_margin_pct=3.0`, dritter Modus, s. u.), ausgelöst durch zwei
Notfall-Closes am selben Abend (11,20 €/20,47 €, s. „B0"-Analyse) — dabei hing
die Schwelle beim ersten Trade noch auf einem händisch aus dem UI-Feld getesteten
**Restwert von 5 €** (viel zu eng), nicht auf einer bewusst gesetzten Zahl. ⚠
**Kopplungs-Regel (gilt weiter, jetzt bewusst in Kauf genommen):** Ein %-Notfall-
Stop ist unter reinem Margin-Sizing (80 %, `risk_pct=0`) grundsätzlich enger als
der 2×ATR-SL — 3 % der Margin ist aber deutlich lockerer als der frühere 2 %-
Balance-Versuch (bei ~800 € Margin einer Standardposition sind 3 % ≈ 24 €, vs.
vorher 2 % von ~830 € Balance ≈ 16,62 €), soll als Sicherheitsnetz GEGEN genau
solche „vergessener enger Restwert"-Fälle wirken, nicht als enger Ersatz für den
Broker-SL. **Kein Backtest** (reines Risikomanagement-Sizing, kein Signal-Eingriff
— Track A, nicht Track B). Schutz-Stack jetzt: **Broker-SL 2×ATR + Trailing +
Time-Stop + margin-%-Notfall-Stop** als zusätzliches Netz.
- **Notfall-Stop = AUS beim Öffnen (Stand 2026-07-24, `auto_emergency_margin_pct=0`,
`auto_emergency_pct=0`, `auto_emergency_loss=0`).** User-Vorgabe 2026-07-24: „gewinn
close und notfall close … nicht setzen beim Eröffnen" → alle drei Auto-Arm-Modi 0,
beim Öffnen einer Position wird KEIN Notfall-Stop gesetzt. Nur ein **manuell** im
UI-Feld eingegebener Wert armiert (bleibt bis zum nächsten Positionswechsel).
Kurz-Historie des margin-%-Modus: 2026-07-17 komplett raus (2 % ≈ 0,76×ATR zerschoss
die Squeeze-Trades, 48,94-€-Tag) · 2026-07-20 wenige Stunden als **3-%-GAP-NETZ
(Balance-Basis)** mit `risk_pct=1.5` · **2026-07-23 kurz margin-basiert `=3.0`**
(dritter Modus, ausgelöst durch zwei Notfall-Closes am selben Abend 11,20 €/20,47 €,
wobei die Schwelle beim ersten Trade noch auf einem händischen UI-Restwert von 5 €
hing) · **2026-07-24 auf User-Wunsch wieder ganz AUS.** Der margin-%-Modus bleibt im
Code (retry-sicheres Armieren via `_emergency_margin_armed_ticket`, hat Vorrang vor
Balance-%/Fixwert wenn >0), reaktivierbar per ini. ⚠ Kopplungs-Regel (falls
reaktiviert): unter Margin-Sizing kann ein enger %-Stop schneller greifen als der
2×ATR-SL. Schutz-Stack aktuell: **Broker-SL 2×ATR + Trailing + Time-Stop** (der
Auto-Notfall-Stop ist inaktiv).
**UI-Feld** (`#emg-input`, User-Vorgabe 2026-07-22, v=105) in der Trade-Leiste
(rot, neben Gewinn-Close), Enter blurrt nur (kein Doppel-Send/ungewolltes 0,
gleicher Fix wie Mindestgewinn 2026-07-22) — ein am Handy gesetzter Wert
+11 -10
View File
@@ -288,10 +288,10 @@ DEFAULT_CONFIG = {
# Sektion: verliert monoton in beiden Hälften) — bewusster User-Opt-in.
"sr_close_min_gain": "0",
# Gewinn-Close automatisch auf X % des EINSATZES (Margin) der jeweiligen Position
# setzen, sobald sie eröffnet wird (User-Vorgabe 2026-07-23, 1%→3% am selben Tag
# nachgezogen zusammen mit dem margin-%-Notfall-Stop). 0 = aus (dann bleibt
# der manuell gesetzte/gemerkte `sr_close_min_gain` unverändert maßgeblich).
"sr_close_min_gain_pct": "3.0",
# setzen, sobald sie eröffnet wird. 0 = AUS (User-Vorgabe 2026-07-24: NICHTS beim
# Öffnen setzen — der manuell gesetzte/gemerkte `sr_close_min_gain` bleibt dann
# maßgeblich). War kurz 1,0→3,0 (2026-07-23), auf User-Wunsch wieder 0.
"sr_close_min_gain_pct": "0",
# Auto-Notfall-Stop als % der Balance beim Öffnen (skaliert mit dem Konto).
# >0 → Stop = pct% × Balance; 0 = aus. ⚠ Nur zusammen mit risk_pct>0 als
# GAP-NETZ sinnvoll (dann pct ≈ 2× risk_pct → feuert nur bei Slippage/Gap
@@ -301,12 +301,13 @@ DEFAULT_CONFIG = {
# Rückkehr zu Margin-Sizing (80 %) am selben Tag wieder AUS. Bleibt 0 — ersetzt
# durch `auto_emergency_margin_pct` (s. u.), hat Vorrang wenn >0.
"auto_emergency_pct": "0",
# Notfall-Stop als % der EINSATZ-Margin der Position (User-Vorgabe 2026-07-23,
# analog zu `sr_close_min_gain_pct`). >0 → Stop = pct% × Margin dieser Position,
# hat Vorrang vor `auto_emergency_pct` (Balance) und dem Fixwert. 0 = aus.
# ⚠ Gleiche Kopplungs-Warnung wie beim Balance-%-Modus: unter Margin-Sizing kann
# ein enger %-Stop schneller greifen als der 2×ATR-SL — bewusste User-Vorgabe.
"auto_emergency_margin_pct": "3.0",
# Notfall-Stop als % der EINSATZ-Margin der Position (analog zu
# `sr_close_min_gain_pct`). >0 → Stop = pct% × Margin dieser Position, hat Vorrang
# vor `auto_emergency_pct` (Balance) und dem Fixwert. 0 = AUS (User-Vorgabe
# 2026-07-24: beim Öffnen NICHTS setzen). War kurz 3,0 (2026-07-23), wieder 0.
# ⚠ Kopplungs-Warnung (falls reaktiviert): unter Margin-Sizing kann ein enger
# %-Stop schneller greifen als der 2×ATR-SL.
"auto_emergency_margin_pct": "0",
# Entry-Raum-Gate: Signal → WARTEN, wenn das Gegenlevel (M5-Pivot in Trade-
# Richtung) näher als X×ATR liegt (gemessen `backtest_entryroom.py` — Raum
# <0,6 in beiden Hälften negativ: Ertrag am Level gedeckelt, Kosten fressen
+2 -2
View File
@@ -37,13 +37,13 @@ auto_squeeze_skip_night = false
auto_squeeze_reverse = false
auto_emergency_loss = 0
auto_emergency_pct = 0
auto_emergency_margin_pct = 3.0
auto_emergency_margin_pct = 0
auto_takeprofit = 0
auto_sr_close = true
sr_close_pbreak = 0.60
export_mql5_levels = true
sr_close_min_gain = 0
sr_close_min_gain_pct = 3.0
sr_close_min_gain_pct = 0
startup_close_grace_s = 60
[gemini]