Schliesst die letzte Luecke der Boot-Pipeline: OilTradingServer und
HyperliquidDashboard haengen an einem Logon-Trigger, nach einem Update-Reboot
laeuft nichts bis zur Anmeldung (real 20.07.: Reboot 01:30, Server bis 07:42
tot, -95,48 EUR).
Ein Task "ohne angemeldete Sitzung" hilft NICHT: der Bot braucht das laufende
MT5-Terminal, und das ist eine GUI-Anwendung — es braucht eine echte
Desktop-Sitzung. Auto-Logon ist hier also das richtige Mittel, nicht nur das
bequeme.
BEWUSST NICHT der Registry-Weg: der legt das Passwort als DefaultPassword im
KLARTEXT unter HKLM\...\Winlogon ab, lesbar fuer jeden lokalen Admin und in
jedem Backup-Image. Stattdessen Sysinternals Autologon — verschluesseltes
LSA-Secret. Die EXE ist Microsoft-signiert (Signatur geprueft: Status Valid).
Das Skript verifiziert danach, dass DefaultPassword NICHT im Klartext steht.
Das eigentliche Restrisiko ist nicht das Passwort, sondern die offene Sitzung:
nach dem Reboot steht ein angemeldeter Desktop mit MT5 und Live-Broker-
Verbindung da. Deshalb legt das Skript zusaetzlich die Aufgabe
OilAutoLogonLock an — 30 s nach Anmeldung LockWorkStation. Die Sitzung laeuft
weiter (MT5 und beide Server arbeiten), der Bildschirm ist gesperrt.
NICHT ABGESCHLOSSEN: HKLM ist aus einer normalen Sitzung nicht schreibbar
(getestet: "Requested registry access is not allowed"). Der letzte Schritt
braucht ein Administrator-Fenster.
Das Passwort steht NICHT im Skript, nicht in der Doku und nicht im Repo — es
wird im Autologon-Dialog eingegeben. tools/autologon/ ist gitignored (Binaries,
gleiche Regel wie tools/piper/).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ersetzt das von Hand zusammengesetzte "killen, starten, warten, nachsehen" —
und macht die dokumentierte Schwachstelle der Pipeline pruefbar.
Fuenf Schritte, Rueckgabecode 0 nur wenn alle durchlaufen (verkettbar):
1. Prozess GEZIELT AM PORT beenden — nicht per *server.py*-Muster wie
restart_server.bat, das trifft auch das HL-Dashboard auf 8001 (real: es
wurde bei jedem MT5-Neustart still mit-erschlagen und riss die Luecken in
die Lead-Lag- und Order-Flow-Datensammlung).
2. starten und warten, bis /api/snapshot WIRKLICH antwortet.
3. genau EINE Instanz je Port.
4. --feld <name> pruefen.
5. Log AB DER STARTPOSITION auf ERROR/Traceback.
Schritt 4 ist der Kern: restart_server.bat hat zweimal still nicht neu
gestartet, und weil statische Dateien je Request frisch von der Platte gelesen
werden, belegt eine korrekt ausgelieferte app.js?v=N gar nichts ueber den
geladenen Python-Code. Ein neues Snapshot-Feld ist der einzige belastbare
Beweis — genau daran fiel der Fehler am 02.08. auf (hl_live.basis_stale). Ohne
--feld sagt das Skript ausdruecklich, dass der Beweis fehlt.
Beide Richtungen geprueft:
--feld rec_track -> "Python-Code ist neu", Exit 0
--feld dieses_feld_gibt_es_nicht -> "FEHLT - der alte Code laeuft weiter!",
Exit 1
Eine Pruefung, die nicht scheitern kann, waere wertlos.
Aufrufe:
python tools/deploy.py --feld <snapshot_feld>
python tools/deploy.py --nur-pruefen
python tools/deploy.py --hl
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlass war die Frage nach numpy. Statt zu vermuten wurde profiliert — und das
Ergebnis war ein anderes als erwartet: von 10,07 s Gesamtlaufzeit steckten
8,17 s in der EIGENZEIT der Backtest-Schleife, nur 0,44 s in _build.
Ursache:
[C[j] for j in PH if i - _PIV_LOOK <= j <= i - _PIV_K] # je BAR, ganze Liste
Das ist O(Bars x Pivots) — bei 80k Bars hunderte Millionen Vergleiche, und
genau daher kamen die 9-20-Minuten-Laeufe. PH/PL sind sortiert, also genuegen
zwei Binaersuchen fuer dieselbe Menge in O(log n).
Gemessen: backtest_signal_touchfill.py ueber 80k Bars von ~9 min auf 8,9 s
(~60x), bei 8k Bars 10,07 s -> 1,43 s. Das Ergebnis bleibt inhaltlich
identisch (alle sechs Felder negativ); die Handvoll Trades Unterschied ist die
bekannte Live-Bar-Drift, nicht der Umbau.
MIGRATIONS-REGEL ERNST GENOMMEN: ein Vorher/Nachher-Vergleich zweier LAEUFE
taugt hier nicht, weil copy_rates_from_pos am neuesten Bar ankert und
eintreffende Live-Bars das Fenster verschieben. Die Gleichheit wird deshalb
DIREKT auf der Datenstruktur bewiesen — tests/test_pivotfenster.py mit vier
Faellen: 4.000 Bars x 400 Pivots, Randfaelle, leere Liste, beidseitig
inklusive Grenzen.
Angewandt auf 7 Skripte (auto_signal_v3, breakout_gated, dist_gated, htf_vola,
metalabel, sl_width, trail_be) — mechanisch identische Transformation, alle
kompilieren, Stichprobe gegengelaufen (dist_gated 20k in 1,1 s).
Lehre: die naheliegende Antwort (numpy) war die falsche. Ein Profil kostet zwei
Minuten und haette diese Bremse jederzeit gezeigt — sie lag seit Monaten in
jedem gegateten Backtest.
17 Tests gruen, n-Falle-Scan sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im Projekt sind ueber Monate dutzende Szenario-Tests entstanden ("mit 10
Szenarien getestet", "mit 18 synthetischen Szenarien") — alle als
Wegwerf-Skripte, keiner lief je ein zweites Mal. Bei einem System, das man vor
jeder Aenderung neu starten und live verifizieren muss, ist das der teuerste
Teil der Schleife.
Erfasst sind die beiden juengsten Pfade:
· _check_pending_fill (6 Faelle) — u.a. "fremde Position NICHT taggen" und
"derselbe Fill zaehlt nur einmal"
· Selbst-Kalibrierung (7 Faelle) — Episoden-Dedup, WARTEN re-armt, Auswertung
in beide Richtungen inkl. Broker-Offset, fehlende Bar bleibt offen,
Aggregation
Drei harte Regeln in tests/conftest.py: keine Live-DB (frische Temp-Datei je
Test), kein MT5 / kein laufender Server (gestubbt), kein Netz. Das Schema legen
die ECHTEN Konstruktoren an — HistoryLogger UND CandleLogger, denn candles_m1
gehoert nicht zum History-Schema. Ein handgebautes Test-Schema wuerde
irgendwann vom Produktivstand abweichen.
Warum Temp-DB statt Kopie der Live-DB: am 06.08. haben echte candles_m1-Zeilen
in einem vermeintlich leeren Fenster einen Test verfaelscht — zweimal sah es
nach einem Code-Fehler aus, es waren Testfehler.
MUTATIONS-GEPRUEFT, weil eine Suite die immer gruen ist wertlos waere: eine
absichtlich eingebaute "fremde Position wird doch getaggt"-Regression wird
gefangen. Nebenbefund: der Fill-Dedup ist DOPPELT gesichert (_pending_tagged
und der pop aus _pending_tickets) — nur eines zu entfernen faellt nicht auf,
beides zusammen bricht sofort zwei Tests. Gewollte Redundanz, kein
ungetesteter Zweig.
tests_rec_outcomes.py (Wegwerf-Fassung von gestern) und die verwaiste
test_pbreak.db entfernt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backtest_cost_gate.ci95(): 95-%-Bootstrap-KI des Mittelwerts (Perzentil, 2000
Resamples, random_state fest -> reproduzierbar, ab n>=20). kennzahlen() liefert
es als neuen Schluessel `ci` — rein additiv, alle 11 Aufrufer lesen weiter nur
n/wr/oer/sr/pf, keine dokumentierte Zahl verschiebt sich (geprueft).
Sofortiger Ertrag: der erste Lauf relativiert das `3 von 7 tragen` vom 06.08.
Auf der entscheidenden Spalte C (Beruehrungs-Fill):
KONTROLLE Squeeze H1 [+0,037…+0,229] H2 [+0,225…+0,366]
PDH / PDL H1 [-0,032…+0,544]⚠ H2 [+0,155…+0,764]
Equal H/L H1 [+0,001…+0,425] H2 [-0,035…+0,356]⚠
Asian Range H1 [-0,067…+0,357]⚠ H2 [-0,060…+0,332]⚠
Nur der Squeeze hat in BEIDEN Haelften ein Intervall klar ueber null. Bei Asian
Range enthalten beide die Null — als Ueberlebender war das zu stark formuliert.
Formulierung auf `1 gesichert, 2 unklar` korrigiert.
Zwei verschiedene Fragen, beide noetig: die 2-Stichproben-Regel prueft die
Stabilitaet des VORZEICHENS ueber Regime, das KI die Unterscheidbarkeit vom
RAUSCHEN innerhalb einer Stichprobe. Hier war Ersteres erfuellt, Letzteres
nicht. Ein KI, das die Null enthaelt, heisst nicht widerlegt, sondern nicht
belegt — und zwei gleichgerichtete Haelften sind zusammen mehr Evidenz als jede
fuer sich.
Grenze dokumentiert: der Bootstrap unterstellt unabhaengige Ziehungen. Fuer die
sequentielle Sim mit EINEM Slot passt das; fuer ueberlappende Fenster
(analyze_hl_funding.py) ist er zu optimistisch — dort braeuchte es einen
Block-Bootstrap. ci95 ist dafuer ausdruecklich NICHT gedacht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auf die Frage nach einem Lint-Modul: pyflakes installiert und als Stufe A2 in
tools/check_nfalle.py eingebunden. py_compile prueft nur die SYNTAX; ein
Tippfehler in einem NAMEN ist syntaktisch einwandfrei — und dieses Projekt hat
sehr viele breite except-Exception-Bloecke, in denen ein NameError unsichtbar
bleibt.
Beim ERSTEN Lauf zwei echte Fehler, beide in core/trader.py, beide nutzten
log. (den Namen gibt es dort nicht, nur log_trade/log_hist):
· _broker_offset_s(): der NameError lief in das except-pass UND nahm die
darunter stehende Zuweisung self._boff = int(off) mit -> ein echter
Broker-Zeitzonen-Wechsel waere nie uebernommen worden, dauerhaft und
lautlos. Ausgerechnet der Zweig, der als Deployment-Drift Fall 4 gebaut
wurde (falscher Offset -> Time-Stop-Alter negativ).
· modify_sltp(): steht NICHT in einem try -> der Fehler lief bis in
/api/sltp. Der Broker hatte SL/TP bereits geaendert, der User bekam trotzdem
eine Fehlermeldung, und set_sltp kam nie bis trail.deactivate() — das
Trailing blieb an und haette die Handeingabe zurueckgezogen. Seit dem
Initial-Commit drin.
Beide behoben (log_trade). Zusaetzlich die Annotation 'HistoryLogger | None'
ueber if TYPE_CHECKING sauber importiert (String-Annotation, kein
Laufzeit-Import, kein Zirkel). Projektweit jetzt 0 undefinierte Namen.
Schweregrad-Trennung ist Absicht: nur undefined name / syntax error werden
gemeldet, die ~105 kosmetischen Hinweise unterdrueckt. Auch
'redefinition of unused' bleibt draussen — es trifft das legitime Muster
hook = None + bedingtes def hook (in zwei Backtests geprueft, beide korrekt).
Eine Pruefung mit Dauer-Treffern wird ignoriert, und mit ihr die eine echte.
Backtest-Dateien nicht angefasst (Zahlen). Neustart verifiziert, Log sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nachtrag zum Scanner-Commit — die Doku-Ergaenzung war dort durchgefallen, weil
mein eigenes Heredoc an den deutschen Anfuehrungszeichen scheiterte. Damit ist
die Regel dreimal an EINEM Tag belegt: engine.py, measurement_reminder.py und
das Dokumentieren der Regel selbst.
Regel jetzt in CLAUDE.md: mehrzeilige Strings mit \n oder Text mit deutschen
Anfuehrungszeichen nie per Heredoc schreiben, sondern ueber den Edit-Weg.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auftrag "ueberpruefe alle dateien auf \n-Falle". Die Falle: ueber ein
Shell-Heredoc geschriebener Code macht aus einem gemeinten \n einen ECHTEN
Zeilenumbruch mitten im String-Literal. Heute zweimal passiert (Telegram-Text
in engine.py, Reminder-Eintrag in measurement_reminder.py).
Der Scan prueft in beide Richtungen:
A) kompiliert alle .py (161 Dateien) — sauber
B) JS: unabgeschlossene String-Literale — app.js sauber
C) UMGEKEHRT: literales \n als sichtbarer Text in HTML-title= und Markdown
— alle sauber
D) Signatur der beiden heutigen Faelle (Zeile endet offen, naechste besteht
nur aus einem Quote) — keine
⚠ Fehlalarm im Scanner selbst gefunden und behoben: Quotes zu ZAEHLEN meldet
'"' als offenes Literal (gueltiges JS mit einem Anfuehrungszeichen darin, real
in app.js). Der Scan verfolgt jetzt zeichenweise den AKTIVEN Quote-Typ.
Die betroffene app.js-Stelle trotzdem aufgeraeumt: schliessendes
Anfuehrungszeichen jetzt als U+201C statt ueber eine Konkatenation mit '"'.
Regel in CLAUDE.md ergaenzt: mehrzeilige Strings mit \n nicht per Heredoc
schreiben, sondern ueber den Edit-Weg.
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>
User-Fund: Headline "◌ WARTEN · M30", darunter "stark LONG · 2 von 2
stimmberechtigten fuer LONG (7 ohne Aussage)". Beide Zahlen stimmten, die
Kombination war irrefuehrend. Zwei Ursachen:
(1) Die Headline nannte den Grund nicht. Er stand im Snapshot
(wave_signal.block = min_conf, conf 49 gegen 55 % — die Welle HATTE eine
LONG-Richtung, ihr fehlten sechs Punkte), gerendert wurde er aber nur bei
breakout_pending. ⚠ Meine Luecke vom 06.08.: ich habe die Tages-Verteilung
(#vd-blocks) gebaut und den AKTUELLEN Grund vergessen. Jetzt Mapping fuer
alle neun Gate-Codes an der Headline.
(2) "2 von 2" las sich wie Einstimmigkeit — es waren 2 von 7 sichtbaren
Modulen (H1 1,5 und Liq-Trend 0,5), und die Welle, die als einzige die
Order steuert, war nicht dabei. bias=1,0 ist arithmetisch korrekt, aber die
Basis war winzig. Das Entmachten von Elliott/Orderbuch hat das Problem
nicht erzeugt, aber verschaerft.
Neu: Zeile fuehrt mit der Basis, "stark/leicht" entfaellt solange weniger
als die Haelfte der Module spricht, stumme Welle wird ausdruecklich genannt.
Live gegengerechnet:
"◌ WARTEN · M30 · Konfidenz 49 % < 55 % — Setup zu schwach"
"2 von 7 Modulen sprechen, alle fuer LONG · die Welle ... schweigt"
Reine Anzeige — Gewichte, Gates und Order-Logik unveraendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide .kv-Zeilen samt JS-Zuweisungen (wave-setup, wave-move) raus. Das Setup
steht ohnehin in der Verdict-Headline und den Gruenden, der "Lauf" beschrieb
die Vergangenheit ohne Handlungsbezug.
⚠ Fallstrick beim Entfernen, korrigiert: die Zeile
`const w = d.wave_signal || {}, ws = ...` stand direkt ueber der
Setup-Zuweisung und ist zunaechst mit rausgefallen — `w` wird aber weiter
unten noch achtmal gebraucht (Gruende, Button-Blinken, Close-Alarm,
News-Konflikt). Ein ReferenceError mitten in render() bricht den GESAMTEN
Render ab und friert das Dashboard ein.
Gegenprobe ergaenzt: alle $("id")-Zugriffe der app.js gegen die IDs der
index.html geprueft — 0 verwaiste Referenzen. Klammern-Balance ok,
v=148 ausgeliefert, eine Instanz auf 8000.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
· Modul-Chips: neues `used`-Flag in _verdict.add(). used=False = dauerhaft
entmachtet (Elliott, Orderbuch — beide heute gemessen ohne Inhalt), das
Frontend filtert sie aus. ⚠ Sie bleiben im Snapshot und in verdict_votes:
log_verdict_votes speist daraus die Telemetrie und die 25.000-Verdict-Messung
braucht die Reihe weiter. Ausgeblendet wird die Anzeige, nicht die Messung.
Module mit weight=0 aus SITUATIVER Stille (Welle bei WARTEN, Squeeze ohne
Ausbruch) bleiben sichtbar.
· #vd-note (Muenzwurf-Hinweistext) entfernt, samt CSS. Die Aussage steht
weiter im Karten-Tooltip.
· Tooltips auf allen Dashboard-Anzeigen (59 title-Attribute): Karten,
Header-Boxen, Trade-Leiste, Anzeige-Elemente. Wo eine Messung existiert,
steht sie drin. Gesetzt ueber set_tooltips.py — idempotent, ergaenzt nur
fehlende title=.
Verifiziert: keine Anzeige mehr ohne Tooltip, keine doppelten IDs, Tag-Balance
ok, v=147 ausgeliefert, Elliott/Orderbuch used=False, eine Instanz auf 8000.
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>
Der offene Test aus dem Fill-Befund ist gelaufen (backtest_signal_touchfill.py,
80k M5, voller Live-Gate-Stack, kanonischer Exit, Echtkosten):
Konf A) Markt B) Close-Bruch C) BERUEHRUNG (real)
>=55 -0,015/-0,172 +0,381/+0,315 -0,392/-0,338
>=65 -0,024/-0,085 +0,367/+0,385 -0,478/-0,471
>=75 -0,148/-0,310 +0,288/+0,136 -0,184/-0,202
C ist in allen sechs Feldern negativ (PF 0,38-0,71). Der Look-ahead-Aufschlag
betraegt 0,77-0,85 R — groesser als beim Momentum (0,45) und Squeeze (0,32).
⚠ C ist sogar schlechter als der Markt-Einstieg. Sichtbar am Trade-Zaehler:
C hat MEHR Fills als B (441 gegen 328, 659 gegen 455) — die zusaetzlichen sind
die Beruehrungen, die zurueckfallen. Eine Order an einem WANDERNDEN Level
faengt systematisch die Fehlausbrueche ein.
Damit ist die Vorhersage bestaetigt: entscheidend ist nicht "Level statt
Markt", sondern ob das Level STILLSTEHT. Squeeze-Box haelt (+0,124/+0,292),
_pend und Momentum wandern und fallen durch.
Empfehlung dokumentiert: signal_pending_entry = false. Nicht eigenmaechtig
umgestellt — Live-Schalter sind User-Entscheidungen, und auto_signal ist
ohnehin aus (der Pfad platziert derzeit keine Orders).
Migrations-Pruefung ehrlich vermerkt: der Vorher/Nachher-Vergleich war nicht
bitgenau (ein Trade in H2), Ursache sind zwischenzeitlich eingetroffene
Live-Bars, nicht der Patch — H1 war identisch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kontext in die Meldungen (v=145)
Direkt gegen die HL-API geprueft statt aus dem Code geschlossen.
ANGEBOT: 4 Oel-Maerkte (2 liquide: xyz:CL OI 3,07 Mio, xyz:BRENTOIL 2,25 Mio),
je Markt mark/oracle/funding/open_interest/day_volume + l2Book (20 Level je
Seite). Historie: fundingHistory 5.095 Stundenwerte ueber 7 Monate inkl.
premium. Open Interest hat KEINE Historie -> waere sammelpflichtig.
Netz-Frage geklaert: config sagt testnet (leeres Buch, 0 Bids/0 Asks), aber es
sind zwei Schalter — [hyperliquid] network steuert das Handeln (aus),
[sim] price_network die Daten (mainnet, live bestaetigt).
(1) Mehr Orderbuch-Daten: NEIN. Zweimal unabhaengig gemessen — bookflow_report
0,2-1,0 bp gegen eine ~3-bp-Schwelle und KIPPT; Lead-Lag: Pepperstone
fuehrt, HL trifft nach 6 s zu 51 %.
(2) Modul "Orderbuch" Gewicht 0,5 -> 0. Ueber 2.688 Episoden beidhaelftig
negativ (-0,054/-0,066, 49 % Treffer). Chip bleibt.
(3) analyze_hl_funding.py: Funding/Premium gegen den CFD, 2 Haelften.
⚠ Der erste Lauf meldete mehrere "robuste" Buckets und war FALSCH —
ueberlappende Forward-Fenster (aus n=506 werden ~21 unabhaengige Faelle)
und global gebildete Quintile (Bucket mit der Zeit konfundiert). Dass
Funding- und Premium-Tabelle fast identisch waren, war der dritte Hinweis:
HL rechnet das Funding aus dem Premium. Entueberlappt haelt kein Bucket.
(4) hl_ctx in den Meldungen (#hl-note) als reine Anzeige.
⚠ Zwei Bau-Fallen behoben: der Aufruf erbte den 2-s-Timeout der Waende und
lief still ins Leere (braucht real 7,2 s), und er haette den Trend-Loop
blockiert -> Daemon-Thread wie beim Wirtschaftskalender.
Live verifiziert: hl_ctx befuellt, Orderbuch weight=0 bei erhaltenem Chip,
v=145 ausgeliefert, eine Instanz auf Port 8000.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Elliott entmachtet (v=144)
Vier Verbesserungen, alle aus dem Gemessenen abgeleitet — kein neues Signal.
Ausgangspunkt: die Karte hat genau eine belegte Funktion, das Veto; als Prognose
ist sie ein Muenzwurf (48-51 % ueber 1.071 Episoden).
(1) SELBST-KALIBRIERUNG. Neue Tabelle rec_outcomes: eine Zeile je EPISODE
(Richtungswechsel, nicht je Minute), Auswertung ~alle 5 min gegen candles_m1
nach 30/60 min, Snapshot rec_track, Zeile #vd-selfcal. Gegen 50 % zu lesen.
Warum der groesste Hebel: die Qualitaet war bis heute unsichtbar und musste
auf Nachfrage rueckwirkend gemessen werden. Dasselbe Muster
(pbreak_predictions) hat den Ausfall des P(break)-Modells LIVE aufgedeckt.
Mit 4 Szenarien getestet (tests_rec_outcomes.py). Zwei Fehlschlaege dabei
waren Testfehler, keine Code-Fehler — dokumentiert.
(2) alignment_stats auf die VOLLE Historie (1.216 statt 40 Trades) und
zusaetzlich je Lot. Absolute Euro-Vergleiche sind bei wechselnder
Positionsgroesse ungueltig (Lehre 04.08.). Damit steht die einzige
beidhaelftig robuste Aussage der Karte auf ihrer vollen Stichprobe.
(3) Block-Gruende sichtbar (block_mix -> #vd-blocks): "heute X % ohne Block ·
entry_room … · min_conf …". Bisher nur per DB-Abfrage zu beantworten.
(4) ELLIOTT: Verdict-Gewicht 1,0 -> 0. Gemessen ueber 15.544 Zeilen hatte es mit
1.384 Episoden die groesste Stichprobe der Tabelle und ist darin flach
(-0,075/+0,032, 50 % Treffer) — bei 25,9 % Einfluss auf die Nadel, weil es
in nur 1 % der Zeilen schweigt. Chip bleibt, Stimme entfaellt.
⚠ Folge: die Nadel schlaegt staerker aus (real +0,33 -> +1,00).
⚠ Namenskollision beim Bau gefunden und behoben: die neue Klasse hiess zuerst
.vd-track — so heisst bereits die Schiene der Bias-Nadel; sie waere
ueberschrieben worden. Jetzt .vd-selfcal.
Live verifiziert: alignment je Lot, block_mix (93 von 1381 ohne Block),
rec_outcomes angelegt, Elliott weight=0 bei erhaltenem Chip, v=144 ausgeliefert,
eine Instanz auf Port 8000.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher stand dazu nur alignment_stats(40). Ueber alle 1.216 geschlossenen
Trades, je Lot normiert und in zwei Haelften:
MIT Signal n=354 WR 56,5 % +3,22 EUR/Lot (H1 +0,37 / H2 +5,62)
GEGEN Signal n= 87 WR 40,2 % -6,60 EUR/Lot (H1 -7,01 / H2 -5,68)
OHNE Signal n=775 WR 56,6 % +0,36 EUR/Lot (kippt: -2,68 / +0,76)
Die schaerfste Zeile ist MIT gegen OHNE: 56,5 % zu 56,6 %, identisch. Der
Empfehlung zu FOLGEN bringt gegenueber "ohne Empfehlung handeln" gemessen
nichts. Nur sie zu VERLETZEN kostet — und das robust in beiden Haelften.
Damit ist die Rolle praezise: Veto, keine Prognose. Das ist zugleich die
einzige Richtungsaussage ueber die Gesamtempfehlung, die den
2-Stichproben-Test besteht.
Grenze benannt: gegen hat n=87 und die Zuordnung ist konfundiert (der Mensch
waehlt aus, wann er gegen das Signal geht).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User: "backteste alle verworfenen Signale". Bewusst kein Komplettlauf (der lief
am 04.08., 14 Klassen, alle blieben verworfen) — neu ist genau eine Achse, der
Einstiegspreis, angewandt mit der heutigen Korrektur (Fill bei BERUEHRUNG statt
bei Schluss-Bruch) und nur dort, wo sie greifen kann: stehendes Level +
Ausbruchsrichtung.
Ergebnis (Variante C, 80k M5, 2 Halbjahre):
KONTROLLE Squeeze +0,133/+0,293 (reproduziert touchfill — Pipeline ok)
ORB (4 Varianten) faellt durch (bestaetigt 2026-07-17)
PDH/PDL +0,246/+0,464
Asian Range +0,142/+0,134
Equal H/L +0,218/+0,170
Alle drei nachbar-robust (11 Zellen, keine kippt).
⚠ Das sind keine drei neuen Signale: PDH/PDL, Asian-Range-Extrem, Equal H/L und
die Squeeze-Box sind dasselbe — waagerechtes Level aus frueheren Extremen,
gebrochen, ruhende Order, kanonisches Trailing. Deckt sich mit der Kontrolle
"beliebige Box" aus dem Multi-Instrument-Lauf.
⚠⚠ Mit der gemessenen Exit-Slippage bleibt fast nichts uebrig. Beim guenstigsten
Wert (0,0124 $, Tagfenster): PDH/PDL +0,099/+0,386 haelt, Equal H/L duenn, Asian
Range faellt — und der LIVE laufende Auto-Squeeze steht in H1 bei -0,002.
Die Edges dieser Familie liegen in derselben Groessenordnung wie die
Ausstiegskosten, und die Slippage-Zahl ist eine Untergrenze.
Konsequenz: kein neues Setup bauen. Der naechste Hebel ist die
Ausfuehrungsqualitaet am EXIT, nicht ein weiteres Einstiegs-Signal.
Offen und benannt: Volume-Profile-LVN und die Chartmuster-Nackenlinie
qualifizieren sich, wurden aber nicht gemessen (Laufzeit bzw. Detektor).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Messungen und eine UI-Aenderung, ausgeloest von der Frage, ob das Konzept
zu ueberdenken ist.
1) SQUEEZE AUF ANDEREN INSTRUMENTEN (backtest_squeeze_multi.py): 7 von 9 halten
alle vier Bedingungen, alle nachbar-robust. Die zwei Durchfaller (Gasoline,
USDX) sind exakt die mit Spread >= ATR — der Test scheitert, wo er muss.
⚠ 7 sind nicht 7 unabhaengige Tests (Crude/Brent, Gold/Silber, NAS/GER40
korrelieren), und die Kompression traegt weniger als der Ausbruch selbst
(Kontrolle "beliebige Box" ist ueberall positiv).
2) MOMENTUM (backtest_momentum_v2.py): bleibt verworfen. Mit Level-Order sah es
nach +0,4 aus — das war Look-ahead. Eine liegende Order fuellt bei der ersten
BERUEHRUNG, nicht erst wenn der Bar jenseits des Levels SCHLIESST. Ehrlich
gerechnet: -0,04..-0,09 in H1. Struktureller Grund: das Momentum-Level wandert
jede Bar mit C[i-N] und ist damit kein Ort, an dem eine Order liegen bleibt.
3) FILL-ANNAHME (backtest_squeeze_touchfill.py): dieselbe Frage fuer den Squeeze.
Er haelt (+0,124/+0,292, PF 1,24/1,64) und die Umstellung auf ruhende Orders
bleibt richtig (Market -0,158/-0,006). ABER die heute zitierten +0,456/+0,611
sind als Live-Erwartung ~0,32 R zu hoch. Die Beruehrungs-Variante trifft fast
genau das original validierte Band +0,14..+0,23.
⚠ OFFEN: derselbe Test fehlt fuer den SIG-Pending-Pfad, der seit 05.08. live
ist — und dort ist ein schlechteres Ergebnis zu erwarten, weil das _pend-Level
wandert statt stillzustehen.
4) UI (v=143): fester Vorbehalt unter der Headline und "Score" statt nackter
Prozentzahl am Ring. Statisches Markup, kein JS.
Eigener Fehler dokumentiert: der erste Momentum-Entwurf pruefte nicht, ob das
Level als Stop-Order auf der richtigen Marktseite liegt, und lieferte ØR +2,2 —
unmoeglich, und genau daran erkennbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Beobachtung "die Empfehlungen heute waren fast immer gegenlaeufig" — vor
einer Konzeptdebatte gemessen, und zwar an den TATSAECHLICH ausgegebenen
recommendations-Zeilen (nach allen Live-Gates), nicht im Backtest.
20.365 Zeilen -> 1.071 Episoden (08.05.-06.08.), gegen die Drift der jeweiligen
Haelfte gelesen. Trefferquote ueber alle sechs Felder 48,3-51,1 %. Bester
Ueberschuss +0,085xATR bei 60 min — unter der B3-Huerde (0,1) und weit unter
den realen M5-Kosten (0,265). Auf 120 min ist H2 mit -0,259 klar negativ.
Der Anlasstag war typisch, kein Ausreisser: 8 von 10 Episoden auf 30 min
gegenlaeufig; die fuenf Vormittags-SHORTs liefen gegen einen Tag, der von
75,5 auf 78 stieg.
Wichtige Einordnung, damit daraus nicht der falsche Schluss gezogen wird:
dasselbe Signal ist mit ruhender Order am Bestaetigungs-Level in beiden
Haelften klar positiv (+0,35/+0,32, PF 2,2) und am Markt negativ. Der Ertrag
kommt aus Einstiegspreis und Exit-Asymmetrie, nicht aus der Trefferquote —
wie beim Squeeze (43-46 % Treffer, trotzdem positiv).
Die Headline ist damit kein Kursurteil, sondern ein Ausloeser fuer eine
Level-Order. Die Suche nach einem besseren Richtungssignal folgt daraus
NICHT — die ist mit 23 verworfenen Eingriffen beantwortet.
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>
Der M1-Squeeze hing an der Exit-Slippage bei kurzer Haltedauer. Die bisher
zitierten "Median 0,017 / Ø 0,234" waren die Statistik NUR ueber die
Ausreisser — analyze_execution.py zaehlt ausschliesslich Faelle, die
schlechter als der Initial-SL endeten.
Sauber ist E[Slippage] >= P(gap>0) x Ø(gap|gap>0). Unkontaminiert, weil das
Trailing den gap nur negativer machen kann: ein positiver gap ist zwingend
Slippage. Ueber 317 SL-Closes, <30 min:
alle Stunden 0,0370 $ (0-15 min allein 0,0470)
nur 10-17 Uhr 0,0124 $ (0-15 min allein 0,0058)
Der Schwanz sitzt ausserhalb von 10-17 — bei kurzen Trades dort 8x kleiner.
Gleiche Ursache wie beim Spread (Buchtiefe), also Mechanismus statt Zufall.
Endvergleich mit dem gemessenen Wert je Fenster:
M1 alle Stunden -0,107/-0,161 PF 0,83/0,76 FAELLT HART DURCH
M1 10-17 +0,354/+0,247 ΣR +150/+121
M5 alle Stunden +0,401/+0,261 ΣR +108/+71
M5 10-17 +0,751/+0,444 ΣR +68/+45
Der ΣR-Vorsprung von M1 ueber alle Stunden war reines Artefakt der Annahme
"keine Exit-Slippage". Auf demselben Fenster bleibt ein echter Zielkonflikt:
M5 doppelt so gut je Trade, M1 doppelt so gut in der Summe — bei EINEM Slot.
Urteil: nicht umstellen. Der entscheidende Parameter ist nur als Untergrenze
bekannt und M1 hat davon nur ~3x Luft bis zur Kippgrenze (M5 ~7x); die
Stichproben sind duenn; 80 Tage = ein Regime. Die Bedingung fuer ein spaeteres
Ja ist in CLAUDE.md benannt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nicht ausgeschlossen — aber in JEDER Variante schlechter je Trade als die
M5-Kontrolle auf demselben Fenster (beste M1-Variante +0,474/+0,387 gegen
+0,605/+0,491). Alle Nachbar-Parameter halten, Einstiegs-Slippage bis
0,20xATR haelt, der skalierte ATR-Floor erzeugt den Befund nicht (Kontrolle
ohne Floor bestaetigt), Broker blockt nicht (trade_stops_level = 0).
Entscheidend ist die EXIT-Slippage, und sie trifft M1 doppelt so hart, weil
sie absolut ist: M1 kippt bei ~0,04 $, M5 erst bei ~0,09 $ (Faktor 2,2 =
das ATR-Verhaeltnis). Gemessener Median 0,017 $ -> beide halten; gemessener
Ø 0,234 $ -> beide fallen. Die entscheidende Zahl — Slippage bedingt auf
Haltedauern <30 min — ist ungemessen.
Urteil: nicht umstellen. M1s Vorteil kommt allein aus der 4,3-fachen
Frequenz, und genau die multipliziert die ungemessene Groesse.
Zwei Methodik-Lehren dokumentiert: der Haertetest lief zuerst auf der
schwaechsten statt der besten Variante (Auswahl nach Reihenfolge statt nach
Ergebnis), und die Regel "nicht schlechter als die Kontrolle" war wieder
unterspezifiziert (ØR und ΣR zeigen gegenlaeufig) — deshalb gibt zeig()
jetzt beide Spalten aus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Frage "wie sinnvoll waere ein Scalping-Modul auf 1M-Basis". Vor dem Bau
gemessen, weil es zuerst eine Kosten- und keine Signalfrage ist: der Spread
ist absolut ~konstant und skaliert nicht mit der Zeitebene, die Bewegung schon.
Spread/ATR im Median: M1 0,319 · M5 0,193 · M15 0,133. Eine mittlere M1-Kerze
ist nur 3,4x so gross wie der Spread. Noetige Trefferquote bei 1:1 steigt von
50 auf 65,9 %; um 01:00 uebersteigt der Spread mit 1,051xATR_M1 die gesamte
durchschnittliche Bar-Spanne.
Dazu drei Gruende, die schwerer wiegen als die Kosten:
- M1-Historie ist hart bei 80.000 Bars / 80 Tage gedeckelt -> kein
2-Stichproben-Test ueber verschiedene Regime moeglich
- das Aufloesungs-Artefakt vom 05.08. trifft M1 am haertesten (Scalp lebt in
2-3 Bars, Bar-Sim ueberschaetzt enge Stops)
- der Slippage-Schwanz ist absolut: Ø 0,234 $ uebersteigt einen 2xATR_M1-Stop
(0,174 $) bereits im Mittel
Empfehlung: kein eigenstaendiges Modul; messbar waere der Squeeze auf M1
(offene Variante B) beschraenkt auf 10-17 Uhr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Skript zaehlte im Abschnitt "per Pending gefuellt" JEDEN Trade seit dem
Umbau — es meldete "31 Trades, davon 30 ohne Market-Log-Zeile". Real waren
es 5 Bot-Trades (1 Market-Fallback + 4 Pending-Fills); der Rest waren
manuelle. Moeglich war die Verwechslung genau deshalb, weil ein Pending-Fill
bis zum Fix von heute ohne `setup` gebucht wurde.
Jetzt Filter auf SQUEEZE_*/AUTOSIG_* und Setup in der Ausgabe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auftrag "überprüfe die heutigen autotrades": die DB meldete für den 06.08.
null Bot-Trades, das Log vier gefüllte SQZ-STOP-Orders. Beides stimmte.
Ein Pending-Fill läuft nicht über engine._open — die Position wird von
trader._refresh_locked per magic-match adoptiert, und dieser Pfad loggt nur
Ticket/Symbol/Richtung/Lots/Preis. Es fehlten setup, sl_at_entry und alle
16 ctx_*-Spalten. Damit war genau die Messpipeline, die den Pending-Umbau
vom 05.08. kontrollieren soll, blind für ihn (B4-Monitor, squeeze_b5,
squeeze_entry_gap zählten null) — Deployment-Drift Fall 8, erste Variante,
bei der nicht die Strategie driftet, sondern ihre Beobachtbarkeit.
- history.tag_bot_trade(): UPDATE nur wenn setup IS NULL, stiller Fail-open
- engine._pending_tickets: Ticket -> Quelle, beim Platzieren/Stornieren gepflegt
- engine._check_pending_fill() im _pos_loop vor dem Pending-Manager;
Zuordnung über Positions-Nr == Order-Nr (an allen 4 Fills verifiziert),
setzt zusätzlich _bot_open_ticket/_source und die Entry-Zähler
6 Szenarien getestet, darunter die zwei gefährlichen: fremde Position wird
nicht getaggt, derselbe Fill zählt bei Folge-Ticks nur einmal.
Die 4 Trades des 06.08. nachgetragen (Backup .bak-2026-08-06).
ctx_*/sl_at_entry bewusst NICHT nachgetragen: rekonstruiert wären sie später
von gemessenen Werten nicht unterscheidbar.
Dabei gefunden, dokumentiert, NICHT behoben: der Signal-Pfad setzt/storniert
dieselbe Order 4x in 76 s bei identischem Level, weil block_reason zwischen
entry_room und breakout_pending pendelt (Drift Fall 9).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
geschlossen
Der 05.08. hat 1427 Zeilen geloggt (Soll ~1440), die Erfassung ist also intakt.
5,0 % gerichtet - und auffaellig ist die Verteilung: alle 71 gerichteten
Empfehlungen fielen vor 10:00, danach 16 Stunden lang genau eine.
Gegen den gueltigen Massstab (backtest_dist_gated.py, 19,5 % gerichtet) ist
entry_room NICHT der Unterschied - es ist live mit 36,5 % sogar seltener als im
Backtest (41,4 %). Die Luecke tragen die live-only-Gates, allen voran min_conf
(16,1 % live gegen 0,9 % im Backtest), dazu htf_counter, EIA und stale.
Telemetrie-Luecke: min_conf-Zeilen schrieben conf_pct = 0, die verworfene
Konfidenz stand nur als Fliesstext in den Gruenden. Damit war beim
zweitgroessten Blocker nicht feststellbar, ob die Signale knapp (50-54) oder
weit (20-30) unter der Schwelle lagen. wave_rec._build gibt den Wert jetzt mit -
reine Telemetrie, das Signal bleibt WARTEN. Erste Live-Zeile: conf 52.
Das beantwortet noch nicht, ob 55 die richtige Schwelle ist: backtest_conf.py
hat das Band 40-54 % als negativ gemessen, eine Senkung ist nicht angezeigt.
Die Zahl sagt nur, wieviel Signalmenge direkt hinter der Schwelle steht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entfernt: Tab-Button, #view-charts, der gesamte app.js-Chart-Block
(Kartenaufbau, renderChart, loadCharts, 20-s-Refresh, Resize-Handler), die
Chart-CSS-Regeln, die vendorte Bibliothek
web/lightweight-charts.standalone.production.js (164 KB) samt script-Tag - und
die Backend-Kette dahinter: /api/bars und engine.get_bars (60 Zeilen). Beide
existierten ausschliesslich fuer dieses Tab; geprueft, dass es keinen anderen
Aufrufer gibt.
Nicht betroffen (sahen nur aehnlich aus): die Chartmuster-Karte (Verdict-Gewicht
0,25, im Tab "SIG Live"), der MQL5-Indikator samt sr_levels.csv-Export (eigener
Pfad ueber _write_levels_file) und die Analyse-Module structure/patterns/cone -
die speisen den Snapshot, nicht das Chart. Der MT5-Chart bleibt voll bedient.
Ein veralteter Kommentar in trader.py, der auf engine.get_bars verwies, wurde
auf core/gaps.py umgehaengt.
Verifiziert am laufenden Server: /api/bars -> 404, Bibliothek -> 404,
data-view="charts" und id="view-charts" nicht mehr im ausgelieferten HTML,
6 Tabs zu 6 Views paarig, keine verwaisten JS-Referenzen, Klammern-Balance ok,
keine Fehler im Log. v=142.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zu pessimistisch
Geprueft gegen unabhaengige SQL-Rechnung: /api/stats ueber today/week/all mit
~50 Werten (n_trades, wins/losses/breakeven, total_pnl, avg_win/loss,
gross_win/loss, winrate, profit_factor), dazu die inneren Konsistenzen
(wins+losses+be = n, gross_win-gross_loss = total_pnl, Summe closed_by = n,
Summe hour_stats = wins/losses) und 8 Setup-Zeilen. Ebenso stats_compact und
day_pl. Alles stimmt bitgenau.
Der Defekt liegt in server._add_net / _add_net_setup:
net_pnl = total_pnl - gross_win x 26,375 %. Das unterstellt, die Quellensteuer
sei endgueltig verloren - sie wird aber groesstenteils erstattet, was CLAUDE.md
selbst dokumentiert ("erstattet via taegl. Tax settlement"), die Rechnung aber
ignoriert.
Empirisch aus den echten Broker-Buchungen (history_deals_get, gleicher Zeitraum
wie die Statistik): einbehalten -2236,10, erstattet +1789,65, tatsaechlich
verblieben -446,45. Das Modell rechnet mit -2097,10.
Angezeigtes Netto -1104,67 gegen reales Netto +545,98 - Abweichung 1650,65 EUR,
und das Vorzeichen dreht. Real verbleiben nur 21 % der modellierten Last.
Richtige Loesung waere, die tatsaechlichen WHT-/Tax-Deals zu verwenden statt zu
schaetzen (ueber history_deals_get + Kommentar-Filter exakt abrufbar, gecacht und
unter mt5_lock). Nicht gebaut - Umfang war die Pruefung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
trader._calc_sl_tp bekommt die ATR-Zeitebene als Parameter (Default SL_TF =
M15); _send/_send_locked/open_long/open_short und place_stop reichen sie durch.
Gesetzt wird sie an genau zwei Stellen: engine._open bei source="auto_squeeze"
und _manage_squeeze_pending bei quelle="squeeze". Manuelle Trades und
Auto-Signal bleiben bei M15.
Grundlage backtest_sl_basis.py: auf Squeeze-Entries ist der Ertrag zwischen
beiden Basen ein Wash (alle Varianten innerhalb eines Standardfehlers), der
Worst-Case sinkt aber von -8,83 auf -2,44 xATR_M5 = Faktor 3. Auf der
Wellen-Population ist der weite M15-SL in BEIDEN Haelften besser - deshalb
bewusst keine globale Umstellung.
Die Multiplikatoren (1,8-2,2 xATR) sind nicht angefasst, nur die Zeitebene.
TP bewusst NICHT betroffen (User: "nur fuer SL, der TP soll mit dem Runner
mitwachsen"). Geprueft statt angenommen: der von _calc_sl_tp zurueckgegebene TP
wird von KEINEM Aufrufer gesendet, beide setzen nur req["sl"]. Das Ziel
verwaltet trailing.py dynamisch (3,5 x ATR der Wellen-Zeitebene). Warnkommentar
im Code, warum der TP dort nicht mit in die Order darf.
4 Szenarien getestet. Dabei eigene Fehlannahme korrigiert: ohne Pivot greift der
1,2-%-Fallback, der beim M15 vom MINDEST-Deckel aufgeweitet wird - die
2,2x-Obergrenze wird dort gar nicht erreicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Strukturfund vorweg: exit_model.simulate nimmt EINEN atr fuer SL, TP, Trail und
Breakeven - und alle Backtests uebergeben ATR_M5. Live kommt der SL aus ATR_M15
(Median 1,80x groesser). Praktisch jede Projekt-Messung modelliert damit
2,0xATR_M5, waehrend live ~4,0xATR_M5 gilt. Einzige bisherige Ausnahme war
backtest_sl_width.py.
Gemessen auf der NEUEN Level-Entry-Population (80k, 2 Halbjahre, nur die
SL-Basis variiert):
SQUEEZE: Ertrag ist ein Wash - alle Varianten innerhalb eines Standardfehlers,
und die einzige beidhaelftig bessere Zelle (2,5) hat schlechtere Nachbarn.
WELLE: der weite Live-SL ist in BEIDEN Haelften der beste, jede Verengung
kostet.
Der einzige robuste Unterschied ist das Tail-Risiko: Worst-Case -8,83 xATR
(live, Squeeze H2) gegen -2,94 bei 2,5xATR_M5 = Faktor 3. Bei 3,5 Lots sind das
~-890 EUR gegen ~-300 EUR im schlechtesten Einzeltrade.
Antwort auf die Frage: vertretbar ja, aber als Risiko- und nicht als
Ertragsentscheidung. Saubere Umsetzung waere quellen-abhaengig (M5-ATR nur bei
auto_squeeze) - strukturell begruendet, nicht data-mined. Nicht gebaut.
Reproduziert NICHT backtest_sl_tf_mismatch.py (23.07.): dort Einstieg am
Bar-Close, hier am Level - der Einstiegspreis hat den Befund gedreht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlass: Trade T=49423144 (-343 EUR) und der Wunsch, der Breakout haette frueher
schliessen sollen - nachgeschaerft zu "bei einem Squeeze den SL sofort eng
setzen". Beide Varianten gemessen, kanonischer Exit + stop_when-Hook (keine
Exit-Kopie), Echtkosten, 2 Halbjahre, zwei Populationen.
Der eigentliche Befund steht nicht in den Kennzahlen, sondern in den
Ausloesungen: sofort-schliessen feuert 1x von 809 bzw. 1274 Squeeze-Trades, der
enge SL 0x. Bei Wellen-Entries 8x bzw. 2-3x. Grund ist konstruktionsbedingt: ein
Gegen-Ausbruch verlangt eine NEUE Kompression (Box ueber 10 M5-Bars = 50 min),
waehrend die mittlere Haltedauer bei 12-18 min liegt. Der Gegen-Ausbruch trifft
also in ~0,1 % (Squeeze) bzw. ~1 % (Welle) der Trades ein - der Fall des Users
war einer davon.
Damit sind die Kennzahl-Unterschiede Rauschen aus einer Handvoll Faelle, und
keine Variante besteht auf beiden Populationen. Die abgeschwaechte Form (enger
SL statt Close) adressiert zwar genau den alten Einwand (Gegen-Ausbrueche sind
oft Fehlausbrueche), kann ihn aber nicht ausspielen, wenn sie 0-mal ausloest -
und waere von einer Bar-Simulation ohnehin ueberschaetzt.
Dritte Ablehnung, diesmal mit einer Begruendung, die nicht vom Exit-Modell
abhaengt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Artefakt, das einen alten Schluss entwertet
Anlass: Frage zur Trail-Kalibrierung "jetzt bei 3 Lot". Zur Praemisse: die
Positionsgroesse aendert das Optimum NICHT (R ist ATR-normiert). Gemessen wurde
die echte offene Frage - be=1,3 stammt aus der Zeit mit Trail 1,5, mult wurde am
31.07. auf 1,0 gesenkt ohne das Breakeven neu zu pruefen.
(1) Breakeven ist praktisch wirkungslos: bei mult <= 0,6 sind alle be-Zeilen
identisch (der enge Trail erreicht den Einstand frueher als der BE-Boden). Bei
mult 1,0 ist be=0,6 um +0,019 besser - unter einem Standardfehler. Keine
Aenderung.
(2) Der Trail ist monoton besser bis hinunter zu 0,05 xATR (~3 Cent) - das waere
vom Spread allein ausgeloest. Ein Optimum, das bis an die physikalische
Unmoeglichkeit monoton bleibt, misst die Methode, nicht den Markt.
Aufloesungs-Artefakt nachgewiesen (analyze_trail_resolution.py): mit in DOLLAR
fixiertem Trail auf M5 gegen M1, 597 gemeinsame Einstiege, kippt das Vorzeichen
der Differenz bei ~0,3 xATR - die groebere Aufloesung ueberschaetzt enge Trails
(-0,027 bei 0,10) und unterschaetzt weite (+0,036 bei 1,0, +0,066 bei 1,5).
Damit ist der Befund vom 31.07. ("enger ist monoton besser") teilweise entwertet.
Erster Testentwurf war falsch konstruiert: der Trail wurde mit dem ATR der
jeweiligen Zeitebene skaliert, damit bleibt das Verhaeltnis Trail/Bar-Spanne
konstant und die Aufloesung wird gar nicht variiert.
Nebenbefund gegen die eigene Slippage-Vermutung: die Trade-Zahl ist ueber alle
Multiplikatoren fast konstant (2108 bei 0,3 gegen 2083 bei 1,0), Worst-Case
ueberall -2,44. Das Slippage-Argument traegt kaum, das Aufloesungs-Argument
traegt.
Ergebnis: Trail 1,0 / Breakeven 1,3 bleiben.
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>
Der einzige Einwand gegen die Backtest-Ablehnung war die Live-Bilanz von
+284,22 EUR aus 4 Ausloesungen. Kontrafaktisch nachgerechnet (kanonischer Exit
ab demselben Einstieg, Methode wie analyze_manual_close.py): ohne den Flip
waeren es +183,51 EUR gewesen - der Flip war auf diesen Trades also +100,71 EUR
BESSER.
Das ist trotzdem kein Beleg: n=4, und +101 EUR stecken in EINEM Trade (04.08.
16:15). Der 04.08. ist genau der Ausreisertag, der allein die 30-Tage-Bilanz
traegt. Gegen ~2.000 Trades je Haelfte im Backtest (jede Variante, beide
Haelften negativ, -92/-160 R) wiegt das nichts - dieselbe Falle wie der
12k-Vorlauf beim Kerzen-Fade.
Empfehlung: abschalten. Der Alarm bleibt (Blinken/Ton/Telegram), nur die
automatische Ausfuehrung entfaellt - damit ist der dokumentierte
Ursprungszustand wieder da. Nichts umgeschaltet, das ist eine User-Entscheidung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Anteil "ueber alle Zeilen" mischt Gewichtung und Haeufigkeit. Entscheidend
fuer "ist die Gewichtung kaputt?" ist der Anteil, WENN ein Modul spricht:
Welle 44,4 % · H1 39,3 % · Squeeze 37,3 % · M30 31,9 % · Elliott 26,2 % ·
KI 16,2 %
Die Welle dominiert also mit dem hoechsten Wert im Feld, genau wie entworfen -
ihre 3,8 % im Alltag sind schlicht die 91 % gewollte Stille der Gates. Meine
vorherige Formulierung ("Gewichtung invertiert") war zu scharf und ist
korrigiert.
Was bleibt: H1 und Elliott haben in beiden Spalten fast denselben Wert, weil sie
praktisch nie schweigen - ein permanenter Hintergrund von ~65 %, gegen den die
episodischen Module anschieben muessen. Elliott ist dabei ueber 1.163 Episoden
flach (49 % Treffer).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
analyze_verdict_modules.py, 13.568 Zeilen (24.07.-05.08.). Nominal-Gewicht sagt
fast nichts darueber, wie stark ein Modul die Bias-Nadel bewegt - entscheidend
ist, wie oft es ueberhaupt mitredet. Realer Anteil am Gesamtgewicht:
H1 38,5 % · Elliott 26,0 % · M30 12,2 % · Squeeze 7,0 % · Liq-Trend 6,1 % ·
Orderbuch 4,1 % · Welle 3,8 % · Muster 1,8 % · KI-Copilot 0,5 %
Die Welle hat das hoechste Nominal-Gewicht (3,0) und den drittkleinsten realen
Einfluss - die Gates schalten sie zu 91 % stumm. Die Nadel wird faktisch von
H1 + Elliott bestimmt (zusammen 64,5 %); die beiden validierten Module kommen
zusammen auf 10,8 %.
Dokumentations-Fehler korrigiert: CLAUDE.md behauptete, Elliott habe Gewicht nur
bei gerichtetem Ziel (1,3 % der Zeilen). Real ist elliott_w > 0 in 13.558 von
13.568 Zeilen (99,9 %) - Elliott ist die zweitlauteste Stimme im Verdict.
Praediktivitaet als Sichtung (Forward-Return 60 min, gegen die Drift-Null,
Minutentakt zu Episoden zusammengefasst): Elliott -0,031/-0,020 bei 49 %
Treffern ueber 1.163 Episoden - groesste Stichprobe, und flach. Uebrige Module
zu duenn oder kippend. 12 Tage = ein Regime, deshalb Sichtung statt Urteil.
Methodik-Korrektur beim Bau: erst wurde nur die Stimme gezaehlt, nicht das
Gewicht (getrennte Spalten). Genau dabei kam heraus, dass elliott_w praktisch
immer gesetzt ist.
Nichts geaendert - die Bias-Nadel ist reine Anzeige, die Order steuert die Welle
ueber die Headline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Vorgabe. Sortiert wird nicht nach Thema, sondern danach, ob ein Modul die
Empfehlung bewegt - und das ist am Code pruefbar: engine._verdict ruft
add(name, vote, gewicht, ...); Gewicht > 0 heisst Einfluss auf die Bias-Nadel.
SIG Live <- KI-Copilot (Gewicht 1,0) · Chartmuster (_PAT_W = 0,25)
SIG Anzeige <- Marktstruktur · Kerzen-Anatomie (gemessen ohne Einfluss)
Chartmuster landet damit bewusst in "Live", obwohl die Klasse als Signal
verworfen wurde - seit 01.08. hat sie 5 % Stimmanteil. "Gewicht" heisst nicht
"belegt"; genau deshalb ist die Trennung nach Wirkung sinnvoll: sie zeigt, was
die Empfehlung TATSAECHLICH bewegt, unabhaengig von der Beleglage.
Auf dem Dashboard bleiben Trade-Leiste, Gesamtempfehlung, Meldungen und
Statistik (live). Die Meldungen-Karte enthaelt zwar einflussreiche Teile
(Squeeze-Stimme, S/R-Close-Hinweis, Flip-Close), ist aber der Live-Meldungsstrom
zum laufenden Trade und gehoert dorthin, wo gehandelt wird.
Reiner Markup-Umzug: showView bildet data-view="siglive" auf #view-siglive ab,
keine JS-Aenderung noetig. CSS-Regel analog zum Statistik-Tab, weil beide Views
ausserhalb des <main>-Grids liegen. Die verschobenen Bloecke wurden aus git
zurueckgeholt statt nachgetippt.
Verifiziert am ausgelieferten HTML: 7 Tabs, 7 Views, keine doppelten IDs, keine
verwaisten JS-Referenzen, section-Tags balanciert. v=141.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backtest_candle_fade2.py. Bewusst nur EINE neue Achse geprueft - der
Einstiegspreis, der am selben Tag Squeeze und Signal von negativ auf positiv
gedreht hat: Market am Bar-Close gegen ruhende Limit-Order am Kerzen-Extrem,
dazu der kanonische Exit (Trail 1,0 statt der alten Kopie mit 1,5).
Sequentiell EIN Slot, Echtkosten, 80k M5, 2 Halbjahre, Kontrollgruppe ohne
Volumen, Regel vorab fixiert.
Ergebnis: keine einzige Variante ist irgendwo positiv - beide Einstiegsarten,
alle Volumen-Schwellen, alle Gueltigkeitsdauern der Limit-Order.
Der lehrreiche Teil: der Ausfuehrungs-Hebel ist NICHT universell. Beim Squeeze
und beim Signal dreht die ruhende Order das Vorzeichen, hier macht sie es
schlechter. Strukturell: eine Stop-Order fuellt einen BREAKOUT im Moment der
Bestaetigung, eine Limit-Order fuellt einen FADE nur dann, wenn die Klimax sich
weiter ausdehnt - also genau wenn man falsch liegt. Sichtbar an der Schere:
Trefferquote steigt (38,0 -> 40,1 %, bei Vol>=2,5 auf 48,5 %), OeR faellt
trotzdem. Merksatz: ruhende Order hilft bei Momentum-Entries, schadet bei
Reversion-Entries.
Nebenbefund: im 12k-Vorlauf gab es positive Zellen (bis +0,291), ueber 80k
verschwinden sie restlos. Ein kleiner Lauf haette zum dritten Mal zum
Fehl-Einbau gefuehrt.
Kachel bleibt reine Anzeige, kein neuer Zaehl-Eintrag (dieselbe Klasse wie #18).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Vorgabe. #card-cone/#cone-list raus; neu die einzeilige #vd-cone unter der
Bias-Nadel: "erwartete Spanne · 30' 75,99-76,77 · 60' ... · trifft 77 %".
Gezeigt wird nur noch das 80-%-Band je Horizont; das enge 50-%-Band und der
Erklaer-Absatz stecken im title.
Platzierung und Farbe sind Absicht: die Zeile steht UNTER der Nadel und ist
neutral/randlos - sie zeigt Streuung, nicht Richtung, und darf optisch nicht mit
dem Bias konkurrieren. Beschriftet bleibt sie mit der REAL gemessenen Abdeckung
(~77 %), nicht mit dem Nennwert 80 %.
Backend unveraendert aktiv (core/cone.py, Snapshot cone, MT5-Export CN;...).
Verifiziert am ausgelieferten HTML: card-cone weg, vd-cone da, keine verwaisten
JS-Referenzen, Klammern-Balance ok. v=140.
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>
SIG laeuft damit auf der gemessen positiven Variante (OeR +0,35/+0,32, PF 2,2)
statt auf der Market-Order (-0,09/-0,11).
Der heikelste Punkt war nicht die Order, sondern die Kollision beider Pfade:
trader.pending_orders() liefert ALLE magic-gleichen Orders, zwei getrennte
Manager haetten sich gegenseitig storniert - sporadisch und im Log kaum
erkennbar. Deshalb EIN gemeinsamer Ziel-Zustand (engine._pending_ziel), der
Manager gleicht nur noch ab. Vorrang Squeeze > Signal (unabhaengig validiert,
selten; das Signal feuert dauernd, es gibt einen Positions-Slot).
Zwei additive Ergaenzungen in wave_rec._confirm_breakout: das
Bestaetigungs-Level wird auch NACH der Bestaetigung veroeffentlicht (die
Nachjagd-Bremse braucht es genau dann; pending bleibt False, Frontend
unberuehrt), und conf = die Konfidenz VOR dem Stummschalten - sonst muesste
die ruhende Order blind platziert werden.
Nachjagd-Bremse jetzt auch fuer SIG (0,20 xATR, Haertetest-gedeckt).
12 Szenarien getestet, live am Snapshot verifiziert. Snapshot-Felder
squeeze_pending_levels -> pending_levels + pending_quelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backtest_auto_signal_v3.py, voller Live-Gate-Stack (echte _build /
_confirm_breakout / _room_gate), sequentiell EIN Slot, Live-Dedup,
kanonischer Exit, Echtkosten, 80k M5, 2 Halbjahre.
A) Einstieg am Bar-Close (= heutige Market-Order): in ALLEN acht Feldern
negativ (Konf 55/65/75/85 x 2 Halbjahre). Bestaetigt die drei Vormessungen.
B) Einstieg am Bestaetigungs-Level (_pend["level"], ruhende Stop-Order):
besteht in ALLEN acht - WR 39,6 -> 53,2 %, PF 0,83 -> 2,20, und alle vier
Nachbar-Schwellen halten mit.
Haertetest Fill-Slippage (Konf>=65): +0,05 -> +0,315/+0,249 · +0,20 ->
+0,148/+0,090 (noch beidseitig positiv) · +0,31 -> +0,026/-0,031. Die letzte
Zeile ist die interne Kontrolle: bei Slippage gleich dem gemessenen
Median-Abstand (0,311 xATR) konvergiert B gegen A.
Nichts umgeschaltet. Grenzen dokumentiert: fuer SIG ist nicht verifizierbar,
wo live zwischen A und B liegt (nur 4 echte Trades); _pend verankert sich
staendig neu, eine ruhende Order muesste nachgezogen werden und faellt bei
Nicht-Platzierbarkeit auf A zurueck; _pend steht nicht im Snapshot.
Methodik-Fehler beim Bau gefunden und behoben: der erste Entwurf liess
pend["level"] nach der Bestaetigung stehen und waere bei verzoegertem Einstieg
zu einem laengst verlassenen Preis eingestiegen - sichtbar an einem
unplausiblen Bruch zwischen Konf 65 und 75. Behoben ueber ein frisch-Flag.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Vorgabe: die drei sind Rueckschau, das Dashboard soll das
Handlungsrelevante zeigen. Reiner Umzug im Markup - keine Logik beruehrt.
Die Karten werden weiterhin von render() aus dem Snapshot gefuettert und
haengen NICHT an loadStats(); ein ausgeblendeter View ist nur display:none,
die Elemente bleiben im DOM.
Noetig war eine CSS-Regel: #view-stats > .card{margin:11px 10px}. Das
Dashboard ist ein <main>-GRID mit eigenem Padding, #view-stats eine schlichte
<section> - ohne die Regel klebten die Karten randlos aneinander und
.card.wide{grid-column:1/-1} liefe ins Leere.
Verifiziert am ausgelieferten HTML (alle drei nach id="view-stats",
card-stats-live bleibt im Dashboard), keine doppelten IDs, Tag-Balance
geprueft. v=138.
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>
1) STOP-ORDER STATT MARKET (gebaut, live). engine._manage_squeeze_pending haelt
beide Box-Grenzen mit BUY_STOP/SELL_STOP bestueckt, solange der Squeeze armed
ist; trader.place_stop/cancel_pending/pending_orders neu. Groesse und SL kommen
aus denselben Funktionen wie die Market-Order, nur bezogen auf den Trigger.
OCO-Ersatz: faellt eine Seite, wird die andere im selben Tick storniert.
Der kritische Punkt bei einer ruhenden Order sind die Gates - sie waren bisher
Laufzeit-Checks im Market-Pfad. Neu: engine._squeeze_guard() als EINE Quelle
fuer beide Wege, jeden Tick neu bewertet; schlaegt ein Gate zu, werden die
Orders storniert. Market bleibt Fallback mit Nachjagd-Bremse
squeeze_max_chase_atr=0.20 (gemessen der noch positive Bereich).
Behandelt: Broker-Mindestabstand, falsche Marktseite, Toleranz 0,02 xATR gegen
Order-Churn, Log nur bei Fehleraenderung, Startup-Schonfrist. 10 Szenarien
getestet, live am Snapshot verifiziert.
2) META-LABELING (backtest_metalabel.py) - VERWORFEN. Zweitmodell auf 12
kausalen Merkmalen, Fit/Test in BEIDEN Richtungen: AUC 0,508 und 0,479 =
Muenzwurf, Kalibrierung im Top-Bucket 74 % vorhergesagt gegen 39 % real, und
8 von 12 Gewichten kippen das Vorzeichen. Die scheinbar besseren Schwellen
sind reine Handelsvermeidung und reproduzieren gegenlaeufig nicht.
23. verworfener Signal-Eingriff - deckt sich mit dem Caveat der Quelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anstoss aus der Web-Recherche ("don't chase breakouts with market orders;
place orders just beyond the breakout level"). Variante E in
backtest_squeeze_entry.py: PENDING BUY_STOP/SELL_STOP, die schon liegt
waehrend der Squeeze armed ist, und vom Ausbruch selbst ausgeloest wird -
anders als die Limit-Order wartet sie NICHT auf einen Ruecklauf.
Ergebnis (80k M5, 2 Halbjahre, sequentiell, kanonischer Exit, Echtkosten):
Level +0,05 xATR -> OeR +0,397 / +0,553 PF 2,28 / 3,06
Level +0,10 xATR -> OeR +0,355 / +0,509
Level +0,20 xATR -> OeR +0,244 / +0,426 PF 1,62 / 2,25
gegen Market/Live -0,158 / -0,006. Selbst mit dem ~9-fachen Median-Spread
als unterstellter Fill-Slippage bleibt es beidhaelftig klar positiv.
Kernpunkt: nicht der Median-Abstand toetet den Edge, sondern der SCHWANZ
(live Median +0,306 xATR, Mittel +0,741, Max +4,339). Eine Stop-Order
deckelt den Einstiegspreis konstruktiv, die Market-Order auf dem 5-s-Poll
nicht. Die Extremfaelle stammen aus blockiert-dann-freigegebenen Ausbruechen.
NICHT gebaut - die Guards (Nacht/News/Cooldown/flat) wirken heute als
Laufzeit-Checks und muessten mit einer ruhenden Order ueber Platzieren/
Stornieren durchgesetzt werden; dazu MT5-Mindestabstand und Storno beim
Klaeren des Squeeze.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Validierung nie unterstellt hat
backtest_breakout_squeeze.py steigt AM LEVEL ein. Live schickt
_check_auto_squeeze eine MARKET-Order - aus 34 echten Entries (Logs
16.07.-05.08., Level aus der Log-Zeile x Einstiegspreis aus der DB) liegt der
Einstieg im Median +0,306 xATR ueber dem Level, nur 18 % innerhalb 0,10.
Gemessen (backtest_squeeze_entry.py, 80k M5, 2 Halbjahre, sequentiell EIN
Slot, kanonischer Exit, Echtkosten): allein der Einstiegspreis dreht das
Setup - OeR +0,456 -> -0,158 (H1) und +0,611 -> -0,006 (H2), WR 56 -> 37 %.
Ordnet den B4-Befund vom 01.08. neu ein: dort wurde die Luecke zwischen
Mechanik (+0,102) und Live (-0,242) dem EXIT zugeschrieben. Die Mechanik-Zahl
unterstellt aber denselben Level-Einstieg - es war ueberwiegend der ENTRY.
Beide naheliegenden Reparaturen fallen durch (Regel vorab fixiert):
Abstands-Bremse 0,10-0,40 xATR alle 5 durch (die NAHEN Ausbrueche sind pro
Trade die schlechteren - Fehlausbruch-Effekt), LIMIT/Retest am Level in allen
5 Varianten schlechter als Market.
Nichts abgeschaltet - der Befund staerkt die bereits fixierte
B5-Abbruchregel, die Entscheidung bleibt beim User.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1) LLM-Failover (core/agent.py): ein hart gescheiterter Provider wird zeitweise
uebersprungen, analyze() nimmt den naechsten aus der Kette. Hart = 401/402/403/
404 (Key/Guthaben/Modell) -> 30 min, nicht erreichbar -> 5 min. Timeout/429/5xx
loesen BEWUSST keinen Wechsel aus (voruebergehend; sonst kostet jede Lastspitze
die volle Timeout-Summe aller Anbieter). Neu im Snapshot: agent.provider_dead
mit Restminuten - der DeepSeek-Ausfall stand vorher nur im Log und blieb
deshalb 18 h unbemerkt. 9 Szenarien getestet.
2) Einsatz-Prozentfeld (web, v=137): margin_buffer_pct hatte bisher keine UI.
Neues Feld "Einsatz %" neben "Einsatz EUR", POST /api/marginpct ->
engine.set_margin_pct -> config.set_margin_buffer, Snapshot margin_pct,
neustart-fest. Der feste EUR-Betrag hat Vorrang; das Prozentfeld wird dann
ausgegraut, damit nicht unklar bleibt was gilt. Auf 1-99 % geklemmt.
Ende-zu-Ende getestet (50, 150->99, 0 und -5 abgelehnt, 95, persistiert).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DeepSeek liefert seit 04.08. 14:52 durchgehend HTTP 402 "Insufficient
Balance" - 29 Fehlversuche. Alle konfigurierten Provider real getestet:
zai/glm-4.5-flash OK in 2,3 s (kostenlos), kimi-k2.6 OK in 7,6 s
(kostenpflichtig), deepseek 402, ollama nicht konfiguriert.
Gewechselt auf zai: kostenlos, schneller als DeepSeek, im Projekt schon
fuer daily_levels im Einsatz, und der _has_cjk-Retry deckt es ab. Live
verifiziert nach Neustart ("[zai] NEUTRAL (30%)").
Nebenbefund, dokumentiert aber NICHT behoben: die Fallback-Kette
deepseek->kimi->zai->local hat nicht gegriffen, weil _active_provider in
avail nur das Key-FORMAT prueft, nicht ob der Key noch funktioniert. Ein
Provider ohne Guthaben gilt als verfuegbar und blockiert die ganze Kette -
der Copilot lief ~18 h still ins Leere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
