f3e7eeff6c7043b9c778141dd2728e76b2e66787
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Axel HocksandClaude Opus 5
|
f3e7eeff6c |
Doku: Netto-Steuerrechnung war faelschlich als 'nicht gebaut' gefuehrt
Bei der Durchsicht offener Punkte gefunden: CLAUDE.md fuehrte die Umstellung auf die echten WHT-/Tax-settlement-Buchungen weiter als offen -- sie ist seit dem 12.08. gebaut (trader.steuer_buchungen + server._add_net + Feld wht_quelle, Ergebnis: all von -2.449,95 auf +181,00 EUR). Stelle korrigiert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
204e80bb68 |
Meldungen oben links im MT5-Chart (MS;<text>, Indikator v1.36)
User-Wunsch. Neue CSV-Zeile MS;<text>, im Indikator als gestapelte OBJ_LABEL an CORNER_LEFT_UPPER (oben rechts sind Kurs, G/V und HL belegt). Inhalt = dieselben Zeilen wie die Dashboard-Karte "Meldungen": Squeeze, Ueberdehnung, S/R-Ziel mit P(break), Stop-Seite, News-Blackout. NUR ZUSAMMENGESETZT, NICHT NEU GERECHNET -- alles aus bereits berechneten Snapshot-Teilen bzw. _last_sr_close_hint/_last_stop_approach; calendar.blackout() ist ein reiner Speicher-Zugriff. Der Konsens-Pfeil hat im 5-s-Export-Takt einmal ein komplettes zweites _verdict() gezogen. Zwei Felder vorher geprueft statt angenommen: _last_calendar und _export_meldungen gab es NICHT -- ohne die Pruefung haette das umgebende except Exception es still verschluckt und die Meldungen waeren dauerhaft leer geblieben (dieselbe Klasse wie der wave_snap-Fallstrick vom 04.08.). ASCII-SICHER, real noetig: der erste Lauf lieferte "MS; Kompression Ausbruch steht bevor" -- Emoji und Gedankenstrich waren zu Leerzeichen geworden. Der Indikator liest die CSV nicht als UTF-8 (deshalb steht dort auch "Unterstuetzung"). Jetzt Ersetzung + Filter auf 32-126. Verifiziert: MS;Squeeze-Ausbruch LONG @ 82.413, 0 Nicht-ASCII-Zeichen. Deckel 5 Zeilen a 70 Zeichen; eigener Praefix SRB_MSG_*, damit die Labels beim Redraw verschwinden. Abschaltbar per [trading] export_meldungen=false oder InpShowMeldungen. Kompiliert ins richtige Terminal (0 errors, 0 warnings), deployt und am laufenden Server verifiziert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
55dc69ef42 |
Kerzenmuster fuer die Richtung der naechsten Kerze = nein (4. Messung der Klasse)
User-Anschlussfrage. Gemessen mit den ECHTEN Muster-Schwellen aus
core/candles.py (1:1 importiert, kein Nachbau), 80k M5-Bars, 2 Halbjahre,
unveraenderte Schlusskurse ausgeschlossen, 95-%-Intervall je Zelle. Bewertet
wird die Lehrbuch-Lesart, damit sichtbar wird, ob sie stimmt.
Marubozu 46,5 % / 45,2 % beide KI unter 50
Engulfing 47,4 % / 49,5 %
Outside Bar 47,3 % / 48,9 %
langer Koerper 48,5 % / 47,6 %
langer Docht OBEN 49,4 % / 47,8 %
langer Docht UNTEN 50,6 % / 50,6 % beide KI enthalten 50
KEIN Muster erfuellt die vorab fixierte Regel. Trefferquoten 45,2-50,6 %, fuenf
Zellen mit Intervall komplett unter 50 -- in der Lehrbuch-Lesart also
verlaesslich falsch. Die einzige beidhaelftig ueber 50 kippt beim Vorzeichen der
Bewegung (+0,0004 / -0,0037).
Das reproduziert den 60-Minuten-Befund vom 31.07. ("Lehrbuch-Lesart in beiden
Haelften invertiert") jetzt auf dem 1-Bar-Horizont, mit den echten Klassen statt
grober Proxys. Vierte Messung der Kerzen-Klasse.
Und selbst umgedreht zahlt es nicht: groesste Oe-Bewegung 0,0077 $, kippt in der
anderen Haelfte auf -0,0019; halber Spread 0,0100 $, Median-Kerze 0,0400 $.
URTEIL: der Pfeil bleibt bei der kalibrierten Level-Aussage. Nichts geaendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
eec28e3382 |
Pfeil "naechste Kerze" gemessen: Effekt existiert, ist aber 50-100x zu klein
User: der Pfeil an der aktuellen Kerze zeigt die Abprall-Wahrscheinlichkeit des S/R -- er soll stattdessen die Richtung der naechsten Kerze schaetzen. Die Beobachtung stimmt und ist Absicht: live steht AR;L;81.815;81.983;62% Abprall -- der L-Pfeil, seit v1.32 bewusst als BEDINGTE, kalibrierte Groesse gebaut (haelt DIESES Level, AUC 0,65 oos) statt als freie Prognose. Trotzdem neu gemessen statt abgelehnt: die bisherigen Richtungs-Messungen liefen ueber 60-360 Minuten, die naechste M5-Kerze ist ein kuerzerer Horizont mit eigener Mikrostruktur. 80k M5-Bars, 2 Halbjahre, 5 Praediktoren: EMA-Trend 49,6 % / 49,6 % Momentum 3 Bars 48,3 % / 48,3 % letzte Kerze fort 48,6 % / 48,8 % letzte Kerze UMKEHR 51,4 % / 51,2 % <- beide KI ueber 50 langer Docht 49,5 % / 49,3 % Es GIBT einen Effekt, und zwar den umgekehrten: 1-Bar-Mean-Reversion trifft beidhaelftig ueber 50 %. Trendfolge und Momentum liegen darunter. ABER die oekonomische Bedingung faellt katastrophal durch: die Oe-Bewegung in Vorhersagerichtung ist +-0,0002 $, der halbe Spread 0,0100 $ -- der Effekt ist 50-100x zu klein. Eine M5-Kerze bewegt sich im Median 0,0400 $, der Spread ist 0,0200 $ = 50 % davon. URTEIL: der Pfeil bleibt. Ein "naechste Kerze"-Pfeil waere technisch wahr und praktisch wertlos -- und muesste nach der Messung GEGEN die letzte Kerze zeigen, was jeder Mensch als Fehler lesen wuerde. EIGENER MESSFEHLER, dokumentiert weil er eine Klasse ist: der erste Lauf zaehlte unveraenderte Schlusskurse als Fehltreffer, wodurch ein Praediktor UND sein Gegenteil beide unter 50 % lagen (43,4 + 45,8 = 89,2) -- arithmetisch unmoeglich und damit der Verraeter. Real sind ~11 % der M5-Kerzen unveraendert. Merksatz: wenn A und Nicht-A sich nicht zu 100 % addieren, ist die Messung kaputt, nicht der Markt. Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
792355e8f9 |
Sieben Verbesserungen umgesetzt: Breaker scharf, B5 entschieden, 5 Werkzeuge
1) CIRCUIT-BREAKER SCHARF -- daily_loss_limit_pct 0 -> 8. Live verifiziert:
enabled=True, limit_eur 89,44. Steht nicht in runtime_state.json, die ini
greift direkt. Begruendung: MaxDD 82,8 % auf dem gemessenen IST-Pfad,
schlechtester Einzeltrade -381 EUR.
2) B5-DEADLOCK RECHNERISCH AUFGELOEST -- die Regel ist ENTSCHIEDEN, nicht
vertagt. Stand 11/20: Verhaeltnis 0,14 (Latte 1,0), PF 0,39 (Latte 1,0).
Was die 9 Rest-Trades leisten muessten:
9/0 Gewinner -> 165,72 EUR je Trade = 12,2x der bisherige Schnitt
7/2 -> 186,17 EUR
5/4 -> 222,99 EUR
Der groesste Squeeze-Gewinn des Zeitraums war 77,34 EUR -- selbst der beste
Fall verlangt 2,1x den Rekord, neunmal in Folge. Latte nicht mehr erreichbar.
auto_squeeze bleibt FALSE. Wiederaufnahme waere eine NEUE Entscheidung mit
NEUER, vorab fixierter Latte.
3) core/kontrolle.py -- Kontroll-Fixture mit den Referenzwerten. Bricht bewusst
NICHT ab: ein Backtest darf abweichen, er muss es nur wissen und sagen.
4) core/live_config.py -- EINE Quelle der Live-Parameter (ini + runtime_state in
der Vorrangfolge des Engine-Starts). Dritte Instanz derselben Fehlerklasse:
ATRMIN_STD 0,12 statt 0,06, fehlendes set_entry_room, nachgebauter Cluster.
5) stichprobe.paarweise()/zeig_paarweise() -- gepaarter Vergleich. Anlass:
trail_start sah sequentiell besser aus, gepaart kippte das Vorzeichen
(Selektions- statt Exit-Effekt). Selbsttest in drei Richtungen bestanden.
6) tools/check_konstanten.py -- Waechter fuer veraltete Zahlen.
Erster Lauf: zwei Befunde, BEIDE Fehler in meiner eigenen Ableitung (Margin
aus Balance geschaetzt statt vom Broker gelesen; Elliott ohne
Gueltigkeitsfenster gezaehlt). Beide korrigiert.
Danach ein ECHTER Fund: meine am 13.08. notierten "~405 EUR/Lot" sind falsch,
der exakte Broker-Wert ist 712,84 -- die urspruenglich notierten 670 lagen
naeher als meine Korrektur. Lehre: eine abgeleitete Zahl ist keine gemessene.
Stand jetzt 0 Befunde.
7) Puls-Waechter bedingungs-bewusst: PULS traegt je Zeile die Vorbedingung,
bedingte Tabellen erscheinen als Hinweis statt als Ausfall. 0 Zeilen bleibt
IMMER ein Befund (der rec_outcomes-Fall). Grund: ein Waechter mit
Fehlalarmen wird ignoriert -- so ist der Divergenz-Waechter verstummt.
Pipeline gruen (85 Tests), Deployment ueber deploy.py --feld circuit_breaker
verifiziert, genau eine Instanz je Port.
Nicht angefasst: Sizing (User-Entscheidung) und die 44 Backtests mit eigener
Exit-Kopie (Migrations-Regel).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
9dbc5d0452 |
Recherche neue Datenquellen: keine empfohlen -- und eine Projektzahl korrigiert
User-Frage nach weiteren Quellen (Websites, Newsfeed, Telegram, X). DER ENTSCHEIDENDE FILTER IST DIE HALTEDAUER (12-18 min). Damit faellt die gesamte Fundamentaldaten-Welt weg, sie ist woechentlich: EIA-Lager / API-Bulletin woechentlich -> nur Event-Blackout (gebaut) CFTC COT woechentlich -> nein Baker-Hughes Rig Count woechentlich -> nein OPEC / IEA monatlich -> nein Tanker/Satellit taeglich -> zu grob UND Enterprise-Preis Als Event-Gate ist genau das bereits umgesetzt (EIA-Blackout + econ_calendar ueber Forex Factory). oilpriceapi.com (10k Anfragen gratis) buendelt EIA/Baker Hughes/OPEC bequem, liefert aber dieselben woechentlichen Zahlen. KORREKTUR EINER PROJEKTZAHL: die dokumentierten "X-API Basic 200 $/Monat, Pro 5.000 $" gelten nicht mehr. Seit Februar 2026 ist X auf pay-per-use umgestellt: 0,005 $ je gelesenem Post, Deckel 2 Mio./Monat, alte Abo-Stufen fuer Neukunden geschlossen. 300 Posts/Tag waeren ~45 $/Monat statt 200. Der KOSTEN-Einwand von damals ist damit hinfaellig -- der MESSUNGS-Einwand steht unveraendert: der vorhandene Textstrom (News-Sentiment) ist gemessen nicht robust praediktiv. Telegram-Kanaele bleiben verworfen (transportieren Screenshots; und das Orderbuch selbst ist am 17.08. als reaktiv gemessen). GESAMTURTEIL: keine neue Quelle empfohlen. 25 Signal-Eingriffe gescheitert, die HL-Quelle in allen drei Auspraegungen durchgemessen, und der einzige je gemessene grosse Hebel war die Ausfuehrung (+0,32 R). Diese Latte muesste eine neue Quelle schlagen. Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
819b2277b8 |
Orderbuch fuer die Empfehlung? Nein -- es ist reaktiv, nicht praediktiv
User-Frage. Neu gerechnet auf 196.720 Buch-Schnappschuessen / 17,4 Tagen mit dem MT5-Kurs in derselben Zeile (64 % bei lebendem Broker verwertbar). Merkmale imb1/imb5/imb20, Horizonte 60 s und 300 s, Quintile je Haelfte, nicht ueberlappende Fenster, 95-%-Bootstrap. Ergebnis: alle 12 Zellen haben ein Intervall, das die Null enthaelt. DER AUFSCHLUSSREICHE TEIL IST DIE RUECKWAERTS-KONTROLLE. Neben der kuenftigen wird auch die VERGANGENE MT5-Bewegung je Quintil berichtet -- in 10 von 12 Zellen ist die RUECKWAERTS-Spanne groesser: imb1 · 60 s vorwaerts -0,05 / +0,08 bp rueckwaerts +0,72 / +0,50 imb1 · 300 s vorwaerts +0,06 / -0,91 rueckwaerts +1,31 / +1,73 imb5 · 60 s vorwaerts -0,09 / +0,10 rueckwaerts +0,53 / +0,78 imb20 · 60 s vorwaerts +0,05 / +0,06 rueckwaerts +0,63 / +0,65 Das Buch spiegelt die Bewegung, die auf Pepperstone schon passiert ist. Die zwei Ausnahmen (imb5/imb20 300 s H1) reproduzieren in H2 nicht. Das passt exakt zum Lead-Lag-Befund vom selben Tag: Pepperstone fuehrt HL um ~6 s. Ein Orderbuch, dessen Boerse hinterherlaeuft, kann den Broker nicht vorhersagen -- der Befund ist damit mechanistisch erklaert, nicht nur gemessen. Oekonomisch entscheidet es ohnehin: die groesste Vorwaerts-Spanne ueber alle Zellen ist +1,63 bp, der Pepperstone-Spread ~2,7 bp. URTEIL: nicht nutzbar. Bestaetigt unabhaengig die Entmachtung des Verdict-Moduls "Orderbuch" am 06.08. -- damals aus der Verdict-Telemetrie, jetzt aus den Rohdaten der Quelle selbst. Grenzen: nach der Entkopplung bleiben bei 300 s nur 1.252/1.254 Faelle; gemessen wurde die Imbalance, nicht die Waende (deren Preis-Zuordnung braeuchte die Basis-Korrektur und waere zirkulaer); 17,4 Tage = ein Regime. Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
82ccf292ff |
Lead-Lag HL gegen Pepperstone neu gemessen: Pepperstone fuehrt, nicht HL
User-Frage, ob der Hyperliquid-Kurs dem Broker vorauslaeuft und den Trend
vorhersagen koennte. Im Projekt stand dazu ein Befund aus n=545; neu gerechnet
auf 245.073 Ticks / 20,4 Tagen -- er reproduziert, deutlich schaerfer.
KREUZKORRELATION der Renditen (k>0 = HL fuehrt, k<0 = Pepperstone fuehrt):
Lag GESAMT H1 H2
k=-1 (~6 s, Pepperstone voraus) +0,455 +0,460 +0,447
k=0 (gleichzeitig) +0,505 +0,507 +0,503
k=+1 (~6 s, HL voraus) +0,020 +0,029 +0,005
Die Asymmetrie ist die Antwort: +0,455 gegen +0,020, Faktor 23. Beidhaelftig
identisch. Kontrolle bestanden (k=0 bei +0,505 -- beide handeln erkennbar WTI).
RICHTUNGSTEST, entkoppelt (nicht ueberlappende Fenster): ueber 12 Zellen
(Vorlauf 6-30 s x Horizont 6-30 s x Schwelle 0,5-2,0 bp) liegt die Trefferquote
zwischen 47,6 und 49,8 % -- durchweg am oder unter dem Muenzwurf; fuenf Zellen
haben ein Intervall komplett unter 50 %.
Oekonomisch entscheidet es ohnehin: die Oe-Bewegung in HL-Richtung betraegt
+0,00 bis +0,14 bp (bei 30 s sogar -0,09), der Pepperstone-Spread ist ~2,7 bp --
20- bis 270-mal so gross.
URTEIL: HL taugt nicht als Vorlaufindikator. Deckt sich mit dem uebrigen Befund
zu dieser Quelle (Orderbuch-Druck 0,2-1,0 bp, Modul am 06.08. entmachtet,
Funding/Premium tragen nicht). Was HL bleibt: der 24/7-Kurs am Wochenende --
eine Verfuegbarkeits-, keine Vorhersage-Eigenschaft.
Drei methodische Punkte, ohne die es anders ausgefallen waere:
(1) 32 % der Zeit steht Pepperstone still (Wochenende) -- ein stehender Kurs
erzeugt zwangslaeufig den Eindruck, HL laufe voraus. Nur die 65 %
verwertbaren Ticks bei lebendem Broker gehen ein.
(2) Gerechnet auf ROHEN Kursen: hl_mid + basis ist bei stehendem Broker
zirkulaer (dokumentiert 02.08.).
(3) Nur Renditen, nie Niveaus -- kointegrierte Preisreihen korrelieren immer
nahe 1 und sagen nichts ueber Vorlauf.
Grenze: Abtastung ~6 s, ein Vorlauf darunter waere unsichtbar -- praktisch aber
nicht ausbeutbar (1-s-Poll, WireGuard, Market-Order).
Nichts am Live-System geaendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
276c8c7f07 |
trail_start gemessen: keine Aenderung -- und der gepaarte Test kippt das Ergebnis
User-Frage "warum wurden meine Trades automatisch geschlossen". Am Log und an der DB beantwortet: 9 von 11 sl-Closes seit dem 13.08. waren der NACHGEZOGENE Stop (-75,90 EUR), einer der echte Initial-SL (-113,94), und der groesste Verlust (-215,60) war eine MANUELLE SL-Aenderung, nach der sich das Trailing per Konstruktion abschaltet. Der Mechanismus ist Arithmetik: der Trail sitzt 1,0xATR hinter dem Bestkurs und erreicht den Einstieg damit erst bei 1,0xATR Gewinn -- aktiviert wird er aber schon bei 0,3xATR. Dazwischen liegt der Stop zwangslaeufig im Verlust. GEMESSEN (backtest_trail_start.py, 80k M5, Squeeze-Entries, nur trail_start): trail_start "war im Plus, schloss im Minus" H1 / H2 0,3 (live) 47,6 % / 38,2 % 0,8 27,7 % / 19,4 % 1,0 12,0 % / 6,9 % 1,3 0,0 % / 0,5 % Das beobachtete Verhalten ist damit bestaetigt und quantifiziert. ABER DER ERTRAG TRAEGT NICHT. Sequentiell sahen vier Werte in beiden Haelften besser aus (0,5/0,8/1,3/1,5, Delta bis +0,101). Der GEPAARTE Test dreht das: alle 12 Intervalle enthalten die Null, und in H2 kippt das Vorzeichen (0,8: -0,006 · 1,3: -0,023 · 1,5: -0,023). Grund: ein spaeterer Trail-Start haelt Trades laenger, also passen ANDERE Trades in den EINEN Slot. Der scheinbare Gewinn war ein SELEKTIONSEFFEKT, kein Exit-Effekt -- exakt die Falle aus backtest_exit_combo.py (31.07.). Der gepaarte Vergleich ist hier der einzig gueltige Test und zugleich trennschaerfer als die Einzel-Intervalle. KEINE AENDERUNG. trail_start bleibt 0,3. Nichts am Live-System angefasst. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
44191947ac |
Telegram bei gruener M15-Karte (m15_alert) + Tests verschmutzen nicht mehr das Log
User: "wenn es eine Empfehlung gibt (gruen), schicke eine Telegram-Nachricht." engine._check_m15_alert, direkt hinter _log_m15_state -- dieselbe Quelle wie Anzeige und Selbstmessung, damit die drei nicht auseinanderlaufen koennen. DIE ENTPRELLUNG IST DER GANZE BAU. Roh springt die Karte 85x/Tag auf gruen (m15_states, 3 Tage nach der Hysterese vom 12.08.) -- das waere Spam. Alle Stufen an den echten Daten kalibriert, nicht geraten: nur Flanke 85,0/Tag + Level & Richtung als Schluessel 23,7/Tag + 30 min Mindestabstand 13,3/Tag + Fenster 8-20 Uhr (Default) 7,7/Tag (Vergleich: Close-Meldung ab 50 EUR 2,4-6,1/Tag) Nach 4 h darf dasselbe Level erneut melden, sonst verschweigt der Alert ein Setup, das den ganzen Tag wiederkommt. Der Text sagt ausdruecklich, dass es KEINE Prognose ist: die Karte automatisch zu handeln faellt gemessen durch (backtest_m15_auto.py: OeR -0,162/-0,094). Die Meldung ist ein Hinweis zum Hinsehen fuer den Menschen (+3,20 EUR/Lot ueber 146 Trades). Die P(break)-Formulierung ist wortgleich zu Karte und Chart (v1.35). 13 Tests, Schwerpunkt auf dem was NICHT gesendet werden darf. Mutationsprobe in vier Zweige, alle gefangen. DIE PROBE HAT EIN TESTLOCH AUFGEDECKT: das Entfernen der Flankenerkennung liess zunaechst ALLE Tests gruen, weil Cooldown und 4-h-Schluessel dasselbe abfangen. Zwei Schutzschichten, die sich maskieren -- dasselbe Muster wie beim Fill-Dedup. Geschlossen durch test_flankenerkennung_ISOLIERT. NEBENBEFUND, behoben: Tests schrieben ins Produktions-Log (ueber 150 M15-Alert-Zeilen + Close-Push #4711 aus test_close_buchung). Ich hielt die Entprellung deshalb zuerst fuer live defekt. conftest.py entfernt den FileHandler des oil-Loggers jetzt fuer die Sitzung -- vierte Grundregel der Suite. Verifiziert: Log-Groesse vor und nach einem Komplettlauf identisch. Live verifiziert: seit dem Serverstart genau 1 Alert trotz mehrfachem gruen/gelb-Wechsel. 85 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
c251652d33 |
Enger Stop fuer die ersten N Bars: keine Aenderung (backtest_sl_staged.py)
User-Idee: SL beim Eroeffnen sehr eng, damit falsch laufende Trades frueh geschlossen werden; laeuft er richtig, etappenweise nachziehen. Der zweite Teil ist laengst gebaut (Phasen-Ratsche); neu war allein der zeitlich befristete enge Stop. Ohne Exit-Nachbau gerechnet: Lauf A (sl_atr=eng) und B (sl_atr=weit) laufen auf DEMSELBEN Pfad; innerhalb der ersten N Bars ist der einzige Unterschied der SL-Abstand, jeder Nicht-SL-Ausstieg faellt identisch aus. Also exakt R = R_A wenn A vor/bei Bar N aussteigt, sonst R_B. Keine fuenfte Exit-Kopie. 80k M5, Squeeze-Entries, ruhende Order am Level, kanonischer Exit, Echtkosten, ein Slot. Basis = durchgehend 3,4xATR_M5 (der Live-Stop, aus 121 echten Trades als Median gegengerechnet): Basis H1 -0,248 / WR 37,0 % / worst -3,73 H2 -0,107 / 44,4 % / -3,74 N=3, eng 0,5 H1 -0,263 / WR 23,3 % H2 -0,043 / 30,4 % N=6, eng 0,5 H1 -0,242 / WR 22,9 % / worst -0,89 H2 -0,045 / 30,1 % / -0,96 N=12, eng 0,5 H1 -0,240 H2 -0,044 DER ENTSCHEIDENDE BEFUND IST STRUKTURELL: die Staffelung hat keinen Raum. Bei N=12 steigen 269 von 279 Trades schon in Phase 1 aus (96 %) -- die mittlere Haltedauer ist 12-18 min, "die ersten 30-60 Minuten" sind der ganze Trade. Wo die Staffelung ueberhaupt etwas anderes tut als ein dauerhaft enger Stop (N=3), ist sie in H1 bei allen vier eng-Werten schlechter. Wo sie gewinnt (N=6/12), ist sie kein gestaffelter Stop mehr, sondern ein permanent enger. Regel verfehlt: die zwei nominell besseren Kombinationen liegen in H1 bei +0,007/+0,008, also weit unter einem Standardfehler (~0,055 bei n=279), die Nachbarn kippen, und alle Werte sind negativ (Verlustgrade, kein Edge). WAS ECHT IST: der Tail. Worst-Case -3,73 -> -0,83/-0,96 = Faktor 4. Bezahlt mit der Trefferquote (37,0 -> 22,9 %). Aber die Bar-Sim ueberschaetzt enge Stops systematisch (Kipp ~0,3xATR) -- die Verzerrung geht zugunsten der Idee, das Nein ist damit umso belastbarer. Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
02bec8fbb2 |
Sizing auf der echten Historie gerechnet (analyze_sizing_live.py)
Folge der S/R-Widerlegung: der Hebel zeigt auf die GROESSE. Pfad-Simulation ueber 1.278 geschlossene Trades (08.05.-13.08.), pnl/lots als groessenunabhaengiges Ergebnis, Lots aus der simulierten Equity abgeleitet. Zwei dokumentierte Zahlen stimmten nicht mehr und wurden aus den Daten neu geschaetzt: EUR je $ und Lot = 86,90 (notiert 87,6), Margin je Lot ~405 EUR (notiert 670). DER IST-PFAD IST DIE BOTSCHAFT: Start 1.115,70 · Hoch 2.724,16 (05.08.) · Tief 261,36 (30.07.) · Ende 1.279,04 Max-Drawdown 82,8 % · schlechtester Einzeltrade -381,16 EUR 42 von 71 Tagen negativ; getragen von wenigen Tagen (04.08. +1.297). Das Konto hat zweimal den Grossteil seines Werts verloren. Fuer unbeaufsichtigten Betrieb ist das die entscheidende Zahl, nicht der Endstand. VARIANTEN (Ende / MaxDD / schlechtester Trade): IST 1.279 / 82,8 % / -381 Lot-Deckel 1,5 1.362 / 82,8 % / -345 -> bringt fast nichts Risiko 1,5 %/Trade 680 / 54,4 % / -77 Risiko 0,5 %/Trade 960 / 22,2 % / -27 IST + Breaker 8 %/Tag 2.018 / 59,2 % / -381 -> verbessert BEIDES ABER: ein Tag traegt 70 % des Breaker-Vorteils (07.08. +556,82 von +800,19), und an drei Tagen kostet er (-106,85 / -96,00 / -50,77). Ohne den 07.08. bleiben +243 EUR ueber 10 Tage. Das ist kein Makel der Messung, sondern das Wesen einer Versicherung -- ihr Wert sitzt im Tail. Die +739 sind eine Realisierung, keine Erwartung. GRENZEN: die Sim sperrt nach dem Ausloesen ALLE Trades des Tages; live sperrt der Breaker nur die autonomen. Bei einem zu 94 % manuell gehandelten Konto misst sie damit eher eine Disziplin-Regel -- fuer das Ziel Autotrading ist sie dagegen das richtige Modell. Confounder bei Risiko-Sizing: laeuft auf 1.118 von 1.278 Trades (nur die mit sl_at_entry). Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
1e8d700f46 |
"S/R-Close kappt die Squeeze-Laeufer" = widerlegt (backtest_squeeze_srclose2.py)
Meine eigene Hypothese vom selben Tag -- gemessen falsch, und zwar doppelt. (1) BACKTEST (80k M5, 2 Halbjahre, Einstiege ueber den geteilten squeeze_scan.scan(on_entry=...), ruhende Order am Level mit Fill bei Beruehrung, kanonischer Exit, Echtkosten, ein Slot; identische Entry-Liste ueber alle Varianten, variiert wird NUR der Exit): A) ohne S/R-Close H1 -0,151 / PF 0,72 H2 -0,079 / PF 0,86 B) mit p<0,35 (LIVE) H1 -0,119 / PF 0,76 H2 -0,049 / PF 0,91 D +0,032/+0,030 B) mit p<0,45 H1 -0,088 H2 -0,046 D +0,063/+0,033 Der S/R-Close ist in BEIDEN Haelften besser als ohne -- die vorab fixierte Regel sagt: anlassen. Und die von mir vorgeschlagene "Abhilfe" (Close erst ab Mindestgewinn) macht H1 schlechter (D -0,006 / -0,011). (2) LIVE, 11 Squeeze-Trades ab 01.08.: sl 5 Trades -198,17 EUR sr_close 4 Trades +15,98 EUR <- der verdaechtigte Exit hat BEIGETRAGEN manual 2 Trades +8,73 EUR Der groesste Gewinner (+77,34) kam ebenfalls ueber sl, also ueber das Trailing. Die Groesse steckt allein auf der Verlustseite: -175,21 EUR bei 2,91 Lots = 0,695 $ = der planmaessige 2xATR-Stop. Der Hebel zeigt auf SIZING, nicht Exit. GRENZE, nicht ueberspielt: die ABSOLUTEN Werte reproduzieren den dokumentierten Kontrollwert NICHT (backtest_squeeze_touchfill.py: +0,124/+0,292 bei 1.092/1.807 Trades gegen -0,151/-0,079 bei 273/422). Belastbar ist allein der RELATIVE Vergleich; "der Squeeze ist negativ" ist hier NICHT belegt. Zwei eigene Fehler dokumentiert, weil es Fehlerklassen sind: - erster Lauf nahm den Modul-Default ATRMIN_STD=0,12 statt des Live-Werts 0,06 -> H1 127 gegen H2 483 Einstiege, voellig andere Population. Dieselbe Klasse wie das fehlende set_entry_room(0.6): ein aufgerufenes Gate ist nicht dasselbe wie ein aktives Gate. - erster Entwurf haengte den Close an stop_when (prueft den BAR-CLOSE gegen ein 0,018-$-Fenster) -> feuerte fast nie. Live prueft den laufenden Kurs im Sekundentakt; das Analogon ist die Bar-SPANNE. Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
03329c44b5 |
Zwischenstand Autotrading: Entry repariert, Defekt in den Exit gewandert
Erhebung auf die Frage "wie erreiche ich das Ziel Autotrading?". Nichts am Live-System geaendert -- aber die Diagnose verschiebt sich. Der Pending-Umbau vom 05.08. hat gewirkt: von 8 Bot-Trades seit dem Umbau fuellten 7 per ruhender Order; der Market-Fallback ist praktisch weg (n=1 bei +0,148xATR, innerhalb der Nachjagd-Bremse). Vorher lag der Live-Median bei +0,275xATR ueber dem Level. Deployment-Drift Fall 7 ist damit geschlossen. Und trotzdem verliert der Squeeze -- die Ursache ist also eine andere geworden. B5 (ab 01.08., n=11/20): Trefferquote 73 %, aber OeGewinn 13,62 gegen OeVerlust 94,15 = Verhaeltnis 0,14 (Latte 1,0), PF 0,39 (Latte 1,0), Summe -173,46 EUR. Die Signatur steht im Trade-Protokoll: drei der sieben Pending-Trades wurden per sr_close bei +0,26 / +2,88 / +0,28 EUR geschlossen, waehrend die Verlierer bis zum vollen Stop liefen (-43 / -64 / -175). Der Squeeze lebt gemessen von Laeufern (43 % Treffer, Ertrag im Tail) -- genau die werden gekappt. Die alte Entlastung des S/R-Closes ist nicht mehr bindend: backtest_squeeze_srclose.py (24.07.) mass einen Wash, aber mit dem ALTEN P(break)-Modell und Schwelle 0,55/0,60. Heute laeuft das nachtrainierte Modell mit 0,35, das 94-97 % aller Beruehrungen schliesst. Gemessen unter X, betrieben unter Y -- dasselbe Muster wie die acht dokumentierten Faelle. NAECHSTE MESSUNG: Squeeze mit gegen ohne S/R-Close unter dem heutigen Stand. Kontext, je Lot normiert: AUTONOM n=11 -5,85 EUR/Lot · MENSCH n=146 +3,20/Lot. Die setup-Spalte taugt NICHT als Bot/Mensch-Trennung (engine._open schreibt die Wellenlage auch bei manuellen Trades mit) -- ein erster Auswertungsversuch hat genau das verwechselt und dem Bot 152 Trades mit +730 EUR zugeschrieben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
354a57ef5f |
M15-Karte automatisch handeln = faellt durch (backtest_m15_auto.py)
User: "messe ob wir den Autotrader bei M15-Empfehlung automatisch traden lassen
koennen." Track-B-Frage, Regel VORAB fixiert (OeR>0 & PF>1 & KI ohne Null in
beiden Haelften, n>=100, schlaegt die Kontrolle, Nachbarn kippen nicht).
Neu gemessen wurde genau EIN Zusatz: die Karte hat bewusst keine Richtung, die
entsteht erst aus der `lesart` (aus P(break)). backtest_m15_gates.py handelt die
vom HTF ERLAUBTE Richtung, nicht die Lesart -- die war nie geprueft.
80k M5-Bars, 2 Halbjahre, echte core.sr_levels/_p_break-Gewichte, Status+Lesart
inkl. Hysterese, kanonischer Exit, Echtkosten, Fill bei BERUEHRUNG, ein Slot:
A) Karte (Lesart) H1 -0,162 / PF 0,72 H2 -0,094 / PF 0,84
B) Lesart + Veto-konform H1 -0,104 / PF 0,81 H2 -0,051 / PF 0,91
C) KONTROLLE HTF-Richtung H1 -0,085 / PF 0,85 H2 -0,030 / PF 0,95
D) KONTROLLE Gegenrichtung H1 -0,070 / PF 0,87 H2 +0,007 / PF 1,01
Alle vier laufen auf DENSELBEN gruenen, gerichteten Momenten -- variiert wird nur
die Richtung. Die Lesart ist damit in BEIDEN Haelften schlechter als die
HTF-Richtung UND schlechter als ihr eigenes Gegenteil; sie kostet -0,077 bzw.
-0,064 OeR gegenueber C.
A ist nicht "unbelegt", sondern belegt NEGATIV: das 95-%-KI schliesst in beiden
Haelften die Null aus ([-0,222 … -0,099] und [-0,152 … -0,038]).
Nachbarn 0,40/0,50/0,60 alle beidhaelftig negativ und monoton schlechter.
Unabhaengige LIVE-Gegenprobe (m15_states, 3.678 Zustaende): der handelbare
Zustand trifft entkoppelt 46,8 % (30 min) und 42,6 % (60 min) -- beide unter dem
Muenzwurf. Roh saehe es mit 51,5 % besser aus; die Entkopplung (1.793 -> 124
unabhaengige Faelle) ist der ganze Unterschied.
MECHANISMUS: zum vierten Mal derselbe Fehler dieser Karte -- aus einer Aussage
ueber die STRUKTUR ("haelt dieses Level?") wird eine RICHTUNGSprognose. Das ist
Mean Reversion am Extrem, und P(break) taugt gemessen zum EXIT, nicht zum ENTRY.
URTEIL: nicht bauen. Auch kein Umschwenken auf C oder D -- die sind nur weniger
schlecht, ebenfalls negativ. Nichts am Live-System geaendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
77ed1d5572 |
S/R-Beschriftung: Chart und M15-Karte nannten verschiedene Zahlen (v1.35, v=169)
User: "die Beschriftung fuer S/R im Chart stimmt nicht mit der Analyse in der M15-Karte ueberein." Die LEVEL stimmten -- nur die Zahl daneben nicht. Live gegengeprueft: die CSV enthielt R;82.069;69, Gate 3 der Karte meldete res 82.069 / p_break 69. Beide kommen aus _draw_levels(), sind also per Konstruktion identisch; auch die Distanzen sind exakt (0,477~0,48 / 0,909~0,91 / 0,455~0,45). DER DEFEKT: das Chart schrieb die NACKTE Zahl = P(Bruch), die Karte klappte unter 45 % still auf P(Abprall) um und nennt 45-55 % "unentschieden". P(Bruch) 33 % -> Chart "33%" Karte "67 % Abprall" P(Bruch) 46 % -> Chart "46%" Karte "unentschieden" P(Bruch) 72 % -> Chart "72%" Karte "72 % Bruch" Beide Zahlen richtig, aber die Chart-Zahl sagte nicht, WAS sie ist. GEMESSEN in 88,1 % der Zeit verschieden (1.797 Vorhersagen / 14 Tage: 66,3 % unter 45 %, 21,9 % im unentschiedenen Band). Behoben im Indikator v1.35, wortgleich zu app.js. Ueber 1.678 echte P(break)-Werte gegengeprueft: Uebereinstimmung 0 % -> 100 %. Ins RICHTIGE Terminal kompiliert (es gibt real zwei Ordner, nur D0E8209F... bekommt die sr_levels.csv): 0 errors, 0 warnings, .ex5 frisch, Version im Terminal gegengeprueft. Zwei Verdachtsmomente ausgeschlossen statt vermutet: eine stehengebliebene Alt-Linie (der Indikator ruft ObjectsDeleteAll bei jedem Redraw) und ein falsch einsortiertes Level (_draw_levels waehlt seit 23.07. nach Lage zum Kurs). ZWEITER Befund derselben Klasse, ebenfalls behoben: Gate 3 und 3b nannten Level aus VERSCHIEDENEN Zeitebenen, beide nur als "xATR" -- 3 M30-Pivots, ATR_M15, im Chart gezeichnet 3b M5-Pivots, ATR_M5, NICHT gezeichnet Real standen "0,48xATR" und "0,45xATR" nebeneinander, die nicht vergleichbar sind, und die Karte nannte einen "Support 81,78", den man im Chart vergeblich sucht (alle 10 M30-Pivots lagen ueber dem Kurs). Die Quellen-Trennung BLEIBT -- entry_room_atr=0,6 ist ueber 80k Bars auf M5 kalibriert. Geaendert wurde nur die Beschriftung plus Tooltips. Reine Anzeige: an Gates, Gewichten und Order-Logik nichts geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
95521d041c |
Schrift eine Stufe kleiner: -2px an der fluiden Wurzel (v=168)
User: "verkleinere alle Schriftarten um 1em".
Woertlich waere 1em = 100 % der Schriftgroesse, also null. Gemeint ist eine
Stufe -- genommen wurden -2px, exakt der Schritt, in dem die Groesse am 24.07.
zweimal HOCHgesetzt wurde. Das Handy landet damit auf dem Zwischenstand von
damals (~16px statt ~18px).
html { font-size: clamp(15px, 14px + 0.5vw, 22px); } (war 17/16/24)
Fenster v=167 v=168
390px 17,95px 15,95px
768px 19,84px 17,84px
1440px 23,20px 21,20px
ab 1600 24,00px 22,00px
Das war eine EINZIGE Zeile. Die 96 rem-Werte bleiben unberuehrt, alle
Groessenverhaeltnisse untereinander auch -- genau dafuer wurde heute frueh
umgestellt. Der Bump am 24.07. musste noch 96 Einzelwerte anfassen und
uebersah dabei drei Shorthands.
Ausgeliefert verifiziert: Wurzel = clamp(15px, 14px + 0.5vw, 22px),
93 rem-Werte, 0 px-Schriftgroessen, HTML zieht v=168, Klammern ausgeglichen.
Zurueck auf die 18er-Basis: clamp(17px, 16px + 0.5vw, 24px) -- eine Stufe
entspricht 2px in Minimum und Steigungs-Basis, der Deckel wandert mit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
01916134be |
Schrift skaliert mit dem Fenster: 96 px-Werte -> rem + fluide Wurzel (v=167)
User-Wunsch: "Schriftarten im Dashboard auf em einstellen, damit auf jedem
Geraet oder je nach Fenstergroesse die Schriftgroesse automatisch angepasst
wird."
Umgesetzt mit rem + fluider Wurzel, NICHT mit em. Der Wunsch war richtig,
die genannte Einheit nicht: `em` ist relativ zum ELTERNelement und reagiert
auf die Fenstergroesse gar nicht -- verschachtelt multipliziert es sich sogar
(h2 mit 1,2em in einer Karte mit 1,1em landet bei 1,32x).
html { font-size: clamp(17px, 16px + 0.5vw, 24px); }
390px Handy -> 17,95px (bisher 18,00 -- bewusst kein Rueckschritt)
768px -> 19,84px
1440px -> 23,20px
ab 1600px -> 24,00px (Deckel)
Der Anker ist so gesetzt, dass am Handy NICHTS kleiner wird -- der User hat
die Groesse am 24.07. zweimal von Hand hochgesetzt; eine Responsive-Umstellung,
die sie wieder eindampft, waere eine stille Ruecknahme seiner Entscheidung.
Verifiziert statt behauptet:
- alle 96 Deklarationen gegen die 18px-Referenz zurueckgerechnet,
groesster Fehler 0,0008 px
- 93 font-size + 3 font:<weight> Npx/...-Shorthand (.ms-chip/.ms-bos-lbl/
.sqm-badge -- die waren beim Bump am 24.07. zuerst uebersehen worden)
- ausgeliefert: 0 px-Schriftgroessen, fluide Wurzel da, HTML zieht v=167
Zwei Vorbedingungen geprueft, nicht angenommen:
- viewport-Meta ist gesetzt (sonst wuerde vw am Handy ~980px messen)
- beide Media-Queries stehen in px, verschieben sich also nicht mit der
Schrift (die klassische em-Falle bei Breakpoints)
Abstaende bleiben in px -- sie mitzuskalieren waere ein weit groesserer
Eingriff mit Layout-Risiko; die Anfrage betraf die Schrift.
Groesse global aendern = jetzt EINE Zeile statt 96 Einzelwerten.
Zurueck: web/style.css.bak-2026-08-13
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
5819a9df21 |
Netto-Rechnung aus den ECHTEN Steuer-Buchungen statt geschaetzt
Der seit 05.08. dokumentierte Defekt ist behoben. _add_net rechnete net_pnl = total_pnl - gross_win * 26,375 % und unterstellte, die Quellensteuer sei endgueltig verloren. Sie wird aber taeglich per "Tax settlement" erstattet - real zu 99 %. all: vorher net_pnl -2.449,95 EUR, jetzt +181,00 (total +209,93, echte Steuerlast +28,93). Verzerrung rund 2.630 EUR - sie machte aus einem profitablen Konto ein verlustreiches. Die Schaetzung der EINBEHALTENEN Summe war fast exakt; falsch war allein die Annahme, sie bleibe weg. trader.steuer_buchungen() liest die WHT-/Tax-Deals direkt (position_id == 0, sauber von Trade-Deals getrennt), unter mt5_lock, 5 min gecacht. Fail-safe: ohne MT5 Rueckfall auf die Schaetzung, das Feld wht_quelle sagt welche Zahl drinsteht. Kurze Zeitraeume bleiben verzerrt, in BEIDE Richtungen - die Erstattung kommt am Folgetag. Bei "today" ist wht sogar negativ, weil die Erstattung von gestern heute einging. Ehrlich benannt, nicht kaschiert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
d8839ef7c5 |
Tag P/L war falsch: Fehlbuchungen beim Schliessen behoben + repariert
User-Frage "ueberpruefe ob Tag P/L richtig berechnet wird". Die Formel (realisiert + offen) war bitgenau richtig - die Datenbasis nicht: Anzeige +14,26 EUR gegen -74,08 EUR realisiert beim Broker. Ursache, im Log im Sekundentakt (#49926460): 20:04:10 eroeffnet -> 20:04:10 "extern geschlossen" -> "kein OUT-Deal in 1 Deals" -> Fallback bucht 0,00 -> 20:11:42 der echte Close lief ins Leere. Drei Defekte: (1) positions_get sieht die frische Position einen Tick lang nicht, (2) _log_external_close buchte TROTZ "kein OUT-Deal" einen Close - dabei ist genau das der Beweis, dass sie noch offen ist, (3) log_trade_close fasste nur exit_time IS NULL an, die Fehlbuchung blockierte den echten Close dauerhaft. Bei #49852362 kostete das +5,87 statt -95,38 EUR und den falschen Tag. Behoben: (1) Abbruch statt Fallback bei "kein OUT-Deal"; (2) eine erkennbare Fehlbuchung (closed_by='unknown') darf von einem echten Close korrigiert werden - eng gefasst, gute Zeilen bleiben unberuehrt. 4 Tests inkl. Gegenprobe. Altlast: tools/repair_closes.py (Trockenlauf Standard, Backup automatisch). 18 Zeilen ueber 60 Tage korrigiert. Heute von +7,63 auf -72,67 (Restfehler 1,41). Gesamt-P&L von -282,78 auf +169,98. Zeitfalle zweimal getroffen: history_deals_get filtert nach Broker-Wallclock, und fromtimestamp(d.time, BROKER) rendert 3 h zu spaet. Aufgefallen nur, weil eine Deal-Zeit 23:11 lautete, das Log aber 20:11:42 sagte. Statistik-Modul separat geprueft: Arithmetik in allen drei Zeitraeumen bitgenau korrekt (Abweichung 0,00). Der Netto-Defekt vom 05.08. besteht weiter und ist groesser als damals: angezeigt -2.449,95 EUR, real verblieben -17,06 (99 % der Steuer werden erstattet). Nicht gebaut - die Loesung ist dokumentiert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
19ee379f20 |
rec_outcomes: zweiter Bug gefunden und behoben (timeframe_name)
Der Log verriet die wahre Ursache: 'WaveRecommender' object has no attribute 'timeframe_name'. rec["tf"] ist leer, also lief der Aufruf immer in diesen Fallback - AttributeError, im except auf DEBUG verschluckt. Der pb_feats-Fix vom 11.08. war damit RICHTIG: er kam an der ersten Sperre vorbei und legte diese zweite frei. Vorher wurde log_rec_outcome nie aufgerufen (atr immer 0), deshalb konnte der zweite Bug gar nicht auftreten. Richtig ist self._wave_tf_label (die Engine haelt das Label). Lehre: nach einem Fix nicht nur pruefen, ob die Tabelle jetzt schreibt, sondern das LOG lesen. Die Zeilen standen seit Stunden da - ich hatte nur auf INFO gefiltert und daraus geschlossen, es gaebe keine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
bf7e382818 |
Auto-Signal-Entry (SIG) komplett entfernt inkl. Button (v=166)
User-Entscheidung. Der Pfad war seit 01.08. aus und auf BEIDEN Ausfuehrungs-Achsen gemessen negativ: Markt-Einstieg in allen 8 Feldern, ruhende Order mit Touch-Fill -0,392/-0,338 in allen 6 und damit sogar schlechter als Markt. Die +0,35/+0,32 aus backtest_auto_signal_v3.py galten in Variante B (Fill beim Close-Bruch) und waren Look-ahead - Aufschlag 0,77-0,85 R. Ursache strukturell: das Bestaetigungs-Level _pend WANDERT. Nebenbei entfaellt der offene Churn-Defekt (4x setzen/stornieren in 76 s bei identischem Level, gefunden 06.08., nie behoben). Entfernt: _check_auto_signal, set_auto_signal, der Signal-Zweig in _pending_ziel, /api/autosignal, Button + Handler, vier Snapshot-Felder, die auto_signal*/signal_pending_entry-Leser. Geblieben: AUTOSIG_*-Trades in der DB, die Backtests, wave_rec.breakout (speist block_reason) und _confirm_breakout selbst. Sicherung: .removed_backup/auto_signal_2026-08-12.py + Git. Das Risiko war nicht SIG, sondern der GETEILTE Pending-Manager (zwei getrennte Manager wuerden sich gegenseitig stornieren). Deshalb wurde das Squeeze-Verhalten VOR dem Eingriff in tests/test_pending_ziel.py festgenagelt - 7 Tests, vorher gruen, laufen unveraendert weiter. Zwei Folgefehler fing die Pruefkette sofort: ruff F821 ein verwaistes _t, py_compile ein dangling if. Zwei Tests wurden mitgezogen statt geloescht - test_signal_fill_long ist jetzt umgedreht (unbekannte Quelle darf NICHT als Squeeze durchgehen). Live verifiziert: alle vier Snapshot-Felder weg, Endpunkt tot, auto_squeeze/squeeze_pending unveraendert, 67 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b85dd010ab |
Wiedervorlage fuer den S/R-Wiedereinstieg als pruefbare Bedingung
User fragte "Wiedervorlage fuer wann?" - "irgendwann" ist keine. Jetzt als CHECKS-Eintrag im Reminder mit automatisch pruefbarer Bedingung: 500 entkoppelte Faelle "Gate schliesst, Level bricht doch" aus pbreak_predictions (predicted=bounce, outcome=break) ab dem Nachtrainieren. Stand 55/500, ~4,9/Tag -> faellig um den 10.11.2026. Schwelle bewusst bei 500: loest einen wahren OeR ab ~0,118 auf und deckt damit die UNTERE Backtest-Schaetzung (+0,12) ab. Bei n=175 (~25 Tage) waere nur OeR >= 0,20 aufloesbar - die Bedingung liefe ab, ohne entscheiden zu koennen. Genau dieser Fehler steckte in pbreak_accuracy_v2 (Faktor 10 zu frueh faellig). ⚠ Eigener Fehler beim Aufsetzen, dokumentiert: ich hatte "roh 193 = entkoppelt 193" gemessen und daraus ~17 Faelle/Tag geschlossen. schluessel_level_stunde ist eine FABRIK und muss aufgerufen werden - uebergibt man sie selbst, ist jeder Schluessel ein neues Funktionsobjekt und es wird nichts dedupliziert. Richtig sind 55 = ~4,9/Tag, also 3 Monate statt 3 Wochen. Projektweit geprueft: die zwei echten Verwendungen in analyze_divergence.py rufen sie korrekt auf (mit Spaltennummern) - nur die Ad-hoc-Auswertung war betroffen, die D0-Zahlen stehen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
2b668b8fa2 |
CLAUDE.md: 2-Halbjahres-Ergebnis zum Wiedereinstieg nachgetragen
Der vorige Commit hat das Skript gepusht, die Doku aber nicht - der Python-Heredoc scheiterte an der Anfuehrungszeichen-Falle (ASCII-Quote als deutsches Schlusszitat). Genau davor warnt die Projektregel: keine mehrzeiligen Strings mit Zitaten per Heredoc, den Edit-Weg nehmen. Inhalt: die vorab fixierte Regel ist in keiner Zeile erfuellt. Bei 0,3xATR beidhaelftig positiv (+0,119/+0,196), aber H1s KI enthaelt die Null und der Nachbar 0,5 dreht H1 negativ. Bruchquote 32-45 % nahe der Basisrate - die Plausibilitaetspruefung besteht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3ee2b4114a |
Wiedereinstieg nach S/R-Close: 2-Halbjahres-Backtest faellt durch
Nachfolger des Live-Laufs (n=14, von einem Crash-Tag getragen). 80k M5-Bars, live-treu: Level ueber core.sr_levels.linien (ph/pl getrennt geclustert), P(break) mit den echten _PB_*-Gewichten aus core.engine, Bruch als Barrieren-Rennen, Wiedereinstieg als ruhende Stop-Order mit Fill bei Beruehrung, kanonischer Exit. Bruchquote 32-45 % - nahe der Basisrate ~38 %, die Plausibilitaetspruefung besteht. Ergebnis: die vorab fixierte Regel ist in keiner Zeile erfuellt. Bei 0,3xATR ist der OeR beidhaelftig positiv (+0,119/+0,196), aber H1s Intervall enthaelt die Null und der Nachbar 0,5 dreht H1 ins Negative. Keine Parameter-Robustheit. Fairerweise: zwei gleichgerichtete Haelften sind mehr als eine - "KI enthaelt 0" heisst nicht widerlegt, sondern nicht belegt. H1 ist duenn (285 Closes gegen 1.168), der ATR-Floor filtert die Niedrig-Vola- Periode staerker. Kohaerenter Nebenbefund: die ENGERE Bestaetigung ist besser als die weiteren - dieselbe Mechanik wie bei breakout_k (spaeterer Einstieg verschenkt den Anfang des Moves). Urteil: nicht bauen. Wiedervorlage, wenn 0,3 auch in H1 ein Intervall ueber null liefert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
9e5ea22e08 |
Wiedereinstieg nach falschem S/R-Close gemessen - nicht gebaut
User-Frage: wenn die Linie trotz Abprall-Berechnung bricht, waere ein Neustart des Trades logisch. Der Fall ist kein Randfall - P(break) liegt live bei 38,7 %, das Gate schliesst 94-97 % aller Beruehrungen. Erst ein eigener Messfehler: der erste Lauf meldete 93 % Brueche bei einer Basisrate von 38,7 %. Ursache - ich prueft nur EINE Barriere. Das Training entscheidet per Rennen (Bestaetigung gegen Ablehnung, wer zuerst kommt); eine 0,5xATR-Bewegung binnen 60 min passiert fast immer. Mit dem Rennen: 33 % Brueche, praktisch die Basisrate. Die Plausibilitaetspruefung hat den Fehler gefangen. Ergebnis: n=14, Treffer 71 %, OeR +0,859, ~+501 EUR - aber das 95-%-KI ist [-0,084 ... +1,788] und enthaelt die Null. Und drei Trades tragen alles: die drei groessten Gewinne stammen alle vom 04.08. (TP-Deckel, zusammen +529,92 EUR), die uebrigen 11 ergeben -28,63 EUR. Der 04.08. ist der dokumentierte Ausreisser-Tag. Urteil: nicht bauen. Die vorab fixierte Regel ist verfehlt. Fairerweise widerlegt der bestehende Wiedereinstiegs-Cooldown die Idee nicht - er betraf den ungegateten Sofort-Wiedereinstieg, nicht den bestaetigten Bruch. Sauberer naechster Schritt waere ein Backtest ueber 2 Halbjahre statt 43 Live-Closes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5fb1d7e268 |
M15-Karte: Flacker-Ursache gemessen, Hysterese + EINE Quelle (v=165)
Die Karte wechselte den Zustand alle 12 Sekunden (~1.030/Tag) - der Grund, warum ihre Selbstmessung so stark geclustert war. Mein erster Verdacht (das Level im Wechsel-Schluessel) war falsch. Ausgezaehlt ueber 3.525 Zeilen: status 32,9 %, lesart 32,7 %, level allein nur 7,6 %. Das Level zu entfernen braechte 3.525 -> 3.248, also nichts. Der Zustand selbst zappelt: gap <= 0,5 und das 45/55-Band von P(break) sind stetige Groessen um ihre Schwelle. Das Projekt hatte die Loesung schon (analyze_pbreak_flicker.py, 14.07.: Hysterese +-5 Pp) - die Karte umging sie, weil sie P(break) selbst neu rechnet. Jetzt dieselbe Hysterese auf beide Schwellen: Status gruen ab 0,50 / zurueck erst ueber 0,60; Lesart gerichtet ab 40/60 / zurueck erst innerhalb 45/55. Simuliert: 64 % weniger Wechsel. Zweiter, groesserer Befund: Status und Lesart wurden an DREI Stellen unabhaengig gebildet und wichen bereits ab - der Logger kannte den "kein Veto"-Fall des Frontends nicht, protokollierte also einen anderen Zustand als angezeigt wurde. Jetzt eine Quelle: _m15_setup liefert status/lesart/nah im Snapshot, Logger und Frontend lesen sie. Die alten 3.525 Zeilen sind mit den neuen nicht vergleichbar; die Selbstmessung beginnt faktisch neu (Stichtag 12.08.). Kein Verlust - sie liess vorher ohnehin kein Urteil zu. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e882d795a6 |
M15-Karte: Selbstmessung entkoppelt - 60 % waren 53 %
User fragte nach einer zweiten Karte auf M5. Die Antwort haengt daran, ob die bestehende traegt - und sie misst sich seit 08.08. selbst. Befund: die Karte zeigte 60 % Trefferquote. Zwei Gruende, warum das nichts belegt. (1) Geclustert: m15_accuracy nahm die letzten 200 Zeilen ohne Entkopplung, bei ~990 Zustandswechseln/Tag sind das fuenf Stunden derselben Marktlage. Aus 2.302 rohen bleiben 114 unabhaengige. (2) Regime: das Fenster lief +4,93 $, und roh liest die Karte "auf" zu 62 % richtig und "ab" zu 46 % - das ist der Trend. Entkoppelt: 53-54 %, KI [46 ... 63] - enthaelt die 50. Der handlungsrelevante Zustand (gruen + gerichtet) liegt bei 45,5 %. Behoben: m15_accuracy entkoppelt (Schluessel Level+Stunde) und meldet beide Zahlen. Anzeige jetzt 53 % statt 60 %. Antwort auf die M5-Frage: nein, jetzt nicht - die erste Karte hat kein Urteil, M5 waere teurer (0,193 gegen 0,104), die M5-Information ist grossenteils schon da (Gate 3b rechnet bereits auf M5), und eine zweite Karte verdoppelt die Drift-Flaeche. Offen benannt: die Karte flackert (~990 Wechsel/Tag). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b2a1e35f5e |
rec_outcomes: Fix hat nicht gewirkt - jetzt instrumentiert
Korrektur meiner Behauptung vom 11.08. Nach dem Neustart um 22:45 gab
es bis 09:00 mindestens 10 gerichtete Episoden, und rec_outcomes stand
weiter bei 0 Zeilen. Die Praemisse (falsches dict: s.get("pb_feats")
auf dem MT5Data- statt dem Wave-Snapshot) ist live belegt - die
WIRKUNG des Fixes war es nicht. Ich habe "behoben" geschrieben, ohne
sie zu pruefen.
Warum es von aussen nicht feststellbar war: der except-Zweig loggte
auf DEBUG, der Logger steht auf INFO. Genau die Blindheit, die den
Ausfall fuenf Tage getragen hat.
Jetzt melden sich BEIDE Zweige sichtbar:
- Erfolg: "rec_outcome #<id>: LONG @ <px> atr=<atr>" (INFO)
- Fehlschlag: "rec_outcome NICHT geschrieben: atr=.. px=.. pb_feats=.."
- Exception: WARNING statt DEBUG, mit repr
Es feuert nur bei einem echten Richtungswechsel, also selten - kein
Laerm. Ursache offen bis zur naechsten Episode.
Der Telemetrie-Puls ist der Grund, dass die ausbleibende Wirkung
ueberhaupt auffiel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
b18b594639 |
Systemzustand in den Tagesreport - der fehlende letzte Meter
Selbstaendige Empfehlung nach der Gesamtpruefung, vom User beauftragt. Befund: die Erkennung funktioniert, die Zustellung nicht. Sieben Waechter, jeder nach einem eigenen Vorfall gebaut, jeder funktioniert - und trotzdem blieben diese Woche sechs Zustaende tagelang unbemerkt, vier davon waren bereits erkannt. Belegt an den Marker-Dateien: cfg_auto_sr_close traegt 06.08. 18:10, cfg_auto_squeeze sogar 02.08. Der Config-Waechter meldet je Schluessel genau einmal und schweigt danach fuer immer. auto_sr_close war damit fuenf Tage aus - gemessen +350,81 EUR ueber 43 Trades. Ursache ist ein Kategorienfehler: die Marker-Logik behandelt einen Dauerzustand wie ein Einmal-Ereignis. Gebaut: engine._system_status() als Block im Tagesreport (07:30, Telegram + E-Mail) - der einzige Kanal, der nachweislich jeden Tag ankommt. Saubere Trennung: Popup = "etwas Neues", Report = "so steht es gerade". Reine Anzeige. - telemetrie_puls() liegt in core/history.py, beide Nutzer rufen dieselbe Funktion (Skripte importieren core, nie umgekehrt) - measurement_reminder wird lazy und gekapselt importiert; ein Fehlschlag wird sichtbar gemeldet statt still verschluckt - tests/test_system_status.py: 7 Tests, Schwerpunkt Ausfallpfade - der Report darf an dieser Zeile nie scheitern Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
dca3c11bbd |
Gesamtpruefung 2026-08-11: drei Defekte behoben
Zweiter vollstaendiger Durchlauf nach docs/review-prompt.md.
BEFUND 1: rec_outcomes war seit dem Einbau (06.08.) still tot - 0
Zeilen in 5 Tagen. _run_analysis las s.get("pb_feats"), aber s ist der
MT5Data-Snapshot; pb_feats lebt im Wave-Snapshot. _atr also immer 0,0
und die Schreibbedingung nie erfuellt. Kein NameError (ruff sieht
nichts), und das umgebende except loggt auf DEBUG. Aufgefallen nur,
weil die Tabelle mit 0 Zeilen neben ihren Schwestern stand.
Generalisiert als measurement_reminder.telemetrie_puls(): jede
Telemetrie-Tabelle muss einen Puls haben. Erster Lauf meldet genau
diesen Fund, alle uebrigen gruen.
BEFUND 2: der Divergenz-Waechter war selbst driftend. Abschnitt A
verglich gegen 43 % WARTEN - seit 05.08. ausdruecklich ungueltig (das
misst _build allein); richtig sind 80,5 %. Und entry_room galt als
"live-only", obwohl es seit 04./05.08. modelliert wird.
A: +50,8 Pp Warnung -> +13,3 Pp OK. B: 63,9 % -> 5,0 %.
BEFUND 3: P(break) ist wieder kalibriert (Delta -1,7 Pp nach +14,3 Pp
am 07.08.) - stuetzt den Schluss, dass die gewanderte Basisrate ein
Zeitraum-Effekt war.
Sauber: alle Standardpruefungen, 0 fehlende Frontend-IDs, mt5_lock,
Broker-Zeit, Race-Klasse. Performance: Snapshot-Median 15,9 ms, alle
heissen Abfragen ueber Index - keine Optimierung noetig.
Kein toter Code geloescht: die vermeintlich verwaisten Snapshot-Felder
sind Diagnose-Oberflaeche (vier davon heute zur Deploy-Verifikation
benutzt).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
a866c9cec7 |
S/R-Auto-Close wieder an (User-Entscheidung)
Die Funktion existierte und stand seit 06.08. auf false; der Config-Waechter flaggte das durchgehend. Entscheidend ist die Unterscheidung: der PAUSCHALE S/R-Close ist 2x verworfen (Gewinner-Kappen), der P(break)-GEGATETE ist positiv (H1 +357 R, H2 +1.418 R gegen reines Trailing). Live kontrafaktisch nachgerechnet ueber 43 Trades ab dem Nachtrainieren (31.07.): IST +2.171,72 EUR gegen HALTEN mit dem kanonischen Exit +1.820,91 EUR = +350,81 EUR zugunsten sr_close, besser in 27 von 43 Faellen. Das kehrt analyze_manual_close.py (04.08., -530 EUR) um - jene Messung lief auf dem alten Modell. Die 100 % Trefferquote der sr_close-Statistik ist keine Leistung, sondern Konstruktion: geschlossen wird nur im Plus. Vorbehalte: n=43 in einem Regime, EUR-Faktor geschaetzt, das P(break)-Modell ist live fehlkalibriert (14,3 Pp) und das Gate gatet kaum (94-97 % aller Beruehrungen). Alle drei Stellen angeglichen (Snapshot, runtime_state.json, ini) - sonst bliebe dieselbe latente Inkonsistenz, durch die auto_squeeze unbemerkt aus war. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
8584b2b776 |
Entry-Dialog beim Eroeffnen entfernt (v=163)
User-Vorgabe: "entferne auch die Warnung beim Eroeffnen von Trades". LONG/SHORT feuern jetzt sofort. Was wegfaellt: die 7-Punkte-Checkliste und der Ausrichtungs-Split im Moment der Entscheidung - letzterer zeigte die einzige beidhaelftig robuste Zahl des Projekts (gegen das Signal -6,60 EUR je Lot ueber 1.216 Trades). Bewusste User-Entscheidung, kein Messergebnis; liegt aber auf der Linie "sichtbar machen, nicht bevormunden" (harte Blocks waren nie eingebaut, Uebersteuerungen liefen 68 % Trefferquote). Backend unberuehrt: _entry_checklist rechnet weiter und steht im Snapshot, die Zahlen bleiben auswertbar. Die Verlust-Close-Abfrage bleibt - sie schuetzt vor einem Fehlklick, nicht vor einer Entscheidung. Zurueck: const ENTRY_DIALOG = true. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e8de83143c |
M15-Karte: Klartext-Kopfzeile (v=162)
User: "kannst du die M15-Empfehlung vereinfachen, wie: jetzt long/short
zu xxx Prozent". Der Wunsch ist berechtigt - die Karte war sieben
Zeilen Technik. Die Form nicht: eine Richtungs-Prognose ist ueber 1.071
Live-Episoden mit 48-51 % Trefferquote gemessen (frei AUC 0,52
IN-sample), und die Prozentzahl war als conf_pct nicht kalibriert, in
H2 invertiert. Genau daran ist die Gesamtempfehlung gescheitert und
wurde entfernt - es waere der vierte Rueckfall dieser Karte in die
Veto->Richtung-Falle gewesen.
Gebaut ist stattdessen eine Zeile, die sagt WAS ZU TUN IST, mit der
einen kalibrierten Prozentzahl: P(break) des Einstiegs-Levels (AUC
0,65 oos) - eine Aussage ueber die Struktur, nicht ueber den Trade.
gruen JETZT: LONG-Order bei 78,768 (Abpraller) - haelt zu 75 %
- Ziel 79,033 - SHORT meiden
gelb JETZT: warten auf das Level - erlaubt waere LONG
gelb JETZT: kein Trend-Veto - die Karte gibt hier keine Richtung
rot JETZT: nicht handeln - Spread frisst den Edge
"Erlaubt" heisst nicht "empfohlen"; belegt ist nur, dass die
Gegenrichtung kostet (-6,60 EUR/Lot). 45-55 % bleibt ohne Richtung.
Reine Formulierung, keine Aenderung der Gate-Semantik. Frontend-only,
kein Neustart noetig.
Beim Bau in die Anfuehrungszeichen-Falle gelaufen (ASCII-Quote als
deutsches Schlusszitat -> Unexpected token). node --check hat es
gefangen - genau dafuer wurde es eingebaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
661b99cc88 |
Trailing breiter (Richtung M15) gemessen: faellt durch
User-Frage nach einem Trade, der bei Trail 1,0xATR_M5 nach rund einer
ATR Ruecklauf auf Einstand ausgestoppt wurde.
Die Frage war nicht schon beantwortet: backtest_exit_atr_tf.py (08.08.)
stellte den GESAMTEN Exit auf ATR_M15 (simulate nimmt EINEN atr fuer
SL, Trail, TP und Breakeven - daher das verdreifachte Tail), und
backtest_trailmult.py (31.07.) traf die Frage, lief aber auf M5-Bars.
Genau davor warnt analyze_trail_resolution.py: eine Bar-Simulation
ueberschaetzt enge Trails und unterschaetzt weite - bei 1,5xATR kippte
dort sogar das Vorzeichen. Der Sweep war also mit einer Verzerrung
GEGEN weite Trails gemessen.
Diese Messung kontrolliert das: gleiche Einstiege, gleicher ATR (M5),
Trail-Abstand in Dollar identisch, nur die Exit-Aufloesung variiert;
Zeitgrenzen wall-clock gleich (200 M5-Bars = 1000 M1-Bars, Time-Stop
24 = 120 - der Altbestand kappte M1-Trades nach 200 statt 1000 min).
Ergebnis: 1,86 ("M15") faellt in H1 auf BEIDEN Populationen und BEIDEN
Aufloesungen klar durch (Treffer 25-30 %, PF 0,52-0,64).
Wichtiger Nebenertrag: der Aufloesungs-Einwand ist entkraeftet. Die
Differenz M1-M5 ist bei ENGEN Trails gross und verschwindet bei
weiten. Die feinere Aufloesung bestraft enge Trails, sie belohnt weite
nicht. Der Vorzeichenwechsel vom 05.08. kam aus willkuerlichen
Einstiegen und reproduziert mit echten nicht.
Grenzen: Squeeze n=46/47 je Haelfte, M1-Historie ~55 Tage - die zwei
Haelften sind zwei Haelften EINES Regimes. Keine Aenderung, Trail
bleibt 1,0xATR_M5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
4eb92bf192 |
Telegram: Close-Benachrichtigung ab Schwelle + Auto-Squeeze wieder an
Diagnose zu "ich bekomme keine Telegram-Nachrichten mehr": der Kanal war intakt (getMe/getChat ok, Testnachricht zugestellt, keine einzige Fehlermeldung im Log, Tagesreport kam taeglich). Ursache war, dass ALLE NEUN sendenden Ausloeser aus waren - Auto-Squeeze (ueber runtime_state.json, unbemerkt), Auto-Signal, S/R-Close, Flip-Close, 15-Minuten-Regel, Circuit-Breaker und die drei Notfall-Stop-Modi. Jede Abschaltung war fuer sich begruendet; zusammen ergaben sie eine Stille, die niemand beschlossen hatte. Gebaut: engine._check_close_notify - Telegram bei JEDEM geschlossenen Trade ab close_notify_min_eur (50, 0 = aus). Haengt an keiner Automatik, feuert also auch bei manuellem Close und Broker-SL. Der -87-EUR-SL vom 10.08. kam bisher wortlos. Schwelle aus den Daten: bei ~17 Trades/Tag rund 2,4-6,1 Meldungen/Tag, erfasst 54-80 % des bewegten Geldes. Absolute Euro-Schwelle altert mit der Positionsgroesse - bewusst so, ein Mensch denkt in Euro. Der Unterschied zum frueher entfernten Push ist die Schwelle, und sie liegt in der Engine statt in der DB-Schicht. Vorgemerkt statt sofort gesendet, weil der Flat-Zustand dem DB-Schreiber einen Tick voraus sein kann (exit_time IS NULL heisst "noch nicht fertig"). - tests/test_close_notify.py: 7 Tests, Netz abgefangen - Mutationsprobe in beide kritischen Zweige, beide gefangen - Snapshot-Feld close_notify_min (belegt die Schwelle im Prozess) - Auto-Squeeze wieder AN ueber /api/autosqueeze (ini + runtime_state) - v=161 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
35e91474e8 |
Auto-Squeeze Zuverlaessigkeitspruefung + Wochen-Simulation
Befund 0 beantwortet die Frage vorweg: der Trader ist AUS.
runtime_state.json enthaelt "auto_squeeze": false und ueberschreibt
die ini (true) beim Start - dieselbe Falle wie am 31.07. bei
auto_signal, nur mit umgekehrtem Vorzeichen. Letzter Squeeze-Trade
06.08. 13:52, entry_count 0. Der Config-Waechter meldet es korrekt.
Befund 1: die Mechanik arbeitet. Die Simulation nutzt die echte
_squeeze_one und reproduziert 10 von 11 Live-Trades binnen 10 min
auf wenige Cent genau.
Befund 2: Woche n=47, Treffer 57 %, OeR +0,196, PF 1,37, SumR +9,20
(~+610 EUR bei 2,5 Lots) - im validierten Band. ABER: die Sim
ueberhandelt um das 2,4-fache (kein Live-Dedup/Cooldown), der Edge
stirbt bei 0,20xATR Fill-Slippage, und eine Woche ist Rauschen -
die Phase mit AUSgeschaltetem Trader war sogar die bessere.
Befund 3: auf denselben 10 Einstiegen war der LIVE-Exit 70 EUR
BESSER als der kanonische (-109,52 gegen -179,27). Das widerspricht
dem B4-Befund vom 01.08. ("die Luecke entsteht im Exit"). Der
S/R-Close rettete drei Trades. n=10, gemischt - kein Urteil, aber
ein Warnschild gegen den umgekehrten Schluss.
Befund 4: B5 bei 11/20 Trades, beide Bedingungen weit verletzt
(Verhaeltnis 0,17, PF 0,45 bei 73 % Trefferquote). Formal nicht
faellig.
Offen: zwei Live-BUYs am 06.08. 13:51/13:52 zum identischen Preis
auf einen Ausbruch - moeglicher Doppel-Einstieg, ungeprueft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
06ebb014be |
Eroeffnungsluecken (close_open) gemessen: auch kein Magnet
User-Frage "vielleicht will der Kurs erst die Kursluecke schliessen?" war berechtigt offen: der vorhandene Gap-Befund (backtest_gaps.py) beruht auf der vacuum-Definition, und core/gaps.py sagt ausdruecklich, dass nur die gemessen wurde. Die Klasse, die ein Mensch "Kursluecke" nennt (Schluss -> Eroeffnung, Wochenendluecke), war nie geprueft. 124 Luecken >= 0,50 $ ueber 4.359 D1-Bars, 2 Haelften, Bootstrap-KI. Fuellquote sieht stark aus (75-89 % in 10 Tagen) - die Kontrolle (gleiche Distanz, gleiche Bar, GEGENrichtung) liegt praktisch gleich auf, in H2 bei 3/5/10 Tagen exakt identisch. Alle 24 Differenz-KI enthalten die Null. Kontrolle B: an Nicht-Luecken-Tagen laeuft der Kurs dieselbe Strecke in 10 Tagen zu 73,5 % nach unten und 75,5 % nach oben - die ~75-80 % sind die Basisrate, keine Gap-Eigenschaft. Grosse Luecken >= 1,0 $ kippen zusaetzlich das Vorzeichen zwischen den Haelften (n=22/23). Dritte Bestaetigung derselben Lehre nach Vakuum-Gaps und Fibonacci: die Frage ist nie "faellt/haelt es?", sondern "haeufiger als eine willkuerliche Linie gleicher Distanz?". Keine Aenderung - close_open bleibt reine Anzeige, fliesst weiter NICHT in zone_lines(). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
47c596ed70 |
M15-Karte: Gate 3b zeigt Motor-Block + RAUM je Richtung
Anlass Trade #49671601 (-87,03 EUR). Die Praemisse "SL trotz LONG- Empfehlung" stimmte nicht: 138 Zeilen zwischen Ein- und Ausstieg, 100 % WARTEN (entry_room 76 %, breakout_pending 19 %, min_conf 5 %). Gesehen wurde "verboten: SHORT" - ein Veto. Dritter Fall derselben Veto->Richtung-Umwandlung in dieser Karte (Code 08.08., Geometrie 10.08. frueh, jetzt die Lesart). Der eigentliche Befund: entry_room und Gate 3 lesen DIESELBE Tatsache ("ein Level ist nah") mit umgekehrtem Vorzeichen. Beide gemessen, beide richtig - ueber verschiedene Trades (Markt-Einstieg mit dem Level als Hindernis vs. ruhende Order AM Level). Die Karte zeigte nur die gruene Haelfte; die Block-Grund-Zeile war mit der Gesamtempfehlung verschwunden. Gebaut: Zeile 3b (#m15-motor) mit block_reason im Klartext + Raum je Richtung. Reine Anzeige. Das Status-Banner bleibt bewusst unveraendert - es auf gelb zu ziehen waere eine Strategie-Aenderung, und die einzige Live-Zahl dafuer (-9,91 vs +3,24 EUR/Lot, n=76) hat ein KI, das die Null enthaelt. - wave_rec.room_info(): EINE Implementierung fuer Gate und Anzeige, _room_gate rechnet jetzt darueber (kein Nachbau) - tests/test_room_info.py: Bitgleichheit ueber 2.000 Zufallslagen x 3 Signale, Gate feuerte >300x; Grenzfall-Test fuer die Rundung - v=160 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5474c2be61 |
Gate 4 der M15-Karte: Ziel nur noch in der ERLAUBTEN Richtung
User-Fund: Karte zeigte "verboten SHORT" (= LONG erlaubt) UND ein Ziel 0,15 $ UNTER dem Kurs. Die Arithmetik war korrekt - aber fuer die verbotene Richtung. Ursache: das Ziel war schlicht das entferntere der beiden Level (max nach gap), ohne Richtungspruefung. Strukturell steckte dahinter ein Fade-Trade (Gegenlevel als Ziel = Mean Reversion) in einer Kette, deren Gate 2 ein Trendfilter ist - zwei unvereinbare Konzepte. Damit derselbe Fehler, wegen dem die Gesamtempfehlung entfernt wurde: aus einem VERBOT wird ueber die Hintertuer wieder eine RICHTUNG. Fix nach der gemessenen Population (backtest_m15_gates.py): Einstieg am naechstgelegenen Level, Richtung = die vom HTF erlaubte. Ein Ziel nur, wenn es jenseits dieses Einstiegs in der erlaubten Richtung liegt; sonst "kein Ziel" mit Grund statt einer erfundenen Zahl. Richtung steht jetzt im Anzeigetext. - tests/test_m15_ziel.py (6 Tests, Invariante ueber 32 Konstellationen) - Mutationsprobe: alte Zeile zurueck -> 4 von 6 Tests fallen - deploy.py --feld unterstuetzt jetzt Punktpfade (m15_setup.ziel_grund) - v=159 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b8705e297f |
Kegel mit Adaptive Conformal Inference nachkalibriert (v=158)
Der Kegel war seit dem 31.07. dokumentiert 3-5 Pp ZU ENG - 80 % nominal gegen
real 76,7 / 76,6 / 75,3 % - und blieb es, weil Nachfitten das Problem nur
verschiebt. ACI justiert stattdessen ONLINE nach jedem aufgeloesten Fenster und
konvergiert nachweislich gegen die Zielabdeckung, auch unter Drift.
EHRLICH ZUR BAUART: die Lehrbuch-Form justiert alpha und schlaegt das Quantil
nach. Hier liegt nur eine feste Quantil-Tabelle vor, kein Verteilungsobjekt -
umgesetzt ist die multiplikative Variante:
s <- s * exp(gamma * (1{verfehlt} - alpha_ziel)), gamma 0,02, Deckel 0,7-2,0
Dieselbe Regelungsidee, aber die Konvergenz-GARANTIE der Originalform ist damit
nicht woertlich uebertragen.
Verifiziert: bei exakt 20 % Verfehlern bleibt die Skala bei 1,0000 - der
Fixpunkt stimmt. Simulation aus der dokumentierten Lage (76,6 %): nach ~50
Checks um 80 %. Die Skala pendelt um das Ziel statt exakt zu treffen - das ist
das bekannte ACI-Verhalten (garantiert ist die Langfrist-Abdeckung).
NICHT-UEBERLAPPEND geloggt (neue Tabelle cone_checks): ein 120-min-Fenster alle
5 min waere 24-fach ueberlappend - genau die Cluster-Verzerrung, an der
analyze_hl_funding.py aufgelaufen ist und die die Faelligkeitsbedingung
pbreak_accuracy_v2 um das Zehnfache danebenliegen liess. Je Horizont startet ein
neuer Check erst, wenn der vorige ablief -> 48/24/12 Checks je Tag.
Neustart-fest ueber runtime_state.json. build() ohne skalen liefert bitgenau die
alten Werte (additiv geprueft).
ZWEI EIGENE PLATZIERUNGSFEHLER, beide gefangen: der Lade-Block landete zuerst
HINTER den except-Klauseln von _load_runtime_state, wo st nicht mehr existiert;
und beim M15-Setup landete ein Block mitten in einem mehrzeiligen Aufruf. Der
erste waere stillschweigend nie gelaufen - gefunden nur, weil ich die Funktion
danach gelesen habe statt dem gruenen py_compile zu trauen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
86c432f791 |
M15-Karte misst sich selbst + Ausfuehrungsqualitaet sichtbar (v=157)
Nach Web-Recherche umgesetzt, Punkte 2 und 3 der Wahl. SELBSTMESSUNG (neue Tabelle m15_states): die Karte hatte KEINE Rueckkopplung - geprueft, es gab kein Logging. Das war die auffaelligste Luecke: jeder Ausfall, der in diesem Projekt je aufgedeckt wurde, kam aus einer Rueckkopplung (pbreak_predictions entlarvte den Modellausfall LIVE, was kein Backtest konnte; der B4-Monitor die Squeeze-Drift). Die Karte haette monatelang falsch stehen koennen. Neu: eine Zeile je ZUSTANDSWECHSEL, nach 30/60 min gegen candles_m1 ausgewertet, Ergebnis als Zeile 6 in der Karte. Gewertet wird die LESART, nicht der Status, und nur die gerichtete (45-55 % zaehlt nicht mit). Gegen 50 % lesen. Nur bei Wechsel, nie je Tick - sonst dieselbe Cluster-Verzerrung, die am 07.08. elf widerlegte Hypothesen ausgeloest hat. Live verifiziert: 1 Zeile trotz laufendem Sekundentakt. AUSFUEHRUNGSQUALITAET (Zeile 7): analyze_squeeze_entry_gap.py existiert seit dem 05.08. und misst die TCA-Kennzahl (Arrival-Price-Slippage) - niemand hat je hineingesehen. Dabei war das der einzige Erfolgsmassstab des Stop-Order-Umbaus und zugleich der groesste je gemessene Hebel (+0,32 R). Jetzt steht der Zaehlstand in der Karte: 3 von 12 Bot-Trades seit dem Umbau. NICHT gebaut: der Kegel mit Adaptive Conformal Inference. Er ist mit 76,7/76,6/75,3 % gegen 80 % Nennwert dokumentiert zu eng, und ACI waere die Standardmethode (adjustiert online, garantiert Konvergenz auch unter Drift). Bleibt offen. BEIM BAU EIN NAMEERROR IM 1-SEKUNDEN-PFAD, VOM LINTER GEFANGEN: der erste Entwurf berechnete _m15 in _run_analysis und benutzte es in snapshot(); dort gibt es weder market noch wave_snap. py_compile sieht das NICHT, ruff F821 meldete 4 Befunde. Genau die Fehlerklasse, fuer die der Linter am 07.08. eingebaut wurde - und der erste echte Fang. Zweiter Fehler beim Verschieben: der Block landete mitten in einem mehrzeiligen Aufruf. Beide behoben. DB-Backup: oil_widget_history.db.bak-2026-08-08-m15states Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5ddbe07066 |
Gate 3 mit Richtungs-Lesart - bedingt auf das Level, keine freie Prognose (v=156)
User-Frage: kann die Karte eine Wahrscheinlichkeit fuer steigenden oder fallenden Kurs rechnen? FREI: nein, und das ist gemessen. analyze_reversal.py hat genau das gebaut (logistische Regression, 8 kausale Merkmale, 5 Ereignis-Definitionen): AUC 0,499-0,509 out-of-sample und IN-SAMPLE nur 0,52. Die zweite Zahl ist die entscheidende - das Modell erklaert nicht einmal seine eigenen Trainingsdaten. Kein Overfitting, sondern keine Information vorhanden. Dazu Live-Richtung 48-51 % ueber 1.071 Episoden, Meta-Labeling AUC 0,508/0,479. BEDINGT: ja, und die Zahl ist schon da. P(break) fragt nicht "wohin geht der Kurs", sondern "haelt DIESE Struktur" - bedingt auf ein reales Objekt mit Orders dahinter, AUC 0,65 out-of-sample. Gate 3 formuliert das jetzt aus: Widerstand 77.784 (1,27xATR) -> 56 % Abprall, eher abwaerts Support 77.098 (0,90xATR) -> 65 % Abprall, eher aufwaerts 45-55 % bekommt BEWUSST keine Richtung - dort ist die Zahl ein Muenzwurf, und daraus einen Pfeil zu machen waere derselbe Fehler, den die MQL5-Pfeile schon einmal vermieden haben. Tooltip nennt die Beleglage und die aktuelle Fehlkalibrierung (~7 Pp zu niedrig). Logik mit 6 Faellen geprueft (Widerstand/Support x hoch/niedrig/Muenzwurf). Nebenbefund: node --check hat einen Syntaxfehler gefangen - ein gerades " als schliessendes deutsches Anfuehrungszeichen beendete den String. Genau die in CLAUDE.md dokumentierte Falle; die heute eingebaute Pruefung hat sie sofort gemeldet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
0c81c4e651 |
Die zwei geratenen M15-Schwellen gemessen: beide nicht kalibrierbar
Auftrag: Reichweite (0,5xATR) und Kosten-Schwelle (0,32, von M5) messen statt raten. 2 Halbjahre, Level-Beruehrungen M15, Fill bei Beruehrung, kanonischer Exit, Echtkosten, Episoden-entkoppelt, mit Bootstrap je Zelle. ZUERST EIN ARTEFAKT IM EIGENEN CODE: der erste Lauf stieg sofort zum Level-Preis ein, auch wenn der Kurs 0,9xATR entfernt stand - die Sim schenkte sich diesen Abstand. Ergebnis war "je weiter weg, desto besser" (+0,293 im obersten Bucket, KI ohne Null). Mit Fill bei Beruehrung faellt es auf +0,179. Derselbe Fehler wie beim Momentum-Test, wo OeR +2,2 den Code entlarvte. ERGEBNIS: keine der beiden Schwellen ist kalibrierbar. Abstand xATR H1 OeR H2 OeR 0,00-0,10 -0,227 +0,100 0,10-0,20 -0,130 -0,115 0,20-0,30 -0,306 -0,129 0,30-0,50 -0,112 +0,216 0,50-0,75 -0,039 +0,042 0,75-1,00 -0,040 +0,179 H1 ist ueber ALLE sechs Buckets negativ. Kein Bucket besteht die vorab fixierte Regel. Beim Kosten-Gate dasselbe: nur H2 0,06-0,10 schliesst die Null aus, H1 liegt dort bei +0,016/-0,040. Der eigentliche Befund ist nicht "welche Schwelle", sondern: es gibt nichts zu optimieren. Level-Beruehrungen auf M15 in HTF-Richtung sind in H1 durchgehend negativ. Eine Schwelle kann keinen Edge erzeugen, den die Grundgesamtheit nicht hat. Konsequenz: die 0,5xATR bleiben eine gesetzte Zahl (ehrlich so benannt), das Kosten-Gate bleibt auf M15 dekorativ - beides jetzt gemessen statt vermutet. Einzige schwach gestuetzte Richtung: teuer ist schlechter (H2 0,16-0,20 -> -0,482, KI [-0,949 ... +0,008]). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
6a9b554d54 |
M15-Karte an 7 Tagen getestet: Veto haelt ueber 2 Halbjahre, Woche war Rauschen
Wochentest (test_m15_karte_woche.py, 30.07.-07.08., 93 Episoden) meldete das Veto als FALSCH herum: MIT dem HTF OeR -0,273 / PF 0,56, GEGEN den HTF +0,258 / PF 1,83 - Differenz -0,532 R gegen die erlaubte Richtung. Gegenprobe ueber 2 Halbjahre auf DERSELBEN Population (Level-Beruehrungen, M15): H1 (n=1504) MIT -0,072 / PF 0,87 GEGEN -0,116 / PF 0,80 -> +0,044 R H2 (n=1617) MIT +0,028 / PF 1,06 GEGEN -0,012 / PF 0,98 -> +0,040 R Beidhaelftig konsistent. Die Woche war Rauschen (n=93 gegen n=3121). Dieselbe Falle wie bei der 15-Minuten-Regel und dem Nacht-Guard. Der Verdacht war trotzdem berechtigt: der HTF-Filter ist auf SIGNAL-Entries validiert (backtest_htf_filter.py), nicht auf Level-Beruehrungen. Auf der Level-Population traegt er +0,04 R statt des dokumentierten "Edge x2" - richtig, aber klein. Was der Test sonst zeigt - die Karte ist zu permissiv: gruene Bars je Tag 22-56 von 92 (24-61 %) Episoden je Tag 14,7 Kosten-Gate blockte 0 von 644 Bars Das Kosten-Gate ist auf M15 dekorativ (Spread/ATR ~0,10, Schwelle 0,32). Die Level-Einstiege selbst tragen kaum (OeR -0,072 / +0,028); das Veto macht sie nur weniger schlecht. Die einzige diskriminierende Schwelle (Reichweite 0,5xATR) ist gesetzt, nicht gemessen. Fehler im Test selbst, dokumentiert: der erste Lauf zaehlte 46 fortlaufende gruene Bars als 46 Trades und meldete 7 % Trefferquote - eine Bewegung 46-mal gezaehlt. Erst die Entkopplung macht die Zahl lesbar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
30830d76b1 |
M15-Karte: Bias war ein Richtungsgeber - korrigiert zum Veto (v=155)
Tagestest an 07.08. (test_m15_karte_tag.py) deckt einen strukturellen Fehler in meiner eigenen Karte auf. Rohzahlen: 92 M15-Bars, davon 46 (50 %) auf GRUEN. Entkoppelt auf zusammenhaengende Bloecke bleiben 13 Setup-Episoden - und ALLE 13 waren LONG, an einem Tag, der von 78,399 auf 77,383 FIEL (-1,016 $). Trefferquote 0 %, OeR -0,753, SumR -9,79. Ursache ist nicht Pech, sondern ein Denkfehler: gemessen ist "gegen den M30-Trend zu handeln halbiert den Edge" - eine VERBOTS-Aussage. Ich hatte daraus "M30+H1 einig -> Bias LONG" gemacht, also einen Richtungsgeber. Exakt der Fehler, wegen dem die Gesamtempfehlung entfernt wurde (Richtung dort 48-51 % Treffer). Die nachlaufende EMA zeigt im Trendtag stur in die alte Richtung - dokumentiert seit analyze_signal_live.py. Korrigiert: das Feld liefert nur noch, welche Richtung VERBOTEN ist (bias.verboten); bias.richtung ist dauerhaft None. Das Banner nennt keine Richtung mehr: "BEDINGUNGEN OK @ 77,098 - Order ANS LEVEL, nicht zum Markt - SHORT vermeiden" Zwei weitere Befunde aus demselben Test, offen dokumentiert: - Das Kosten-Gate blockte 0 von 92 Bars. Auf M15 liegt Spread/ATR bei ~0,10, die Schwelle bei 0,32 - das Gate ist dort faktisch dekorativ. - Die strengere Bias-Variante (M30 UND H1) unterscheidet sich kaum von der laxen (46 gegen 47 gruene Bars) - die Zusatzstrenge kostet nichts, bringt aber auch nichts. Auch ein Fehler in meinem TEST, dokumentiert: der erste Lauf zaehlte 46 fortlaufende Bars als 46 Trades und meldete 7 % Trefferquote - eine Bewegung 46-mal gezaehlt. Erst die Entkopplung auf Episoden macht die Zahl lesbar. WARNUNG zur Beweiskraft: EIN Tag ist kein Edge-Nachweis. Belastbar ist hier nicht die Trefferquote, sondern der MECHANISMUS - und der ist aus zwei Halbjahren dokumentiert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e5adfc9757 |
Slippage vs Vola-Regime gemessen + Ziel-Erreichbarkeit gebaut (v=154)
MESSUNG (analyze_slippage_vola.py, 337 SL-Closes): die Exit-Slippage steigt MONOTON ueber alle vier Delta-ATR-Quartile: 0,39-0,91 Schaetzer 0,0200 $ 0,91-1,08 0,0390 $ 1,08-1,26 0,0645 $ 1,26-2,39 0,0839 $ Faktor 4,19x Mechanismus stimmig: die Slip-RATE bleibt flach (20-23 %), die GROESSE waechst (0,094 -> 0,396 $). Es rutscht nicht oefter, sondern weiter. ABER: der Bootstrap auf die DIFFERENZ oben-unten ergibt [-0,012 ... +0,183] - enthaelt die Null. Bei n=85 je Quartil NICHT statistisch belegt. Meine vorab fixierte Regel (Faktor >=2 UND monoton) war damit unterspezifiziert - sie haette ein Konfidenzintervall verlangen muessen. Konsequenz: gebaut als reiner HINWEIS im Kosten-Gate, kein Gate, und die Beschriftung sagt "historisch ~4x hoeher", nicht "belegt". ZIEL-ERREICHBARKEIT (Vorschlag 3, Decay-Clock): reine Geometrie auf dem kalibrierten Kegel - passt das Gegenlevel noch in das 80-%-Band des jeweiligen Horizonts? Live: Ziel 77,784 (0,401 $) liegt im 120'-Kegel, nicht im 30'/60'. Die im Vorschlag mitgedachte Annahme "je laenger, desto eher bricht es" ist BEWUSST NICHT eingebaut - sie ist nicht belegt (Touch-Zahl: umgekehrtes U auf 4 Live-Tagen, im Backtest +0,010 AUC, nach dem Nachtrainieren gar nichts mehr). Umsetzung ohne zweiten MT5-Fetch: _vola_regime puffert den ATR_M15 aus dem ohnehin laufenden Turn-Fetch (deque, ~5 h). Kaltstart liefert datr=null statt zu raten - live verifiziert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
44955bf70a |
M15-Karte "Setup-Bereitschaft" gebaut - Ersatz der Gesamtempfehlung (v=153)
Nach drei negativen M15-Messungen (Squeeze-Einstieg, VWAP-Baender, Exit-ATR) steht fest: auf M15 traegt keine Richtungsquelle. Gebaut ist deshalb bewusst KEINE Empfehlung, sondern eine sequenzielle Gate-Kette: [1 HTF-BIAS M30/H1] -> [2 KOSTEN Spread/ATR_M15] -> [3 LEVEL & KEGEL] -> Order AM LEVEL Der Unterschied zur alten Karte ist grundsaetzlich: dort wurden Stimmen zu einem Bias VERRECHNET (gemessen 48-51 % Treffer), hier muss jedes Gate EINZELN passieren. Ein gefallenes Gate laesst sich nicht durch ein anderes ausgleichen. Nur belegte Bausteine: HTF-Trend (einziger robuster Filter, Edge x2), Kosten (M15 gemessen 0,104 gegen M5 0,193), naechstes stehendes Level + P(break), Kegel (out-of-sample kalibriert, 80-%-Band trifft 77 %), Veto (-6,60 EUR/Lot). Status-Banner: SETUP BEREIT / WARTEN AUF LEVEL / KEIN TRADE. Es bestaetigt ausdruecklich auch das NICHT-Handeln - die gemessene Kern-Leckage sind diskretionaere Abweichungen. Die Order-Buttons werden BEWUSST NICHT gesperrt (gegen den Vorschlag "ausgrauen"): hartes Blockieren wurde im Projekt verworfen, und User-Uebersteuerungen liefen gemessen 68 % WR. Umsetzung: engine._m15_setup() setzt nur zusammen, was der Snapshot ohnehin erzeugt. Neu gerechnet wird allein das M15-Kosten-Verhaeltnis und P(break) fuer das naechste Level. Dafuer veroeffentlicht wave_rec jetzt tf_atr (ADDITIV) - der ATR je Zeitebene wurde im Turn-Fetch laengst berechnet, war aber nirgends abrufbar. P(break)-Merkmale bleiben auf M5 (Modell ist darauf trainiert, Fix 2026-07-13). Mit 5 Szenarien getestet (alles passt, Bias uneinig, Kosten teuer, Level zu weit, Kaltstart ohne ATR_M15 -> kein Absturz), live verifiziert ueber deploy.py --feld m15_setup. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |