Zwei Messungen brauchen SQUEEZE-Trades, und auto_squeeze ist seit dem 11.08.
aus -- seit dem 17.08. auch begruendet (B5-Regel gefallen). Ihre Zaehler stehen
seither still: Stop-Order-Umbau 8/12, Nacht-Fenster 3/15.
Als "sammelt (67 %)" angezeigt suggerierten sie einen Fortschritt, den es nicht
gibt: sie laufen NIE ab. Jetzt erscheinen sie als
⏸ ... [RUHT] 8/12 ... -- steht STILL
braucht SQUEEZE-Trades -- auto_squeeze ist AUS ...
RUHEND heisst: die Messung ist nicht langsam, sie ist BLOCKIERT -- und die
Blockade ist eine ENTSCHEIDUNG, keine Datenfrage. Wer den Trader wieder
einschaltet, laesst beide automatisch weiterlaufen; es ist nichts nachzuholen.
Umsetzung: RUHT-Tabelle mit je einer Pruef-Funktion; _auto_squeeze_an() liest
core.live_config (ini + runtime_state in der Vorrangfolge des Engine-Starts).
Faellt die Pruefung aus, gilt "nicht ruhend" -- lieber ein Zaehler zu viel als
eine still verschwundene Messung.
Die sechs uebrigen Messungen laufen unveraendert als "sammelt".
⚠ Beim Bau in die dokumentierte \n-Falle gelaufen: ein per Heredoc geschriebenes
f"\n..." wurde zum echten Umbruch im String-Literal (SyntaxError). CLAUDE.md
sagt genau das ("NIE per Heredoc -- den Edit-Weg nehmen"); ueber den Edit-Weg
behoben, check_nfalle laeuft sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bei der Durchsicht offener Punkte gefunden -- beide derselben Klasse: ein
Waechter, der dauerhaft warnt, wird ignoriert, und mit ihm die eine echte
Meldung (so ist der Divergenz-Waechter verstummt).
(1) Config-Waechter erwartete auto_squeeze='true' und meldete deshalb seit dem
11.08. taeglich eine Abweichung -- obwohl FALSE inzwischen der begruendete
Zustand ist: die B5-Regel ist am 17.08. rechnerisch gefallen (Verhaeltnis
0,14 gegen Latte 1,0, PF 0,39, Latte unerreichbar). Erwartung auf 'false'
gedreht, mit dem Hinweis, dass ein Wiedereinschalten eine NEUE Entscheidung
mit NEUER Latte waere -- dann gehoert der Eintrag zurueckgedreht.
(2) Telemetrie-Puls meldete candles_m1 als Ausfall ("letzte Zeile vor 0,5 h").
Real war der Markt zu -- Pepperstone schliesst ~23:00 und das ganze
Wochenende. Der Logger hatte gestern erst die Vorbedingungs-Kennzeichnung
fuer pbreak_predictions/rec_outcomes bekommen; candles_m1 stand noch auf
"unbedingt". Jetzt mit Vorbedingung -> erscheint als Hinweis statt Ausfall.
0 Zeilen bleibt weiterhin IMMER ein Befund.
Verifiziert: Puls zeigt beide als Hinweis, Config-Waechter still.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FAELLIGE MESSUNG (30.282 Zeilen). Horizont 60 min, gegen die Drift-Null,
Episoden statt Rohzeilen:
Welle 3,0 254 Ep. +0,158 / +0,419 61 % beide +
Liq-Trend 0,5 297 Ep. +0,310 / +0,175 52 % beide +
Squeeze 2,0 249 Ep. +0,110 / +0,254 48 % beide +
Orderbuch 0,5 2.712 Ep. -0,039 / -0,100 49 % beide -
Elliott 1,0 1.388 Ep. kippt 49 %
M30/Muster/H1 kippen
H1 1,5 50 Ep. -1,165 / +1,937 66 % kippt
Meine Vermutung vom 07.08. war FALSCH: Liq-Trend besteht (+0,310/+0,175 ueber
297 Episoden). Ich hatte ihn verdaechtigt, weil er dieselbe HL-Quelle nutzt wie
das entmachtete Orderbuch -- das war Analogie, keine Messung. Bleibt bei 0,5.
Orderbuch bestaetigt: beidhaelftig negativ ueber 2.712 Episoden, die groesste
Stichprobe und der einzige konsistent falsche Beitrag. Entmachtung war richtig.
SCHAERFSTER BEFUND: H1 traegt 41,2 % des Nadel-Einflusses auf 50 Episoden, die
das Vorzeichen kippen. Hoechster Einfluss, duennste Beleglage. Live folgenlos
(die Nadel ist reine Anzeige), aber wer sie liest, sollte es wissen.
FAELLIGKEITSSCHWELLE KORRIGIERT: stand auf 25.000 ZEILEN -- bei Minutentakt in
12 Tagen erreicht, waehrend die auswertbare Einheit Episoden sind (je Modul nur
50 bis 2.712). Dieselbe Klasse wie pbreak_accuracy_v2. Jetzt 400
Headline-Episoden als Proxy, mit dem ausdruecklichen Hinweis, dass es je Modul
deutlich weniger sind.
PUNKT 2 (Stop-Order-Umbau, 8/12): DERSELBE DEADLOCK wie B5. Alle acht Bot-Trades
stammen vom 06.08.; seit auto_squeeze am 11.08. aus ist, kommt keiner mehr dazu.
Was die 8 zeigen, bleibt gueltig und positiv: 7 von 8 fuellten per ruhender
Order, Market-Fallback praktisch weg (n=1 bei +0,148xATR). Die formale
Faelligkeit haengt an derselben Entscheidung wie B5, nicht an weiteren Daten.
Nichts am Live-System geaendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1) CIRCUIT-BREAKER SCHARF -- daily_loss_limit_pct 0 -> 8. Live verifiziert:
enabled=True, limit_eur 89,44. Steht nicht in runtime_state.json, die ini
greift direkt. Begruendung: MaxDD 82,8 % auf dem gemessenen IST-Pfad,
schlechtester Einzeltrade -381 EUR.
2) B5-DEADLOCK RECHNERISCH AUFGELOEST -- die Regel ist ENTSCHIEDEN, nicht
vertagt. Stand 11/20: Verhaeltnis 0,14 (Latte 1,0), PF 0,39 (Latte 1,0).
Was die 9 Rest-Trades leisten muessten:
9/0 Gewinner -> 165,72 EUR je Trade = 12,2x der bisherige Schnitt
7/2 -> 186,17 EUR
5/4 -> 222,99 EUR
Der groesste Squeeze-Gewinn des Zeitraums war 77,34 EUR -- selbst der beste
Fall verlangt 2,1x den Rekord, neunmal in Folge. Latte nicht mehr erreichbar.
auto_squeeze bleibt FALSE. Wiederaufnahme waere eine NEUE Entscheidung mit
NEUER, vorab fixierter Latte.
3) core/kontrolle.py -- Kontroll-Fixture mit den Referenzwerten. Bricht bewusst
NICHT ab: ein Backtest darf abweichen, er muss es nur wissen und sagen.
4) core/live_config.py -- EINE Quelle der Live-Parameter (ini + runtime_state in
der Vorrangfolge des Engine-Starts). Dritte Instanz derselben Fehlerklasse:
ATRMIN_STD 0,12 statt 0,06, fehlendes set_entry_room, nachgebauter Cluster.
5) stichprobe.paarweise()/zeig_paarweise() -- gepaarter Vergleich. Anlass:
trail_start sah sequentiell besser aus, gepaart kippte das Vorzeichen
(Selektions- statt Exit-Effekt). Selbsttest in drei Richtungen bestanden.
6) tools/check_konstanten.py -- Waechter fuer veraltete Zahlen.
Erster Lauf: zwei Befunde, BEIDE Fehler in meiner eigenen Ableitung (Margin
aus Balance geschaetzt statt vom Broker gelesen; Elliott ohne
Gueltigkeitsfenster gezaehlt). Beide korrigiert.
Danach ein ECHTER Fund: meine am 13.08. notierten "~405 EUR/Lot" sind falsch,
der exakte Broker-Wert ist 712,84 -- die urspruenglich notierten 670 lagen
naeher als meine Korrektur. Lehre: eine abgeleitete Zahl ist keine gemessene.
Stand jetzt 0 Befunde.
7) Puls-Waechter bedingungs-bewusst: PULS traegt je Zeile die Vorbedingung,
bedingte Tabellen erscheinen als Hinweis statt als Ausfall. 0 Zeilen bleibt
IMMER ein Befund (der rec_outcomes-Fall). Grund: ein Waechter mit
Fehlalarmen wird ignoriert -- so ist der Divergenz-Waechter verstummt.
Pipeline gruen (85 Tests), Deployment ueber deploy.py --feld circuit_breaker
verifiziert, genau eine Instanz je Port.
Nicht angefasst: Sizing (User-Entscheidung) und die 44 Backtests mit eigener
Exit-Kopie (Migrations-Regel).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheidung. Der Pfad war seit 01.08. aus und auf BEIDEN
Ausfuehrungs-Achsen gemessen negativ: Markt-Einstieg in allen 8
Feldern, ruhende Order mit Touch-Fill -0,392/-0,338 in allen 6 und
damit sogar schlechter als Markt. Die +0,35/+0,32 aus
backtest_auto_signal_v3.py galten in Variante B (Fill beim
Close-Bruch) und waren Look-ahead - Aufschlag 0,77-0,85 R. Ursache
strukturell: das Bestaetigungs-Level _pend WANDERT.
Nebenbei entfaellt der offene Churn-Defekt (4x setzen/stornieren in
76 s bei identischem Level, gefunden 06.08., nie behoben).
Entfernt: _check_auto_signal, set_auto_signal, der Signal-Zweig in
_pending_ziel, /api/autosignal, Button + Handler, vier Snapshot-Felder,
die auto_signal*/signal_pending_entry-Leser.
Geblieben: AUTOSIG_*-Trades in der DB, die Backtests, wave_rec.breakout
(speist block_reason) und _confirm_breakout selbst.
Sicherung: .removed_backup/auto_signal_2026-08-12.py + Git.
Das Risiko war nicht SIG, sondern der GETEILTE Pending-Manager (zwei
getrennte Manager wuerden sich gegenseitig stornieren). Deshalb wurde
das Squeeze-Verhalten VOR dem Eingriff in tests/test_pending_ziel.py
festgenagelt - 7 Tests, vorher gruen, laufen unveraendert weiter.
Zwei Folgefehler fing die Pruefkette sofort: ruff F821 ein verwaistes
_t, py_compile ein dangling if. Zwei Tests wurden mitgezogen statt
geloescht - test_signal_fill_long ist jetzt umgedreht (unbekannte
Quelle darf NICHT als Squeeze durchgehen).
Live verifiziert: alle vier Snapshot-Felder weg, Endpunkt tot,
auto_squeeze/squeeze_pending unveraendert, 67 Tests gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User fragte "Wiedervorlage fuer wann?" - "irgendwann" ist keine.
Jetzt als CHECKS-Eintrag im Reminder mit automatisch pruefbarer
Bedingung: 500 entkoppelte Faelle "Gate schliesst, Level bricht doch"
aus pbreak_predictions (predicted=bounce, outcome=break) ab dem
Nachtrainieren. Stand 55/500, ~4,9/Tag -> faellig um den 10.11.2026.
Schwelle bewusst bei 500: loest einen wahren OeR ab ~0,118 auf und
deckt damit die UNTERE Backtest-Schaetzung (+0,12) ab. Bei n=175
(~25 Tage) waere nur OeR >= 0,20 aufloesbar - die Bedingung liefe ab,
ohne entscheiden zu koennen. Genau dieser Fehler steckte in
pbreak_accuracy_v2 (Faktor 10 zu frueh faellig).
⚠ Eigener Fehler beim Aufsetzen, dokumentiert: ich hatte "roh 193 =
entkoppelt 193" gemessen und daraus ~17 Faelle/Tag geschlossen.
schluessel_level_stunde ist eine FABRIK und muss aufgerufen werden -
uebergibt man sie selbst, ist jeder Schluessel ein neues
Funktionsobjekt und es wird nichts dedupliziert. Richtig sind 55
= ~4,9/Tag, also 3 Monate statt 3 Wochen.
Projektweit geprueft: die zwei echten Verwendungen in
analyze_divergence.py rufen sie korrekt auf (mit Spaltennummern) -
nur die Ad-hoc-Auswertung war betroffen, die D0-Zahlen stehen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Zweiter vollstaendiger Durchlauf nach docs/review-prompt.md.
BEFUND 1: rec_outcomes war seit dem Einbau (06.08.) still tot - 0
Zeilen in 5 Tagen. _run_analysis las s.get("pb_feats"), aber s ist der
MT5Data-Snapshot; pb_feats lebt im Wave-Snapshot. _atr also immer 0,0
und die Schreibbedingung nie erfuellt. Kein NameError (ruff sieht
nichts), und das umgebende except loggt auf DEBUG. Aufgefallen nur,
weil die Tabelle mit 0 Zeilen neben ihren Schwestern stand.
Generalisiert als measurement_reminder.telemetrie_puls(): jede
Telemetrie-Tabelle muss einen Puls haben. Erster Lauf meldet genau
diesen Fund, alle uebrigen gruen.
BEFUND 2: der Divergenz-Waechter war selbst driftend. Abschnitt A
verglich gegen 43 % WARTEN - seit 05.08. ausdruecklich ungueltig (das
misst _build allein); richtig sind 80,5 %. Und entry_room galt als
"live-only", obwohl es seit 04./05.08. modelliert wird.
A: +50,8 Pp Warnung -> +13,3 Pp OK. B: 63,9 % -> 5,0 %.
BEFUND 3: P(break) ist wieder kalibriert (Delta -1,7 Pp nach +14,3 Pp
am 07.08.) - stuetzt den Schluss, dass die gewanderte Basisrate ein
Zeitraum-Effekt war.
Sauber: alle Standardpruefungen, 0 fehlende Frontend-IDs, mt5_lock,
Broker-Zeit, Race-Klasse. Performance: Snapshot-Median 15,9 ms, alle
heissen Abfragen ueber Index - keine Optimierung noetig.
Kein toter Code geloescht: die vermeintlich verwaisten Snapshot-Felder
sind Diagnose-Oberflaeche (vier davon heute zur Deploy-Verifikation
benutzt).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
auto_emergency_margin_pct 0 -> 8. Gewaehlt wurde die MILDESTE Variante: Delta
-14 EUR ueber 1022 Trades ist praktisch neutral, sie feuert bei rund 16 % der
Trades. Schuetzt wenig, kostet wenig - eine Versicherung mit kleiner Praemie.
Sizing bleibt ausdruecklich bei 95 % (margin_pct nicht mitgeaendert).
Bezugsgroesse ist die MARGIN DIESER Position, nicht das Konto: bei ~670 EUR/Lot
sind 8 % rund 54 EUR/Lot, bei den aktuellen 2,33 Lots etwa 124 EUR. Der Modus
hat Vorrang vor auto_emergency_pct und auto_emergency_loss, beide bleiben 0.
AKTIVIERUNG braucht einen Neustart - und die bereits offene Position bekommt
den Stop auch danach NICHT. Verifiziert an engine.py:884: der
Wiederherstellungs-Zweig setzt fuer ein wiedererkanntes Ticket
_emergency_margin_armed_ticket = ticket und _emergency_loss auf den
persistierten Wert (hier null), damit ein Neustart keine gesetzte Entscheidung
ueberschreibt (Fix 2026-07-17). Der 8-%-Stop greift ab der naechsten neuen
Position. Neustart daher am besten fahren, wenn das Konto flat ist.
Neu im Config-Waechter (validiert = 0), damit die Abweichung sichtbar bleibt.
Backup: oil_widget_config.ini.bak-2026-08-07-emergency
Zurueck: auto_emergency_margin_pct = 0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Faellige B4-Messung nach dem Nachtrainieren vom 31.07. (878 Vorhersagen ab
01.08.). Drei Befunde.
1) Das Skript mischte zwei Modelle. Es trennte bei der M30-Umstellung (30.07.),
nicht beim Nachtrainieren (31.07.) - "GESAMT" las altes und neues Modell
zusammen. Derselbe Fehler wie am 02.08. in analyze_divergence.py. Neu:
MODELL_V2 mit demselben Stichtag wie die Faelligkeitsbedingung.
2) Kalibrierung messbar daneben. Die Basisrate ist gewandert: Training 37,8 %,
live 53,2 %, stabil ueber vier volle Tage (51,4 / 54,1 / 56,4 / 53,8 % bei
n=122-276). Ein Modell, dessen Niveau an 37,8 % verankert ist, muss in einem
53-%-Regime systematisch zu niedrig sagen - genau das passiert. Oberste Klasse
invertiert (69 % vorhergesagt, 17 % real).
3) Trennschaerfe NICHT entscheidbar - und das ist der wichtigere Befund.
Entkoppelt n=87, AUC 0,556, 95-%-Bootstrap-KI [0,434 ... 0,674]. Das Intervall
enthaelt den Zufall (0,50) UND die Messlatte (0,654).
Die Faelligkeitsbedingung zaehlte die falsche Groesse: 800 ROHE Vorhersagen,
die aber nicht unabhaengig sind (dieselbe Position pendelt um dasselbe Level).
Aus 878 rohen werden 87 entkoppelte - die Bedingung ueberschaetzte die
Beweismenge um rund das Zehnfache und meldete "faellig", obwohl die Messung
nichts entscheiden konnte. Jetzt 350 ENTKOPPELTE (halbiert die KI-Breite).
Stand 87/350.
Operativ kein Notfall: auto_sr_close ist seit 06.08. false, das Modell
schliesst keine Trades. Es speist nur Anzeige, Chart-Linien und
Copilot-Kontext.
Nichts umgestellt - ein drittes Fitten derselben Bauart wuerde denselben Weg
gehen; der Befund zeigt aufs Niveau, nicht zwingend auf die Rangfolge.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auf die Frage nach Liq-Trend: es bleibt vorerst mit Gewicht 0,5 drin, kommt aber
mit einer ausdruecklichen Begruendung auf die Liste der Verdict-Modul-Messung
(measurement_reminder.py + CLAUDE.md), statt jetzt ohne Datenbasis gehandelt zu
werden.
Offene Punkte fuer den Lauf:
(a) Liq-Trend (0,5) — +0,20/+0,32 ueber nur 132 Episoden. ⚠ Dieselbe Quelle wie
das am 06.08. entmachtete Orderbuch-Modul, und HL-Preisdaten laufen gemessen
hinter Pepperstone her (51 % Treffer nach 6 s). Als einziges verbliebenes
HL-Modul mit Stimmrecht zuerst pruefen.
(b) Muster (0,25) — +1,27/+0,67 bei n=88, zu duenn.
(c) H1 (1,5) — nur 19 Episoden, traegt aber 38 % des Nadel-Einflusses;
praediktiv nicht beurteilbar.
(d) Elliott und Orderbuch sind entmachtet, werden aber WEITER geloggt — die
Reihe darf fuer diese Messung nicht abreissen.
Stand 15.591 von 25.000 Verdicts (62 %). Auswertebefehl auf
analyze_verdict_modules.py praezisiert, mit Hinweis auf die Episoden-Bildung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Touchfill-Test hat den Pfad in allen sechs Feldern negativ gezeigt
(-0,18 bis -0,48, PF 0,38-0,71) und damit schlechter als der Markt-Einstieg:
an einem WANDERNDEN Level faengt eine ruhende Order systematisch die
Fehlausbrueche ein (441 statt 328 Fills).
ini auf false; der Schluessel lebt nicht in runtime_state.json, die ini greift
also direkt. Backup angelegt. Live verifiziert: signal_pending=False,
squeeze_pending=True (dort steht die Box still, Test bestanden).
Neu im Config-Waechter (14 ueberwachte Werte, validiert = false).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
auto_sr_close = false in der ini UND in runtime_state.json — beide Stellen
noetig, weil die Runtime-Datei die ini beim Start ueberschreibt (genau die
Falle, durch die auto_signal am 31.07. unbemerkt weiterlief).
⚠ Das ist eine Abweichung von der Messung, kein Nachvollzug einer: mit dem
am 31.07. nachtrainierten P(break)-Modell schlaegt der gegatete S/R-Close die
Trailing-Baseline in BEIDEN Haelften (Schwelle 0,35: H1 +357 R, H2 +1418 R
gegen die Baseline). Nicht zu verwechseln mit dem PAUSCHALEN S/R-Close, der
2x verworfen wurde — das P(break)-Gate ist der Unterschied.
Abgeschaltet ist nur die Ausfuehrung. Der App-Hinweis, die P(break)-Chart-
Linien, der Copilot-Kontext und das Prognose-Tracking laufen weiter
(_sr_close_hint wird in snapshot() unabhaengig vom Schalter berechnet).
Schutz weiterhin: Broker-SL 2xATR, Trailing, Time-Stop.
Neu im Config-Waechter (validiert = true), damit die Abweichung sichtbar
bleibt; er meldet sie jetzt korrekt. Backups der ini und runtime_state
angelegt. Live verifiziert: snapshot.auto_sr_close=False, Log
"S/R-Close=aus", eine Instanz auf Port 8000.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
[trading] auto_flip_close = false. Grundlage: backtest_flipclose2.py - jede
Variante in BEIDEN Halbjahren negativ, beim Live-Wert 0,5 xATR -92 R (H1) /
-160 R (H2). Mechanismus verstanden: Trefferquote steigt 39 -> 45 %, Ertrag
faellt = Gewinner-Kappen, weil die nachlaufende EMA oft mitten im Pullback
dreht.
Die Live-Bilanz sprach dagegen (+284,22 EUR aus 4 Ausloesungen, kontrafaktisch
sogar +101 EUR besser als der kanonische Exit) - aber n=4, und +101 EUR steckten
in EINEM Trade am 04.08., dem Ausreissertag, der allein die 30-Tage-Bilanz
traegt. 4 gegen ~4.000 Trades.
Der ALARM bleibt unveraendert: _check_close_alert haengt an _run_analysis, nicht
am _pos_loop-Aufruf von _check_flip_close. Nur die automatische Ausfuehrung
entfaellt - damit ist der dokumentierte Ursprungszustand wieder da ("Flip bleibt
Alarm + menschliche Entscheidung", User-Uebersteuerungen 68 % WR).
Kein runtime_state.json-Override vorhanden (anders als bei auto_signal, wo ein
UI-Toggle die ini still ueberschrieb), die ini-Aenderung greift direkt. Live
verifiziert nach Neustart: flip_close=False. Neu im Config-Waechter mit
validated=false, damit ein Zurueckschalten auffaellt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
korrigiert - und ein eigener Messfehler gefunden
(3) backtest_dist_gated.py: der 43-%-Massstab war UNGUELTIG. backtest_dist.py
misst _build ALLEIN, ohne Breakout-Bestaetigung und ohne Entry-Raum-Gate - genau
die beiden sind live die groessten Blocker. Ueber 80k Bars: nur _build 77,9 %
gerichtet, voller Live-Stack 19,5 %, live 7,2 %. Der reale Abstand ist 12,3 Pp,
nicht 50. Damit ist der "93 statt 43 %"-Alarm entschaerft, der den TF-Churn-Fix
ausgeloest hat; die dortige Erfolgskontrolle ist hinfaellig. Ein Rest bleibt
(min_conf live 16,3 % gegen 0,9 % in der Sim) und ist als naechster Ansatzpunkt
notiert.
⚠ Dabei EIGENEN Fehler gefunden: set_entry_room(0.6) fehlte in DREI heute neu
gebauten Skripten - _entry_room_atr ist im Konstruktor 0.0, _room_gate ist dann
ein No-op. Aufgefallen, weil entry_room in der Verteilung mit 0 % auftauchte
statt mit 35 %. Alle drei korrigiert und die SIG-Messung WIEDERHOLT: Population
aendert sich stark (n 967->295 / 1327->524), die Schlussfolgerung nicht - Market
in 7 von 8 Feldern negativ, am Level bestehen alle vier Schwellen
(OeR +0,392/+0,356, PF 2,37/2,39), Slippage-Test haelt bis 0,20 xATR. Die
heutige Bau-Entscheidung ist gedeckt.
(2) auto_flip_close ist jetzt sichtbar (#flip-note, v=139) - mit Schwelle,
Zaehler UND der Messung im Text ("gemessen in beiden Halbjahren negativ"). Ein
blanker Zaehler haette wie ein Erfolg ausgesehen. Der Exit bleibt an.
(1) analyze_squeeze_entry_gap.py erfasst jetzt BEIDE Bot-Pfade (Squeeze +
Signal), Reminder entsprechend erweitert - sonst wartet er auf eine Population,
die vielleicht nie kommt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
analyze_squeeze_entry_gap.py fuehrt die zwei noetigen Quellen zusammen - das
Ausbruchs-Level steht NUR im Log, der tatsaechliche Fill NUR in trades - und
splittet am Umbau-Stichtag. Die Erfolgsmeldung ist paradox: eine per Pending
gefuellte Order erzeugt KEINE AUTO-SQUEEZE-ENTRY-Logzeile (die entsteht nur im
Market-Fallback), Squeeze-Trades ohne Log-Treffer sind also der Erfolg. Das
Skript weist sie deshalb getrennt aus.
Als Messung squeeze_entry_gap im measurement_reminder.py hinterlegt (>=12
Squeeze-Trades ab dem Umbau). Stichtag exakt 05.08. 08:55 statt Mitternacht -
der 08:33-Trade lief noch ueber die Market-Order und haette die Zaehlung
verfaelscht (0/12 statt faelschlich 1/12).
Zahlen-Korrektur: die zuerst dokumentierten +0,306 / +0,741 xATR stammten aus
einer Scratchpad-Auswertung mit FESTEM Stundenversatz. DST-korrekt ueber
zoneinfo sind es +0,275 / +0,686 (n=34 unveraendert). In CLAUDE.md, engine.py,
trader.py und der ini nachgezogen; die Schlussfolgerung aendert sich nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemessen (backtest_cost_gate.py, Teil 2): es gibt KEINE toten Stunden - alle
24 Stunden sind in beiden Halbjahren positiv, keine ist beidhaelftig negativ.
Std 0 ist sogar die staerkste des Tages (OeR +1,48/+1,51) und lag im alten
Gate. Jedes Fenster kostet also Ertrag; die Sperre kauft ausschliesslich
Beaufsichtigungs-Ruhe.
Gewaehlt wurde deshalb nach PREIS, nicht nach Edge: 3-6 ist das guenstigste
Fenster mit noch >=4 h Schutz (SigmaR -12,5/-62,9 gegen -42,4/-242,6 bei 0-7
= ~27 %). Freigegeben: 0, 1, 2, 7 Uhr. Die 4-h-Untergrenze ist gesetzt, nicht
gemessen.
Umsetzung: neues [trading] auto_squeeze_night_hours (Default 3,4,5,6, leer =
aus), genutzt von _check_auto_squeeze und _check_auto_signal. _SQUEEZE_NIGHT
bleibt als STATISTISCHE Nacht-Definition fuer Entry-Checkliste und B4-Monitor
- dort gilt die Kostenfalle weiter und der Altdaten-Vergleich bleibt stabil.
7 Parse-Faelle getestet (Default, fehlender Schluessel, leer, Muell,
Rueckwaerts-Kompatibilitaet). Live verifiziert am NEUEN Snapshot-Feld
squeeze_night_hours = 3,4,5,6 und am Startup-Log; genau eine Instanz auf 8000.
Offen und als Reminder hinterlegt: der Backtest modelliert keine Slippage,
und die freigegebenen Stunden liegen in der duennsten Liquiditaet. Nach 15
Squeeze-Trades aus 0/1/2/7 Uhr gegen die Erwartung pruefen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Faellige Messung aus dem Reminder (28/30 erreicht). S/R-Auto-Closes vor/nach der
Umstellung der Level-Quelle M5 -> M30 am 30.07.
Zeitraum n Med.Lots EUR/Lot O Move
vorher (M5-Level) 89 0,81 +17,53 0,202 $
nachher (M30-Level) 28 0,53 +36,92 0,427 $
Ertrag je Lot mehr als verdoppelt, O-Kursbewegung je Trade ebenfalls - deckt sich
mit der Backtest-Erwartung und mit dem Mechanismus (M30-Level liegen 1,95xATR
auseinander statt 0,61xATR, der Trade laeuft laenger).
DIE NORMIERUNG WAR ENTSCHEIDEND, sonst waere der Schluss falsch gewesen:
unnormiert sah der 04.08. wie der Treiber aus (O +55,41 EUR je Trade gegen
+19,30 im Rest). Je Lot ist heute aber praktisch identisch zum Rest (+38,81 vs
+35,87) - der Unterschied war reine Positionsgroesse (Median 1,36 statt 0,46
Lots, weil das Konto an dem Tag von ~800 auf ~1.400 EUR wuchs). O-EUR-Vergleiche
ueber Zeitraeume mit unterschiedlicher Positionsgroesse sind ungueltig.
NICHT der Level-Quelle allein zuzuordnen: am 31.07. kamen P(break)-Nachtraining
und Schwelle 0,55->0,35 dazu. Getrennt: 30.07. (nur M30-Level, altes Modell)
n=8, +19,88 EUR/Lot; ab 31.07. (M30 + neues Modell) n=20, +43,73 EUR/Lot. Das
Fenster mit nur der Umstellung ist zu klein. Der kombinierte Effekt ist
bestaetigt, die Ursachenaufteilung nicht.
Messung im measurement_reminder ausgetragen (mit Ergebnis als Kommentar).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neue Messung manual_ctx im measurement_reminder: faellig bei >=300 manuellen
Trades mit gefuelltem ctx_*-Kontext (Sammlung laeuft seit 04.08.).
Die Faelligkeitsbedingung ist pruefbar (Zeilenzahl), nicht nur ein Datum - wie
alle anderen Eintraege auch. Der cmd-Text haelt die Methode fest (Fit auf der
ersten Haelfte, validiert auf der zweiten, AUC + Kalibrierung wie bei
backtest_pbreak_retrain.py) UND die Einschraenkung: 300 reichen fuer eine ERSTE
SICHTUNG, nicht fuer ein Urteil - mit ~150 je Haelfte und mehreren Merkmalen ist
die Overfit-Gefahr hoch. Ziel bleibt ein Hinweis im Order-Dialog, ausdruecklich
kein Auto-Entry.
Ohne diesen Eintrag waere die Sammlung genau so liegen geblieben wie die
P(break)-Genauigkeit, die 2213 auswertbare Zeilen hatte bevor jemand hinsah.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backtest_reversal_angle.py hat den Trigger in JEDER Variante beidhaelftig
negativ gemessen (IST -0,122/-0,031 - vorzeichenkorrigiert -0,173/-0,061 -
ohne Winkelbedingung -0,099/-0,023). Ausschlag gab aber nicht nur die Zahl:
das Setup hebelt ZWEI gemessen POSITIVE Schutzmechanismen aus - die
Anti-Ueberdehnung und den M30-Gegen-Trend-Filter (Edge x2). Ein Setup ohne
eigenen Edge, das validierte Filter umgeht, ist der unguenstigste Fall.
Umsetzung: neuer Schalter [trading] reversal_enabled (Config-Default im Engine
false). WICHTIG: der Modul-Default in wave_rec bleibt True - saemtliche
Backtests rufen dasselbe _build, ein False-Default haette alle bestehenden
Messungen still veraendert. Abgeschaltet wird ausschliesslich im Live-Pfad.
Verhaltensaenderung nur im Band |stretch| 3,0-3,5: dort kam vorher ein
antizyklisches REV-Signal, jetzt das normale Trendsignal; ab 3,5 greift wie
gehabt die Anti-Ueberdehnung.
Verifiziert:
- 3 Szenarien: ueberkauft+steigend SHORT/WAVE_REV_SHORT -> LONG/WAVE_LONG,
ueberverkauft+fallend LONG/WAVE_REV_LONG -> SHORT/WAVE_SHORT, normaler
Trend unveraendert
- Live nach Neustart: bei 3,18xATR Ueberdehnung jetzt WARTEN/setup=WAVE/
reversal=None statt REV_SHORT; Log "Reversal-Setup AUS"
- measurement_reminder CONFIG_DEPS ergaenzt, 11 Werte alle korrekt
Die Winkelbedingung wurde bewusst NICHT vorzeichenkorrigiert - die korrigierte
Variante misst sich schlechter. Die irrefuehrenden Kommentare sind jetzt als
solche markiert. Bounce-Anzeige bleibt unveraendert (nur Warn-Kontext).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auto-Signal AUS (auto_signal=false via Toggle -> runtime_state.json). Gruende
sind NICHT die Live-Bilanz (n=4 sagt nichts):
- gemessen in H1 durchgehend negativ (backtest_auto_signal.py, alle 8 Varianten)
- beide Auto-Pfade konkurrieren um den EINEN Positions-Slot -> solange beide
laufen, ist die B5-Pruefung des Auto-Squeeze nicht sauber messbar
B4-Befund Auto-Squeeze (Anlass: negative Auto-Trades vom 31.07.):
Mechanik (isolierter Einstieg): WR 46 %, OR +0,102, PF 1,15
Live (n=31, 17.-31.07.) : WR 45 %, OR -0,242, PF 0,49
Die Trefferquote stimmt ueberein - der Einstieg ist intakt. Die Luecke von
0,34 R/Trade entsteht im EXIT (O-Gewinn +11,02 vs O-Verlust -19,83). Alle drei
Ursachen wurden am 31.07. behoben (P(break) nachtrainiert, 15-Min-Regel aus,
Trail einheitlich 1,0), der Live-Zeitraum liegt also VOR den Reparaturen.
Deshalb kein Rueckbau, sondern vorab fixierte Latte:
>=20 Squeeze-Trades ab 01.08., dann Verhaeltnis < 1,0 ODER PF < 1 -> aus.
measurement_reminder.py:
- neue Messung squeeze_b5 (loest autosig_b4 ab)
- CONFIG_DEPS um auto_signal (soll false) und auto_squeeze (soll true) ergaenzt
- ⚠ _cfg_now() liest jetzt AUCH runtime_state.json und bildet dessen Vorrang ab.
Vorher verglich der Waechter nur die ini -> er meldete "alles auf dem
gemessenen Stand", waehrend auto_signal per persistiertem UI-Toggle lief.
Mit Szenario verifiziert (runtime true gegen validiert false -> gemeldet).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Frage "vielleicht die auto close auf 30 min setzen?" -> Zeit-Achse
mitgemessen (backtest_adverse15_squeeze.py um Zeitpunkt und zweite
Population erweitert): 15/30/45/60 min x 0,5/0,8xATR, Squeeze- UND
Wave-Signal-Entries, kanonischer Exit, Echtkosten, 2 Halbjahre.
Zeit Schwelle Squeeze H1/H2 Wave H1/H2
15 0,5 -18 / -34 -25 / -41 (war live)
30 0,5 -20 / -35 -22 / -13
45 0,8 -12 / -18 -3 / -7
60 0,8 -8 / -10 -3 / -3
ALLE 16 Kombinationen sind in BEIDEN Haelften negativ. Die Regel wird nur
monoton weniger schaedlich, je spaeter und lockerer sie prueft - die
"beste" Variante ist praktisch die, die nie feuert. 30 min haette den
Schaden halbiert, nicht beendet.
Damit ist auch meine Einschaetzung von vor einer Stunde korrigiert ("auf
dem Auto-Signal-Pfad ~neutral"): sie stuetzte sich auf
backtest_auto_signal.py mit eigenem Exit-Modell (+0,001 vs +0,026); mit dem
kanonischen Exit sind es -25/-41. Sechster Fall desselben Musters an einem
Tag.
Schutz-Stack bleibt vollstaendig: Broker-SL 2xATR + Trailing + Time-Stop
120 min. Die Squeeze-Ausnahme bleibt im Code, falls die Regel je wieder
eingeschaltet wird.
Config-Waechter-Anker auf 0 gezogen, mit Begruendung im Eintrag.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
measurement_reminder.py: neuer Punkt "Modul-Audit: zweiter Durchgang",
faellig 28 Tage nach dem ersten (also ab 2026-08-28).
Begruendung im Eintrag: am 31.07. wurden an EINEM Tag 5 Deployment-Drift-
Faelle UND 5 Modul-Inkonsistenzen gefunden - bei gezielter Suche in wenigen
Stunden. Die Trefferquote spricht dafuer, dass weitere existieren.
analyze_divergence.py meldet die Klasse "Betrieb != Messung" inzwischen
selbst; die Klasse "Modul-Inkonsistenz" (Gewichte, stale Quellen, tote
Config, Sonderfaelle) braucht dagegen einen bewussten Durchgang.
Kein neuer Windows-Task noetig - OilMeasurementReminder laeuft bereits
taeglich 18:00 und prueft alle Eintraege. Task testweise ausgeloest:
LastTaskResult 0, Arbeitsverzeichnis korrekt gesetzt. (Ein
Erinnerungssystem, das still scheitert, waere schlimmer als keins - genau
dafuer gibt es das Ding.)
CLAUDE.md-Tabelle auf den Stand 31.07. gebracht; erledigte Punkte
ausgetragen (P(break)-Genauigkeit -> analyze_pbreak_live.py, Modell
daraufhin nachtrainiert; Chartmuster-Kontrolltest -> 30.07.).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Behebt die am selben Tag gefundene Merkmals-Diskrepanz: das alte Modell war
auf "Anlauf zu einem beim Entry FIXIERTEN Level" trainiert, live waehlt
_draw_levels das Level jede Sekunde neu -> mom3 live 0,15 statt 1,45 ->
Ausgabe immer ~23 % -> Gate seit Inbetriebnahme faktisch nie aktiv.
backtest_pbreak_retrain.py: Stichprobe spiegelt den Live-Pfad (Level
dynamisch mit Hysterese, gesampelt an JEDEM Bar im 0,15xATR-Band, keine
Anlauf-Bedingung). Kontrolle: Merkmalsmittel der Stichprobe (mom6 0,203 /
mom3 0,202) treffen die live rekonstruierten Werte (0,181 / 0,149).
AUC auf dieser Stichprobe (H2, out-of-sample):
ALT-Modell 0,368 (schlechter als Zufall, 19,2 % vs real 39,4 %)
NEU-Modell 0,654 kalibriert
backtest_pbreak_rvalue.py (R-Ertrag, Echtkosten, Baseline = nur Trailing):
NEU schlaegt ALT in BEIDEN Haelften bei JEDER Schwelle. Gegen die Baseline
gewinnt es bei 0,35/0,45/0,55 in beiden (bei 0,60 kippt H1).
Bestwert 0,35: H1 -149 vs -506 (+357), H2 +1308 vs -110 (+1418).
Nebenbefund: das ALTE Modell war in H1 schlechter als gar kein Auto-Close.
EINGEBAUT: neue _PB_MU/_SD/_W (final auf allen 80k gefittet, n=76.542,
Basisrate 37,8 %, nach H1->H2-Validierung; alte Werte als Kommentar) +
sr_close_pbreak 0,55 -> 0,35, Config-Waechter-Anker mitgezogen.
Verifiziert: Chart-Linien zeigen 43 %/36 % statt 8-15 %.
ACHTUNG - invertiert eine alte Projekt-Regel: mom3-Gewicht dreht das
Vorzeichen (+1,4330 -> -0,5420). Alt: "kriecht ans Level -> 26 % Bruch, mit
Schwung -> laufen lassen". Neu: Anlauf-Schub -> 26,5 % (Level absorbiert
ihn und haelt), Schwung weg vom Level -> 51 %. Beides gilt in seiner
Population (fixiertes vs. dynamisches Level); fuer den Live-Pfad gilt die
neue Lesart.
Offen: auch NEU schliesst bei 0,35 noch ~94-97 % der Positionen (waehlt vor
allem den besseren Moment). Touch-Zahl bringt im neuen Modell nichts mehr
(0,652 vs 0,654) - die dynamische Level-Wahl erfasst den Effekt bereits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
analyze_pbreak_live.py, 2275 ausgewertete Vorhersagen seit 23.07.
AUC 0,539 (Backtest-Erwartung 0,71) · entkoppelt 0,443 · M30-Teil 0,399
Trefferquote 58,5 % vs 59,0 % fuer "immer Abprall" -> Ueberschuss -0,5 Pp
Kalibrierung: Bucket 0-19 % sagt 8 % voraus, real 39,1 % (Faktor 5);
Bucket 65-100 % sagt 74,5 %, real 48,0 % (invertiert)
KERNBEFUND: die Bruchrate der GESCHLOSSENEN Gruppe ist bei JEDER Schwelle
38-40 %, identisch zur Basisrate. Es findet live keine Auswahl statt. Bei
der ini-Schwelle 0,55 werden 91,2 % aller Beruehrungen geschlossen -> der
"P(break)-gegatete Close" ist faktisch der pauschale S/R-Close, und DER ist
2x gemessen und verworfen (backtest_srclose.py). Erklaert die
kontrafaktische Messung vom Vortag (-8 EUR/Trade, 43 % zu frueh).
Pipeline gegen das Training geprueft, KEIN Bug: dist in beiden
entry-basiert, mom6/mom3 in beiden am Touch-Bar, confirm/reject dieselbe
+-0,5xATR-Definition, Timeout zaehlt in beiden als Abprall. Plausibelste
Ursache: andere Stichproben-Population (2275 roh -> 307 entkoppelt, live
dominieren Chop-am-Level-Faelle). Entlastet das Modell aber nicht -
entkoppelt ist die AUC sogar schlechter.
TOUCH-ZAHL (User-Idee): auf Live-Daten in BEIDEN Haelften bestaetigt, aber
mit Umkehr - 1. Beruehrung 38,3/41,7 %, 4. 45,1/47,4 % (monoton, +6/+4 Pp),
aber 5.+ faellt auf 37,8/41,8 % zurueck (unter Basis, groesste Gruppe).
Umgekehrtes U: 2-4 Beruehrungen machen das Level muerbe, ab 5 in 30 min ist
es eine Range und haelt. Das Modell sieht davon nichts (~23 % konstant) ->
echte orthogonale Information. Belastbarkeit begrenzt (Haelften nur 4 Tage
auseinander, n=82-139). Naechster Schritt: als 5. Merkmal in
backtest_srclose_prob.py aufnehmen, ueber 34.771 Touches / 2 Halbjahre
neu fitten.
Empfehlung: auto_sr_close=false. Eine reine Schwellensenkung repariert es
nicht (aendert die Anzahl, nicht die Auswahl).
Reminder: Punkt erledigt, Wiedervorlage als pbreak_accuracy_v2 (800
Vorhersagen ab 01.08., nach einem Nachtraining).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
C - core/cone.py + Kachel #card-cone + MT5 v1.31 (CN;<min>;<lo>;<hi>):
"Erwartete Spanne" statt "Kursvorhersage". Der User wollte eingezeichnete
Verlaufspfade; bewusst NICHT gebaut - sie suggerieren eine Praezision, die
es nicht gibt (Lehre aus analyze_verdict_calibration.py). Der Kegel sagt
wie WEIT der Kurs in 30/60/120 min plausibel laeuft, nicht wohin.
analyze_cone.py: r(h)=(C[i+h]-C[i])/ATR[i], Fit auf H1, Abdeckung gemessen
auf H2 (echtes out-of-sample):
80%-Band -> 76,7 / 76,6 / 75,3 %
90%-Band -> 87,5 / 87,2 / 86,5 %
Konsistent ~3-5 Pp ZU ENG. Das wird NICHT weggefittet - Kachel und Tooltip
nennen die REAL gemessene Abdeckung, nicht den Nennwert. Damit nach dem
P(break)-Modell die zweite kalibriert geprueft Komponente im Projekt.
Zentriert auf den aktuellen Kurs, KEINE Drift addiert (Median +-0,0..0,16
xATR = klein gegen die Bandbreite; eine Drift-Korrektur waere eine
Richtungsaussage und die ist nicht belegt). Farbe neutral grau, kein
gruen/rot. Kein Signal, kein Verdict-Gewicht.
MQL5 v1.31: zwei sich oeffnende gepunktete Pfade, verkettet 30->60->120.
Startpunkt aus der PX-Zeile - die setzt g_conePx jetzt auch, wenn
InpShowPrice aus ist (sonst verliert der Faecher seinen Anker).
Config-Waechter in measurement_reminder.py (Antwort auf "sollten wir alle
verworfenen Backtests woechentlich neu rechnen?"): NEIN - eine Woche sind
~2000 Bars, und 18 Ideen x 52 Wochen = 936 Tests/Jahr erzeugen bei 5 %
Fehlalarmquote ~47 falsche "funktioniert jetzt!" pro Jahr. Stattdessen
EREIGNIS-gesteuert: CONFIG_DEPS verankert 8 config-abhaengige Messungen an
den Wert, gegen den sie validiert wurden (entry_room_atr 0,6 /
sr_close_pbreak 0,55 / breakout_k 0,3 / risk_pct 0 / margin_buffer_pct 95 /
adverse_15min_atr 0,5 / auto_signal_min_conf 75 / dead_hours leer). Weicht
einer ab, meldet der Timer welche Messung veraltet ist. Numerischer
Vergleich, damit 0.60 == 0.6. Mit 5 synthetischen Szenarien getestet.
Erledigt ausgetragen: Chartmuster-Kontrolltest (30.07., Muster schlagen die
Kontrolle in beiden Haelften +0,022/+0,108).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1) measurement_reminder.py + Task OilMeasurementReminder (taeglich 18:00):
meldet per Popup, welche Messung genug Daten hat. Jeder Punkt mit PRUEFBARER
Bedingung (Datenmenge/Datum), Meldung je Punkt 1x (Marker in .reminders/).
Status: python measurement_reminder.py --status
Direkt zwei FAELLIGE Punkte gefunden:
- P(break)-Prognose-Genauigkeit: 2213 ausgewertete Vorhersagen (Schwelle 500),
lag seit 2026-07-23 unbeachtet herum
- Chartmuster-Kontrolltest (generischer Breakout): jederzeit machbar
Noch sammelnd: verdict_votes 24%, AUTOSIG-Trades 0, M30-Level-Validierung 27%,
M1-History 7%, News-Score 8%.
2) MQL5 v1.26: Beschriftungen UND Pfeile stehen jetzt ganz rechts am Chartrand,
auf einer Linie mit dem Kurs-Label (User: "genau so angeordnet wie der aktuelle
Kurs"). RightTime() rechnet das Ende des Shift-Bereichs aus
(CHART_WIDTH_IN_BARS x InpShiftPct) statt fix 2 Kerzen hinter der letzten Bar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
