Der Kegel wurde heute frueh gebaut, exportiert (CN;30/60/120 stehen korrekt
in der CSV) und kompiliert - war aber nie zu sehen. Ursache: unter
%APPDATA%\MetaQuotes\Terminal\ liegen VIER Instanz-Ordner. Meine
Kopier-Zeile bestimmte das Ziel ueber "hat MQL5\Indicators" +
Select-Object -First 1 und traf 0BA5CADA..., waehrend der Bot nach
D0E8209F... schreibt und der Chart dort laeuft.
Folge: der Chart lief seit heute frueh weiter auf v1.29 - ohne
Prognose-Kegel UND ohne die Konsolidierungs-Beschriftung (v1.30), obwohl
beide "gebaut und mit 0 Fehlern kompiliert" gemeldet waren.
Behoben: v1.31 in das Terminal kopiert und kompiliert, das die CSV
schreibt. Verifiziert: #property version 1.31, ex5 frisch, CN-Handler und
TCONSOL-Label im Terminal-Quelltext vorhanden.
CLAUDE.md: Fallstrick dokumentiert samt der richtigen Ziel-Ermittlung (ueber
die vom Bot geschriebene CSV, nicht ueber die blosse Existenz von
MQL5\Indicators) und der Gegenprobe nach jedem Kompilieren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Frage "sollten wir den S/R close auch deaktivieren?" -> nein, die
beiden sind gegensaetzlich gemessen. Aber sie konkurrieren seit dem Einbau
um dieselben Trades, und die S/R-Freigabe lief OHNE Flip-Close.
backtest_exit_combo.py (NEU, 80k M5, 2 Halbjahre, Echtkosten, Exit-Kern aus
core/exit_model.py, 5 Varianten auf IDENTISCHEN Entries):
nur S/R-Close H1 +59 · H2 -14 (535/284 S/R-Closes)
nur Flip-Close H1 -1 · H2 -43
BEIDE H1 +56 · H2 -50 (507/252)
BEIDE, Flip nachrangig H1 +62 · H2 -49 (516/260)
KOLLISION BELEGT: der Flip nahm dem S/R-Close 28 bzw. 32 Trades weg
(5-11 %) - genau die, fuer die dieser validiert ist. Mit Nachrang ist es in
BEIDEN Haelften besser als ohne.
Umsetzung: liegt ein S/R-ZIEL <=0,6xATR entfernt (dieselbe Schwelle wie der
Live-Hinweis), haelt der Flip sich zurueck.
[trading] auto_flip_close_subordinate (Default true).
Mit 4 Szenarien getestet: in Reichweite, ausser Reichweite, kein Level,
Nachrang aus.
EHRLICH DAZU: auch mit Nachrang kostet der Flip in H2 rund 35 R gegenueber
"nur S/R-Close" (-49 vs -14). Der Nachrang begrenzt den Schaden, er dreht
ihn nicht um.
METHODIK-FEHLER BEIM BAU, KORRIGIERT: der erste Lauf liess die sequentielle
Sim nach dem Exit bei xb+1 weiterlaufen - dadurch hatte JEDE Variante eine
ANDERE Trade-Folge und die Zahlen waren nicht vergleichbar. Jetzt feste,
geteilte Entry-Liste wie in backtest_pbreak_rvalue.py. (Die zunaechst
gemeldeten Deltas -195/-144 stammten aus diesem konfundierten Lauf.)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User: "schliesse den trade automatisch beim close signal". Dreht die
Empfehlung gegen die offene Position und steht sie >=0,5xATR im Plus ->
close(reason="flip_close").
VORHER NEU GEMESSEN, weil das alte Urteil (backtest_flipclose.py,
16.07.) auf einem VIERTEN Exit-Modell fusste: Trail fest 1,5 (live jetzt
1,0), keine Lock-Phase, kein Time-Stop, kein Initial-TP, _MAXH 288 statt
200, Phasen ueber den Bar-Close statt ueber das High-Water.
backtest_flipclose2.py (80k M5, 2 Halbjahre, Echtkosten, Exit aus
core/exit_model.py) bestaetigt das alte Urteil - deutlicher:
Basis ohne Flip H1 SigmaR -537 · H2 -140
Flip ab 0,0xATR Delta H1 -126 · H2 -221
Flip ab 0,3xATR Delta H1 -77 · H2 -216
Flip ab 0,5xATR Delta H1 -92 · H2 -160 <- mildeste, Default
Flip auch im Minus Delta H1 -205 · H2 -364
JEDE Variante ist in BEIDEN Haelften schlechter. Trefferquote steigt
39 -> 45 %, Ertrag faellt = Gewinner-Kappen (die nachlaufende EMA dreht
oft mitten im Pullback).
Gebaut wurde die mildeste Variante (0,5xATR Mindestgewinn), abschaltbar
ueber [trading] auto_flip_close.
Fuer die Neumessung bekam exit_model.simulate() einen stop_when-Hook
(+ ret_bar), damit die Phasen-Mechanik nicht zum fuenften Mal kopiert
werden musste. Rueckwaertskompatibilitaet verifiziert: ohne Hook bitgenau
identisch (die zunaechst gemeldeten Abweichungen kamen allein aus
LIVE.mult 1,5 -> 1,0, gegengeprueft mit mult=1.5 -> identisch).
Mit 10 synthetischen Szenarien getestet: beide Richtungen, aus, unter
Schwelle, gleichgerichtet, WARTEN, im Minus, flat, Startup-Schonfrist,
Ticket-Dedup - alle korrekt.
B4/B5-Pflicht: Live-Ertrag gegen die Erwartung halten, bei Drift
auto_flip_close=false.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Fund: "WARTEN · M15" neben "Modul-Konsens: stark LONG" liest sich wie
ein Widerspruch. Ist keiner - die Welle HAT eine Richtung und haengt nur an
einem Gate. Der Grund stand aber nur als Textzeile in der Meldungen-Karte,
also weit weg von der Stelle, an der die Frage aufkommt.
wave.breakout {pending, dir, level, need} wurde berechnet und im Snapshot
gespeichert, vom Frontend aber NIRGENDS gerendert. Jetzt haengt es direkt
an der Headline:
"◌ WARTEN · M15 · LONG, noch 0.02 bis zur Bestaetigung"
Erste Auswertung der gestern eingebauten block_reason-Telemetrie (3 h):
breakout_pending 63 %
entry_room 20 %
min_conf 18 %
Totband / HTF-Gegen-Trend: KEIN EINZIGES MAL
Das beantwortet die offene Frage aus dem TF-Churn-Fix: die 93 % WARTEN
kommen nicht daher, dass die Welle richtungslos waere, sondern von den
Gates - allen voran der Breakout-Bestaetigung, die bis zum Fix desselben
Tages rechnerisch gar nicht fertig werden konnte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Fund: "Modul-Konsens: stark LONG · 4/4 Module fuer WARTEN" - dabei sind
9 Module sichtbar. Zwei echte Fehler.
(a) FALSCHER BEZUG: der Text lautete "... Module fuer ${sig}" mit der
HEADLINE als Bezug. Seit dem ref-Fix vom 30.07. zaehlt `agree` bei WARTEN
aber die Uebereinstimmung mit der BIAS-Richtung - deshalb stand dort
"stark LONG ... fuer WARTEN". Die Richtung kommt jetzt als verdict.ref_dir
vom Backend, statt im Frontend aus `bias` nachgebaut zu werden (dort galt
ein +-0,05-Totband, im Backend `bias > 0` - die Nachbildung waere am Rand
auseinandergelaufen; dieselbe Sorte Divergenz wie die fuenf
Deployment-Drift-Faelle desselben Tages).
(b) ANDERER NENNER ALS DIE CHIPS: `total` zaehlt nur Module MIT Aussage
(Gewicht>0, ohne die Welle). Nach den Gewichts-Fixes des Tages schweigen
deutlich mehr Module -> "4/4" bei 9 sichtbaren Chips. Neu ist
verdict.silent (Module mit Gewicht 0) dabei, sodass die Summe aufgeht.
Live verifiziert: "Modul-Konsens: leicht LONG · 3 von 5 stimmberechtigten
fuer LONG (4 ohne Aussage)" - 5 + 4 = 9. Sonderfall "kein Modul mit klarer
Aussage" abgedeckt. v=125.
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>
Systematische Pruefung aller Verdict-Module gegen die Regel "keine Aussage
-> Gewicht 0", dazu Config-, Frontend- und Level-Quellen.
(1) KI-COPILOT - der groesste Rest des Musters. Ein explizites "NEUTRAL"
zaehlte als echte Stimme mit Gewicht 1,0. Gemessen (verdict_votes, n=7.084):
das ist in 93,1 % der Faelle der Zustand (Elliott: 1,3 %) - also der
Normalzustand des Copiloten, kein abgewogenes Urteil. Damit hatte
ausgerechnet das Modul mit der schwaechsten Beleglage
(analyze_verdict_calibration.py: nicht robust praediktiv) den GROESSTEN
daempfenden Einfluss auf die Bias-Nadel.
(2) ELLIOTT analog: Gewicht nur bei gerichtetem Ziel.
Kumulierte Wirkung aller Gewichts-Fixes des Tages:
Oe|bias| 0,370 -> 0,441 -> 0,569 (= 1,54x), betrifft 79,5 % der Zeilen
Live verifiziert: KI "NEUTRAL" -> Gewicht 0,00, bias 2,5/4,5 = 0,556
statt 2,5/5,5 = 0,455.
(3) STALE [zones] SPEISTEN DIE WELLEN-KONFIDENZ - entfernt. _sr_levels zog
beide Kanten jeder [zones]-Zone als S/R-Linien heran: 16 Kanten aus einem
~10 $ TIEFEREN Regime (72,90-77,00 bei Kurs 85,3). Aus dem Chart waren sie
am 14.07. schon entfernt worden, WEIL sie stale sind - in die Konfidenz
liefen sie weiter. Realer Audit-Fall: market.sr hatte gar keine
Widerstaende (M15-Cluster sind in frischen Trends oft leer) -> der
"naechste Widerstand" kam aus der fvg-Zone bei 88,00 (2,66 $ weg), der
echte lag bei 85,315 (0,03 $ weg). Der Abzug "dicht unter Widerstand"
(-12) greift nur innerhalb 0,5xATR und feuerte deshalb NIE.
(4) TOTE CONFIG entfernt: [trading] trail_timeframe (nirgends gelesen, Name
suggeriert faelschlich die Trailing-TF) und die komplette [setups]-Sektion
(11 Schluessel).
(5) raise StopIteration als Sprung in einem breiten except durch ein if
ersetzt - funktionierte, waere aber fragil sobald dort Logging dazukommt.
SICHERHEIT: beim Anlegen des Config-Backups fiel auf, dass .gitignore nur
"oil_widget_config.ini" abdeckt, NICHT "...ini.bak-<datum>". Das Backup lag
ungeschuetzt als untracked im Repo und enthaelt dieselben Live-Keys.
Muster ergaenzt. Gegenprobe: die .example-Datei enthaelt 10 secret-artige
Felder, davon 0 identisch mit der echten ini - alles Platzhalter.
Sauber geblieben: Frontend<->Backend (0 verwaiste Element-IDs), alle
uebrigen Verdict-Gewichte, alle anderen Config-Schluessel.
OFFEN (messpflichtig): die Wellen-Konfidenz aus _draw_levels speisen statt
aus dem Misch-Set - wuerde den -12-Abzug tatsaechlich ausloesen, also die
Konfidenz senken und das 55%-Gate verschieben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlass war die User-Frage "H1 aus der Gesamtempfehlung entfernen, da wir
jetzt mit M30 arbeiten?". Antwort NEIN, aber die Frage hat einen echten
Defekt freigelegt.
Zur Praemisse: auf M30 umgestellt wurde die S/R-LEVEL-QUELLE, nicht die
Zeitebenen-Logik. H1 war nie Basis-TF (tf_max=M30), sondern immer Kontext.
Zur vermuteten Doppelzaehlung - gemessen an verdict_votes (n=7.074):
bei gerichteter Welle stimmt M30 nur zu 14,9 % mit ihr ueberein, H1 zu
47 %, M30 und H1 untereinander nur zu 33,8 %. Keine redundanten Stimmen
(Reversals heben den M30-Filter bewusst auf, und M30 ist meist gar nicht
gerichtet). H1 fliesst zwar auch als Konfluenz-Bonus in die Konfidenz -
aber in eine ANDERE Kennzahl (Ring vs. Nadel), nicht zweimal in dieselbe.
DER ECHTE DEFEKT: add("M30", ...) und add("H1", ...) hatten Gewicht 1,5
UNBEDINGT, auch bei Stimme 0. Damit derselbe Fehler wie beim Wellen-Modul
(Bias-Fix Teil 2 vom 30.07.), hier uebersehen. Eine 0-Stimme heisst
"EMA-Abstand im Totband" = keine Aussage, nicht "neutral" - mit vollem
Gewicht im Nenner zog sie die Bias-Nadel dauerhaft zur Mitte.
Gemessen an 7.074 Verdicts: M30 ist in 57,9 % der Faelle ohne Aussage
(H1 nur 1,8 %). Oe-Bias-Betrag 0,371 -> 0,441, Median-Verstaerkung 1,30x,
in 33,3 % der Zeilen deutlich staerkere Nadel.
Fix: 1.5 if vote != 0 else 0.0 fuer beide. `others` filtert bereits auf
weight>0, die "x/y einig"-Zaehlung zieht damit automatisch mit.
Live verifiziert: M30 "flach" -> Gewicht 0,00, bias -1,5/4,5 = -0,333
statt -1,5/6,0 = -0,250 (genau die gemessene 1,33x-Verstaerkung),
agree 3/5 statt 3/6.
REINE ANZEIGE - die Order-Logik haengt an der Wellen-Headline, nicht am
Bias.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backtest_legacy_recheck.py um zwei Abschnitte erweitert (Reversal-Flag und
Efficiency Ratio je Trade), damit alle vier Befunde abgedeckt sind, die auf
dem vereinfachten Legacy-Exit ruhten.
BOUNCE / REVERSAL - relative Aussage haelt, absolute NICHT:
H1 Reversal -0,034 (PF 0,93) vs Trend -0,174 (PF 0,68)
H2 Reversal +0,029 (PF 1,06) vs Trend -0,073 (PF 0,86)
Reversal schlaegt Trend in BEIDEN Haelften (+0,140/+0,102) - robust. Aber
die dokumentierte Kennzahl "OeR +0,185 / PF 1,35 / 70 % Treffer"
REPRODUZIERT NICHT: mit echtem Exit + Echtkosten liegt das Setup bei
~Breakeven. Die alten Werte stammen aus dem vereinfachten Exit ohne Kosten.
Das Setup bleibt sinnvoll als nachrangiges Zweitsignal (so ist es live auch
eingebaut), ist aber kein +0,185-Ertragsbringer.
ER-CHOP-GATE - Ablehnung BESTAETIGT: alle vier ER-Baender liegen gleichauf
(H1 -0,137..-0,172, H2 -0,049..-0,067). Die Efficiency Ratio trennt auch mit
dem echten Exit nicht. Gate bleibt zu Recht verworfen.
Damit sind alle sechs Legacy-Skripte abgedeckt: EIA bestaetigt, Dead-Hours
nicht selektiv, Bounce nur relativ, ER-Gate zu Recht verworfen.
Einschraenkung unveraendert: der Recheck handelt die UNGEGATETE EMA-Richtung
(ohne min_conf, Breakout-Bestaetigung, HTF-Filter, Raum-Gate) - fuer die
Vergleiche neutral, die absoluten Werte sind nicht das Live-Signal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
VORSCHLAG 1 - Trail-Multiplikator 1,5 -> 1,0 (core/exit_model.py LIVE.mult),
live verifiziert ("AKTIVIERT ... mult=1.0x").
Voller Sweep mit FIXEM SL 2,0 (backtest_trailmult.py, 8 Werte 0,5-3,0):
enger ist MONOTON besser. Wave-Signal H1/H2 SigmaR:
0,5 +1258/+2418 · 0,8 +852/+1668 · 1,0 +80/+1360
1,5 -220/+1305 · 2,0 -394/+1198 · 2,5 -1072/+1327
Optimum am RAND = Warnsignal, deshalb Gegentest auf SQUEEZE-Entries mit
Echtkosten (--squeeze): das Setup lebt von Laeufern, muesste also
dagegenhalten - tut es NICHT (1,0: H1 -0,202/H2 +0,010 · 1,5:
-0,219/-0,032). Deshalb 1,0 (besser als 1,5 in beiden Haelften auf BEIDEN
Signalmengen), aber NICHT 0,5: Randwert, und die Sim modelliert keine
Exit-Slippage - ein engerer Trail loest viel haeufiger aus und ist davon
staerker betroffen (real bis 0,75xATR ueber den Stop).
VORSCHLAG 2 - backtest_legacy_recheck.py (NEU): die beiden Legacy-Befunde
nachgerechnet, die live ECHTE Gates steuern.
EIA-Blackout BESTAETIGT: auch mit echtem Exit + Echtkosten in BEIDEN
Haelften schlechter als der Rest (-0,097 / -0,119). Gate ist gedeckt.
DEAD-HOURS reproduzieren NICHT als selektiver Befund: 19 von 22 Stunden
sind in beiden Haelften negativ, keine robust positive Stunde. Die alte
Auswahl (0-7, 12, 16) ist damit nicht mehr gestuetzt. Praktisch folgenlos
(dead_hours ist leer), aber eine Reaktivierung auf der alten Begruendung
waere nicht gedeckt.
Einschraenkung selbst benannt: der Recheck handelt die UNGEGATETE
EMA-Richtung (ohne min_conf, Breakout-Bestaetigung, HTF-Filter, Raum-Gate).
Fuer den Vergleich neutral, die absoluten Werte sind nicht das Live-Signal.
Konsequenz fuer den TF-Churn-Fix: "WARTEN Richtung 43 %" ist eine
Haeufigkeits-, keine Ertragsgroesse - mehr Signale sind nur dann besser,
wenn die freigegebenen Setups auch tragen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
core/exit_model.py (NEU): LIVE:ExitParams als EINZIGE Quelle der Exit-
Parameter; core/trailing.py leitet _TRAIL_START_ATR, _BREAKEVEN_ATR,
_PHASE4_* und _MULT_BY_TF jetzt davon ab statt eigene Zahlen zu halten.
Aendert jemand LIVE.mult, aendern sich Live-Verhalten UND Messung gemeinsam
-> Deployment-Drift-Fall 3 ist konstruktiv unmoeglich geworden. Dazu die
kanonische simulate() fuer Backtests mit Flags timestop/use_tp, um
Teilmodelle EXPLIZIT zu machen statt zu verstecken.
BEFUNDE BEIM REFACTOR - schlimmer als angenommen:
(1) Es gibt mindestens DREI materiell verschiedene Exit-Modelle:
A) Phasen ~ live (_trailing/_exit/_atrfloor/_candle_fade)
B) EINFACH - _TPTRAIL=0.5, kein Breakeven, kein Lock, kein Time-Stop,
_MAXH=240 (_hourly, _hourly_split, _bounce, _events, _deadhour,
_chopgate)
C) Phasen mit be_on=1.0 statt 1,3 (_breakout, _confluence_angle)
=> Dead-Hours, EIA-Blackout, Bounce, Chop-Gate, Stunden-Analyse und
breakout_k ruhen auf einem Exit, der dem Live-System nicht entspricht.
Bewusst NICHT stillschweigend umgestellt (wuerde historische Schluesse
rueckwirkend aendern); als LEGACY_SIMPLE / LEGACY_BE10 markiert.
(2) Selbst die "Phasen"-Skripte weichen voneinander ab: _trailing hat TP
aber keinen Time-Stop, _candle_fade Time-Stop aber kein TP, _atrfloor
liefert Punkte statt R.
(3) backtest_trailing.py koppelt den Initial-SL an mult (sl = entry -
d*mult*atr) statt fix 2,0.
KORREKTUR DER STUFE-1-BEGRUENDUNG: die "67 % groesserer Einzelverlust" war
ein Artefakt von (3) - dort war der Worst-Case per Konstruktion gleich dem
Multiplikator. Sauber nachgemessen mit fixem SL (backtest_trailmult.py, NEU,
80k Bars, 2 Halbjahre):
Trail 1,0 H1 -73 · H2 +1346 · Worst -2,00
Trail 1,5 H1 -325 · H2 +1294 · Worst -2,00 (live)
Trail 2,0 H1 -446 · H2 +1195 · Worst -2,00
Trail 2,5 H1 -1174 · H2 +1223 · Worst -2,00
Trail 3,0 H1 -1088 · H2 +1397 · Worst -2,00
Der Worst-Case ist bei JEDEM Multiplikator identisch -2,00. Die Entscheidung
bleibt richtig (1,5 schlaegt 2,0 und 2,5 in beiden Haelften), nur die
Tail-Begruendung war falsch.
NEU UND OFFEN: Trail 1,0 schlaegt 1,5 in BEIDEN Haelften - eigener
Vorschlag, bewusst nicht ungefragt umgesetzt.
Aequivalenz verifiziert (500 synthetische Kursreihen je Fall): _candle_fade
und _atrfloor sind bitgenau identisch zur neuen simulate().
Live verifiziert: "AKTIVIERT ATR=0.5796 (M30) mult=1.5x".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Behebt die strukturelle Schwachstelle, die heute dreimal zugeschlagen hat:
Komponenten werden unter anderen Bedingungen BETRIEBEN als VALIDIERT.
Track B schuetzt gegen Overfitting, nicht gegen Deployment-Drift.
STUFE 1 (core/trailing.py): _MULT_BY_TF durchgehend 1,5 (vorher M15 2,0 /
M30 2,5 / H1 3,0) und _MULT_BREAKOUT_ADD 0,5 -> 0,0. Die Staffelung war nie
gemessen; backtest_trailing.py validiert nur 1,5 und die breiteren Werte
sind dort messbar schlechter (80k Bars, 2 Halbjahre):
mult 1,5 H1 SigmaR -249 · H2 +1252 · Worst -1,50
mult 2,0 H1 SigmaR -412 · H2 +1187 · Worst -2,00
mult 2,5 H1 SigmaR -1367 · H2 +1450 · Worst -2,50
Auf M30 fuhr der Bot also 5,5x schlechteres H1 und einen 67 % groesseren
Einzelverlust; bei Breakouts waren es 3,0 - nie getestet. Relevant, weil die
TF-Heuristik oft auf M15/M30 landet (31.07.: 19 von 33 Phasen).
STUFE 2a (wave_rec/history/engine): jede Empfehlung loggt einen
maschinenlesbaren block_reason - deadband, dead_hour, eia, htf_counter,
stretch, min_conf, breakout_pending, entry_room, no_data, stale. DB migriert
(Backup angelegt). Ohne den war nicht feststellbar, WELCHES der Gates die
93 % WARTEN erzeugt (Backtest-Erwartung ~43 %).
STUFE 2b (analyze_divergence.py, NEU): haelt vier Dinge gegen die
Backtest-Erwartung - A Signal-Verteilung, B Gate-Anteile inkl.
"im Backtest modelliert?", C TF-Wechsel-Rate, D0 Modell-Kalibrierung,
D Merkmals-Drift gegen _PB_MU/_SD.
LEHRE AUS DEM BAU SELBST: die Merkmals-Drift (D) haette den realen Fehler
NICHT gefangen - mom3 lag nur 0,50 Sigma unter mu, bei Gewicht 1,43 wurden
daraus aber -0,71 im Logit (23 % statt 41 % vorhergesagt). Deshalb ist D0
der schaerfere Test und die D-Schwelle auf 0,5 Sigma gesetzt.
Erster Lauf nach dem Fix bestaetigt das Nachtraining live:
D0 = 27,0 % vorhergesagt vs 28,0 % real (vorher 23 vs 41).
Stufe 3 (geteilter Exit-Kern) bleibt offen, spaeter und einzeln.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auslöser: User-Frage warum der Bot die Rally am 31.07. (82,5 -> 84,4 in 2 h)
nicht gehandelt hat. Befund: in dem Fenster 99x WARTEN und 1x SHORT - und
dieser SHORT wurde am Tief autonom eroeffnet (AUTOSIG, -26,31 EUR, per
adverse15 geschlossen). Den LONG machte der User um 11:56 von Hand.
Der WARTEN-Anteil ist strukturell zu hoch:
Backtest-Erwartung (backtest_dist.py) ~43 %
Live letzte 24 h 93,2 %
Live letzte 7 Tage 88,0 %
Live gesamt (93.599 Zeilen) 78,6 %
MECHANISMUS (im Log belegt): _choose_tf setzt den Score einer TF hart auf
0,0, sobald sie ueberdehnt ist - genau das passiert M5 IM Trend. Real am
31.07.: M5 sprang zwischen 0,00 und 1,93, die TF wechselte 33x am Tag
(Median-Abstand 5 min). Die 1,2x-Hysterese ist dagegen wirkungslos. Und
set_timeframe() verwarf bei JEDEM Wechsel die laufende Breakout-
Bestaetigung und verankerte sie beim aktuellen Kurs neu. Bei k=0,3 und
ATR_M30~0,53 braucht sie ~0,16 $, der Kurs lief ~0,08 $ je 5 min -> die
Bestaetigung konnte rechnerisch nie fertig werden.
Gleicher Fehlertyp wie beim P(break)-Modell am selben Tag:
backtest_breakout.py hat k=0,3 auf einer FESTEN Zeitebene validiert; live
wandert sie - die Bedingung, unter der die Messung gilt, existiert im
Betrieb nicht.
FIX 1 (wave_rec.set_timeframe): _pend wird nicht mehr zurueckgesetzt. Der
Anker gehoert zum Signal, nicht zur Zeitebene; bei Richtungswechsel
verankert _confirm_breakout ohnehin neu.
FIX 2 (engine._tf_loop): Mindest-Verweildauer [trading] tf_min_dwell_s=900.
Verifiziert mit synthetischen Szenarien: Fix 1 - Bestaetigung ueberlebt
M5->M30 und feuert LONG, Richtungswechsel verankert korrekt neu; Fix 2 -
an der ECHTEN Score-Folge vom 31.07. nachgespielt: 4 Wechsel -> 2.
NICHT backtestbar (Backtests laufen auf fester TF, das Churning existiert
dort nicht). Begruendung ist "stellt die Bedingung her, unter der die
Messung gilt", nicht "gemessen besser". Erfolgskontrolle = WARTEN-Anteil
muss sich Richtung ~43 % bewegen.
Bewusst nicht behoben: der 0,0-Einbruch des Scores bei Ueberdehnung selbst
- das waere eine Aenderung der TF-Bewertung und damit messpflichtig.
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>
backtest_pbreak_touches.py (M30-Level wie live, Touch-Zahl als 5. Merkmal)
plus Rekonstruktion der Live-Merkmale aus candles_m1.
Beweiskette:
1) Der Backtest reproduziert die 0,71 (Fit H1 -> AUC oos H2 0,715).
Modell und Pipeline sind in Ordnung.
2) Populations-Hypothese widerlegt: live ist ausgerechnet die 1. Beruehrung
(die trainierte Situation) mit AUC 0,445 die SCHLECHTESTE Gruppe, die
Chop-Faelle (5.+) mit 0,577 die beste. Der Versatz "Modell 23-25 %, real
40-42 %" ist in JEDER Teilmenge gleich gross.
3) Merkmale rekonstruiert (n=2275): mom3 live 0,149 vs Training 1,4523
(-1,303), mom6 0,181 vs 1,6565 (-1,476). Daraus z-Versatz -1,05 ->
aus 39,4 % Basisrate werden ~19 %, beobachtet 23 %. Erklaert praktisch
die gesamte Fehlkalibrierung.
MECHANISMUS: Training fixiert das Level beim Entry (>=0,3xATR entfernt) und
wartet auf den ersten Touch -> mom3 ~1,45xATR = ein Schub. Live waehlt
_draw_levels das naechstgelegene Level jede Sekunde NEU -> der Kurs steht
oft neben einem Level, das gerade erst zum naechsten wurde, ohne Anlauf ->
mom3 ~0,15. Gleicher Code, andere Situation. Folge: das Modell liegt live
immer unter der Schwelle 0,55 -> das Gate war seit Inbetriebnahme faktisch
nie aktiv (91 % aller Beruehrungen geschlossen = der pauschale S/R-Close,
der 2x verworfen wurde).
Zwei Reparaturwege (beide ungemessen): (a) Ziel-Level beim Oeffnen fixieren
statt laufend neu waehlen, oder (b) Modell auf live-spiegelnder Stichprobe
neu trainieren.
TOUCH-ZAHL (User-Idee): im Backtest AUC 0,715 -> 0,725, Gewicht +0,176 fuer
die 2.-4. Beruehrung (Vorzeichen bestaetigt), aber R-Ertrag nicht robust
(H1 +131, H2 -43). Im Trainings-Datensatz 76 % Erst-Beruehrungen und KEINE
5+-Faelle - das live beobachtete umgekehrte U ist dort nicht abbildbar.
Kleine Verbesserung, nicht der Hebel.
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>
User-Frage "koennen wir die Trendumkehr-Wahrscheinlichkeit berechnen?".
Aufgebaut exakt wie das erfolgreiche P(break)-Modell: mechanisch scharfes
Barriere-Rennen (zuerst -X x ATR GEGEN oder +X x ATR MIT dem Trend?),
logistische Regression auf 8 kausalen Merkmalen, Fit auf H1, AUC +
Kalibrierung gemessen auf H2. 80k M5-Bars, ~18,3k/18,5k Stichproben.
Muenzwurf in JEDER von 5 Ereignis-Definitionen (AUC oos 0,499-0,509,
Basisrate ~50 %). Definitionen bewusst variiert (0,5/1,0/1,5/2,0 x ATR,
Fenster 60-360 min) - ein Null-Ergebnis ist nur belastbar, wenn es nicht
an EINER willkuerlichen Schwelle haengt.
Diagnostisch wichtigste Zahl: die IN-SAMPLE-AUC von nur 0,52-0,53. Das
Modell erklaert nicht einmal seine eigenen Trainingsdaten - das ist NICHT
Overfitting (da waere in-sample 0,70+ und oos braeche ein), sondern das
Fehlen jeder Information. Einzelmerkmale allein: alle 0,489-0,515.
Kern-Lehre: P(break) fragt nicht "wohin geht der Kurs", sondern "haelt
diese konkrete Struktur?" - bedingt auf ein reales Objekt. "Trendumkehr"
ist die UNBEDINGTE Richtungsfrage ohne Struktur zum Festmachen. Genau die
Klasse, an der das Projekt 18x gescheitert ist. Die kalibrierte
umkehr-nahe Groesse existiert bereits: stop_approach (P(break) auf dem
Gegen-/Stop-Level, AUC 0,68/0,72).
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>
D - backtest_candle_fade.py: der Lead aus backtest_candles.py (Fade der
volumenstarken Klimax-Kerze) faellt im echten Trade-Sim durch. Live-Exit
(SL 2,0/Trail 1,5/BE 1,3/Time-Stop 120') + Echtkosten, mit KONTROLLGRUPPE
"Fade ohne Volumen-Filter" (die Lehre aus backtest_patterns.py).
Kontrolle -0,080 / -0,046
Vol >= 2,0 -0,059 / +0,103
Vol >= 2,5 +0,144 / -0,080
Vol >= 3,0 +0,113 / -0,064
Benachbarte Schwellen exakt gegenlaeufig = Rauschmuster. Die einzige
beidseitig positive Zelle (Vol>=2,0 + Marubozu, +0,036/+0,043) hat n=91/118
bei 7 Varianten = Mehrfachvergleich-Artefakt. 18. verworfener Eingriff.
Wichtigste Lehre: Informations-Ueberschuss != handelbarer Edge. Dieselbe
2,0-Schwelle liefert im Forward-Fenster +0,12/+0,20 beim Fade, im echten
Trade -0,059/+0,103 - die Gegenbewegung ist diffus, der 2xATR-Stop wird
unterwegs getroffen (WR nur 35-40 %). Der Weg zum Ziel zaehlt.
A - core/candles.py + Kachel #card-candles (M5, ~20 s, unter mt5_lock):
Marubozu, Langer Koerper, Langer Docht oben/unten, Spinning Top, Doji,
Engulfing. Schwellen identisch zum Backtest.
Bewusste UI-Entscheidung: die Kachel ist NEUTRAL gefaerbt (keine gruen/rot-
Ampel) und nennt die GEMESSENE Lesart ("Klimax-Kerze - der Kurs laeuft
danach eher GEGEN die Kerze"), nicht die Lehrbuch-Lesart. Eine
Richtungsampel wuerde hier systematisch falsch stupsen - gleiche Korrektur
wie bei der Bounce-Anzeige. Kein Verdict-Gewicht, kein Trigger.
Beim Bau gefunden: mt5_lock ist ein CONTEXT-MANAGER, kein Lock-Objekt -
.acquire()/.release() wirft. Jetzt "with mt5_lock(3.0) as got".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Vorgabe "Kerzengroesse und Dochtlaenge als Kontext fuer die
Empfehlung". Getestet werden die KONDITIONALEN Behauptungen (nicht
"Kerzenmuster funktionieren", sondern "sie funktionieren im Kontext"):
Docht am Level vs Range-Mitte, Volumen >= 2x, mit/gegen Trend.
Informations-Messung (Forward-Return 60 min in xATR), 80k M5-Bars,
2 Haelften. Wichtig: gerichtete Klassen werden gegen die DRIFT-NULL
(bm x E[d]) gelesen, nicht gegen die Baseline - sonst liest man reine
Regime-Drift als Edge.
Robust in BEIDEN Haelften, aber INVERTIERT gegenueber der Quelle:
* Langer Koerper -> Fortsetzung: -0,059 / -0,076 (laeuft GEGEN die
Koerperrichtung). Mit Trend sogar -0,132 / -0,042 -> "im Trend =
Fortsetzung" ist genau falsch, es ist die Klimax-Kerze.
* "2x Volumen = echt": -0,117 / -0,204 vs -0,065 / -0,035 bei normalem
Volumen. Monoton in die falsche Richtung - mehr Volumen = staerkere
Gegenbewegung.
* "Docht am Level zuverlaessig": in beiden Haelften SCHLECHTER als in
der Range-Mitte.
* mit/gegen Trend beim Docht kippt zwischen den Haelften = Rauschen.
Einziger Lead: Fade eines volumenstarken langen Koerpers, +0,117/+0,204
brutto - noch unter den realen Kosten (0,265xATR), aber erstmals nur um
Faktor ~1,5 statt einer Groessenordnung. Folgetest mit Live-Exit statt
starrem 60-min-Fenster waere der naechste Schritt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backtest_trailing_sr.py --squeeze: gleiche Sim, aber nur SQUEEZE-Ausbrueche
(Regel exakt wie live via core.wave_rec _SQ_N/_SQ_MULT/_SQ_K, Einstieg am
Ausbruchslevel, Echtkosten aus dem Bar-Spread).
Basis H1 +0,102 / H2 +0,108 - KEINE Variante besteht. Anders als im
Wave-Lauf ist das kein Rauschen: der reine S/R-Trail wird monoton
schlechter, je breiter der Puffer (0,10 -> 0,25 -> 0,50, in BEIDEN
Haelften). Mechanismus: der Squeeze lebt von wenigen Laeufern (43 %
Treffer, Ertrag im Tail) - ein ans naechste Level gebundener Stop holt
genau dort raus, wo der Lauf beginnt. Bei Wave-Signalen faellt das kaum
auf, daher das umgekehrte Vorzeichen zwischen beiden Laeufen.
Staerkster Gewinner-Kappen-Beleg des Projekts: die Kontrollvariante
(fester TP am Gegenlevel) dreht den Squeeze von +0,102/+0,108 auf
-0,066/-0,004 = Edge vollstaendig zerstoert.
Abgrenzung: der laufende S/R-Auto-Close ist P(break)-GEGATED und war auf
Squeeze-Trades separat ein Wash (backtest_squeeze_srclose.py). Das Gate
ist der Unterschied zwischen "Wash" und "Edge zerstoert".
Damit ist die User-Idee in allen drei Teilen durchgemessen; der
Live-Exit-Stack bleibt unveraendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Idee "Trailing TP und SL auf die S/R-Linien anpassen". Zerfaellt in
drei Teile; Initial-SL an S/R und fester TP am Gegenlevel waren schon
verworfen, der TRAILING-Teil war offen (bisher nur ATR-Abstaende getestet).
Aufbau wie backtest_trailing.py (echte Phasen-Mechanik, Breakeven 1,3),
Level = M30-Pivots k=3 KAUSAL (Pivot erst 3 M30-Bars spaeter bekannt),
Deckel [0,5..2,0]xATR gegen den -11,4xATR-Fall aus backtest_sl_method.py.
80k Bars, ~19,7k Signale je Haelfte.
Ergebnis: schadet nicht, traegt aber zu wenig. 3 von 5 Varianten schlagen
die Basis in BEIDEN Haelften (Hybrid "engerer Stop" +0,006/+0,006, WR
37->43 %). Trotzdem nicht gebaut: (a) Effekt 0,006-0,014 R/Trade = eine
Groessenordnung unter der B3-Huerde; (b) nicht parameter-robust - Puffer
0,10 besteht, 0,25 faellt durch, 0,50 besteht wieder.
Positiv: Worst-Case bleibt in ALLEN Varianten -2,00xATR, der Deckel
funktioniert - S/R-Verankerung fuegt kein Tail-Risiko hinzu.
Die Kontrollvariante "TP am Gegenlevel" reproduziert den alten Befund
exakt (WR 40->54 %, SigmaR H2 +1261->+740 = Gewinner-Kappen) -> Simulation
gegen backtest_srclose.py validiert, TP-Teil endgueltig erledigt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Frage "ist der Auto-Close beim S/R eher behindernd als dienlich?".
Die rohe Statistik (99 % WR, +13,71 EUR/Trade) ist ein Konstruktions-
Artefakt - der Close feuert nur im Plus. Das Skript misst stattdessen die
Kontrafaktische: fuer jeden sr_close die naechsten 60 min aus candles_m1
(gleiches Fenster wie das Modelltraining, _BRK_W=12 M5-Bars), wie weit der
Kurs noch IN Richtung lief (entgangen) bzw. GEGEN sie (vermieden), in EUR
ueber die echte Lot-Groesse. EUR-je-Punkt wird aus den Trades selbst
kalibriert statt geraten. Broker-Offset (candles_m1.time = rohe UTC+3)
wird korrigiert.
Befund (70 auswertbare Closes): entgangen 33,68 EUR/Trade vs vermieden
25,68 -> netto -8,00 EUR/Trade. 43 % klar zu frueh geschlossen, nur 26 %
klar richtig. Deckt sich mit der Live-P(break)-Genauigkeit (58,8 % bei
einer Basisrate von 59,3 % = kaum Trennschaerfe ueber "immer Abpraller").
⚠ Einordnung: 89 der 98 Closes liefen noch auf M5-Levels; die M30-
Umstellung ist 1 Tag alt (9 Closes). Die Messung beurteilt also vor allem
die ALTE Konfiguration.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
core/econ_calendar.py (NEU): High-Impact-News-Fenster als Handels-Sperre.
Quelle Forex Factory JSON (kostenlos, kein Key, mit impact-Feld), beide
Wochen (thisweek endet Sa, Markt oeffnet So 23:00 -> sonst blinder Fleck),
1x/h im Daemon-Thread, dedupliziert. Filter: High+USD ODER Oil/OPEC-Titel.
WICHTIG - nicht gemessen: Events sind zu selten fuer eine 2-Stichproben-
Aussage. Das ist die Handbuch-Regel, kein belegter Edge. Deshalb bewusst
asymmetrisch: sperrt NUR die autonomen Entries (Auto-Squeeze + Auto-Signal,
ohne Dedup-Marker -> feuert nach dem Fenster nach), in der Entry-Checkliste
nur "warn" statt "fail". Manuelle Orders bleiben frei. Der gemessene
EIA-Blackout (Mi 15:30-16:30) bleibt unabhaengig aktiv und greift auch
ohne Netz.
Verifiziert: Live-Fetch (EIA korrekt Mi 16:30 Berlin, FOMC/GDP/PCE erkannt)
+ 4 synthetische Szenarien (5 min vor/nach Event, 50 min davor, disabled).
MQL5 v1.30: graue Konsolidierungs-Box beschriftet (User-Frage "was bedeutet
die graue Box") - sichtbares Label an der Oberkante, rechtsbuendig wie die
uebrigen: "Konsolidierung (10-Bar-Spanne)" bzw. bei Kompression
"Konsolidierung - komprimiert, Ausbruch steht bevor". 0 Fehler kompiliert.
Frontend v=122: #cal-note in der Meldungen-Karte (laufendes Fenster bzw.
Vorwarnung <=60 min).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Vorgaben: "beruecksichtige die chartmuster mit in der gesamtempfehlung sobald
eins erkannt wird" + "auch der liquiditaetstrend und das orderbuch".
MUSTER (Gewicht 1,0 bestaetigt / 0,5 bildet sich) -- vorher den faelligen
KONTROLLTEST nachgeholt (stand seit heute im measurement_reminder):
Muster H1 +0.206 (Ziel 23%) H2 +0.328 (Ziel 26%)
Kontrolle H1 +0.184 (Ziel 19%) H2 +0.220 (Ziel 18%) <- beliebiger Swing-Bruch
Delta H1 +0.022 H2 +0.108
Die Muster schlagen die Kontrolle in BEIDEN Haelften, aber der Loewenanteil des
Ertrags kommt vom Breakout+Trailing. Deshalb Gewicht 1,0 (wie Elliott/KI), nicht
2,0 (Squeeze). Ziel-Trefferquote bleibt niedrig -> die Stimme sagt Richtungs-
tendenz, kein Kursziel.
ORDERBUCH-Imbalance + LIQ-TREND (Gewicht je 0,5 = kleinstes im Verdict):
⚠ BEIDE UNGEMESSEN. Die Uebertragbarkeit HL->CFD wird gerade erst erhoben
(analyze_bookflow.py, ~3% der Daten). Der Lead-Lag-Test zeigt sogar, dass
PEPPERSTONE fuehrt (r=0.525 bei k=-1) und HL folgt -- HL ist Oracle-basierter
HIP-3-Perp, strukturell Follower. Daher das kleinste Gewicht.
Imbalance-Schwelle _OB_IMB_MIN=0.30, darunter keine Stimme.
MITLOGGING: verdict_votes um pattern/pattern_w/orderbook/orderbook_w/liqtrend/
liqtrend_w erweitert (DB migriert, Backup angelegt). Nur so ist in ein paar Wochen
datenbasiert entscheidbar, ob die Stimmen bleiben, mehr Gewicht bekommen oder
rausfliegen (wie TU 2026-07-06).
Frontend: Chips rendern dynamisch (keine Aenderung noetig); NEU wird das GEWICHT
im Chip angezeigt und stumme Module (w=0) ausgegraut -- so ist sichtbar, dass
Orderbuch/Liq-Trend schwaecher zaehlen als Welle (3,0) oder Squeeze (2,0).
Verifiziert live: alle 9 Stimmen korrekt, Bias-Rechnung geprueft (1.5/5.5=0.273),
Logging schreibt die neuen Spalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User reichte ein 19-seitiges WTI-Trading-Handbuch ein ("lerne daraus Kontext fuer
die Empfehlung"). Systematischer Abgleich statt naivem Einbau:
BEREITS UMGESETZT (Handbuch bestaetigt den Ist-Zustand): HTF-Trend-Filter,
EIA-Blackout, ATR-Stop mit Puffer, Trailing nach TP1, Verlust-Serien-Check,
Journal/Kennzahlen, NY-Session-Fokus.
BEREITS GEMESSEN + VERWORFEN: Liquidity Sweeps, Order-Block-Klasse (Pivot-Zonen,
6x), Double Top/Bottom, H&S/Triangle/Flag/Cup, Wyckoff, False Breakout, DXY.
NEU GEMESSEN (die echten Luecken) -- alle durchgefallen:
PDH/PDL bounce H1 -0.335 / H2 -0.199 (beidseitig negativ)
PDH/PDL sweep H1 -0.462 / H2 -0.184 (schlechtestes Ergebnis im Projekt)
Asian Range bnc H1 -0.134 / H2 -0.005
Asian Range swp H1 -0.178 / H2 -0.040
Discount/Premium: nicht robust (H1 besser, H2 schlechter), -70% Volumen
Freitag-ab-16h : verschlechtert BEIDE Haelften
Bemerkenswert: PDH/PDL ist der am klarsten schaedliche Level-Typ, den das Projekt
je gemessen hat -- obwohl das Handbuch ihn als besonders stark bewirbt. Und der
Freitagnachmittags-Filter kostet Geld, die dort geblockten Trades waren
ueberdurchschnittlich (gleiche Lehre wie beim Dead-Hours-Gate).
Kein Konzept aus dem Handbuch neu ins Signal aufgenommen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User: "schauen wir uns das mal an" (nach dem verworfenen Konsolidierungs-Backtest).
Der Bot exportiert die Spanne der letzten 10 M5-Bars -- exakt die Box, aus der der
validierte Squeeze-Ausbruch kommt (wave._squeeze_one liefert jetzt box_hi/box_lo in
allen Rueckgaben). Der Indikator zeichnet sie als transparentes blaues Rechteck;
ist sie KOMPRIMIERT (<=2.5xATR, also armed/active), wird sie mit doppelter Deckkraft
gezeichnet -> "Ausbruch steht bevor" ist auf einen Blick sichtbar.
Schalter: InpShowConsol / InpConsolColor / InpConsolAlpha / InpConsolBars.
⚠ REINE ANZEIGE. Alle Konsolidierungs-SETUPS sind gemessen verworfen
(backtest_consolidation.py: False Breakout, Distribution, Accumulation, Retest --
inkl. Kontrolltest, der die Distribution-Hypothese kippte). Die Box zeigt WO
gestaut wird, nicht WOHIN es geht. Validiert ist ausschliesslich der Ausbruch.
Verifiziert: CO;84.105;84.815;0 (0.710$ = 2.68xATR = knapp ueber der Schwelle,
daher korrekt als "nicht komprimiert" markiert).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Vorgabe "lerne fuer die Gesamtempfehlung die Konsolidierungen" (3 Chart-
Beispiele: False Breakout, Distribution, Accumulation + Retest). Alle auf derselben
Box wie der validierte Squeeze, 80k M5-Bars, 2 Halbjahre, Live-Exit + Echtkosten.
A) False Breakout / Liquidity Sweep: faellt in JEDER Variante durch (Rueckkehr
1/2/3 Bars x Live-/Setup-Exit x Session). H1 durchgehend negativ, H2 leicht
positiv = Regime-Kippen. Der Setup-eigene Exit (Stop am Docht, Ziel Gegenseite)
ist in ALLEN 6 Kombinationen negativ.
Nebenbefund: 54% aller Box-Ausbrueche kehren binnen 3 Bars zurueck -- der
Squeeze-Ausbruch scheitert mehrheitlich (passt zur 43%-Trefferquote). Die
Gegenrichtung zu handeln rettet das nicht.
B/C) Distribution/Accumulation: Basisrate widerlegt die Richtungs-Hypothese direkt
(48% bzw. 52% treffen die Erwartung, Zufall = 50%). "Distribution" sah mit
+0.168/+0.270 tragfaehig aus -- der KONTROLLTEST (gleicher Vor-Trend, Bruch in
die Gegenrichtung) liefert in H2 mit +0.364 sogar MEHR. Beide sind schlicht
Box-Ausbrueche mit Trailing; welcher fuehrt, wechselt mit dem Regime.
Retest-Einstieg: in beiden Haelften schlechter als der direkte Bruch.
Fazit: nichts davon in die Gesamtempfehlung. 17. verworfener Signal-Eingriff.
Methodisch: der Kontrolltest ist genau der, der bei backtest_patterns.py noch
fehlt -- hier hat er die Idee gekippt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Wunsch. Der Bot exportiert PL;wert;waehrung, der Indikator zeigt es als
OBJ_LABEL direkt unter dem Kurs oben rechts (CORNER_RIGHT_UPPER, Y = Kurs-Y +
Schrifthoehe + Abstand), gruen im Plus / rot im Minus.
Wert ist NETTO wie im Dashboard: bei Gewinn abzueglich der WHT-Quellensteuer
([trading] wht_pct = 26.375), bei Verlust unveraendert (dort faellt keine an).
Ohne offene Position schickt der Bot keine PL-Zeile -> Redraw() raeumt das Label
per ObjectsDeleteAll(PFX) automatisch weg.
Verifiziert: PL;-20.59;EUR in sr_levels.csv, deckt sich mit dem Dashboard-Netto.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User: "entferne 'Durchbruch' bei S/R die Prozentzahl reicht mir".
vorher: Widerstand 84.536 · Durchbruch 18%
jetzt: Widerstand 84.536 · 18%
Der ausgeschriebene Hinweis bleibt im Tooltip der Linie erhalten.
Co-Authored-By: Claude Opus 4.8 <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>
Review der Gesamtempfehlungslogik auf Wunsch des Users ("ueberpruefe die
gesamtempfehlungslogik komplett mit den neuen indikatoren von heute").
Befund 1 (gravierend): Die Regel "Modul ohne Aussage -> Gewicht 0" (2026-07-15
fuer Squeeze/Elliott/KI eingefuehrt) galt NICHT fuer die Welle selbst. Sie stand
mit w=3.0 permanent im Nenner, auch bei WARTEN. Gemessen sind ~91% der letzten
2000 Empfehlungen WARTEN -> die Bias-Nadel war fast immer kuenstlich zur Mitte
gezogen. Realer Fall: bias +0.312 statt +0.625 (Faktor 2).
Fix: weight=0 bei WARTEN.
Befund 2: `agree` nutzte immer die Wellen-Richtung als Referenz -> bei WARTEN
zwangsläufig "0/N", obwohl sich die anderen Module einig waren (real "0/4" bei
2 einigen Modulen). Fix: Referenz = Wellen-Richtung, ersatzweise Bias-Richtung
(real jetzt "2/3").
Beides REINE ANZEIGE, Order-Logik unberuehrt. Mit 6 synthetischen Szenarien
verifiziert + live geprueft.
Nicht geaendert, nur dokumentiert:
- Doppelzaehlung M30/H1 (stecken bereits im Wave-Signal als Filter/Konfluenz)
- Drei divergierende Level-Quellen seit der M30-Umstellung (Supports wichen um
0.65$ ab) -- bewusst, jedes Gate ist auf seine Quelle kalibriert
- toter tu-Parameter
Neue Indikatoren von heute korrekt NICHT im Verdict: Liquiditaets-Waende
(Uebertragbarkeit ungemessen), Liquiditaetszonen + Volume Profile (verworfen),
Chartmuster (nicht reif).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Wunsch. Der Bot haengt P(break) als drittes CSV-Feld an (R;preis;pct /
S;preis;pct), der Indikator schreibt es ins Label:
"Widerstand 84.536 · Durchbruch 34%"
Quelle = dasselbe kalibrierte Logit-Modell wie der S/R-Auto-Close, heute auf die
M30-Level nachtrainiert (AUC 0.72 out-of-sample, Kalibrierung geprueft).
Richtung: Widerstand = Bruch nach oben (+1), Support = nach unten (-1); Merkmale
identisch zu _sr_close_hint/_stop_approach_hint (M5-Momentum, EMA-Richtung,
Abstand/ATR). Abschaltbar via InpShowPBreak.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User: "die liquiditaetspfeile sind immer noch gold".
Ursache: MT5 speichert Input-Werte JE CHART-INSTANZ und ueberschreibt damit neue
Defaults -- auch nach einem Recompile. Die Pfeile blieben deshalb auf dem alten
Gold-Wert (v1.15-v1.22), obwohl der Code laengst neongruen/rot vorgab.
Loesung: die betroffenen Inputs umbenennen. MT5 findet dann keinen gespeicherten
Wert und uebernimmt den Default:
InpWallBidColor -> InpArrowUpColor (neongruen #00FF7F)
InpWallAskColor -> InpArrowDownColor (rot #FF4500)
InpLiqTrendColor -> InpTrendLineColor (neongruen)
InpLiqZoneColor -> InpZoneColor / InpLiqZoneAlpha -> InpZoneAlpha
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Vorgaben: Pfeile rot/gruen behalten, Beschriftungen komplett rechtsbuendig,
alle Beschriftungen weiss, Liquiditaets-Trendlinie neongruen wie der Up-Pfeil.
(a) Pfeile zurueck: Bid NEONGRUEN #00FF7F, Ask ROT #FF4500 (statt Gold).
(b) Liquiditaets-Trendlinie neongruen statt pink.
(c) FIX "nicht komplett rechtsbuendig": auf den Linien war OBJPROP_TEXT gesetzt --
diesen Text zeichnet MT5 IMMER LINKS am Chartrand (Option
"Objektbeschreibungen"). Jetzt OBJPROP_TOOLTIP + CHART_SHOW_OBJECT_DESCR=false.
Betrifft S/R-Linien und Kanal.
(d) Alle Beschriftungen weiss (InpLabelColor) -- die Linien behalten ihre Farbe,
nur der Text ist einheitlich. Kurs oben rechts ebenfalls weiss.
(e) MT5-Positions-Labels ("sell 0.36 ...") stehen systembedingt LINKS und lassen
sich NICHT verschieben -- nur ab-/anschaltbar via InpShowTradeLevels.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User: "entferne die umrandungen fuer trade open und close" + "das bild sieht
komiesch aus" (Screenshot).
(a) Trade-Umrandungen AUS: InpShowTrades=false UND Export im Bot abgeschaltet
([trading] export_trade_marks=false) -- spart auch die DB-Abfrage im
5-s-Export-Takt. Code bleibt reaktivierbar.
(b) Liquiditaets-Trendlinie: RAY_RIGHT entfernt. Eine 60-min-Regression 100 Bars
in die Zukunft zu verlaengern riss die Linie steil ins Bodenlose (im
Screenshot deutlich zu sehen). Sie endet jetzt am aktuellen Rand.
(c) CHART_SHIFT_SIZE auf 12% begrenzt (InpShiftPct). Ohne Begrenzung war der
Shift-Bereich so gross, dass der Kursverlauf links gequetscht stand.
Verifiziert: TR-Zeilen aus sr_levels.csv verschwunden, Rest unveraendert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Vorgaben: Beschriftung aller Linien rechtsbuendig, Schrift 4 Pixel groesser.
- Neue Hilfsfunktion RightTime() (rechter Chart-Rand im Shift-Bereich); die
S/R-Labels werden dort erzeugt UND von RepositionLabels() dort gehalten
(vorher zentriert via CenterTime).
- ANCHOR_RIGHT_LOWER: der Text ENDET am Anker und laeuft nach links -> ragt
nicht ueber den Chartrand hinaus.
- Schriftgroesse 8 -> 12 (+4), einstellbar via InpLabelSize; gilt auch fuer das
(per Default ausgeblendete) Trendlinien-Label.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Vorgabe. CHART_COLOR_BID/ASK/LAST auf InpThemeBidLine (clrWhite), Bid-Linie
explizit eingeschaltet -- hebt sich klar von den blau/roten Kerzen und den
farbigen Overlays ab.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User: "setze die transparenz der zone auf 10 %".
MT5 kann bei OBJ_RECTANGLE KEIN echtes Alpha (nur Canvas-Objekte koennten das).
Loesung: BlendBg() mischt die Fuellfarbe gegen den bekannten, einfarbigen
Chart-Hintergrund -- optisch identisch zu echter Transparenz.
Gold #F59E0B bei 10% auf #0D1117 -> #241F15 (dezent)
InpLiqZoneAlpha = Deckkraft in % (Default 10). Farbe wird bei JEDEM Redraw neu
gesetzt, damit eine Alpha-Aenderung sofort greift (nicht erst beim Neuanlegen des
Objekts). Die gestrichelte Kante bleibt in voller Goldfarbe wie im Referenzbild.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pfeil-Bugfix (User: "liquiditaetspfeile werden immer noch nicht angezeigt"):
(1) ANCHOR_LEFT ist fuer OBJ_ARROW UNGUELTIG (nur TOP/BOTTOM)
(2) Pfeile sitzen rechts neben der letzten Kerze -> ohne CHART_SHIFT kein
sichtbarer Bereich dort
Blink-Fix (User: "blinken nur manchmal auf"): hl_walls setzte den Cache bei jedem
Fehlschlag auf None -> LQ-Zeilen fehlten -> Indikator loeschte die Pfeile. Jetzt
letzter guter Stand 120s Grace.
Neu (alles reine Anzeige):
- TR;<O|C>;zeit -> Kerze der Eroeffnung HELLGRUEN, des Close DUNKELGRUEN umrandet
- EQ;<H|L>;lo;hi;zeit -> Equal Highs/Lows aus M30-Pivots als goldenes Band +
gestrichelte Kante (wie im User-Referenzbild). Als Signal gemessen verworfen.
- PX;bid -> aktueller Kurs fett oben rechts
- Beschriftung der Liquiditaets-Trendlinie per Default aus (v1.16)
Alles kompiliert und live in sr_levels.csv verifiziert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ApplyTheme() setzt beim Indikator-Start die Chart-Eigenschaften auf die
Dashboard-Palette:
Bull #3B82F6 (blau) - Bear #EF4444 (rot) - BG #0D1117
Gitter #10151C (dezent) - Text #8B949E - Kerzen gefuellt (CHART_CANDLES)
Liquiditaets-Pfeile Gold #F59E0B (= "Liquiditaetszone" der Legende)
Periodentrenner aus, Bid/Ask in Bull/Bear-Farbe.
Abschaltbar via InpApplyTheme, alle Farben einzeln als Inputs ueberschreibbar.
WARNUNG dokumentiert: aendert das Chart dauerhaft (bleibt nach Entfernen des
Indikators bestehen).
Kompiliert. CLAUDE.md aktualisiert (Indikator-Stand v1.12 -> v1.15, inkl. der
v1.14-Umstellung auf "nur Pfeile rechtsbuendig").
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1) Entry-Checkliste (User: "blende einen Hinweis ein wenn die Checkliste gegen
meine Eroeffnung ist"): engine._entry_checklist prueft 7 Punkte mit Live-Daten
-- Signal-Deckung, HTF-Trend M30+H1, Entry-Raum, News-Konflikt, Kosten,
Verlust-Serie heute (Mental-Check), Nacht-Stunde. Snapshot checklist{long,short},
Anzeige im Bestaetigungs-Dialog, blockt nicht. Kommt jetzt auch bei vorhandenem
Signal (alter Dialog nur bei WARTEN/Gegen-Signal).
Real beim Einbau: beide Richtungen "stop" (11 Verluste heute = 80% des Kontos).
2) MQL5 v1.14 (User: "blende die liquiditaetslinien aus, nur die Pfeile sollen
rechtsbuendig angezeigt werden"): LQ-Linien + Text-Labels raus, nur noch der
Pfeil auf dem Wand-Preis, rechtsbuendig am aktuellen Rand (in RepositionLabels
nachgefuehrt, bleibt beim Scrollen rechts). Details im Tooltip. Pinke
Liquiditaets-Trendlinie unveraendert. Kompiliert.
3) backtest_liquidity_sweep.py (SMC Equal Highs/Lows + Swing Liquidity, Multi-TF-
und Session-Achse): faellt durch -- Details folgen in der Doku.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User: "DIE S/R Linien liegen oft sehr nahe beieinander" -> Option 2 (beides
umstellen, Modell nachtrainieren) gewaehlt. Erst gemessen: backtest_level_tf.py,
80k M5-Bars, 2 Halbjahre, Trades bleiben M5, nur die Level-Quelle variiert.
Ergebnis (M30 gewinnt in BEIDEN Haelften):
TF AUC(H2) Abstand <1xATR dR bei P<0.55 (H1/H2)
M5 0.710 0.61xATR 71% +6698 +7749 (bisher live)
M15 0.725 1.16xATR 46% +10138 +12071
M30 0.721 1.95xATR 28% +12424 +13047 <- gewaehlt
Die Beschwerde ist damit quantifiziert: 71% der M5-Level lagen naeher als 1xATR.
Umsetzung:
- wave_rec: _m30_hl gespeichert, neues _pb_levels30 (k=3, letzte 50 M30-Bars =
trainingsgleich zum 300-M5-Lookback), im Snapshot.
- engine._draw_levels nutzt pb_levels30 (Fallback pb_levels beim Kaltstart);
speist Chart, MQL5-CSV, Dashboard UND den P(break)-Auto-Close.
- _PB_MU/_PB_SD/_PB_W auf M30 nachtrainiert: out-of-sample validiert (H1->H2),
dann auf allen 80k gefittet (34771 Touches, Kalibrierung 23/25, 38/36, 58/59,
86/87). Merkmale bleiben M5. Alte M5-Werte als Kommentar (Rueckweg).
- NICHT mitveraendert: Entry-Raum-Gate nutzt weiter M5-pb_levels
(entry_room_atr=0.6 ist darauf kalibriert).
Verifiziert live: R/S 84.617/83.722 = 2.9xATR Abstand (vorher 0.28xATR),
M30-Pivots 4/7 statt M5 27/31, keine Fehler im Log.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Wunsch: "Kennzeiche die Liquiditaetslinie mit einem Pfeil in welche richtung
die linie den Kurs treibt. Zeichne mir eine Trendlnie in pink im mt5 auf basis
der liquiditaet ein".
(a) Pfeil je Wand in Wirkrichtung (Lesart "die Wand haelt": Nachfrage stuetzt hoch,
Angebot deckelt runter); groessere Wand dicker + "<<". CSV-Format erweitert:
LQ;<B|A>;preis;size;<U|D>;<1|0>.
WICHTIG: Pfeilrichtung ist INTERPRETATION, nicht gemessen -- die Gegenthese
("Liquidity Grab", Kurs laeuft ZUR Wand) ist genauso verbreitet. Klaert
analyze_bookflow.py Frage 3.
(b) Pinke Liquiditaets-Trendlinie LT;t1;p1;t2;p2;<U|D>: Regression ueber den
VOLUMENGEWICHTETEN Wand-Schwerpunkt der letzten 60 min. Zeigt, wohin das
Gewicht der RUHENDEN Orders wandert -- nicht der gehandelte Kurs.
Zeiten im Bot in Broker-Zeit umgerechnet, Preise basis-korrigiert.
HL /api/walls liefert jetzt arrow_bid/arrow_ask/dominant/trend.
Verifiziert: LQ;B;84.182;2441;U;1 / LQ;A;84.223;2441;D;0 /
LT;1785427175;84.135;1785430664;83.978;D in sr_levels.csv. Indikator kompiliert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Vorgabe: "bei restart_server.bat sollten beide server neugestartet werden".
Dabei echten Bug gefunden: die Kill-Zeile matcht '*server.py*' und traf damit
BEIDE Prozesse -- der HL-Server wurde bei jedem MT5-Neustart still mit-erschlagen
und nie wieder gestartet. Folgen:
- Luecken in der Lead-Lag-/Order-Flow-Datensammlung (72h Spanne, nur 2292 Samples)
- Liquiditaetslinien verschwanden aus dem MT5-Chart
Jetzt: erst HL-Dashboard (8001, versteckt via start_hidden.vbs, wartet max 10s
aufs Lauschen), dann Oil-Backend (8000) im Vordergrund. Fail-safe wenn das
HL-Projekt fehlt.
Verifiziert: vorher lief nur 8000 (8001 tot), nachher beide; LQ-Zeilen nach 5s
wieder in sr_levels.csv.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Wunsch: "zeichne mir die liquiditaetslinien in den mt5 ein. entferne die
chartmuster linien aus dem mt5".
- core/hl_walls.py: holt GET /api/walls vom HL-Dashboard (groesstes L2-Level je
Seite, basis-korrigiert auf CFD-Niveau). Fail-safe: HL aus -> keine Linien, kein
Fehler; Cache 10s, Daten >60s alt werden verworfen, Log nur 1x.
- engine._write_levels_file: PT-Zeilen raus, LQ;<B|A>;preis;size rein.
- SR_Levels.mq5 v1.12: PT-Handler entfernt, LQ-Handler (dick gestrichelt +
Groessen-Label), InpShowWalls/InpWallBidColor/InpWallAskColor. Kompiliert.
- config: export_hl_walls=true, hl_walls_url.
Zwei Fallen dokumentiert: (1) Basis-Differenz HL vs CFD ~0,45$ -- ungerechnet laegen
die Linien falsch. (2) 127.0.0.1 statt localhost (IPv6 -> 2066ms statt 19-46ms, lief
in den 2s-Timeout).
Verifiziert: LQ-Zeilen erscheinen in sr_levels.csv (B 83.619/3120, A 83.665/1721),
plausibel zwischen R 83.721 und S 83.516.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Frage "System zur besseren Vorhersage - Liquiditaetsnachfragelinien?".
Getestet, weil es die einzige Klasse mit ANDERER Datenquelle war (Volumen = wo
wurde gehandelt, statt Pivots = wo war ein Docht). SMC/Order Blocks selbst sind
strukturell Pivot-Zonen = die schon 5x verworfene Klasse.
Aufbau: feste Preis-Bins 0.05$, rollierendes 24h-Fenster, tick_volume ueber
[low,high] verteilt, Value Area 70%; 80k M5-Bars, 2 Halbjahre, Live-Exit+Echtkosten.
Ergebnis - nichts traegt, die Kern-Idee am eindeutigsten:
A) Reversion am POC ("Kurs prallt an der Liquiditaetslinie ab")
H1 -0.178 / H2 -0.121 (PF 0.79/0.84) -> in BEIDEN Haelften negativ
A) Reversion am HVN H1 -0.067 / H2 +0.044 -> kippt
B) Momentum durch LVN H1 -0.031 / H2 +0.003 -> Breakeven-Rauschen
Informations-Test (Forward-Return 2h, relativ zur mid-Baseline): kein Bucket
weicht konsistent ab. Tiefere Einsicht: die Volume-Profile-Position ist ein
TREND-PROXY ("ausserhalb Value Area" = Ausbruch laeuft = folgt dem Regime),
keine unabhaengige Information -> erbt die Regime-Anfaelligkeit von Momentum.
15. verworfener Signal-Eingriff. CLAUDE.md aktualisiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User will Auto-Eroeffnung bei Empfehlung trotz negativem Backtest -> gebaut,
Default AUS, mit den GEMESSEN besten Parametern statt geratenen:
Entry (_check_auto_signal, [trading] auto_signal=false):
- min_conf=75 + Nacht-Sperre = beste Kombi (H1 -0.053 mildester Verlust,
H2 +0.141 bestes Netto). NICHT weil "mehr Konfidenz besser" -- conf_pct ist
unkalibriert, 75 ist empirisch.
- Nur FLAT, 1x je Signal-Episode (Dedup, re-armt bei WARTEN/Flip), kein Nachkauf,
kein Drehen einer Gegen-Position; erbt Circuit-Breaker + beide Cooldowns.
- Setup-Tag AUTOSIG_<dir> -> in der DB separierbar fuer B4-Monitor.
- Toggle POST /api/autosignal, Button "SIG" (bernstein = gemessen nicht tragfaehig),
neustart-fest via runtime_state.json.
15-Min-Regel (_check_adverse15, adverse_15min_atr=0.5):
- Schwelle GEMESSEN kalibriert: "sobald im Minus" ist die SCHLECHTESTE Variante
(WR 39->31%, Netto -0.067 vs +0.026 ohne); 0.5xATR ist die beste (H1 -0.111
-> -0.079). Netto bringt die Regel ~nichts = Regime-Schutz.
- Nur BOT-eroeffnete Trades (_bot_open_ticket) -- manuelle Diskretion bleibt.
- 1x je Ticket geprueft, Startup-Grace respektiert, closed_by=adverse15.
Verifiziert: 18 synthetische Szenarien (9 Entry + 9 Adverse) alle korrekt;
Live-Neustart ohne Loop-Fehler, Toggle + Persistenz geprueft. v=119.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
User-Wunsch "Trades bei Empfehlung automatisch eroeffnen" -> erst gemessen (B2).
Methodik: echte _build-Logik (kein Nachbau), M30-/H1-Trend aus M5 aggregiert und
in _build gefuettert, sequentielle 1-Positions-Sim, Live-Exit (SL2,0/Trail1,5/
BE1,3/Time-Stop 120min), Echtkosten (Bar-Spread/ATR), 80k M5-Bars, 2 Halbjahre.
Ergebnis: ALLE 8 Varianten (Konf 55/65/70/75 x Nacht-Sperre) fallen durch.
H1 durchgehend NEGATIV -0.076..-0.182 (PF 0.78-0.90)
H2 durchgehend positiv +0.112..+0.167
-> Regime-Kippen, n=718-1167 je Haelfte (keine Stichprobenfrage).
Kontroll-Beleg: der Squeeze laeuft durch DIESELBE Exit-/Kosten-Maschinerie und
ist in H1 +0.187/PF1.29 -> die Sim funktioniert, das Wave-Signal traegt in H1 nicht.
Deckt sich mit dem Live-Dry-Run (WR 29%/PF 0.64).
Nebenbefunde: hoehere Konfidenz hilft NICHT monoton (conf_pct nicht kalibriert);
Nacht-Sperre verbessert konsistent, reicht aber nicht; ein 6k-Vorlauf zeigte
faelschlich "traegt" (n=60-99 = Rauschen) -> kleine Stichprobe haette zum
Fehl-Einbau gefuehrt.
CLAUDE.md aktualisiert (14. verworfener Signal-Eingriff).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
