010007f7a3c823fedcea49ae091223045a1d7c1e
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Axel HocksandClaude Opus 5
|
010007f7a3 |
Exit-Abstand aus M15-ATR gemessen = faellt durch, Exit bleibt am M5-ATR
Zweiter Teil der M15-Idee: M5-Einstieg behalten, nur den Exit groeber fuehren.
Schliesst zugleich den seit 31.07. in core/trailing.py offenen Punkt
("bisher misst er nur M5").
M5-ATR (heute) H1 +0,219 / PF 1,41 / Worst -2,17
H2 +0,117 / PF 1,25 / Worst -2,23
M15-ATR H1 +0,096 / PF 1,14 / Worst -4,26
H2 +0,019 / PF 1,02 / Worst -6,73
Schlechter in BEIDEN Haelften und das Tail-Risiko verdreifacht sich. Dasselbe
Muster wie bei backtest_sl_basis.py.
Zwei Methoden-Fallen, die die Messung fast entwertet haetten:
1) simulate() normiert R mit DEMSELBEN ATR, den es fuer SL/Trail/TP nutzt. Mit
dem 1,86x groesseren M15-ATR waere dieselbe Dollar-Bewegung ein kleineres R -
die M15-Variante haette mechanisch schlechter ausgesehen. Beide werden
deshalb in M5-Risikoeinheiten zurueckgerechnet.
2) Der erste Lauf sammelte die Entry-Liste ueber exit_fn - das wird von scan()
bei JEDEM Box-Ausbruch gerufen, nicht nur bei den komprimierten: 519 statt
132 Einstiege, also die Kontrollgruppe statt des Squeeze. Behoben ueber den
additiven Rueckruf on_entry(j, d, lvl, atr, komprimiert) in
core/squeeze_scan.py; Bitgleichheit weiter durch tests/test_squeeze_scan.py
belegt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
b5eff2a5d6 |
Squeeze auf M15 gemessen = faellt durch, kein M15-Modul gebaut
User-Wunsch nach einem M15-Empfehlungsmodul. Der Squeeze ist der einzige beidhaelftig validierte Einstieg, gemessen auf M5 und M1, nie auf M15. DIE KONTROLLE HAT ZUERST VERSAGT - und das war der wichtigste Teil. Meine M5-Kontrolle lieferte -0,133/+0,044 statt der dokumentierten +0,124/+0,292. Ursache: allein der ATR-Floor. mein Ansatz (0,542xMedian) = 0,060 = 0,54x Median -> -0,108 / +0,036 dokumentiert = 0,120 = 1,08x Median -> +0,224 / +0,087 max_hold war irrelevant. Ich hatte auf M15 einen halb so strengen Filter angelegt wie auf M5 - der relative Floor aus backtest_squeeze_multi.py diente dort der Vergleichbarkeit zwischen INSTRUMENTEN, nicht zwischen Zeitebenen. Deshalb ueber die ganze Floor-Spanne gemessen statt einen Wert zu waehlen: 0,50 H1 -0,253 (n=143) H2 -0,024 0,75 H1 -0,290 (n=108) H2 +0,047 1,00 H1 -0,030 (n= 39) H2 +0,086 1,08 H1 +0,216 (n= 33) H2 +0,080 <- M5-aequivalent 1,25 H1 -0,309 (n= 16) H2 +0,097 1,50 H1 -0,279 (n= 7) H2 +0,151 Die einzige beidhaelftig positive Zelle hat n=33 in H1, und BEIDE Nachbarn kippen. Vorab fixierte Regel verfehlt: Rauschen, exakt das ORB-Muster. Dazu: alle sechs Nachbar-Kombis sind mit den Live-Parametern in mindestens einer Haelfte negativ, die Kontrolle "beliebige Box" ist BESSER als der Squeeze, und der Slippage-Haertetest verschlechtert monoton. Struktureller Grund in der n-Spalte: bei wirksamem Filter bleiben in H1 nur 33-39 Ausbrueche. Der Squeeze feuert auf M5 2-3x/Woche; M15 ist zu grob. Positiv-Befund: Median Spread/ATR auf M15 gemessen 0,104 - besser als die erwarteten 0,133 (M5 0,193, M1 0,319). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
abd5dc0cb8 |
Echtes CME-Volumen (CL=F) gemessen: traegt nicht mehr als die CFD-Tick-Zaehlung
User-Idee eines Volumen-Spike-Alerts. Berechtigte Frage dahinter: das Projekt kennt nur tick_volume vom CFD - eine Zaehlung von Preisaenderungen bei einem Market-Maker-Broker, kein gehandeltes Volumen. Echtes NYMEX-Volumen waere die erste Datenquelle, die NICHT aus dem Preis abgeleitet ist. Beide Quellen auf DEMSELBEN Fenster gemessen (28.05.-07.08., 13.855 CME- gegen 14.178 CFD-Bars), gleiche Methode, Ueberschuss ueber die Drift, zwei Haelften. Bewusst nicht gegen den dokumentierten Wert gestellt - genau dieser Vergleich (kurzes Fenster gegen Langfrist-Mittel) war am 07.08. der Messfehler. Volumen CME H1/H2 CFD H1/H2 1,5-2,0x +0,116 / -0,203 -0,011 / +0,152 2,0-2,5x -0,221 / -0,282 -0,101 / +0,589 >=2,5x +0,102 / +0,096 -0,267 / -0,881 Trefferquote in ALLEN Zellen 44-53 % - Muenzwurf, in beiden Quellen. Kein monotoner Zusammenhang, Vorzeichen kippen. Die einzige beidhaelftig konsistente Zelle (CME >=2,5x) ist mit [-0,234 ... +0,428] bzw. [-0,265 ... +0,461] klar Rauschen. EHRLICHE GRENZE: meine CFD-Kontrolle reproduziert den alten Befund (-0,117/-0,204) NICHT - Populations-Unterschied, kein Widerspruch. backtest_candles.py mass bedingt auf ein Kerzen-MUSTER, hier laeuft es unbedingt ueber alle Kerzen. Der alte Befund gilt weiter fuer seine Population. 60 Tage = ein Regime (yfinance-Deckel), also nur ein Ausschluss-Urteil moeglich. Konsequenz: kein Volumen-Spike-Signal. Die Datenquelle funktioniert, sie traegt nur keine Richtungsinformation. Telegram-Kanaele als Eingabe (Bookmap/ATAS) ohne Messung verworfen: sie transportieren Screenshots. Ein Orderbuch-Zustand ist vorbei, sobald ihn jemand abfotografiert. Nebenbefund zum eingereichten Skript: das .iloc[0]-Muster ist KORREKT (MultiIndex-Spalten), nicht wie von mir zunaechst vermutet ein Fehler. Echte Maengel: kein Dedup, kein Handelszeit-Gate, voller Tagesabruf im 60-s-Takt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
56a3fe31d8 |
VWAP-Baender auf M15 gemessen = verworfen (24. Signal-Eingriff)
User-Wunsch nach einem M15-Daytrading-Modul auf Profi-Methodik. Abgleich: fast
alles aus dem Werkzeugkasten ist hier schon durchgefallen (Volume Profile,
Liquidity Sweeps, Market Structure, ORB, RSI/MACD, Inter-Market);
Footprint/CVD/DOM existieren nicht (Market-Maker-Broker). VWAP war die EINZIGE
nie gemessene Zutat.
Gemessen: 26.000 M15-Bars, session-verankert auf den Berliner Kalendertag,
2 Haelften, kanonischer Exit, Echtkosten, Fill bei Beruehrung.
ZUERST DER EIGENE FEHLER: der erste Lauf zeigte Reversion mit OeR +0,13 bis
+0,27 und PF bis 1,71 in beiden Haelften - verdaechtig sauber. Das Band an Bar i
wird MIT Bar i berechnet, und getestet wurde, ob genau diese Bar es beruehrt.
Ein Ausschlag zieht das Band zu sich hin und erzeugt seine eigene Beruehrung.
Mit Band aus i-1 bleibt:
k=2,0 +0,130/+0,130 -> +0,041/-0,009
k=2,5 +0,189/+0,235 -> +0,046/+0,087
k=3,0 +0,162/+0,272 -> +0,024/+0,010
Der Look-ahead war 0,10-0,25 R wert.
Alle drei vorab fixierten Kriterien verfehlt:
(b) Eine WILLKUERLICHE Linie gleicher Distanz haelt in 9 von 10 Zellen
genauso gut oder besser (VWAP 70,3-75,1 %, Zufall 73,9-76,6 %) - der
Fibonacci-Befund reproduziert.
(c) k=2,0 kippt in H2, also der Nachbar der besten Zelle. Und alle sechs
95-%-Bootstrap-Intervalle enthalten die Null (beste Zelle k=2,5 H2:
+0,087 [-0,012 ... +0,185]).
(a) Die Regel war von mir unterspezifiziert ("<= Squeeze-Box-Niveau" = 0 ist
fuer ein gleitendes Band unerfuellbar). Gemessen: Median 0,03-0,05xATR je
Bar, 90-Perzentil aber bis 0,34xATR - mehr als die Einstiegstoleranz.
Kohaerenz-Kontrolle: der Ausbruch an den Baendern ist spiegelbildlich negativ.
Reversion leicht positiv, Ausbruch klar negativ - ein stimmiges Bild.
Nichts gebaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
30c8616280 |
Gesamtempfehlung entfernt (User-Entscheidung 2026-08-08)
"Funktioniert so leider nicht, entferne es komplett - wir bauen etwas Neues."
Entfernt: Headline, Konfidenz-Ring, Bias-Nadel, Modul-Chips, Konsens-Zeile,
Block-Gruende. Dazu renderVerdict(), die zugehoerigen 24 CSS-Regeln,
docs/gesamtempfehlung.md und die Snapshot-Felder `verdict` + `block_mix`.
Die Aggregation war reine ANZEIGE - vor dem Loeschen belegt: die Order-Logik
haengt an `wave_signal` bzw. `checklist`, nicht am Verdict (Blinken app.js:821,
Order-Dialog 1312/1366/1391). Orders, Alarme und das gemessene Veto
(-6,60 EUR/Lot) sind unberuehrt.
BEHALTEN (sassen nur in derselben Karte, je eigene Beleglage, User-Entscheidung):
Zeitebenen-Ampel #wave-turns - war aus der Welle-Karte dorthin verschoben
Erwartete Spanne #kx-cone - out-of-sample kalibriert, trifft real ~77 %
Selbstkalibrierung #kx-selfcal - misst das Wellen-Signal, das bleibt
HL-Kontext #hl-note - lief in renderVerdict mit, schreibt aber in
die Meldungen-Karte
Sie stehen jetzt in der neuen, schlanken Karte "Marktkontext" (#card-kontext).
IDs von vd- auf kx- umbenannt, damit keine tote Nomenklatur zurueckbleibt.
verdict_votes wird WEITER geloggt (User-Entscheidung): `_verdict()` bleibt
bestehen und laeuft 1x/min fuer die Telemetrie sowie fuer den optionalen
MQL5-Konsens-Pfeil. Aus dem 1-s-Snapshot ist es raus - dort waere es Arbeit fuer
eine Anzeige, die es nicht mehr gibt.
Verifiziert: node --check gruen, 34 Tests gruen, 0 verwaiste $("id")-Zugriffe
(die zwei Treffer 'neu'/'x' stehen in Kommentaren), CSS-Klammern ausgeglichen
(287/287), @media und @keyframes intakt. Zeile 1572 (_SQM_VERDICT[d.verdict])
ist der SQUEEZE-MONITOR-Verdict und bleibt.
Asset-Version v=152.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
dd7c4e6b15 |
Notfall-Stop auf 8 % der Margin aktiviert (User-Entscheidung, gegen die Messung)
auto_emergency_margin_pct 0 -> 8. Gewaehlt wurde die MILDESTE Variante: Delta -14 EUR ueber 1022 Trades ist praktisch neutral, sie feuert bei rund 16 % der Trades. Schuetzt wenig, kostet wenig - eine Versicherung mit kleiner Praemie. Sizing bleibt ausdruecklich bei 95 % (margin_pct nicht mitgeaendert). Bezugsgroesse ist die MARGIN DIESER Position, nicht das Konto: bei ~670 EUR/Lot sind 8 % rund 54 EUR/Lot, bei den aktuellen 2,33 Lots etwa 124 EUR. Der Modus hat Vorrang vor auto_emergency_pct und auto_emergency_loss, beide bleiben 0. AKTIVIERUNG braucht einen Neustart - und die bereits offene Position bekommt den Stop auch danach NICHT. Verifiziert an engine.py:884: der Wiederherstellungs-Zweig setzt fuer ein wiedererkanntes Ticket _emergency_margin_armed_ticket = ticket und _emergency_loss auf den persistierten Wert (hier null), damit ein Neustart keine gesetzte Entscheidung ueberschreibt (Fix 2026-07-17). Der 8-%-Stop greift ab der naechsten neuen Position. Neustart daher am besten fahren, wenn das Konto flat ist. Neu im Config-Waechter (validiert = 0), damit die Abweichung sichtbar bleibt. Backup: oil_widget_config.ini.bak-2026-08-07-emergency Zurueck: auto_emergency_margin_pct = 0 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
cef6646a17 |
Verlustbegrenzung: Notfall-Stop und HTF-Flip-Close gemessen - beide durchgefallen
User-Frage nach automatischem Notfall-Close (30 %?) und alternativ einem Flip-Close bei entgegengerichtetem Trend. 1) NOTFALL-STOP. 30 % waere ohnehin wirkungslos: Einsatz 670 EUR/Lot, Median-Verlust 20 EUR/Lot = 3 % der Margin. 30 % erreichen 1 % aller Verluste. Kontrafaktisch ueber 1022 echte Trades (MAE aus M5-Bars, 87 EUR/$/Lot aus den Trades selbst geschaetzt): ohne Stop +358 EUR 3 % -293 | 5 % -639 | 8 % -14 | 15 % -416 | 30 % -331 Keine Schwelle schlaegt "gar kein Stop". Nach Einstiegsart: bei "ohne Signal" sieht 8-10 % mit +298/+290 gut aus, aber beide Nachbarn kippen (-292 / -106) -> Rauschen. 2) FLIP-CLOSE AUF DEN HTF-TREND (backtest_flipclose_htf.py) - war nie gemessen. Alle sechs Varianten in BEIDEN Haelften schlechter: BASIS H1 -548 H2 -154 M30 ab +0,0R -629 -247 M30 ab +0,5R -574 -234 M30 ab +1,0R -549 -183 M30 auch im Minus -616 -327 M30+H1 ab +0,5R -570 -222 M30+H1 auch im Minus -616 -290 Die mildeste Variante ist die, die kaum feuert - exakt das Muster der 15-Minuten-Regel. Kontrolle: die Basis (-548/-154) reproduziert backtest_flipclose2.py (-537/-140), die Pipeline ist in Ordnung. Methodik: feste, geteilte Entry-Liste ueber alle Varianten. backtest_flipclose2.py laeuft nach jedem Exit bei xb+1 weiter, wodurch jede Variante eine andere Trade-Folge bekommt (der am 31.07. bei backtest_exit_combo.py korrigierte Fehler). Hier von vornherein vermieden. Mechanismus in allen Faellen derselbe: Trefferquote steigt (38->44 %, 42->51 %), Ertrag faellt = Gewinner-Kappen. Fuenfte unabhaengige Messung dieser Klasse, alle negativ. Nichts gebaut. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
59e9498237 |
G/V-Lag: 1-s-Fallback + ehrlicher Verbindungspunkt (v=151)
Zuerst gemessen, dann gedreht - und das Backend war NICHT das Problem: /api/snapshot 75 Abrufe in 20 s -> 21 verschiedene ts = ~1/s WebSocket-Push direkt am Socket gemessen: Median 1,04 s (min 1,00 max 1,06) G/V-Aenderungen Ø 1,44 s - das ist der Markt, keine Verzoegerung Die ganze Server-Kette liefert bereits 1 s. Der Lag entsteht erst am Handy: bricht der WebSocket STILL weg (WireGuard-Aussetzer, App-Wechsel), traegt nur noch der REST-Poll - und der stand auf 4 s. POLL_MS 4000 -> 1000, aber mit Sperre: solange der WS liefert (lastWsMs, Fenster WS_FRISCH_MS=2200 ms), ueberspringt der Poll den Abruf. Kein zusaetzlicher Verkehr im Normalfall. Denkfehler, den erst die Simulation zeigte: der erste Entwurf las die WS-Frische aus lastRecvMs (jede Quelle) - damit drosselte sich der Poll SELBST und kam bei totem WS nur auf 2,9 s statt 1 s. Jetzt zwei getrennte Uhren. Simuliert: WS gesund -> 0 Zusatz-Abrufe, max. Alter 0,9 s. WS tot -> 1/s, max. Alter 0,9 s. WS traege (5 s) -> max. 2,9 s. Vorher bei totem WS: 4,0 s. Der Verbindungspunkt log: er wurde nur bei sock.onclose auf "off" gesetzt, aber genau der Fall, der den Lag erzeugt, feuert KEIN onclose - der Socket haengt still, der Punkt blieb gruen. Neu .dot.stale (bernstein, pulsierend) ab 3,5 s ohne frischen Snapshot: gemessen wird, was ANKOMMT, nicht was der Socket ueber sich behauptet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
c445c687f5 |
Streu-Datei 'start_server.bat)' entfernt
Entstand versehentlich beim Testen (unmaskierte Klammer in einer Shell-Zeile) und wurde im vorigen Commit mit eingecheckt. Kein Inhalt von Belang. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b14d81f412 |
restart_server.bat prueft jetzt auch - und zwei cmd-Fallen dabei behoben
Korrektur meiner eigenen Einordnung von vorhin: ich hatte restart_server.bat als "Wiederanlauf-Pfad" ausgenommen. Falsch. Die Aufgabenplanung startet start_server_hidden.vbs -> start_server.bat; restart_server.bat wird von NICHTS automatisch aufgerufen (geprueft) und ist damit ein absichtliches Deployment. Es prueft jetzt vor dem Kill, Notausgang --ohne-pruefung. Nur start_server.bat bleibt ungeprueft - das ist der echte Wiederanlauf-Pfad. Zwei cmd-Fallen, beide NUR durch den Positiv-Test gefunden: 1) `if errorlevel 1` innerhalb eines geklammerten if/else-Blocks wird zur PARSE-Zeit ausgewertet, nicht zur Laufzeit. Der erste Entwurf brach deshalb auch bei SAUBEREM Code ab - der Neustart haette nie mehr funktioniert. Behoben mit Sprungmarken statt Klammer-Bloecken. 2) `echo ... ^(x^)` maskiert im Block anders -> "Der Befehl [0] ist falsch geschrieben". Text jetzt ohne runde Klammern. Der Negativ-Test allein sah in beiden Faellen voellig in Ordnung aus: kaputter Code -> Abbruch, Server unangetastet, Exit 1. Erst der Positiv-Test hat es entlarvt. Eine Sperre muss man in beide Richtungen pruefen. Alle drei Zweige verifiziert (sauber -> weiter/rc 0, kaputt -> Abbruch/rc 1, --ohne-pruefung -> weiter/rc 0), gegen eine Attrappe, deren Kill/Start durch ein echo ersetzt ist - so liess sich der Durchlauf-Zweig pruefen, ohne den laufenden Server anzufassen. Auch der Testaufbau hatte einen Fehler: die Attrappe lag zuerst in %TEMP%, dort macht `cd /d "%~dp0"` das Temp-Verzeichnis zum Arbeitsordner und %~dp0tools\pre_commit.py existiert nicht -> scheinbarer Fehlschlag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
0ab79f1876 |
Code-Pruefung ans Deployment haengen, nicht nur an den Commit
User-Frage "wird die Pipeline bei jedem Deployment ausgefuehrt?". Antwort war NEIN: git commit check_nfalle + pytest (Hook installiert) tools/deploy.py prueft nur den LAUFENDEN Server, nicht den Code restart_server.bat gar nichts Aufgabe OilTradingServer -> start_server_hidden.vbs gar nichts Commit und Deployment sind zwei Ereignisse und fallen beliebig auseinander: eine geaenderte, nie committete Datei ging ueber restart_server.bat ungeprueft live; nach einem Reboot startet die Aufgabe, was auf der Platte liegt. "Der Server kommt hoch" ist kein Ersatz: die beiden log.-NameError in core/trader.py sassen MONATE in except-Zweigen (einer seit dem Initial-Commit), und der Server startete jedes Mal sauber. deploy.py bekommt Schritt 0: check_nfalle + pytest VOR dem Kill, bei Rot Abbruch mit Rueckgabecode 1. Die Reihenfolge ist der Punkt - ein laufender, funktionierender Server darf fuer kaputten Code nicht abgeschossen werden. Notausgang --ohne-pruefung. Beide Richtungen verifiziert: mit eingebautem F821-Fehler -> ABBRUCH, Exit 1, Server-PID vorher/nachher identisch (20892), der Prozess wurde nachweislich nicht angefasst. Ohne Fehler laeuft es durch. BEWUSST NICHT in restart_server.bat und die Aufgabenplanung - das sind WIEDERANLAUF-Pfade. Wuerde ein fehlschlagender Test dort den Start verhindern, staende eine offene Position ohne Trailing, Time-Stop und Notfall-Stop da, nur mit dem Broker-SL. Eine Pruefung, die den Bot offline laesst, ist schlimmer als der Fehler, den sie sucht. Der Batch gibt stattdessen einen Hinweis aus und verweist auf deploy.py. Regel: absichtliches Deployment blockieren, Wiederanlauf niemals. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3f1f19087d |
Live-Backtest-Vergleich in die Pipeline: core/stichprobe.py + Abschnitt E
Konsequenz aus dem Messfehler vom 07.08.: der Vergleich lief nur, wenn jemand
daran dachte - und als er lief, war er falsch gebaut.
1) core/stichprobe.py - die Praevention ist KONSTRUKTIV, nicht ermahnend:
entkoppeln() / anteil_ci() / unterscheidbar() / schluessel_level_stunde().
Regel: vor jeder berichteten Rate entkoppeln, jede Aussage ueber einen
Unterschied mit Konfidenzintervall belegen. Die Zeilen in
pbreak_predictions und recommendations sind nicht unabhaengig.
8 Tests, darunter einer, der die reale Konstellation nachspielt
(roh 77 %, entkoppelt 33 %).
Fallstrick beim Bau, gefunden weil ich es laufen liess: ein sqlite3-Cursor
liefert Tupel, keine dicts - die Feldangabe akzeptiert jetzt Namen UND
Spaltennummern.
2) analyze_divergence.sec_d0 war selbst der Fehler. Es mittelte AVG(p_break)
ueber ALLE Rohzeilen und flaggte bei Delta > 8 Pp:
vorher 1058 rohe Zeilen, Delta +8,7 Pp -> ALARM
jetzt 110 entkoppelte, 37,6 % liegt in [37,3 ... 55,5] % -> OK
Der Waechter haette heute also einen Fehlalarm produziert - genau den, dem
ich elf Hypothesen lang nachgegangen bin.
3) NEU: Abschnitt E "GLEICHES FENSTER" (--backtest). Rechnet den Backtest ueber
genau den Live-Zeitraum und haelt ihn gegen das Intervall der entkoppelten
Live-Rate. Erster Lauf: live 46,4 % [37,3 ... 55,5] gegen Backtest 43,9 %
-> im Intervall, kein Befund.
4) Eingebaut in den Wochenreport (weekly_review._divergenz_section, montags
07:30 per Mail + Telegram), mit demselben Fail-safe wie der
Squeeze-Abschnitt. Bewusst NICHT in den pre-commit-Hook: der braucht MT5 und
Minuten, Stufe 1 muss bei ~5 s bleiben.
Ausserdem ein Rechenfehler in meinem ersten Entwurf behoben (p_break steht in
der DB bereits in Prozent, ich hatte zusaetzlich skaliert -> "3763,9 %") und
ein \n-Heredoc-Fall, der genau gegen die dokumentierte Regel verstiess.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
1f58049049 |
Die "Basisraten-Luecke" war ein Messfehler - meiner. Aufgeloest.
Nach elf einzeln gemessenen Hypothesen: es gab keinen Fehler im System. Die
14,1 Pp (Backtest 38,6 % gegen live 52,7 %) entstanden, weil ich eine
GECLUSTERTE 6-Tage-Stichprobe gegen ein 208-Tage-Mittel gehalten habe.
Zeitraum Backtest auf 03.-07.08. eingeschraenkt: 38,6 -> 43,4 % +4,8 Pp
Clusterung live entkoppelt (max 1 je Level/Stunde): 52,7 -> 45,2 % -7,5 Pp
Rest +1,8 Pp
Entkoppelt: live 45,2 % [KI 35,5 ... 54,8] gegen Backtest 43,4 % - der
Backtest-Wert liegt IM Intervall. Kein belegbarer Unterschied.
Das ist exakt der Fehler, den ich am selben Tag in der Faelligkeitsbedingung
korrigiert hatte (800 rohe statt entkoppelte Vorhersagen) - und ich habe ihn in
der Auswertung selbst noch einmal gemacht. Regel: bei pbreak_predictions immer
entkoppeln, bevor eine Rate berichtet wird.
Was bleibt:
Basisrate "gewandert 37,8 -> 53,2 %" ZURUECKGEZOGEN
Kalibrierungsfehler BLEIBT: 14,3 Pp entkoppelt,
KI [6,8 ... 25,5], Modell sagt 38,1 %,
real 45,2 % -> ~7 Pp Unterschaetzung
"oberste Klasse invertiert" NICHT belegt (beruhte auf n=29 rohen
Zeilen = wenige unabhaengige Faelle)
AUC unveraendert unentschieden
Konsequenz: nichts umbauen. Die Stichprobe ist fuer eine Reparatur zu klein -
genau deshalb steht die Faelligkeit jetzt auf 350 entkoppelten (Stand 93).
Die elf Hypothesen, alle gemessen: Niveau-Drift, Regime-Merkmal, Vola-Regime,
aktuelles Regime, Sammelart, ATR-Floor, Level-Auswahl, Beruehrungs-Erkennung,
Timeout, Auswertungs-Aufloesung M1/M5, Richtungsquelle.
Zwei Kontrollen bestaetigen die Werkzeuge: mein M1-Nachspiel reproduziert die
Live-Auswertung zu 100 %, und pb_levels30 ist live befuellt - der M5-Fallback
ist nicht aktiv.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
aefac274d3 |
Level-Auswahl: Nachbau behoben (core/sr_levels.py) - Luecke bleibt offen
Auftrag zum benannten naechsten Schritt: die Backtests bauten die
Live-Level-Auswahl nach, statt sie zu benutzen. Drei echte Abweichungen:
1. Der Nachbau clusterte den GEMISCHTEN Rohpool (sorted(ch+cl)); live werden
ph und pl GETRENNT geclustert. Das ist exakt der Fehler, den der Live-Code
als behoben dokumentiert ("nicht vorher zusammenlegen!" - Ketten-Mega-
Cluster in dichten Zonen). Gemessen: 4,5 % aller Zeitpunkte hatten einen
anderen Widerstand.
2. Live rundet jede Linie auf 3 Stellen, der Nachbau nicht.
3. Live fuehrt Widerstand und Unterstuetzung mit getrennter Hysterese.
Geloest ueber core/sr_levels.py (cluster/linien/naechste/halten).
engine._draw_levels ruft es auf, Verhalten bitgenau unveraendert
(tests/test_sr_levels.py, 6 Tests, je 300-400 Zufallsfaelle). Der Test enthaelt
die Gegenprobe, dass der Nachbau wirklich abwich - sonst waere nicht belegt,
dass es etwas zu beheben gab.
backtest_pbreak_retrain.build_levels bleibt unveraendert (Migrations-Regel: die
daraus gefitteten Live-Gewichte duerfen sich nicht rueckwirkend verschieben).
Daneben neu: build_levels_live fuer kuenftige Fits.
ABER die Korrektur schliesst die Basisraten-Luecke nicht: 38,0 -> 38,3 %,
live 52,7 %.
Damit fuenf Hypothesen geprueft und alle widerlegt:
Niveau/Achsenabschnitt Roll-Achse faellt live durch
Vola-Regime ueber 5 Quintile flach (37,0-39,2 %)
Sammelart -1,7 Pp, falsche Richtung
ATR-Floor-Artefakt +2,8 Pp; bei live-gleichem ATR erst 40,1 %
Level-Auswahl +0,4 Pp
Nebenbefund: 53,9 % aller Backtest-Bars sitzen auf dem ATR-Floor 0,12, live nur
5,4 % - der Backtest-Zeitraum ist deutlich ruhiger. Der ATR selbst stimmt aber
ueberein (Median live 0,2167 gegen letzte 7 Tage 0,2174).
Kein Notfall: auto_sr_close ist false, das Modell schliesst keine Trades.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
2e89724368 |
P(break) Niveau-Reparatur gemessen: beide Varianten fallen durch
Folgeauftrag zur B4-Pruefung. Hypothese war: das Modell rankt brauchbar, nur
sein Niveau haengt an einer wandernden Basisrate. Geprueft wurden ein
Regime-Merkmal (ATR/gleitender Median) und ein laufend nachgefuehrter
Achsenabschnitt, Regel vorab fixiert.
collect() in backtest_pbreak_retrain.py hat dafuer einen ADDITIVEN
REG-Parameter bekommen (Default None), Ausgabe ohne ihn bitgenau geprueft
(4371 Zeilen, 0 Abweichungen).
Auf Backtest-Daten besteht die Roll-Achse (Kalib 2,61->1,95 und 10,51->3,25 Pp,
AUC leicht besser), das Regime-Merkmal faellt durch (H2->H1 schlechter).
Auf LIVE-Daten (n=921 ab 01.08.) faellt auch die Roll-Achse durch: Kalib
14,16 -> 10,64 Pp (also nicht repariert), AUC 0,531 -> 0,516 (ueber der
Toleranz), und der Nachbar n=800 kippt auf 15,14 Pp = schlechter als der
Ausgangswert.
Grund: die oberste Klasse bleibt INVERTIERT (69 % vorhergesagt, 17,2 % real).
Eine Niveau-Verschiebung kann eine invertierte Klasse nicht reparieren. Die
Ausgangshypothese ist damit widerlegt.
Drei Erklaerungen fuer die Basisraten-Luecke geprueft, alle widerlegt:
Sammelart (live 1x je Beruehrung vs Backtest jeder Bar): -1,7 Pp, falsche
Richtung
Vola-Regime: Bruchrate ueber 5 Quintile flach (37,0 bis 39,2 %)
aktuelles Regime ungewoehnlich: letzte 7 Tage Median 0,96 = normal
Der flache Vola-Befund erklaert zugleich, warum das Regime-Merkmal nichts
bringt.
Kontrolle: das Modell VOR dem 31.07. hat auf diesen Daten AUC 0,364/0,406 -
unter 0,5, also invertiert. Reproduziert exakt den Grund fuer das
Nachtrainieren.
Nichts gebaut. Naechster Schritt ist kein drittes Fitten, sondern die einzige
ungeprueft gebliebene Divergenz: die Level-Auswahl selbst (Backtest baut sie
mit pick_level/_cluster nach, live entscheidet _draw_levels).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
908e20a9d0 |
P(break) v2 live geprueft: Kalibrierung daneben, Trennschaerfe unentschieden
Faellige B4-Messung nach dem Nachtrainieren vom 31.07. (878 Vorhersagen ab 01.08.). Drei Befunde. 1) Das Skript mischte zwei Modelle. Es trennte bei der M30-Umstellung (30.07.), nicht beim Nachtrainieren (31.07.) - "GESAMT" las altes und neues Modell zusammen. Derselbe Fehler wie am 02.08. in analyze_divergence.py. Neu: MODELL_V2 mit demselben Stichtag wie die Faelligkeitsbedingung. 2) Kalibrierung messbar daneben. Die Basisrate ist gewandert: Training 37,8 %, live 53,2 %, stabil ueber vier volle Tage (51,4 / 54,1 / 56,4 / 53,8 % bei n=122-276). Ein Modell, dessen Niveau an 37,8 % verankert ist, muss in einem 53-%-Regime systematisch zu niedrig sagen - genau das passiert. Oberste Klasse invertiert (69 % vorhergesagt, 17 % real). 3) Trennschaerfe NICHT entscheidbar - und das ist der wichtigere Befund. Entkoppelt n=87, AUC 0,556, 95-%-Bootstrap-KI [0,434 ... 0,674]. Das Intervall enthaelt den Zufall (0,50) UND die Messlatte (0,654). Die Faelligkeitsbedingung zaehlte die falsche Groesse: 800 ROHE Vorhersagen, die aber nicht unabhaengig sind (dieselbe Position pendelt um dasselbe Level). Aus 878 rohen werden 87 entkoppelte - die Bedingung ueberschaetzte die Beweismenge um rund das Zehnfache und meldete "faellig", obwohl die Messung nichts entscheiden konnte. Jetzt 350 ENTKOPPELTE (halbiert die KI-Breite). Stand 87/350. Operativ kein Notfall: auto_sr_close ist seit 06.08. false, das Modell schliesst keine Trades. Es speist nur Anzeige, Chart-Linien und Copilot-Kontext. Nichts umgestellt - ein drittes Fitten derselben Bauart wuerde denselben Weg gehen; der Befund zeigt aufs Niveau, nicht zwingend auf die Rangfolge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3e8fa9fea8 |
Auffang-Element in app.js: ein fehlendes Element bricht nicht mehr den Render
Gemessen: 95 direkte $("id")-Zugriffe, 0 davon abgesichert - obwohl die Regel
"neue Elemente per const el = $(..); if (el) {..}" seit 01.08. in CLAUDE.md
steht. Eine Regel mit 0 Prozent Befolgung ist keine Regel, also loest es jetzt
der Code an EINER Stelle statt an 95.
$() gibt bei fehlendem Element ein detachiertes <span> zurueck statt null,
plus einmalige console.warn je ID (kein stiller Fallback - das war der
catch{}-Fehler in pollSnapshot).
?. war NICHT die Loesung: 80 der 95 Zugriffe sind Zuweisungen, und
$("x")?.y = v ist ein Syntaxfehler.
$streng() ist der wichtige Teil. Alle Eingabefelder sind type="number", und
leer heisst dort ausdruecklich "Stop entfernen" (sl: null). Mit dem
Auffang-Element waere .value undefined -> parseFloat NaN -> JSON.stringify
macht daraus wieder null: eine fehlende Eingabemaske haette den Broker-SL
einer laufenden Position stillschweigend geloescht. Betroffen war genau eine
Funktion (sendSltp); setSrMin/setEmg/setManualMargin/setMarginPct fangen NaN
bereits ab (geprueft, nicht angenommen).
Beide Richtungen an einem Minimal-DOM verifiziert, das eine alte index.html
simuliert: mit der alten $-Definition bricht der Render beim ZWEITEN Feld ab,
mit der neuen laeuft er durch. Der Order-Pfad bricht in beiden Faellen sauber
ab.
Asset-Version v=149 -> v=150.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
e7112e1ab6 |
JS-Syntaxpruefung: node --check als Stufe B in check_nfalle
CLAUDE.md behauptete "kein node im Env" - das stimmte nicht mehr, Node
v24.18.0 ist installiert. Die Zeile hat die Frage jahrelang falsch
beantwortet.
Gemessen an 5 realistischen Fehlern findet die alte Klammern-Balance 1,
node --check findet 5 (86 ms):
Klammer zu viel Balance ok node ok
const x = ; Balance blind
let doppelt Balance blind
const doppelt Balance blind
return ausserhalb Fkt. Balance blind
Ein Syntaxfehler in app.js bricht den GESAMTEN Render - das Dashboard
friert auf Altwerten ein. Bei 95 direkt dereferenzierten $("id")-Zugriffen
(0 davon mit ?.) ist das kein theoretisches Risiko.
Geprueft wird als MODUL (.mjs), nicht als CommonJS: als CJS haelt Node ein
top-level return fuer legal, der Browser laedt app.js aber als klassisches
Script, wo es ein Syntaxfehler ist. Verifiziert, dass das echte app.js den
strengeren Modus ohne Anpassung besteht.
Kein npm, keine package.json, kein node_modules - node --check ist die
Laufzeit selbst. Damit entsteht NICHT die Divergenz "Pruefumgebung ist nicht
die Laufumgebung" (der .ps1-BOM-Fehler, das pre-commit-Framework): Node und
Chrome benutzen denselben Parser (V8).
Drei Richtungen verifiziert:
sauber -> gruen
mit eingebautem Fehler-> Exit 1, Commit gestoppt
ohne node im PATH -> Rueckfall auf alte Pruefung, Exit 0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
fd3c7f57a5 |
Live-Code von Backtest-Skript entkoppelt: core/squeeze_scan.py
core/engine.py (squeeze_monitor) und weekly_review.py importierten
backtest_breakout_squeeze - die Abhaengigkeitsrichtung war verkehrt:
ein Fehler im Backtest konnte den laufenden Bot treffen.
Schwerer wog, WIE die Parameter hineinkamen:
BQ._N = _SQ_N; BQ._K = _SQ_K
Das mutiert Modul-Globale eines Backtests, wirkt prozessweit und damit auf
jeden anderen Nutzer desselben Moduls im selben Prozess. Die Werte weichen
real ab (Backtest _N=12, live _SQ_N=10).
Geloest ueber core/squeeze_scan.py - Parameter stehen in der Signatur.
backtest_breakout_squeeze.py leitet nur noch weiter, damit es EINE
Implementierung gibt statt zweier (der sim_run/_ema_series-Fehler).
Der Exit ist bewusst NICHT mitrepariert: exit_legacy ist eine bitgenaue
Kopie inkl. seiner Abweichungen vom kanonischen Exit (Trail 1,5 statt 1,0,
kein Lock/Time-Stop/TP, max_hold 288 statt 200). Damit misst der B4-Monitor
gegen einen veralteten Exit - separater, offener Befund. Ihn hier still
mitzuaendern haette die Vergleichsgrundlage verschoben.
Bitgenauigkeit bewiesen (tests/test_squeeze_scan.py): die alte Fassung liegt
eingefroren im Test und laeuft gegen die neue ueber 500 synthetische Reihen
x 3 Multiplikatoren. Ein Vorher/Nachher-Lauf waere ungueltig gewesen - der
Backtest zieht Bars live aus MT5, das Fenster verschiebt sich staendig.
Test selbst per Mutationsprobe geprueft: 5 von 6 eingebauten Fehlern schlagen
an, der sechste (d>0 -> d>=0) ist beweisbar aequivalent, da d nur +-1 ist.
Live-Gegenprobe auf 9000 M5-Bars: n=112, Treffer 44%, OeR +0,178, PF 1,26.
Aktivierung beim naechsten Neustart - bei offener Position kein Neustart fuer
eine verhaltensneutrale Aenderung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel Hocks
|
a35a0e7006 |
Pipeline-Stufe 1 automatisiert: requirements, pre-commit-Hook, ruff
Nach Web-Recherche zum 2026er-Python-Standard umgesetzt, aber gefiltert: von
uv/Ruff/pyproject/CI passt hier nur, was zu einer Einzelmaschine mit
GUI-gebundenem MT5 und Live-Geld passt.
(1) requirements.txt (Laufzeit) + requirements-dev.txt (Werkzeuge/Messung),
Versionen gepinnt. Bis dahin gab es GAR KEINE Liste — nach einem
Maschinenausfall waere die Rekonstruktion Raten gewesen. Per AST ueber
core/, server.py, tools/ ermittelt statt geraten.
(2) tools/pre_commit.py faehrt vor jedem Commit check_nfalle + pytest (~5 s).
Einrichten: python tools/pre_commit.py --install. Notausgang
'git commit --no-verify' ist Absicht.
Bewusst OHNE das pre-commit-Framework: dessen Nutzen ist
Werkzeug-Versionierung ueber mehrere Maschinen. Hier gibt es eine, und es
wuerde eine ZWEITE ruff-Version in einer isolierten Umgebung installieren —
genau die Divergenz 'Pruefumgebung != Laufumgebung', die heute schon einmal
zugeschlagen hat.
(3) Ruff statt pyflakes (--select F821), ganzer Scan in 2,1 s. KEIN
ruff format — das wuerde 161 Dateien umformatieren, darunter alle
Backtests, und die Migrations-Regel verletzen.
⚠ VIERTER Fall der Klasse 'Erfolg melden, wo nichts geprueft wurde', und nur
durch den Test aufgefallen: --select F821,E999 laesst ruff 0.16 komplett
abbrechen (E999 wurde entfernt, Exit 2); die Meldung geht nach stderr, und weil
ich den Rueckgabecode nicht pruefte, meldete die Stufe 'keine undefinierten
Namen' — ohne irgendetwas geprueft zu haben. Ein absichtlich eingebauter
F821-Fehler kam glatt durch den Hook. Behoben: nur F821, und Exit 2 loest jetzt
den pyflakes-Rueckfall aus.
Beide Richtungen verifiziert: mit Fehler stoppt der Hook den Commit, ohne ist
er gruen. Der Test-Commit wurde zurueckgenommen (war nur lokal, ahead 1).
Nicht umgesetzt: Gitea Actions (Runner auf derselben Maschine wie der Live-Bot,
kein Mehrwert bei 5 s Pruefzeit), Container/Blue-Green (MT5 braucht eine
Desktop-Sitzung, EINE Broker-Verbindung), mypy/ty (kaum Annotationen).
Struktureller Fund: core/engine.py importiert backtest_breakout_squeeze — ein
Backtest ist Teil des LIVE-Abhaengigkeitsgraphen.
|
||
|
Axel HocksandClaude Opus 5
|
41e527c492 |
Auto-Logon aktiv — Registry-Weg, sicherer Weg blieb wirkungslos
Endstand verifiziert: AutoAdminLogon=1, DefaultUserName=ah, DefaultDomainName=HOMEBASE, Aufgabe OilAutoLogonLock Bereit und auf autologon_lock.ps1 zeigend. Die Boot-Luecke ist damit konfiguratorisch geschlossen. ⚠ Der SICHERE Weg hat nicht funktioniert: Sysinternals Autologon beendete sich mit ExitCode 0, schrieb aber nichts — weder ueber den Dialog noch ueber die Argument-Form. Ausgeschlossen: DevicePasswordLessBuildVersion (nicht gesetzt), fehlende Elevation, haengender Prozess. Ursache ungeklaert. Aktiv ist deshalb der Registry-Weg, und damit steht das Passwort im KLARTEXT unter HKLM\...\Winlogon\DefaultPassword — lesbar fuer jeden lokalen Admin und jedes Backup-Image. Entfernen-Kommando in CLAUDE.md. ⚠ Dritter Fall derselben Fehlerklasse in diesem Skript, jetzt behoben: die Speicherart wurde aus einer stale Variable gelesen, die VOR dem Registry-Schreiben gefuellt war. Die Ausgabe widersprach sich direkt — erst korrekt 'steht jetzt im KLARTEXT', zwei Zeilen spaeter 'nicht im Klartext ✅'. Der Zustand wird jetzt nach jedem Schreibvorgang frisch gelesen. Lehre aus allen drei Faellen: eine Erfolgsmeldung muss den Zustand NACH der Aktion pruefen, nicht den davor. Offen: die Wirkung ist erst beim naechsten Reboot belegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
bdff39a278 |
Autologon: Rueckmeldung nicht mehr verschlucken, Registry-Weg als Ausweg
Zwei Fehler in meinem Direkt-Zweig, beide behoben:
(a) '& $exe ...' WARTET bei GUI-Anwendungen NICHT — das Skript las die
Registry, bevor Autologon fertig war. Jetzt Start-Process -Wait -PassThru.
(b) '$null = ... 2>&1' hat die Rueckmeldung verschluckt — genau die
Information, die zur Diagnose noetig war, wurde weggeworfen. Jetzt werden
ExitCode und Ausgabe gezeigt.
Zusaetzlich diagnostiziert: Autologon64.exe startet nur elevated (direkter
Aufruf aus einer normalen Sitzung scheitert mit 'erfordert erhoehte Rechte').
Der Windows-11-Blocker DevicePasswordLessBuildVersion ist NICHT gesetzt, war
also nicht die Ursache.
Neu als letzter Ausweg: der Registry-Weg, aber nur nach ausdruecklicher
Zustimmung und mit klarer Warnung — dort landet das Passwort im KLARTEXT unter
HKLM\...\Winlogon\DefaultPassword. Er funktioniert dafuer immer. Die
Entscheidung gehoert dem Nutzer, nicht dem Skript; das Entfernen-Kommando wird
gleich mit ausgegeben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
b35f27541f |
Autologon: Rueckfall auf den Direkt-Weg statt Sackgasse
Der Dialog-Weg ist zweimal ohne Ergebnis geblieben, weil er mit ENABLE bestaetigt werden muss. Statt den Nutzer ein drittes Mal tippen zu lassen, bietet das Skript nach einem abgebrochenen Dialog jetzt direkt an, es ohne Dialog zu erledigen (j/n) — die Aktivierung steckt dafuer in einer Funktion, die von beiden Wegen aufgerufen wird. Ausserdem ehrlicher in der Fehlerursache: ein falsches Passwort meldet Autologon nicht zurueck, das Ergebnis sieht dann genauso aus wie ein abgebrochener Dialog. Beides wird jetzt genannt statt nur eines. Mit dem echten 5.1-Parser geprueft, BOM gesetzt, Scan sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
4c8ce18a9f |
Autologon: -Direkt-Weg ohne GUI-Dialog
Der GUI-Weg fuehrte zweimal zu nichts. Diagnostiziert: der Dialog OEFFNET sich (Fenstertitel 'Autologon - Sysinternals', Prozess verifiziert), muss aber mit ENABLE bestaetigt werden — nur schliessen tut nichts. Neu: -Direkt. Autologon 3.10 nimmt Benutzer/Domaene/Passwort als Argumente; das Skript fragt es per Read-Host -AsSecureString ab (unsichtbar, nicht in der History) und ruft ohne Dialog auf. Schlaegt es fehl, nennt das Skript jetzt den wahrscheinlichen Grund je nach Weg (Dialog nicht bestaetigt vs. falsches Passwort). Abwaegung dokumentiert: bei -Direkt steht das Passwort fuer den Moment des Aufrufs in der Kommandozeile des Kindprozesses (fuer Admins kurz sichtbar). Es landet nicht in einer Datei, nicht in der Shell-History — und anschliessend als verschluesseltes LSA-Secret statt im Klartext in der Registry. Mit dem echten 5.1-Parser geprueft (0 Fehler), -Direkt als Parameter erkannt, BOM gesetzt, n-Falle-Scan sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
eccc13f2cf |
Autologon-Skript: zwei Fehler behoben, die Erfolg meldeten wo keiner war
Der erste Lauf hat NICHTS eingerichtet — weder Auto-Logon noch die
Sperr-Aufgabe. Nachgeprueft: AutoAdminLogon, DefaultUserName und
OilAutoLogonLock allesamt nicht vorhanden.
(1) $ErrorActionPreference = 'Stop' PLUS schtasks /Delete auf eine noch nicht
existierende Aufgabe: native Programme schreiben nach stderr, PowerShell
macht daraus unter 'Stop' einen Abbruch. Das Skript endete, BEVOR /Create
lief. Jetzt wird vorher per /Query geprueft.
(2) Die Erfolgsmeldung log: ein fehlendes DefaultPassword wurde als
"LSA-Secret ✅" ausgegeben — dabei war gar nichts gesetzt, weil der
Autologon-Dialog ohne Enable geschlossen wurde. Abwesenheit eines
Klartext-Passworts beweist nicht, dass der sichere Weg genommen wurde; sie
ist auch mit "nichts passiert" vereinbar. Jetzt ist AutoAdminLogon = 1 die
Bedingung, und erst danach wird ueber die Speicherart geurteilt. Ohne
aktives Auto-Logon bricht das Skript mit Code 1 ab und ueberspringt
Schritt 2.
Dazu ein Design-Fehler, der erst beim Nachdenken auffiel: die Sperre haette bei
JEDER Anmeldung gefeuert — ein ONLOGON-Trigger unterscheidet nicht zwischen
Auto-Logon und manuellem Login. 30 s nach jedem normalen Anmelden waere der
Bildschirm zugefallen. Neu: tools/autologon_lock.ps1 prueft die Systemlaufzeit
und sperrt nur, wenn der Rechner < 3 min laeuft (= Auto-Logon nach Boot).
Trocken getestet: bei 1088 min Laufzeit -> sperrt nicht.
Beide .ps1 mit BOM geschrieben und mit dem echten 5.1-Parser gegengeprueft
(0 Fehler). check_nfalle.py Stufe C2 deckt alle drei Skripte ab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
da863371d3 |
.ps1 braucht ein BOM: Autologon-Skript brach unter powershell.exe 5.1
Das Skript liess sich nicht ausfuehren — "Schliessende ) fehlt", "Zeichenfolge hat kein Abschlusszeichen". Es war KEIN Syntaxfehler: Windows PowerShell 5.1 liest .ps1 als CP1252, wenn kein BOM da ist. Aus dem Gedankenstrich werden drei Zeichen, das darin enthaltene Anfuehrungszeichen schliesst den String vorzeitig, und der Fehler kaskadiert bis zum Dateiende. Der eigentliche Punkt ist, warum es beim Schreiben nicht auffiel: das hiesige PowerShell-Werkzeug ist pwsh 7, und das liest UTF-8 ohne BOM klaglos. Die Datei war in meiner Umgebung fehlerfrei und beim Nutzer kaputt — dieselbe Divergenz-Klasse wie der Deployment-Drift, nur eine Ebene tiefer: die Pruefumgebung war nicht die Laufumgebung. Behoben (UTF-8 MIT BOM) und mit dem ECHTEN 5.1-Parser gegengeprueft (Parser::ParseFile, 0 Fehler) — nicht mit pwsh 7, das den Fehler ja gerade nicht zeigt. Dabei ein zweiter Fall gefunden und mitbehoben: scripts/send_daily_report.ps1 (Umlaute, kein BOM). Der ist zwar dormant (Microsoft.Graph-Modul fehlt), haette aber genauso gebrochen. Dauerhaft abgesichert: tools/check_nfalle.py prueft es als Stufe C2 — .ps1 mit Nicht-ASCII und ohne BOM ist ab jetzt ein Befund. .bat ist nicht betroffen: cmd.exe verzeiht das in echo/Kommentaren (restart_server.bat enthaelt Sonderzeichen, bricht aber nicht). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
47d6d1ddae |
Auto-Logon vorbereitet — verschluesselt statt Klartext, mit Bildschirmsperre
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> |
||
|
Axel HocksandClaude Opus 5
|
4cbb1f1db5 |
tools/deploy.py: Stufe 5 der Pipeline ist jetzt ein pruefbares Skript
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>
|
||
|
Axel HocksandClaude Opus 5
|
cddcefa463 |
Der Engpass war nie die Mathematik: quadratische Schleife, ~9 min -> 8,9 s
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>
|
||
|
Axel HocksandClaude Opus 5
|
9887e3d5da |
pytest-Suite: 13 Tests in ~1 s, mutations-geprueft
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>
|
||
|
Axel HocksandClaude Opus 5
|
79f3e8efe1 |
Konfidenzintervalle (scipy-Bootstrap) — und sie korrigieren den Befund vom 06.08.
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> |
||
|
Axel HocksandClaude Opus 5
|
e69907edbe |
pyflakes eingebunden — zwei echte Fehler in core/trader.py gefunden
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> |
||
|
Axel HocksandClaude Opus 5
|
394786b312 |
CLAUDE.md: die \n-Falle als Dauerregel festgehalten
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> |
||
|
Axel HocksandClaude Opus 5
|
5a89544a27 |
tools/check_nfalle.py: Scan gegen die \n-Falle — Projekt ist sauber
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>
|
||
|
Axel HocksandClaude Opus 5
|
b858ae9aa2 |
Liq-Trend und die uebrigen offenen Modul-Fragen fuer die 25.000er-Messung notiert
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>
|
||
|
Axel HocksandClaude Opus 5
|
4155afb434 |
Widerspruch "stark LONG" bei WARTEN aufgeloest (v=149)
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>
|
||
|
Axel HocksandClaude Opus 5
|
cf94679022 |
Setup- und Lauf-Zeile aus den Meldungen entfernt (v=148)
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>
|
||
|
Axel HocksandClaude Opus 5
|
caa937f87d |
Gesamtempfehlung: nur noch Module mit Stimmrecht · Tooltips ueberall (v=147)
· 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> |
||
|
Axel HocksandClaude Opus 5
|
38b493de35 |
signal_pending_entry abgeschaltet (User-Entscheidung)
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> |
||
|
Axel HocksandClaude Opus 5
|
ec6a2c5842 |
SIG-Pending faellt durch: Look-ahead 0,8 R, schlechter als der Markt-Einstieg
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> |
||
|
Axel HocksandClaude Opus 5
|
2cdd1ba0e8 |
Hyperliquid geprueft: Orderbuch-Stimme raus, Funding gemessen (traegt nicht),
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>
|
||
|
Axel HocksandClaude Opus 5
|
874ee16e00 |
Gesamtempfehlung: Selbst-Kalibrierung, voller Ausrichtungs-Split, Block-Gruende,
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>
|
||
|
Axel HocksandClaude Opus 5
|
4f85d2ce75 |
Ausrichtungs-Split ueber die ganze Historie: die Empfehlung ist ein Veto
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> |
||
|
Axel HocksandClaude Opus 5
|
7e03e481ca |
Verworfene Setups auf der Ausfuehrungs-Achse — und der Squeeze steht mit auf null
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> |
||
|
Axel HocksandClaude Opus 5
|
45bfc87153 |
Squeeze auf 9 Instrumenten · Momentum neu gemessen · Fill-Annahme korrigiert · UI
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> |
||
|
Axel HocksandClaude Opus 5
|
64eef14871 |
analyze_signal_live.py: die Richtungsaussage der Empfehlung ist ein Muenzwurf
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> |
||
|
Axel HocksandClaude Opus 5
|
58af6eba43 |
Automatischen S/R-Close abgeschaltet (User-Vorgabe)
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> |
||
|
Axel HocksandClaude Opus 5
|
217981ccf5 |
analyze_slippage_holdtime.py: die offene Zahl gemessen — M1 ist entschieden
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> |
||
|
Axel HocksandClaude Opus 5
|
92187d7d32 |
backtest_squeeze_m1.py: Squeeze auf M1 gemessen (Variante B)
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> |
||
|
Axel HocksandClaude Opus 5
|
c888bcc3e8 |
analyze_scalping_costs.py: B3-Check fuer ein M1-Scalping-Modul
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> |
||
|
Axel HocksandClaude Opus 5
|
bf838b4d03 |
analyze_squeeze_entry_gap: nur noch echte Bot-Trades zaehlen
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> |
||
|
Axel HocksandClaude Opus 5
|
3c1442109d |
Pending-Fill: Bot-Trades wurden nicht als solche gebucht
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> |
||
|
Axel HocksandClaude Opus 5
|
730219fce8 |
Wenige Empfehlungen nachgeprueft: Telemetrie-Luecke bei min_conf gefunden und
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> |
||
|
Axel HocksandClaude Opus 5
|
a1a5d560b9 |
Charts-Tab komplett entfernt (User-Vorgabe)
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> |
||
|
Axel HocksandClaude Opus 5
|
6ff3c15b1d |
Statistik geprueft: Aggregate exakt, aber die Netto-Rechnung ist um Faktor 4,7
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>
|
||
|
Axel HocksandClaude Opus 5
|
7009541c42 |
Squeeze-Trades bekommen den SL aus M5-ATR (User-Entscheidung), TP unveraendert
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> |
||
|
Axel HocksandClaude Opus 5
|
a6c43183e2 |
SL-Basis M5 vs M15 auf Level-Entries gemessen: Tail-Frage, keine Ertragsfrage
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> |
||
|
Axel HocksandClaude Opus 5
|
d8a243612a |
Gegen-Squeeze als Exit zum 3. Mal gemessen: der Mechanismus feuert praktisch nie
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> |
||
|
Axel HocksandClaude Opus 5
|
c8c3e32926 |
Trail x Breakeven gemeinsam geprueft: keine Aenderung - und ein Aufloesungs-
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>
|
||
|
Axel HocksandClaude Opus 5
|
4bc4625391 |
Auto-Flip-Close abgeschaltet (User-Entscheidung)
[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>
|
||
|
Axel HocksandClaude Opus 5
|
01e77bfb98 |
Live-Gegenprobe zum Auto-Flip-Close + Empfehlung zum Abschalten
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> |
||
|
Axel HocksandClaude Opus 5
|
71aec2e240 |
Korrektur der eigenen Verdict-Auswertung: die Gewichtung ist NICHT invertiert
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>
|
||
|
Axel HocksandClaude Opus 5
|
45c3cec5b5 |
Erste Auswertung der verdict_votes: die Gewichtung ist in der Praxis invertiert
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> |
||
|
Axel HocksandClaude Opus 5
|
a13adb891b |
Zwei neue Tabs: "SIG Live" und "SIG Anzeige", Module nach WIRKUNG sortiert
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> |
||
|
Axel HocksandClaude Opus 5
|
65e12ab264 |
Kerzen-Anatomie zum dritten Mal gemessen: alle 40 Zellen negativ
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> |
||
|
Axel HocksandClaude Opus 5
|
e55b866f29 |
Kachel "Erwartete Spanne" entfernt, Kernwerte komprimiert in die Gesamtempfehlung
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> |
||
|
Axel HocksandClaude Opus 5
|
516f1eaa7f |
Roast-Punkte 1-3: Erfolgskontrolle erweitert, flip_close sichtbar, WARTEN-Massstab
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>
|
||
|
Axel HocksandClaude Opus 5
|
90d77a2305 |
Pending-Pfad fuer SIG: ruhende Stop-Order am Bestaetigungs-Level
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> |
||
|
Axel HocksandClaude Opus 5
|
12fb11fa44 |
Auto-Signal (SIG) neu gemessen: besteht erstmals - aber nur am Level, nicht am Markt
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> |
||
|
Axel HocksandClaude Opus 5
|
43b7756df3 |
Manuelle Trades, Letzte Trades und Kurslueken in den Statistik-Tab verschoben
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>
|
||
|
Axel HocksandClaude Opus 5
|
5f70980e59 |
Erfolgskontrolle fuer den Stop-Order-Umbau: Skript + Reminder
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> |
||
|
Axel HocksandClaude Opus 5
|
5e0e8b00ca |
Squeeze-Einstieg ueber ruhende Stop-Orders + Meta-Labeling gemessen (verworfen)
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> |
||
|
Axel HocksandClaude Opus 5
|
3b00820c15 |
Loesung fuer Fall 7 gemessen: ruhende Stop-Order am Level statt Market
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>
|
||
|
Axel HocksandClaude Opus 5
|
8d93de9867 |
Deployment-Drift Fall 7: Squeeze wird zu einem Preis gehandelt, den die
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> |
||
|
Axel HocksandClaude Opus 5
|
cc4f1a0863 |
Provider-Failover bei hartem Fehlschlag + Einsatz-Prozentfeld im Dashboard
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> |
||
|
Axel HocksandClaude Opus 5
|
7e9b0196a5 |
Copilot-Provider auf z.ai umgestellt (DeepSeek-Guthaben leer)
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>
|
||
|
Axel HocksandClaude Opus 5
|
1c9bb34095 |
Auto-Squeeze-Nachtsperre von 0-7 auf 3-6 Uhr verkuerzt (User-Vorgabe)
Gemessen (backtest_cost_gate.py, Teil 2): es gibt KEINE toten Stunden - alle 24 Stunden sind in beiden Halbjahren positiv, keine ist beidhaelftig negativ. Std 0 ist sogar die staerkste des Tages (OeR +1,48/+1,51) und lag im alten Gate. Jedes Fenster kostet also Ertrag; die Sperre kauft ausschliesslich Beaufsichtigungs-Ruhe. Gewaehlt wurde deshalb nach PREIS, nicht nach Edge: 3-6 ist das guenstigste Fenster mit noch >=4 h Schutz (SigmaR -12,5/-62,9 gegen -42,4/-242,6 bei 0-7 = ~27 %). Freigegeben: 0, 1, 2, 7 Uhr. Die 4-h-Untergrenze ist gesetzt, nicht gemessen. Umsetzung: neues [trading] auto_squeeze_night_hours (Default 3,4,5,6, leer = aus), genutzt von _check_auto_squeeze und _check_auto_signal. _SQUEEZE_NIGHT bleibt als STATISTISCHE Nacht-Definition fuer Entry-Checkliste und B4-Monitor - dort gilt die Kostenfalle weiter und der Altdaten-Vergleich bleibt stabil. 7 Parse-Faelle getestet (Default, fehlender Schluessel, leer, Muell, Rueckwaerts-Kompatibilitaet). Live verifiziert am NEUEN Snapshot-Feld squeeze_night_hours = 3,4,5,6 und am Startup-Log; genau eine Instanz auf 8000. Offen und als Reminder hinterlegt: der Backtest modelliert keine Slippage, und die freigegebenen Stunden liegen in der duennsten Liquiditaet. Nach 15 Squeeze-Trades aus 0/1/2/7 Uhr gegen die Erwartung pruefen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
cdee6eced7 |
Kosten-Gate gegen Stunden-Gate gemessen: Nachtsperre ist auf falscher Population begruendet
backtest_cost_gate.py — echte _squeeze_one, kanonischer Exit, Echtkosten,
80k M5, 2 Halbjahre, geteilte Entry-Liste + sequentielle 1-Slot-Sim.
(a) Kein Kosten-Gate ersetzt das Stunden-Gate nach der vorab fixierten Regel.
(b) Das Stunden-Gate selbst kostet in BEIDEN Haelften: sequentiell SigmaR
-42 (H1) / -243 (H2) gegen "kein Gate". Die geblockten Ausbrueche sind
in beiden Haelften positiv (OeR +0,496/+0,589).
Mechanismus belegt: die Nacht-Kostenfalle ist echt (alle Nacht-Bars Median
0,333 / Mittel 0,387 xATR, reproduziert backtest_realcosts), gilt aber nicht
fuer Squeeze-Ausbrueche (0,183/0,191 = Tag-Niveau). Der Squeeze verlangt
anziehenden ATR und selektiert sich damit aus der Falle heraus. Gemessen am
Wellensignal, angewandt auf den Squeeze = Deployment-Drift Fall 6.
KEINE Aenderung vorgenommen: Slippage ist nicht modelliert (groesste
Bedrohung des Befunds), die duenne Live-Stichprobe sagt das Gegenteil, und
der Beaufsichtigungs-Grund ist eine Praeferenz. auto_squeeze_skip_night
bleibt true.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
c9f1e8d039 |
Zeitzonen-Bug in analyze_tageszeit.py behoben + Squeeze-Nachtsperre 05.08. dokumentiert
Zeitzone: datetime.fromtimestamp(rates["time"], UTC+3) behandelt den MT5- Bar-Zeitstempel als echten UTC-Epoch - MT5 liefert dort aber bereits die Broker-Wallclock. Jede Stunde war 3 h zu spaet einsortiert. Empirisch gegen die Wallclock geprueft (letzte Bar 11:00 statt real 08:00). Helfer _berlin() mit korrekter Konvention; Rest des Projekts war nicht betroffen (geprueft). Neu gerechnet: ALLE VIER Tagesbloecke kippen zwischen den Haelften - es gibt gar kein Tageszeit-Muster. Der zuvor gemeldete "Nachmittag robust negativ" war der um 3 h verschobene Abend. Plausibilitaetstest, der es entlarvt haette: die duennen Stunden (n~650) muessen am Marktschluss liegen, nicht nachts. Squeeze 05.08.: 5 active-Ausbrueche zwischen 02:00 und 07:30 Berlin, alle von auto_squeeze_skip_night geblockt; Bot war ab 01:15 flat, also alleiniger Blocker. Mit kanonischem Exit + Echtkosten Sigma +3,56 R (~+95 EUR), davon 92 % in zwei Trades - n=5 an einem Tag ist kein Gegenbeleg zum Guard. Messbarer Ansatz notiert: kosten- statt stundenbasiertes Gate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
d75789ac72 |
Tageszeit-Drift gemessen: Morgens-runter/Nachmittags-rauf widerlegt
analyze_tageszeit.py misst die ROHE Kursdrift je Berliner Stunde (nicht den Signal-Edge). 80k M5-Bars, DST-korrekt, 2 Halften, Ueberschuss gegen den Tagesschnitt. Ergebnis: Vormittag 08-12 kippt zwischen den Halften, Nachmittag 14-18 ist robust NEGATIV - beide Halften der Vermutung fallen durch. Groessenordnung ohnehin unter dem Spread (staerkste robuste Stunde ~0,03 $/h vs 0,0225 $ Spread). Korrektur am eigenen Skript: der erste Entwurf hatte einen ATR-Filter (< 0,06 uebersprungen) plus ATR-Normierung. Der Filter verwarf ausgerechnet die ruhigen Morgenstunden der aelteren Periode (n 138-391 statt 1740) und erzeugte so den vermeintlichen Befund. Beides entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
6af4c868bc |
Feste Einsatz-Margin (UI-Feld) + lokale Sprachausgabe via Piper
EINSATZ-FELD (User-Wunsch): Laufzeitwert MANUAL_MARGIN in core/config.py (set/get_manual_margin, Muster wie set_margin_buffer). 0 = automatisch wie bisher (margin_buffer_pct % der freien Margin), > 0 = Position wird auf genau diesen Margin-Einsatz gerechnet. - calc_lots setzt es um und DECKELT auf freie Margin x Buffer; ein zu hoher Wunschwert wird begrenzt und geloggt statt an den Broker durchgereicht. Reicht der Betrag nicht fuers Mindestlot -> 0.0 + Warnung, Trade sauber abgelehnt. - Vorrang vor dem Risiko-Modus in trader._send_locked: eine ausdrueckliche Groessenvorgabe schlaegt die Rechenregel. - Wirkt auf ALLE neuen Positionen, auch die autonomen. - UI-Feld "Einsatz" in der ORDER-Leiste (nicht in der Trade-Leiste: die ist nur bei offener Position sichtbar, der Einsatz muss vorher einstellbar sein), bernstein umrandet solange gesetzt. Enter blurrt nur, change sendet einmal. - POST /api/manualmargin, Snapshot manual_margin, neustart-fest ueber runtime_state.json. Ende-zu-Ende getestet (250 -> Snapshot -> 0 -> persistiert). - Lot-Logik isoliert geprueft: 200 EUR -> 0,58 Lots; 5000 EUR -> gedeckelt. SPRACHAUSGABE: Piper lokal (tools/speak.py). Windows-TTS funktioniert zwar, aber es ist KEINE deutsche Stimme installiert - weder SAPI5 noch OneCore (nur David/Zira/Mark, en-US); deutscher Text kaeme mit englischer Aussprache. Add-WindowsCapability scheitert ohne Adminrechte. Piper gewaehlt: laeuft lokal (passt zum Rest - WireGuard-only, Secrets in der ini, keine Cloud), kostet nichts, aus PowerShell/Python aufrufbar. Stimme thorsten-medium (de_DE), Real-Time-Faktor 0,08 (4,3 s Audio in 0,36 s). Das ZIP entpackt eine Ebene tiefer als erwartet (tools/piper/piper/piper.exe) - speak.py SUCHT Binary und Modell statt Pfade fest zu verdrahten. Der erste Entwurf scheiterte daran; der Fail-safe meldete die Pfade sauber statt stumm zu bleiben. Drei Modi getestet (Argument, Pipe, --wav). tools/piper/ ist gitignored (Binaries + 60-MB-Modell), speak.py versioniert. v=136. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
33b6b8f629 |
Letzte Trades: 5 -> 10 (User-Wunsch)
Zwei unabhaengige Begrenzungen mussten mitgezogen werden: - engine.snapshot -> history.last_closed_trades(5) -> (10) - app.js -> slice(0, 5) -> slice(0, 10) Nur eine davon zu aendern haette still weiter 5 gezeigt; beide sind jetzt gegenseitig im Kommentar vermerkt. Verifiziert: Snapshot liefert 10 Trades, v=135 ausgeliefert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
1c976cc8fd |
M30-Level-Umstellung live gegengeprueft — bestaetigt, Normierung war entscheidend
Faellige Messung aus dem Reminder (28/30 erreicht). S/R-Auto-Closes vor/nach der Umstellung der Level-Quelle M5 -> M30 am 30.07. Zeitraum n Med.Lots EUR/Lot O Move vorher (M5-Level) 89 0,81 +17,53 0,202 $ nachher (M30-Level) 28 0,53 +36,92 0,427 $ Ertrag je Lot mehr als verdoppelt, O-Kursbewegung je Trade ebenfalls - deckt sich mit der Backtest-Erwartung und mit dem Mechanismus (M30-Level liegen 1,95xATR auseinander statt 0,61xATR, der Trade laeuft laenger). DIE NORMIERUNG WAR ENTSCHEIDEND, sonst waere der Schluss falsch gewesen: unnormiert sah der 04.08. wie der Treiber aus (O +55,41 EUR je Trade gegen +19,30 im Rest). Je Lot ist heute aber praktisch identisch zum Rest (+38,81 vs +35,87) - der Unterschied war reine Positionsgroesse (Median 1,36 statt 0,46 Lots, weil das Konto an dem Tag von ~800 auf ~1.400 EUR wuchs). O-EUR-Vergleiche ueber Zeitraeume mit unterschiedlicher Positionsgroesse sind ungueltig. NICHT der Level-Quelle allein zuzuordnen: am 31.07. kamen P(break)-Nachtraining und Schwelle 0,55->0,35 dazu. Getrennt: 30.07. (nur M30-Level, altes Modell) n=8, +19,88 EUR/Lot; ab 31.07. (M30 + neues Modell) n=20, +43,73 EUR/Lot. Das Fenster mit nur der Umstellung ist zu klein. Der kombinierte Effekt ist bestaetigt, die Ursachenaufteilung nicht. Messung im measurement_reminder ausgetragen (mit Ergebnis als Kommentar). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e558a8dd5b |
Reminder: Stufe 2 "Manuelle Trades" eingetragen
Neue Messung manual_ctx im measurement_reminder: faellig bei >=300 manuellen Trades mit gefuelltem ctx_*-Kontext (Sammlung laeuft seit 04.08.). Die Faelligkeitsbedingung ist pruefbar (Zeilenzahl), nicht nur ein Datum - wie alle anderen Eintraege auch. Der cmd-Text haelt die Methode fest (Fit auf der ersten Haelfte, validiert auf der zweiten, AUC + Kalibrierung wie bei backtest_pbreak_retrain.py) UND die Einschraenkung: 300 reichen fuer eine ERSTE SICHTUNG, nicht fuer ein Urteil - mit ~150 je Haelfte und mehreren Merkmalen ist die Overfit-Gefahr hoch. Ziel bleibt ein Hinweis im Order-Dialog, ausdruecklich kein Auto-Entry. Ohne diesen Eintrag waere die Sammlung genau so liegen geblieben wie die P(break)-Genauigkeit, die 2213 auswertbare Zeilen hatte bevor jemand hinsah. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
da7d8f5b90 |
Stufe 1: voller Entscheidungskontext beim Einstieg + Karte "Manuelle Trades"
Frage: kann der Bot aus den manuellen Trades lernen? Vorpruefung: noch NICHT.
1) Die entscheidenden Merkmale wurden nie gespeichert - beim Einstieg nur 5
Felder, davon ai_sentiment in 1,4 % und news_score in 34 % befuellt.
2) Das naive Lernziel ("wann steigt er ein") braucht unbeschriftete Negative;
brauchbar ist nur "welche Einstiege liefen gut" (Labels ueber P&L).
3) Die scheinbaren Muster sind Einzeltage: Stunde 13:00 zeigt +478 EUR ueber
n=69, davon +382 EUR (80 %) aus den fuenf Trades des 04.08.
Gebaut wurde Stufe 1 - reine Telemetrie, kein Verhalten:
- trades um 16 ctx_*-Spalten erweitert (DB-Backup .bak-2026-08-04, 1.148 Zeilen
unveraendert): p_break_target/-stop, dist_res_atr/dist_sup_atr, structure,
squeeze, htf_trend/h1_trend, spread_atr, session, block_reason, conf_pct,
atr_m5, bias, cone_pos, hour
- log_trade_open haengt die Spalten dynamisch an und ignoriert unbekannte
Schluessel -> aeltere DB ohne Migration laeuft weiter (fail-open)
- Kette: engine._run_analysis -> trader.set_open_context(ctx=) -> log_trade_open
Fallstrick beim Bau: wave_snap existiert in _run_analysis NICHT (nur in
snapshot()). Der erste Entwurf haette einen NameError erzeugt, den das umgebende
except still geschluckt haette - der Kontext waere dauerhaft leer geblieben ohne
dass es auffaellt. Jetzt self.wave.snapshot(); vd zusaetzlich per locals()-Guard.
Verifiziert auf einer DB-KOPIE: alle 16 Spalten korrekt geschrieben, unbekannter
Schluessel ignoriert, Basisfelder unberuehrt. Snapshot liefert manual_stats.
Dashboard-Karte "Manuelle Trades" (#card-manual, v=134): heute / 30 Tage /
gesamt / Bot-Vergleich plus Split mit vs ohne Signal-Deckung. Backend
history.manual_stats(30) mit ~120-s-Cache wie _alignment_cached. Bewusst neutral
gefaerbt und deskriptiv; eine Reifegrad-Zeile nennt die ctx-Abdeckung (heute
0 %), damit die Karte nicht ueberschaetzt wird.
Stufe 2 NICHT gebaut: erst bei ausreichender ctx-Abdeckung messen, was Gewinner
von Verlierern unterscheidet (Fit H1, validiert H2, AUC + Kalibrierung). Ergebnis
waere ein Hinweis im Order-Dialog, ausdruecklich KEIN Auto-Entry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
7432be0e8c |
M30-Filter nach Vola-Regime geprueft — Hypothese invertiert, keine Aenderung
Anlass: Am 04.08. fiel WTI -4,12 $ (davon -4,16 $ in EINER Stunde), der Bot stand zu 93 % auf WARTEN, htf_counter blockte 160-mal. Hypothese: die nachlaufende M30-EMA sperrt in schnellen Umkehrungen das Richtige. Die Messung invertiert die Hypothese. Geblockte Signale, kanonischer Exit, Echtkosten, nach ATR-Terzil x 2 Halbjahre: Terzil geblockt H1 geblockt H2 durchgel. H1 durchgel. H2 niedrig -0,086 +0,107 -0,136 -0,134 mittel -0,172 +0,067 -0,198 -0,069 hoch -0,625 -0,329 -0,061 +0,014 Im HOHEN Terzil sind die geblockten Signale mit Abstand die schlechtesten des gesamten Datensatzes (PF 0,15 / 0,42) - der Filter ist dort am wertvollsten, nicht am schaedlichsten. Die durchgelassenen Hoch-Vola-Signale in H2 sind das einzige positive Feld der ganzen Tabelle. In den unteren Terzilen kippen die geblockten Signale zwischen den Haelften = Rauschen. Den Filter in schnellen Bewegungen zu lockern waere die schlechtestmoegliche Aenderung gewesen. 22. verworfener Eingriff. Auflösung des scheinbaren Widerspruchs: die 160 geblockten Signale und die 17 manuellen Gewinn-Trades desselben Tages sind VERSCHIEDENE Grundgesamtheiten. Die manuellen Trades liefen alle auf rec=WARTEN, stammen also gar nicht aus der Signal-Logik - der Filter hat den User nie gebremst. "Das Gate blockte X" und "der Mensch verdiente Y" gehoeren nur zusammen, wenn Y aus X stammt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
20137a3dd1 |
SL-Breite gemessen: Confounder bestaetigt, aber keine Aenderung (Regel greift)
Anlass: analyze_manual_close.py fand +1.229 EUR auf der Verlustseite, mit dem explizit benannten Confounder, dass simulate() 2,0xATR_M5 ansetzt waehrend live ATR_M15 gilt. backtest_sl_width.py trennt beides: gegatete Live-Population (1.224 Entries, Reversal aus, k=0,3), kanonischer Exit, variiert wird ausschliesslich die SL-Breite. ATR_M15 / ATR_M5 = 1,80 im Median -> der Live-SL ist rund 3,6xATR_M5 breit, nicht 2,0. Genau daraus entstanden die 1.229 EUR. Confounder bestaetigt. SL-Basis H1 OR/SR H2 OR/SR Worst H1/H2 2,0xATR_M5 -0,092 / -44 -0,024 / -18 -2,33 / -2,29 2,0xATR_M15 LIVE -0,145 / -69 +0,064 / +48 -4,77 / -5,64 1,5xATR_M5 -0,081 / -38 -0,038 / -28 -1,83 / -1,85 2,5xATR_M5 -0,121 / -58 -0,013 / -10 -2,83 / -2,79 3,0xATR_M5 -0,130 / -62 +0,018 / +13 -3,33 / -3,29 KEINE engere Variante schlaegt den Live-SL in BEIDEN Haelften - H2 bevorzugt den weiten Stop klar. Die vorab fixierte Regel ist nicht erfuellt: keine Aenderung. Das reproduziert backtest_sl_tf_mismatch.py (23.07., dort auf Squeeze-Entries mit eigenem Exit-Nachbau) jetzt auf der gegateten Population mit kanonischem Exit - der alte Schluss war korrekt. Der echte Unterschied ist das TAIL-RISIKO und damit eine SIZING-Frage: Worst-Case -5,64xATR (live) gegen -1,85xATR (bei 1,5xATR_M5), Faktor 3. Bei ATR 0,30 sind das ~1,7 $; unter 95 %-Margin auf ~800 EUR Konto ist ein solcher Trade ~19 % des Kontos. Der weite Stop kauft die H2-Performance mit genau diesem Tail. Wer ihn begrenzen will, senkt margin_buffer_pct - nicht die SL-Breite, die kostet gemessen H2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3ec4d53022 |
Frueh-Kappen kontrafaktisch geprueft — Hypothese widerlegt, Leckage liegt woanders
analyze_manual_close.py simuliert fuer jeden real geschlossenen Trade ab dem echten Einstieg den kanonischen Exit und vergleicht gegen das tatsaechliche Ergebnis. EUR-Faktor 87,6 EUR/$/Lot, robust aus 251 Trades geschaetzt (trader.pnl enthaelt Swap, direkte Rueckrechnung waere verfaelscht). Schliessgrund n IST Bot-Exit Delta manual Gewinn 143 +1428 +962 -467 sr_close Gewinn 106 +1591 +1060 -530 emergency Verlust 98 -1750 -1235 +515 sl Verlust 69 -1926 -697 +1229 Die Frueh-Kappen-Hypothese ist WIDERLEGT: das diskretionaere Schliessen kostet nichts, es bringt +467 EUR MEHR als der kanonische Exit; in 62 % der Faelle war der manuelle Close besser. Dasselbe gilt fuer den S/R-Auto-Close (-530). Beide realisieren Gewinne besser als reines Trailing. Die Leckage liegt auf der VERLUSTSEITE: die 69 per Broker-SL geschlossenen Trades haetten mit dem kanonischen Exit 1.229 EUR weniger verloren, die 98 Notfall-Closes 515 EUR weniger. Ueber alle Trades waere der kanonische Exit rund +700 EUR besser gewesen, praktisch vollstaendig aus der Verlustseite. Confounder benannt: simulate() setzt den Initial-SL auf 2,0xATR_M5, live kommt er aus ATR_M15 und ist oft deutlich weiter - unter Margin-Sizing schlaegt das voll auf den EUR-Verlust durch. Der +1.229-Wert misst also erheblich SL-BREITE, nicht Exit-Logik. backtest_sl_tf_mismatch.py hat die M5-Umstellung schon geprueft und wegen H2 verworfen; dieser Befund gibt Anlass, das mit dem kanonischen Exit zu wiederholen. Zweite Grenze: Vergleich gilt pro Trade, nicht als Kontostand-Hochrechnung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b376619663 |
Mini-Trades untersucht: Mindestgewinn-Gate erneut verworfen, Praemisse korrigiert
User-Frage: "es gibt immer noch Mini-Trades mit geringen Gewinnen, wie
verhindern wir das?"
1) Mindestgewinn-Gate mit dem NACHTRAINIERTEN P(break)-Modell nachgemessen -
Ablehnung bestaetigt, deutlicher als zuvor. Delta SR gegen minR=0:
0,1xATR -6 / +10
0,2xATR -720 / -42
0,3xATR -1136 / -157
0,5xATR -1998 / -683
0,8xATR -2887 /-1577
Monoton schlechter in BEIDEN Haelften. Uebersprungene Klein-Closes prallen am
haltenden Level ab und enden schlechter.
2) Die Praemisse stimmt so nicht. 295 Trades seit 20.07.: die 28 Gewinne <=2 EUR
bringen zusammen +21,11 EUR = 0,8 % der Brutto-Gewinne (2.770 EUR). Kein
Ertragsproblem. Entscheidend ist die Herkunft:
sr_close (Bot) n=81 Median +14,65 davon <=2EUR: 10 (+7,65)
manual (User) n=64 Median +6,37 davon <=2EUR: 18 (+13,46)
Zwei Drittel der Mini-Gewinne sind MANUELLE Closes, und der manuelle
Median-Gewinn ist weniger als die Haelfte des Bot-Medians. Die Klein-Closes
des Bots sind gemessen richtig; die Asymmetrie liegt im diskretionaeren
Frueh-Kappen. Ein Code-Gate am Bot-Exit adressiert das falsche Ende.
Keine Codeaenderung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
a172353cee |
Fibonacci-Retracements gemessen — verworfen (21. Signal-Eingriff)
Anlass: USOIL-Kommentar "ein Fibonacci-Retracement sollte den Kurs auf 79 $
druecken". Fib-Level waren im Projekt nie gemessen worden. Aufbau wie beim
P(break)-Training: Schwuenge aus M15-Pivots, Beruehrung <=0,15xATR, Ausgang
+/-0,5xATR in 12 M5-Bars, 80k Bars, 2 Halbjahre, ZWEI Kontrollgruppen.
Haltequote:
H1 H2
Fibonacci 54,3 % 54,5 %
(a) Zufalls-Level 55,7 % 53,8 %
(b) M30-Pivots 56,6 % 55,4 %
Handelbarkeit (Bounce, kanonischer Exit, Echtkosten):
H1 OR -0,168 / PF 0,71 H2 OR -0,082 / PF 0,85
Der aufschlussreichste Wert ist die Zufalls-Kontrolle: ~55 % Haltequote. Ein
BELIEBIGES Level haelt in diesem Markt in gut der Haelfte der Faelle - das ist
die Basisrate kurzfristiger Mean-Reversion, keine Eigenschaft von Fibonacci.
Damit ist auch das Selbsterfuellungs-Argument entkraeftet: dann muesste Fib
ueber der Zufallslinie liegen; es liegt darunter bzw. gleichauf.
Bestaetigt umgekehrt die Struktur-These: M30-Pivots - Stellen, an denen real
gehandelt wurde - halten in BEIDEN Haelften besser als beide gerechneten Linien.
Dieselbe Trennlinie wie beim Regressionskanal und beim P(break)-Modell:
"Linie im Chart" ist nicht "Struktur im Markt".
Zur konkreten Aussage: 79,00 ist beim aktuellen M15-Schwung (78,808 -> 82,680)
gar kein Fib-Level, sondern ein Retracement von 95 %. Die naechsten echten
Marken sind 80,29 (61,8 %) und 79,64 (78,6 %). Der kalibrierte Kegel legt 79,00
in allen drei Horizonten ausserhalb des 80-%-Bandes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
3dc56e8571 |
breakout_k mit vollem Live-Gate-Stack gemessen
Nachgeholt, was in der Vollpruefung offen blieb: die ungegatete Messung zeigte k=0,5/0,8/1,0 besser als den Live-Wert 0,3 - aber ohne min_conf, HTF-Filter und Entry-Raum. backtest_breakout_gated.py schliesst die Luecke mit den ECHTEN Methoden (_build, _confirm_breakout-Mechanik, _room_gate mit kausalen M5-Pivots). k=0,0 H1 -0,173/-193 H2 +0,003/ +7 k=0,2 H1 -0,185/-149 H2 -0,012/ -16 k=0,3 H1 -0,160/-122 H2 -0,036/ -47 (LIVE) k=0,5 H1 -0,127/ -85 H2 -0,041/ -47 k=0,8 H1 -0,101/ -54 H2 -0,012/ -11 k=1,0 H1 -0,096/ -45 H2 -0,016/ -12 Bestaetigt: k=0,5/0,8/1,0 schlagen 0,3 in BEIDEN Haelften, die Nachbarn halten mit, und die OR verbessert sich in H1 monoton - also nicht nur Handelsvermeidung. Die vorab fixierte Regel ist erfuellt. TROTZDEM keine Umstellung empfohlen, und der Grund ist kein Messfehler sondern eine Zweckfrage: alle Werte bleiben negativ (PF 0,70-1,01), das Gate begrenzt Schaden statt Edge zu erzeugen; der Auto-Signal-Pfad ist ohnehin aus, das Signal ist ein Vorschlag fuer den Menschen, und dessen gemessener Vorteil entstand auf der k=0,3-Population; k=0,8 kuerzt die Empfehlungen um ~39 % und treibt den WARTEN-Anteil weiter hoch, der mit 93 % ohnehin im Fokus steht. Zwei benannte Abweichungen der Simulation: - _confirm_breakout misst seinen Timeout mit time.time() gegen 3600 s. Im Bar-Loop vergeht keine Wall-Clock-Zeit, der Timeout wuerde nie feuern. 3600 s sind auf M5 exakt 12 Bars, so wird gezaehlt. Merke: jede time.time()-Messung im Live-Code ist in einer Bar-Simulation stumm. - hour=None, weil die EIA-Pruefung in _build ueber datetime.now(_BERLIN) laeuft - mit Bar-Stunde wuerde ein Lauf am Mittwoch 15:30-16:30 alle Bars blocken. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
80a5be7fe5 |
Vollpruefung aller 87 Skripte + Nachrechnung der verworfenen Modelle
Phase 1 - Lauffaehigkeit: 87 von 87 Skripten laufen fehlerfrei (8000 Bars, Timeout 900 s). Kein Defekt durch die heutigen wave_rec-Aenderungen. Werkzeug: run_all_backtests.py, probiert die uneinheitlichen Aufruf-Signaturen adaptiv durch (Bar-Zahl / TF+Bars / zwei TFs+Bars). Phase 2a - breakout_k: die dokumentierte Begruendung REPRODUZIERT NICHT. k=0,3 war mit dem LEGACY_BE10-Exit (Breakeven 1,0) validiert. Erstmals mit dem kanonischen Exit nachgerechnet (backtest_breakout_canon.py, echte _confirm_breakout-Mechanik, 80k M5, 2 Halbjahre, Echtkosten): k=0,0 H1 -0,180/-569 H2 -0,054/-250 k=0,3 H1 -0,170/-356 H2 -0,069/-217 (LIVE) k=0,5 H1 -0,142/-262 H2 -0,074/-208 k=0,8 H1 -0,112/-166 H2 -0,032/ -73 k=1,0 H1 -0,101/-130 H2 -0,004/ -8 k=0,5/0,8/1,0 schlagen den Live-Wert in BEIDEN Haelften (bis +226/+209 SR). TROTZDEM keine Aenderung empfohlen: (a) alle Werte negativ (PF 0,70-0,99), es ist eine Wahl zwischen Verlusten; (b) Optimum lag am Rand -> Gegenprobe bis k=3,0 zeigt kein sauberes Optimum (H2: -8 -> -17 -> -20 -> -19); (c) gemessen wurde das UNGEGATETE Signal, live laufen min_conf/HTF/Entry-Raum davor. Naechster Schritt waere eine gegatete Neumessung, bevor ein Gate angefasst wird, das 63 % der WARTEN erzeugt. Phase 2b - verworfene Modelle bei vollen Bars: ALLE bleiben verworfen. 14 Klassen (ORB, Doppeltop, Volume Profile, Liquidity Sweeps, Konsolidierung, Handbuch-Level, Marktstruktur, Momentum, Inter-Market, Chop-Gate, Reversal-Lockout, S/R-Close-Signal, MACD/ADX/RSI, HTF-Winkel) - keine kippt ins Positive. Bei ~14 Tests waere bei 5 % Fehlalarmquote ein falsch-positives Ergebnis zu erwarten gewesen; es gab keins. Regel vorab fixiert. Kein Freibrief fuer regelmaessiges Nachrechnen - die Begruendung gegen woechentliche Laeufe steht unveraendert. Anlass war die einmalige Signalaenderung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
9e6e81dd34 |
Backtest-Audit: alle 87 Skripte geprueft
Lauffaehigkeit in Ordnung: alle 87 kompilieren, 12 repraesentative (alle die
WaveRecommender konstruieren) laufen fehlerfrei. Die heutigen wave_rec-
Aenderungen brechen nichts - der Modul-Default _reversal_enabled=True haelt die
Altmessungen stabil. Drei Skripte nehmen [TF] [N] statt einer Bar-Zahl als
erstes Argument (signal/pullback/htf_filter); mit einer Zahl als TF gibt es
KeyError. Kein Defekt, nur die Signatur beachten.
angle=-Befund: 11 Skripte, NICHT 26.
Methodik-Fehler bei mir selbst, korrigiert: die erste Pruefung per Regex
(_build\([^)]*angle\s*=) meldete 26 Treffer - die Zeichenklasse [^)]* bricht an
der ersten Klammer ab, sodass Aufrufe wie
w._build(..., htf_trend=m30s(T[i]), angle=ang) faelschlich als "ohne Winkel"
galten. Die AST-Pruefung ergibt 11 echte Faelle und erkennt zusaetzlich
positional uebergebene angle-Argumente. Regex ist fuer Aufruf-Analysen das
falsche Werkzeug.
Wirkung, gemessen ueber 37.577 M5-Bars:
mit Reversal ohne Reversal (live seit heute)
Signal weicht ab 19,1 % 1,1 %
Konfidenz-Differenz +7,7 -4,4
ueber dem 55%-Gate 79,4->90,6 % 79,4->78,5 %
Das Reversal-Abschalten von heute hat die Luecke nebenbei fast geschlossen.
Solange das Reversal aktiv war, sahen die 11 Skripte eine Signal-Population,
die sich in jedem fuenften Bar unterschied - das betrifft den Grossteil der
Projekt-Historie. Ab jetzt sind sie naeherungsweise gueltig.
Bewusst NICHT getan: die 11 Skripte "repariert". Ein angle= zu ergaenzen aendert
ihre Zahlen - das waere laut Migrations-Regel keine Refaktorierung, sondern eine
Neumessung. Sie bleiben unveraendert und reproduzierbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
81c4c195da |
Auto-Signal nach dem Reversal-Abschalten gemessen — immer noch nicht tragfaehig
Frage: liefert der Auto-Signal-Entry mit den heutigen Aenderungen positive Ergebnisse? Antwort: nein, aber deutlich naeher dran. LIVE-Konfiguration (Reversal aus, Winkel modelliert), conf>=75: H1 OR -0,047 PF 0,94 n=678 H2 OR +0,120 PF 1,17 n=710 H1 bleibt negativ -> 2-Stichproben-Regel weiterhin NICHT erfuellt. Kein Konfidenz-Schwellwert rettet das (55: -0,103 - 65: -0,111 - 75: -0,047). Das Reversal-Abschalten wirkt aber konsistent. Delta OR: conf 55 +0,015 / +0,099 conf 65 +0,001 / +0,047 conf 75 +0,099 / +0,087 An der Live-Schwelle verbessern sich BEIDE Haelften um ~+0,09; H1 geht von -0,145 auf -0,047, PF von 0,82 auf 0,94. Erste Bestaetigung der gestrigen Entscheidung auf dem GESAMTEN Signal statt nur dem isolierten Trigger. DABEI GEFUNDEN - die Messung vom 30.07. war strukturell unvollstaendig: backtest_auto_signal.py ruft _build OHNE angle= auf. Der Default 90,0 macht ad = 0, damit konnte dort weder der Reversal-Zweig feuern noch der Winkel-Konfidenzterm (+/-15 Punkte) greifen - obwohl die Docstring "echte _build-Logik inkl. Reversal-Zweig" behauptet. Der Winkelterm allein hebt H1 bei conf 75 von -0,123 auf -0,047. Deployment-Drift Fall 5. Die Originaldatei bleibt unveraendert (ihre Zahlen sind dokumentiert); die live-treue Variante steht als backtest_auto_signal_norev.py daneben und sollte kuenftig die Referenz sein. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
dcdd53b703 |
Winkel-Beschriftung korrigiert (Zahlen unveraendert) + Spiegeltest bestanden
Anlass: "pruefe die Logik im umgekehrten Fall, fallender Kurs". 1) Spiegeltest bestanden. Mit reversal_enabled=false ist das Verhalten ueber die ganze Ueberdehnungs-Spanne exakt symmetrisch (steigend/LONG <-> fallend/SHORT): gleiche Signale, gleiche Konfidenz, gleicher Anti-Ueberdehnungs-Schnitt bei 3,5. 2) Dabei gefunden: die Winkel-Beschriftung war ueberall invertiert. calc_trend_angle liefert 0 Grad = AUFWAERTS ... 180 = ABWAERTS, also ist ad = angle-90 NEGATIV bei steigendem Kurs. Ein LONG in einem steigenden Markt bekam daher "Winkel gegen EMA" (-10), ein LONG in einem fallenden "Winkel bestaetigt" (+5). ABER: backtest_angle.py benutzt DIESELBE verdrehte Beschriftung (a5_dis = a5 < 90-dead fuer LONG heisst "dagegen", ist aber STEIGEND). Der dokumentierte Befund "dafuer/neutral +0,055 vs dagegen +0,025" bedeutet richtig gelesen: LONG bei FALLENDEM Kurzfrist-Winkel (= Pullback) traegt doppelt so gut. Das ist der mehrfach belegte Pullback-Effekt. => Die Gewichtung war von Anfang an NUMERISCH RICHTIG. Nicht umgedreht. Geaendert wurden nur die Reason-Texte und Kommentare. Verifiziert: Konfidenzwerte vorher/nachher identisch (60/70/75 je Richtung). Lehre: der erste Verdacht "systematisch invertierte Logik" war falsch - die Zahlen stimmten, die Sprache log. Bei einer verdrehten Konvention erst pruefen, ob die MESSUNG dieselbe Verdrehung teilt, bevor man den Code "repariert". Beim Reversal war es anders: dort wies die eigenstaendige Messung das Setup unabhaengig von der Beschriftung als negativ aus. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
1a67944842 |
Reversal-Setup abgeschaltet (User-Entscheidung nach der Messung)
backtest_reversal_angle.py hat den Trigger in JEDER Variante beidhaelftig negativ gemessen (IST -0,122/-0,031 - vorzeichenkorrigiert -0,173/-0,061 - ohne Winkelbedingung -0,099/-0,023). Ausschlag gab aber nicht nur die Zahl: das Setup hebelt ZWEI gemessen POSITIVE Schutzmechanismen aus - die Anti-Ueberdehnung und den M30-Gegen-Trend-Filter (Edge x2). Ein Setup ohne eigenen Edge, das validierte Filter umgeht, ist der unguenstigste Fall. Umsetzung: neuer Schalter [trading] reversal_enabled (Config-Default im Engine false). WICHTIG: der Modul-Default in wave_rec bleibt True - saemtliche Backtests rufen dasselbe _build, ein False-Default haette alle bestehenden Messungen still veraendert. Abgeschaltet wird ausschliesslich im Live-Pfad. Verhaltensaenderung nur im Band |stretch| 3,0-3,5: dort kam vorher ein antizyklisches REV-Signal, jetzt das normale Trendsignal; ab 3,5 greift wie gehabt die Anti-Ueberdehnung. Verifiziert: - 3 Szenarien: ueberkauft+steigend SHORT/WAVE_REV_SHORT -> LONG/WAVE_LONG, ueberverkauft+fallend LONG/WAVE_REV_LONG -> SHORT/WAVE_SHORT, normaler Trend unveraendert - Live nach Neustart: bei 3,18xATR Ueberdehnung jetzt WARTEN/setup=WAVE/ reversal=None statt REV_SHORT; Log "Reversal-Setup AUS" - measurement_reminder CONFIG_DEPS ergaenzt, 11 Werte alle korrekt Die Winkelbedingung wurde bewusst NICHT vorzeichenkorrigiert - die korrigierte Variante misst sich schlechter. Die irrefuehrenden Kommentare sind jetzt als solche markiert. Bounce-Anzeige bleibt unveraendert (nur Warn-Kontext). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
d052905319 |
Reversal-Winkelbedingung gemessen: alle drei Varianten fallen durch
Anlass: User-Frage "warum SHORT im starken M5-Aufwaertstrend?". Antwort war ein
WAVE_REV_SHORT (3,25xATR ueberdehnt). Beim Nachrechnen kam heraus, dass die
Winkelbedingung gegen ihre eigene Dokumentation laeuft:
calc_trend_angle liefert 0 Grad = starker AUFWAERTStrend, 180 = ABWAERTS.
ad = angle-90 heisst also: ad<0 = STEIGEND. Der Code triggert
stretch>=+3.0 and ad<=-2 -> SHORT, kommentiert als "Winkel ab" - feuert also bei
ueberkauft UND WEITER STEIGENDEM Winkel, waehrend CLAUDE.md "Einstieg IN
Winkel-Richtung" beschreibt. Dasselbe Vorzeichen im Konfidenz-Block: ein SHORT
bekommt "Winkel bestaetigt" (+5), waehrend der Kurs steigt. Mit synthetischen
Reihen direkt nachgestellt.
Erklaert zwei dokumentierte Befunde: ~50 % Richtungstreffer der Bounce-Anzeige
und "blutet in starken Trends".
Statt das Vorzeichen blind zu drehen (alle Messungen beruhen auf dem
IST-Verhalten): backtest_reversal_angle.py, 80k M5, kanonischer Exit,
Echtkosten, 2 Halbjahre, drei Varianten.
IST -0,122 / -0,031 PF 0,79/0,94 n=1100/1615
KORRIGIERT -0,173 / -0,061 PF 0,68/0,89 n= 106/ 163
KONTROLLE -0,099 / -0,023 PF 0,82/0,96 n=1153/1693
(a) Die Vorzeichenkorrektur ist SCHLECHTER - gut, dass sie nicht blind eingebaut
wurde. Sie feuert zudem kaum, weil bei 3xATR Ueberdehnung die 14-Bar-
Regression fast immer noch steigt.
(b) Die Kontrolle OHNE Winkel ist die beste der drei - die Winkelbedingung
entfernt Trades, die im Schnitt besser waren als die behaltenen.
(c) Der Trigger ist in jeder Variante beidhaelftig negativ.
Gemessen wurde der ROHE Trigger ohne Konfidenz-/Raum-Gate; der Legacy-Recheck
der gegateten Variante kam auf ~Breakeven (PF 0,93/1,06), dieselbe Richtung.
Keine Messung stuetzt die dokumentierten "+0,185 / PF 1,35" mehr.
Noch KEINE Strategieaenderung - das Abschalten ist eine User-Entscheidung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
94fbde1dba |
News-Sentiment war gesaettigt — Beweismengen-Gewichtung eingebaut
Anlass: Frage nach X-Anbindung fuer den Copiloten. Vorher geprueft, ob der vorhandene Textstrom ueberhaupt traegt. Er trug nichts, weil der Score kaputt war. calc_news_sentiment bildete ein REINES VERHAELTNIS (bull-bear)/total, ohne Bezug zur Beweismenge. Eine einzige bullische Schlagzeile bei null baerischen ergab +1,00. Diagnose: - 173 von 173 Log-Eintraegen auf +/-1,00 gesaettigt (100 %) - in 100 % der Faelle eine Seite exakt 0 - Median-Beweismenge nur 2,8 gewichtete Headlines - ueber die DB (54.548 Zeilen): 63,9 % auf exakt +1,00 Real am 03.08.: +1,00 waehrend WTI -5,9 % stand. Der Wert trug ein Bit und loeste im Entry-Check dauerhaft falsche "News-Konflikt"-Warnungen aus. Die Keyword-Listen sind NICHT die Ursache (56/48, keine Ueberschneidung). Fix: Shrinkage score = raw * total/(total+4,0). Die 4,0 ist begruendet, nicht optimiert: bei der realen Median-Beweismenge 2,8 bleibt eine einseitige 3-Headline-Lage unter der 0,5-Warnschwelle, ~10 Headlines ergeben 0,71. Zusaetzlich raw_score und evidence im Rueckgabewert, damit unterscheidbar wird ob "ausgewogene Lage" oder "kaum Daten". Leer-Fall liefert dieselben Felder. 6 Szenarien getestet, live verifiziert: bei identischer Beweislage (bull=1.8, bear=0.0) +1,00 -> +0,31. EHRLICH: das repariert die Kalibrierung, nicht die Aussagekraft. Parallel gemessen (Forward-Return 120 min, 38.213 Paare, 84 Tage, 2 Haelften, gegen die Regime-Drift gelesen): der stark-bullische Bucket liegt in BEIDEN Haelften bei null bis negativ, der baerische kippt das Vorzeichen. News-Sentiment ist nicht robust praediktiv. Bleibt Kontext-Chip ohne Verdict-Stimme. Methodik-Falle dokumentiert: der erste Messlauf nutzte candles_m1 (nur ~14 Tage) -> bisect lieferte fuer aeltere Zeitstempel denselben Randwert, alle Forward-Returns exakt 0,0000. Erst der Lauf mit MT5-M5-Bars plus Deckungspruefung war gueltig. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
fe7a1acb97 |
Kurslueckenerkennung: zwei Fehler behoben
User-Meldung "die Kurslueckenerkennung funktioniert nicht richtig". Zwei Fehler
gefunden:
1) Die groesste Luecke des Jahres wurde um 3 Cent verfehlt. Die Definition
verlangte ein lueckenloses Vakuum zwischen den TAGESSPANNEN. Am Wochenende
31.07.->03.08. fiel WTI von Schluss 86,33 auf Eroeffnung 79,76 = -6,57 $ -
unsichtbar, weil Montags Hoch (81,67) das Freitags-Tief (81,64) um 0,03 $
ueberlappte. In einem 24/5-Markt ueberlappen die Tagesspannen fast immer;
die strenge Regel fand im ganzen Jahr nur 5 Gaps.
2) Alle Gap-Datumsangaben waren einen Tag zu frueh: int(b["time"]) minus
_BROKER_OFFSET_S zog 3 h von einer Bar-Zeit ab, die MT5 bereits als naive
Broker-Zeit liefert. Die gemeldete Luecke "2026-07-26" war real der 27.07.
Am Jahreswechsel haette es zusaetzlich den year-Filter verschoben.
Fix: zwei getrennte Gap-Begriffe (kind).
- vacuum = alte strenge Definition. NUR diese speisen zone_lines() ->
_sr_levels -> Wellen-Konfidenz, denn nur auf ihnen wurde
gemessen (backtest_gaps.py). Strategie-Eingang bitgenau
unveraendert: zone_lines() liefert vorher wie nachher [88.288].
- close_open = Schluss->Eroeffnung, das was ein Mensch "Kurslucke" nennt.
REINE ANZEIGE, ab 0,50 $, fuellt auch am selben Tag.
Live: 4 offene Luecken statt 1 (1 Vakuum + 3 Eroeffnungsluecken), darunter
endlich die -6,57-$-Wochenendluecke mit Fill bei 86,33. Frontend kennzeichnet
beide Arten mit Tooltip. v=133.
Bewusst NICHT getan: close_open in die Konfidenz einspeisen - das waere ein
ungemessener Strategie-Eingriff, und der vorhandene Befund beruht auf der
Vakuum-Definition.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
5f94917014 |
Kanal-Pullback ueber alle Zeitebenen gemessen — 24/24 negativ
Anlass: User-Beobachtung im M5-Chart "der Kurs folgt dem Marktstrukturkanal und bricht die untere Linie nicht — koennen wir das nutzen?". Die vorhandene Messung (backtest_structure.py, 20.07.) lief NUR auf M30; M5 war ungetestet. Neues Skript backtest_structure_tf.py — bewusst mit dem KANONISCHEN Live-Exit (exit_model.LIVE: Trail 1,0 + Time-Stop + TP) statt der Exit-Kopie der alten Datei (Trail 1,5, kein Time-Stop). Die alte Datei bleibt unveraendert, weil die Migrations-Regel eine Umstellung nur bei identischen Zahlen erlaubt. Getestet: M5/M15/M30 x zwei Lesarten des M5-Kanals (60 Bars = 5 h "was man im Chart sieht" und 360 Bars = 30 h zeitgleich zu M30) x drei Regel-Varianten, 80k Bars je Zeitebene, 2 Haelften, Echtkosten. Ergebnis: 24 Zellen, ALLE negativ, PF 0,66-0,99. - Trefferquote 37-43 % ueber 1200-2400 Beruehrungen je Haelfte: der Kanalrand haelt in WENIGER als der Haelfte der Faelle. Die im Chart sichtbaren "Halter" sind Selektion. - M5 ist die SCHLECHTESTE Zeitebene (-0,201 vs -0,103 auf M30). - Keine Parameterfrage: 60-Bar- und 360-Bar-Kanal liefern identische Zahlen. Legacy-Recheck-Bonus: die M30-Zeile reproduziert den Befund vom 20.07. (-0,103/-0,019 gegen damals -0,05...-0,11) — der alte Schluss war NICHT durch das abweichende Exit-Modell verzerrt. Mechanismus: hinter einer Regressionslinie liegt nichts — keine Order, kein Pivot. Darin liegt der Unterschied zu P(break) auf einem echten S/R-Level. 19. verworfener Signal-Eingriff. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |