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>
