f02fd43b3934c5c0be6f21d4128a4a38ba9fed0d
303
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Axel HocksandClaude Opus 5
|
496713b396 |
Meldungen vor Marktkontext (v=173)
User-Wunsch. Reihenfolge im Dashboard war: Trade-Leiste -> M15 -> Marktkontext -> Meldungen. Jetzt: Trade-Leiste -> M15 -> Meldungen -> Marktkontext. Sachlich passend: die Meldungen sind der LIVE-Strom zum laufenden Trade (Squeeze, Ueberdehnung, S/R-Naehe, News-Konflikt), der Marktkontext dagegen Hintergrund ohne Handlungsbezug. Was handlungsrelevant ist, gehoert nach oben. Umgesetzt als reiner Markup-Umzug (kompletter <section>-Block inkl. passendem </section> ueber Tiefenzaehlung, nicht per Zeilennummer). Von hinten nach vorn ersetzt, sonst verschieben sich die Indizes. Verifiziert: Tag-Balance 18/18, 0 doppelte IDs, 0 verwaiste app.js-Referenzen, ausgeliefert steht card-pos jetzt vor card-kontext. Backup index.html.bak-2026-08-19-reihenfolge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3b5706c6bb |
Picos Formular-Hoehe zurueckgenommen (v=172)
User: die Textfelder des laufenden Trades sind viel zu hoch.
ZWEI Pico-Regeln waren schuld:
(1) input{height:calc(1rem*line-height + spacing-vertical*2 + border*2)} --
mit --pico-form-element-spacing-vertical:0.75rem sind das ~3rem = 48px.
Unsere .tb-field-Regel setzt nur padding, KEINE Hoehe -- also gewann Pico.
(2) input{margin-bottom:var(--pico-spacing)} -- nochmal 0,7rem darunter.
height:auto laesst wieder das eigene Padding die Hoehe bestimmen; margin-bottom:0
entfernt den Formular-Abstand. Checkbox/Radio/Range ausgenommen (eigene
Groessenlogik).
Rechnerisch am Handy (Wurzel 16px): vorher ~50px, jetzt ~30px.
Das ist die erste Stelle, an der Pico sichtbar durchgeschlagen hat -- genau der
Fall, den ich beim Einbau angekuendigt habe. Die Bruecke im Kopf von style.css
ist der Ort fuer weitere solche Ruecknahmen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
572c6c0253 |
PicoCSS v2.1.1 als Basisschicht eingebunden (v=171)
User-Wunsch "schreibe auf pico css um".
⚠ EHRLICH ZUM UMFANG: Pico ist KLASSENLOS -- es stylt semantisches HTML
(button, input, article, nav), nicht die ~60 Trading-Klassen (.card, .tb-field,
.m15-item, .px ...). Ein echtes "Umschreiben" ist damit gar nicht moeglich; was
geht, ist eine SCHICHT: Pico liefert Typografie, Formulare, Buttons und
Fokus-Ringe, style.css steht DANACH und gewinnt bei Konflikten.
LOKAL eingebunden (83 KB), kein CDN: die PWA laeuft ueber WireGuard und muss
offline funktionieren; ein CDN-Link waere zudem CSP-blockiert.
Damit Pico das Dashboard nicht in sein Standard-Blau umfaerbt, sind seine
Variablen auf die BESTEHENDE Palette gemappt (--pico-* -> --bg/--card/--accent
...). Zwei Pico-Defaults bewusst ausgeschaltet:
- --pico-font-size: 100% -- Picos eigene fluide Schrift wuerde sich mit
html{font-size:clamp(...)} vom 13.08. MULTIPLIZIEREN.
- Block-Abstaende auf 0,7rem gezaehmt; die Karten bringen ihre eigenen mit.
Dazu drei Ruecknahmen, wo Picos Container-Regeln mit dem Grid kollidieren.
Verifiziert am laufenden Server: pico.min.css HTTP 200 (83.319 Bytes),
style.css 200, data-theme=dark im ausgelieferten HTML, und die Reihenfolge
stimmt (Pico Zeile 14, style.css Zeile 15).
Nebenbefund: das CDN antwortete sofort -- das Netz ist in Ordnung, nur Gitea
ist weiterhin nicht erreichbar.
Backups: index.html.bak-2026-08-19-pico, style.css.bak-2026-08-19
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
d03d6a1a50 |
Dashboard wirklich responsive: Hauptgitter selbstregelnd, Abstaende in rem (v=170)
User: am Handy passen sich die Groessen nicht an.
HAUPTBEFUND: main hatte FESTE 2 Spalten und brach erst bei <=360px um --
moderne Handys haben 390-430 CSS-Pixel. Auf dem Geraet standen also zwei
Spalten a ~190px nebeneinander. Der Breakpoint war schlicht zu schmal geraten.
Jetzt selbstregelnd, ohne geratenen Breakpoint:
main{grid-template-columns:repeat(auto-fit,minmax(320px,1fr))}
360/390/430px -> 1 Spalte · 768 -> 2 · 1024 -> 3 · 1440 -> 4
ZWEITER BEFUND: 138 Abstaende in px, 0 in rem -- die Schrift skalierte seit dem
13.08., die Polster nicht. Damit sass der Text am Handy eng und auf dem Desktop
verloren. Jetzt 122 von 138 auf rem umgestellt (Basis 18px, passend zur fluiden
Wurzel); die verbleibenden 29 sind Werte < 4px, wo Rundung mehr schadet als
nuetzt. Rahmen, Radien und Punktgroessen bleiben BEWUSST px -- die sollen nicht
mitwachsen.
Auch .trades (5 feste Spalten, sprengte 390px) auf auto-fit umgestellt.
Ausgeliefert verifiziert: auto-fit im CSS, 122 rem-Abstaende, HTML zieht v=170.
Backup web/style.css.bak-2026-08-19.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
3a1d8f7687 |
Y-Stapel oben rechts: gemessen statt geschaetzt (Indikator v1.42)
User: oben rechts ueberlagern die Texte immer noch.
ZWEI Fehler in meinem eigenen v1.41-Fix:
(1) Die Y-Zuweisungen standen INNERHALB von if(ObjectFind < 0) -- sie griffen
also nur beim ERZEUGEN. Ein bereits vorhandenes Label behielt seine alte
Position. Denselben Fehler hatte ich bei der X-Zentrierung schon gefangen
und hier trotzdem wiederholt.
(2) Der Faktor 1,8 px je Punkt war nur die NAECHSTE Schaetzung. Bei anderer
DPI-Skalierung waere er wieder falsch gewesen.
Jetzt: LabelH() misst die TATSAECHLICHE Pixelhoehe ueber TextGetSize
(TextSetFont nimmt 1/10 Punkt bei negativer Groesse) und gibt sie +6 px Luft
zurueck; Rueckfall size*2, falls die Messung 0 liefert. Y wird bei JEDEM Redraw
gesetzt.
⚠ TextGetSize verlangt uint& -- mit int& kompiliert es nicht (error 246).
Kompiliert ins richtige Terminal: 0 errors, 0 warnings, .ex5 frisch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
e1a671a137 |
Y-Stapel oben rechts korrigiert (Indikator v1.41)
User: oben rechts die Texte ueberlagern sich. Dieselbe Punkt-statt-Pixel- Rechnung wie gestern links -- OBJPROP_FONTSIZE ist in PUNKT, die alten Formeln behandelten sie wie Pixel. Bei InpPriceSize=20 stand: Kurs y=14, 20 pt -> belegt 14..50 G/V y=44 -> lag MITTEN im Kurs HL y=56 -> lag MITTEN im G/V Jetzt gestapelt mit Faktor 1,8 px je Punkt (konservativ zwischen 1,6 und 2,0, traegt auch 125 % DPI): Kurs 14 · G/V 50 · HL 78 Die Positionen werden deterministisch aus den Schriftgroessen berechnet, nicht ueber eine laufende Variable -- die CSV-Zeilen kommen nicht in garantierter Reihenfolge, ein Akkumulator waere davon abhaengig. Kompiliert ins richtige Terminal: 0 errors, 0 warnings, .ex5 frisch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e471170b01 |
Meldungen zentriert statt oben links (Indikator v1.40)
User-Wunsch. MT5 kennt keine 'Mitte'-Ecke: der Bezugspunkt bleibt CORNER_LEFT_UPPER, aber der ANKER wird auf ANCHOR_UPPER (Text-Oberkante mittig) gesetzt und X auf die halbe Chartbreite. Damit waechst der Text nach beiden Seiten und bleibt bei jeder Fensterbreite zentriert. X wird bei JEDEM Redraw neu gesetzt, nicht nur beim Erzeugen -- sonst haengt die Zentrierung nach einer Fenster-Groessenaenderung auf der alten Breite fest. Startabstand von oben 40 -> 24, weil MT5s eigene Symbol-/Zeitrahmen-Zeile links steht und mittig nicht mehr im Weg ist. Weiterhin ueber InpMeldungY einstellbar, Zeilenabstand bleibt Faktor 2,0 der Schriftgroesse (v1.39). Kompiliert ins richtige Terminal: 0 errors, 0 warnings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
046d9c6948 |
Meldungen oben links neu positioniert (Indikator v1.39)
User: die Anzeigetexte oben links ueberlagern sich. Zwei Fehler im alten
'16 + i*(size+6)':
(1) START zu hoch -- MT5 zeichnet oben links SELBST die Symbol-/Zeitrahmen-
Zeile; y=16 landete mitten darin. Beleg: es ueberlagerte sich, obwohl nur
EINE MS-Zeile aktiv war -- es konnten also gar nicht zwei Meldungen sein.
(2) ABSTAND zu knapp -- OBJPROP_FONTSIZE ist PUNKT, nicht Pixel; 10 pt rendern
je nach DPI 16-20 px. Bei 16 px Zeilenabstand ueberlappen mehrere
Meldungen zwangslaeufig.
Jetzt Startabstand ueber InpMeldungY (40) und Zeilenabstand Faktor 2,0.
Kompiliert ins richtige Terminal: 0 errors, 0 warnings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
adcae09317 |
Ruhende Messungen als RUHT markieren statt als "sammelt"
Zwei Messungen brauchen SQUEEZE-Trades, und auto_squeeze ist seit dem 11.08.
aus -- seit dem 17.08. auch begruendet (B5-Regel gefallen). Ihre Zaehler stehen
seither still: Stop-Order-Umbau 8/12, Nacht-Fenster 3/15.
Als "sammelt (67 %)" angezeigt suggerierten sie einen Fortschritt, den es nicht
gibt: sie laufen NIE ab. Jetzt erscheinen sie als
⏸ ... [RUHT] 8/12 ... -- steht STILL
braucht SQUEEZE-Trades -- auto_squeeze ist AUS ...
RUHEND heisst: die Messung ist nicht langsam, sie ist BLOCKIERT -- und die
Blockade ist eine ENTSCHEIDUNG, keine Datenfrage. Wer den Trader wieder
einschaltet, laesst beide automatisch weiterlaufen; es ist nichts nachzuholen.
Umsetzung: RUHT-Tabelle mit je einer Pruef-Funktion; _auto_squeeze_an() liest
core.live_config (ini + runtime_state in der Vorrangfolge des Engine-Starts).
Faellt die Pruefung aus, gilt "nicht ruhend" -- lieber ein Zaehler zu viel als
eine still verschwundene Messung.
Die sechs uebrigen Messungen laufen unveraendert als "sammelt".
⚠ Beim Bau in die dokumentierte \n-Falle gelaufen: ein per Heredoc geschriebenes
f"\n..." wurde zum echten Umbruch im String-Literal (SyntaxError). CLAUDE.md
sagt genau das ("NIE per Heredoc -- den Edit-Weg nehmen"); ueber den Edit-Weg
behoben, check_nfalle laeuft sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
7a832c4f40 |
Zwei Waechter-Fehlalarme behoben (auto_squeeze-Erwartung, candles_m1-Vorbedingung)
Bei der Durchsicht offener Punkte gefunden -- beide derselben Klasse: ein
Waechter, der dauerhaft warnt, wird ignoriert, und mit ihm die eine echte
Meldung (so ist der Divergenz-Waechter verstummt).
(1) Config-Waechter erwartete auto_squeeze='true' und meldete deshalb seit dem
11.08. taeglich eine Abweichung -- obwohl FALSE inzwischen der begruendete
Zustand ist: die B5-Regel ist am 17.08. rechnerisch gefallen (Verhaeltnis
0,14 gegen Latte 1,0, PF 0,39, Latte unerreichbar). Erwartung auf 'false'
gedreht, mit dem Hinweis, dass ein Wiedereinschalten eine NEUE Entscheidung
mit NEUER Latte waere -- dann gehoert der Eintrag zurueckgedreht.
(2) Telemetrie-Puls meldete candles_m1 als Ausfall ("letzte Zeile vor 0,5 h").
Real war der Markt zu -- Pepperstone schliesst ~23:00 und das ganze
Wochenende. Der Logger hatte gestern erst die Vorbedingungs-Kennzeichnung
fuer pbreak_predictions/rec_outcomes bekommen; candles_m1 stand noch auf
"unbedingt". Jetzt mit Vorbedingung -> erscheint als Hinweis statt Ausfall.
0 Zeilen bleibt weiterhin IMMER ein Befund.
Verifiziert: Puls zeigt beide als Hinweis, Config-Waechter still.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
30ed913678 |
Beschriftung der Konsolidierungs-Box entfernt (Indikator v1.38)
User-Wunsch. Die sichtbare Beschriftung ("Konsolidierung (10-Bar-Spanne)" bzw.
"Konsolidierung - komprimiert, Ausbruch steht bevor") kam in v1.30 auf die Frage
"was bedeutet die graue Box" und stand seither dauerhaft im Chart.
Der erklaerende Text bleibt als TOOLTIP an der Box -- die Information geht also
nicht verloren, sie draengt sich nur nicht mehr auf. Die Box selbst und ihre
Farbgebung (komprimiert/normal) bleiben unveraendert.
Ein evtl. noch vorhandenes Alt-Objekt aus v1.30-v1.37 wird beim ersten Redraw
geloescht: ObjectsDeleteAll(0, PFX) raeumt zwar ohnehin, aber nur solange der
Indikator laeuft -- nach einem Versionswechsel ohne Redraw bliebe es sonst
stehen (dieselbe Alt-Objekt-Falle wie bei den HL-Pfeilen).
Kompiliert ins richtige Terminal: 0 errors, 0 warnings, .ex5 frisch, Version im
Terminal gegengeprueft, nur noch die Loeschzeile enthaelt TCONSOL.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
ca61cf1498 |
S/R als ZONE statt Linie (RZ/SZ, Indikator v1.37)
User-Wunsch nach einem TradingView-Bild: Resistance Zone und eine untere Zone
als farbige Baender. Neu RZ;lo;hi und SZ;lo;hi, im Indikator als OBJ_RECTANGLE
mit Beschriftung, nach rechts verlaengert.
DIE BREITE IST ECHT: sie ist die Spanne der M30-Pivots, die den Cluster gebildet
haben (sr_levels.zonen(), additiv -- cluster() bleibt unveraendert, weil es den
S/R-Auto-Close speist). Live verifiziert: R;82.786 liegt in RZ;82.776;82.797,
S;82.15 in SZ;82.14;82.16. Einzel-Pivot bekommt 0,10xATR Mindestbreite.
ZWEI ABWEICHUNGEN VOM VORBILD, beide begruendet:
(1) KEIN Fibonacci. Das Bild leitet seine Zone aus 0,618/0,658 ab. Fib ist hier
gemessen und verworfen (04.08.): 54,3/54,5 % Haltequote gegen 55,7/53,8 %
einer Zufallslinie gleicher Distanz, und schlechter als M30-Pivots.
(2) Die untere Zone heisst SUPPORT, nicht "Cumulative Long Liquidation". Echte
Liquidationsdaten hat das Projekt nicht; die HL-Waende sind am 17.08. als
reaktiv gemessen. Bricht die Support-Zone, liegen dort die Long-Stops --
dieselbe Stelle, ehrlich benannt.
Abschaltbar InpShowZonen. Kompiliert ins richtige Terminal (0/0), deployt,
verifiziert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
8d17cf08e0 |
Verdict-Module gemessen (2. Durchgang) + Faelligkeitsschwelle zaehlte die falsche Groesse
FAELLIGE MESSUNG (30.282 Zeilen). Horizont 60 min, gegen die Drift-Null, Episoden statt Rohzeilen: Welle 3,0 254 Ep. +0,158 / +0,419 61 % beide + Liq-Trend 0,5 297 Ep. +0,310 / +0,175 52 % beide + Squeeze 2,0 249 Ep. +0,110 / +0,254 48 % beide + Orderbuch 0,5 2.712 Ep. -0,039 / -0,100 49 % beide - Elliott 1,0 1.388 Ep. kippt 49 % M30/Muster/H1 kippen H1 1,5 50 Ep. -1,165 / +1,937 66 % kippt Meine Vermutung vom 07.08. war FALSCH: Liq-Trend besteht (+0,310/+0,175 ueber 297 Episoden). Ich hatte ihn verdaechtigt, weil er dieselbe HL-Quelle nutzt wie das entmachtete Orderbuch -- das war Analogie, keine Messung. Bleibt bei 0,5. Orderbuch bestaetigt: beidhaelftig negativ ueber 2.712 Episoden, die groesste Stichprobe und der einzige konsistent falsche Beitrag. Entmachtung war richtig. SCHAERFSTER BEFUND: H1 traegt 41,2 % des Nadel-Einflusses auf 50 Episoden, die das Vorzeichen kippen. Hoechster Einfluss, duennste Beleglage. Live folgenlos (die Nadel ist reine Anzeige), aber wer sie liest, sollte es wissen. FAELLIGKEITSSCHWELLE KORRIGIERT: stand auf 25.000 ZEILEN -- bei Minutentakt in 12 Tagen erreicht, waehrend die auswertbare Einheit Episoden sind (je Modul nur 50 bis 2.712). Dieselbe Klasse wie pbreak_accuracy_v2. Jetzt 400 Headline-Episoden als Proxy, mit dem ausdruecklichen Hinweis, dass es je Modul deutlich weniger sind. PUNKT 2 (Stop-Order-Umbau, 8/12): DERSELBE DEADLOCK wie B5. Alle acht Bot-Trades stammen vom 06.08.; seit auto_squeeze am 11.08. aus ist, kommt keiner mehr dazu. Was die 8 zeigen, bleibt gueltig und positiv: 7 von 8 fuellten per ruhender Order, Market-Fallback praktisch weg (n=1 bei +0,148xATR). Die formale Faelligkeit haengt an derselben Entscheidung wie B5, nicht an weiteren Daten. Nichts am Live-System geaendert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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>
|