cf94679022badbf9306dfcdb24dcbfb8bfc32591
69
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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
|
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
|
3c1442109d |
Pending-Fill: Bot-Trades wurden nicht als solche gebucht
Auftrag "überprüfe die heutigen autotrades": die DB meldete für den 06.08. null Bot-Trades, das Log vier gefüllte SQZ-STOP-Orders. Beides stimmte. Ein Pending-Fill läuft nicht über engine._open — die Position wird von trader._refresh_locked per magic-match adoptiert, und dieser Pfad loggt nur Ticket/Symbol/Richtung/Lots/Preis. Es fehlten setup, sl_at_entry und alle 16 ctx_*-Spalten. Damit war genau die Messpipeline, die den Pending-Umbau vom 05.08. kontrollieren soll, blind für ihn (B4-Monitor, squeeze_b5, squeeze_entry_gap zählten null) — Deployment-Drift Fall 8, erste Variante, bei der nicht die Strategie driftet, sondern ihre Beobachtbarkeit. - history.tag_bot_trade(): UPDATE nur wenn setup IS NULL, stiller Fail-open - engine._pending_tickets: Ticket -> Quelle, beim Platzieren/Stornieren gepflegt - engine._check_pending_fill() im _pos_loop vor dem Pending-Manager; Zuordnung über Positions-Nr == Order-Nr (an allen 4 Fills verifiziert), setzt zusätzlich _bot_open_ticket/_source und die Entry-Zähler 6 Szenarien getestet, darunter die zwei gefährlichen: fremde Position wird nicht getaggt, derselbe Fill zählt bei Folge-Ticks nur einmal. Die 4 Trades des 06.08. nachgetragen (Backup .bak-2026-08-06). ctx_*/sl_at_entry bewusst NICHT nachgetragen: rekonstruiert wären sie später von gemessenen Werten nicht unterscheidbar. Dabei gefunden, dokumentiert, NICHT behoben: der Signal-Pfad setzt/storniert dieselbe Order 4x in 76 s bei identischem Level, weil block_reason zwischen entry_room und breakout_pending pendelt (Drift Fall 9). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
730219fce8 |
Wenige Empfehlungen nachgeprueft: Telemetrie-Luecke bei min_conf gefunden und
geschlossen Der 05.08. hat 1427 Zeilen geloggt (Soll ~1440), die Erfassung ist also intakt. 5,0 % gerichtet - und auffaellig ist die Verteilung: alle 71 gerichteten Empfehlungen fielen vor 10:00, danach 16 Stunden lang genau eine. Gegen den gueltigen Massstab (backtest_dist_gated.py, 19,5 % gerichtet) ist entry_room NICHT der Unterschied - es ist live mit 36,5 % sogar seltener als im Backtest (41,4 %). Die Luecke tragen die live-only-Gates, allen voran min_conf (16,1 % live gegen 0,9 % im Backtest), dazu htf_counter, EIA und stale. Telemetrie-Luecke: min_conf-Zeilen schrieben conf_pct = 0, die verworfene Konfidenz stand nur als Fliesstext in den Gruenden. Damit war beim zweitgroessten Blocker nicht feststellbar, ob die Signale knapp (50-54) oder weit (20-30) unter der Schwelle lagen. wave_rec._build gibt den Wert jetzt mit - reine Telemetrie, das Signal bleibt WARTEN. Erste Live-Zeile: conf 52. Das beantwortet noch nicht, ob 55 die richtige Schwelle ist: backtest_conf.py hat das Band 40-54 % als negativ gemessen, eine Senkung ist nicht angezeigt. Die Zahl sagt nur, wieviel Signalmenge direkt hinter der Schwelle steht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
a1a5d560b9 |
Charts-Tab komplett entfernt (User-Vorgabe)
Entfernt: Tab-Button, #view-charts, der gesamte app.js-Chart-Block (Kartenaufbau, renderChart, loadCharts, 20-s-Refresh, Resize-Handler), die Chart-CSS-Regeln, die vendorte Bibliothek web/lightweight-charts.standalone.production.js (164 KB) samt script-Tag - und die Backend-Kette dahinter: /api/bars und engine.get_bars (60 Zeilen). Beide existierten ausschliesslich fuer dieses Tab; geprueft, dass es keinen anderen Aufrufer gibt. Nicht betroffen (sahen nur aehnlich aus): die Chartmuster-Karte (Verdict-Gewicht 0,25, im Tab "SIG Live"), der MQL5-Indikator samt sr_levels.csv-Export (eigener Pfad ueber _write_levels_file) und die Analyse-Module structure/patterns/cone - die speisen den Snapshot, nicht das Chart. Der MT5-Chart bleibt voll bedient. Ein veralteter Kommentar in trader.py, der auf engine.get_bars verwies, wurde auf core/gaps.py umgehaengt. Verifiziert am laufenden Server: /api/bars -> 404, Bibliothek -> 404, data-view="charts" und id="view-charts" nicht mehr im ausgelieferten HTML, 6 Tabs zu 6 Views paarig, keine verwaisten JS-Referenzen, Klammern-Balance ok, keine Fehler im Log. v=142. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
7009541c42 |
Squeeze-Trades bekommen den SL aus M5-ATR (User-Entscheidung), TP unveraendert
trader._calc_sl_tp bekommt die ATR-Zeitebene als Parameter (Default SL_TF = M15); _send/_send_locked/open_long/open_short und place_stop reichen sie durch. Gesetzt wird sie an genau zwei Stellen: engine._open bei source="auto_squeeze" und _manage_squeeze_pending bei quelle="squeeze". Manuelle Trades und Auto-Signal bleiben bei M15. Grundlage backtest_sl_basis.py: auf Squeeze-Entries ist der Ertrag zwischen beiden Basen ein Wash (alle Varianten innerhalb eines Standardfehlers), der Worst-Case sinkt aber von -8,83 auf -2,44 xATR_M5 = Faktor 3. Auf der Wellen-Population ist der weite M15-SL in BEIDEN Haelften besser - deshalb bewusst keine globale Umstellung. Die Multiplikatoren (1,8-2,2 xATR) sind nicht angefasst, nur die Zeitebene. TP bewusst NICHT betroffen (User: "nur fuer SL, der TP soll mit dem Runner mitwachsen"). Geprueft statt angenommen: der von _calc_sl_tp zurueckgegebene TP wird von KEINEM Aufrufer gesendet, beide setzen nur req["sl"]. Das Ziel verwaltet trailing.py dynamisch (3,5 x ATR der Wellen-Zeitebene). Warnkommentar im Code, warum der TP dort nicht mit in die Order darf. 4 Szenarien getestet. Dabei eigene Fehlannahme korrigiert: ohne Pivot greift der 1,2-%-Fallback, der beim M15 vom MINDEST-Deckel aufgeweitet wird - die 2,2x-Obergrenze wird dort gar nicht erreicht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
90d77a2305 |
Pending-Pfad fuer SIG: ruhende Stop-Order am Bestaetigungs-Level
SIG laeuft damit auf der gemessen positiven Variante (OeR +0,35/+0,32, PF 2,2) statt auf der Market-Order (-0,09/-0,11). Der heikelste Punkt war nicht die Order, sondern die Kollision beider Pfade: trader.pending_orders() liefert ALLE magic-gleichen Orders, zwei getrennte Manager haetten sich gegenseitig storniert - sporadisch und im Log kaum erkennbar. Deshalb EIN gemeinsamer Ziel-Zustand (engine._pending_ziel), der Manager gleicht nur noch ab. Vorrang Squeeze > Signal (unabhaengig validiert, selten; das Signal feuert dauernd, es gibt einen Positions-Slot). Zwei additive Ergaenzungen in wave_rec._confirm_breakout: das Bestaetigungs-Level wird auch NACH der Bestaetigung veroeffentlicht (die Nachjagd-Bremse braucht es genau dann; pending bleibt False, Frontend unberuehrt), und conf = die Konfidenz VOR dem Stummschalten - sonst muesste die ruhende Order blind platziert werden. Nachjagd-Bremse jetzt auch fuer SIG (0,20 xATR, Haertetest-gedeckt). 12 Szenarien getestet, live am Snapshot verifiziert. Snapshot-Felder squeeze_pending_levels -> pending_levels + pending_quelle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5f70980e59 |
Erfolgskontrolle fuer den Stop-Order-Umbau: Skript + Reminder
analyze_squeeze_entry_gap.py fuehrt die zwei noetigen Quellen zusammen - das Ausbruchs-Level steht NUR im Log, der tatsaechliche Fill NUR in trades - und splittet am Umbau-Stichtag. Die Erfolgsmeldung ist paradox: eine per Pending gefuellte Order erzeugt KEINE AUTO-SQUEEZE-ENTRY-Logzeile (die entsteht nur im Market-Fallback), Squeeze-Trades ohne Log-Treffer sind also der Erfolg. Das Skript weist sie deshalb getrennt aus. Als Messung squeeze_entry_gap im measurement_reminder.py hinterlegt (>=12 Squeeze-Trades ab dem Umbau). Stichtag exakt 05.08. 08:55 statt Mitternacht - der 08:33-Trade lief noch ueber die Market-Order und haette die Zaehlung verfaelscht (0/12 statt faelschlich 1/12). Zahlen-Korrektur: die zuerst dokumentierten +0,306 / +0,741 xATR stammten aus einer Scratchpad-Auswertung mit FESTEM Stundenversatz. DST-korrekt ueber zoneinfo sind es +0,275 / +0,686 (n=34 unveraendert). In CLAUDE.md, engine.py, trader.py und der ini nachgezogen; die Schlussfolgerung aendert sich nicht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5e0e8b00ca |
Squeeze-Einstieg ueber ruhende Stop-Orders + Meta-Labeling gemessen (verworfen)
1) STOP-ORDER STATT MARKET (gebaut, live). engine._manage_squeeze_pending haelt beide Box-Grenzen mit BUY_STOP/SELL_STOP bestueckt, solange der Squeeze armed ist; trader.place_stop/cancel_pending/pending_orders neu. Groesse und SL kommen aus denselben Funktionen wie die Market-Order, nur bezogen auf den Trigger. OCO-Ersatz: faellt eine Seite, wird die andere im selben Tick storniert. Der kritische Punkt bei einer ruhenden Order sind die Gates - sie waren bisher Laufzeit-Checks im Market-Pfad. Neu: engine._squeeze_guard() als EINE Quelle fuer beide Wege, jeden Tick neu bewertet; schlaegt ein Gate zu, werden die Orders storniert. Market bleibt Fallback mit Nachjagd-Bremse squeeze_max_chase_atr=0.20 (gemessen der noch positive Bereich). Behandelt: Broker-Mindestabstand, falsche Marktseite, Toleranz 0,02 xATR gegen Order-Churn, Log nur bei Fehleraenderung, Startup-Schonfrist. 10 Szenarien getestet, live am Snapshot verifiziert. 2) META-LABELING (backtest_metalabel.py) - VERWORFEN. Zweitmodell auf 12 kausalen Merkmalen, Fit/Test in BEIDEN Richtungen: AUC 0,508 und 0,479 = Muenzwurf, Kalibrierung im Top-Bucket 74 % vorhergesagt gegen 39 % real, und 8 von 12 Gewichten kippen das Vorzeichen. Die scheinbar besseren Schwellen sind reine Handelsvermeidung und reproduzieren gegenlaeufig nicht. 23. verworfener Signal-Eingriff - deckt sich mit dem Caveat der Quelle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
cc4f1a0863 |
Provider-Failover bei hartem Fehlschlag + Einsatz-Prozentfeld im Dashboard
1) LLM-Failover (core/agent.py): ein hart gescheiterter Provider wird zeitweise uebersprungen, analyze() nimmt den naechsten aus der Kette. Hart = 401/402/403/ 404 (Key/Guthaben/Modell) -> 30 min, nicht erreichbar -> 5 min. Timeout/429/5xx loesen BEWUSST keinen Wechsel aus (voruebergehend; sonst kostet jede Lastspitze die volle Timeout-Summe aller Anbieter). Neu im Snapshot: agent.provider_dead mit Restminuten - der DeepSeek-Ausfall stand vorher nur im Log und blieb deshalb 18 h unbemerkt. 9 Szenarien getestet. 2) Einsatz-Prozentfeld (web, v=137): margin_buffer_pct hatte bisher keine UI. Neues Feld "Einsatz %" neben "Einsatz EUR", POST /api/marginpct -> engine.set_margin_pct -> config.set_margin_buffer, Snapshot margin_pct, neustart-fest. Der feste EUR-Betrag hat Vorrang; das Prozentfeld wird dann ausgegraut, damit nicht unklar bleibt was gilt. Auf 1-99 % geklemmt. Ende-zu-Ende getestet (50, 150->99, 0 und -5 abgelehnt, 95, persistiert). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
1c9bb34095 |
Auto-Squeeze-Nachtsperre von 0-7 auf 3-6 Uhr verkuerzt (User-Vorgabe)
Gemessen (backtest_cost_gate.py, Teil 2): es gibt KEINE toten Stunden - alle 24 Stunden sind in beiden Halbjahren positiv, keine ist beidhaelftig negativ. Std 0 ist sogar die staerkste des Tages (OeR +1,48/+1,51) und lag im alten Gate. Jedes Fenster kostet also Ertrag; die Sperre kauft ausschliesslich Beaufsichtigungs-Ruhe. Gewaehlt wurde deshalb nach PREIS, nicht nach Edge: 3-6 ist das guenstigste Fenster mit noch >=4 h Schutz (SigmaR -12,5/-62,9 gegen -42,4/-242,6 bei 0-7 = ~27 %). Freigegeben: 0, 1, 2, 7 Uhr. Die 4-h-Untergrenze ist gesetzt, nicht gemessen. Umsetzung: neues [trading] auto_squeeze_night_hours (Default 3,4,5,6, leer = aus), genutzt von _check_auto_squeeze und _check_auto_signal. _SQUEEZE_NIGHT bleibt als STATISTISCHE Nacht-Definition fuer Entry-Checkliste und B4-Monitor - dort gilt die Kostenfalle weiter und der Altdaten-Vergleich bleibt stabil. 7 Parse-Faelle getestet (Default, fehlender Schluessel, leer, Muell, Rueckwaerts-Kompatibilitaet). Live verifiziert am NEUEN Snapshot-Feld squeeze_night_hours = 3,4,5,6 und am Startup-Log; genau eine Instanz auf 8000. Offen und als Reminder hinterlegt: der Backtest modelliert keine Slippage, und die freigegebenen Stunden liegen in der duennsten Liquiditaet. Nach 15 Squeeze-Trades aus 0/1/2/7 Uhr gegen die Erwartung pruefen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
6af4c868bc |
Feste Einsatz-Margin (UI-Feld) + lokale Sprachausgabe via Piper
EINSATZ-FELD (User-Wunsch): Laufzeitwert MANUAL_MARGIN in core/config.py (set/get_manual_margin, Muster wie set_margin_buffer). 0 = automatisch wie bisher (margin_buffer_pct % der freien Margin), > 0 = Position wird auf genau diesen Margin-Einsatz gerechnet. - calc_lots setzt es um und DECKELT auf freie Margin x Buffer; ein zu hoher Wunschwert wird begrenzt und geloggt statt an den Broker durchgereicht. Reicht der Betrag nicht fuers Mindestlot -> 0.0 + Warnung, Trade sauber abgelehnt. - Vorrang vor dem Risiko-Modus in trader._send_locked: eine ausdrueckliche Groessenvorgabe schlaegt die Rechenregel. - Wirkt auf ALLE neuen Positionen, auch die autonomen. - UI-Feld "Einsatz" in der ORDER-Leiste (nicht in der Trade-Leiste: die ist nur bei offener Position sichtbar, der Einsatz muss vorher einstellbar sein), bernstein umrandet solange gesetzt. Enter blurrt nur, change sendet einmal. - POST /api/manualmargin, Snapshot manual_margin, neustart-fest ueber runtime_state.json. Ende-zu-Ende getestet (250 -> Snapshot -> 0 -> persistiert). - Lot-Logik isoliert geprueft: 200 EUR -> 0,58 Lots; 5000 EUR -> gedeckelt. SPRACHAUSGABE: Piper lokal (tools/speak.py). Windows-TTS funktioniert zwar, aber es ist KEINE deutsche Stimme installiert - weder SAPI5 noch OneCore (nur David/Zira/Mark, en-US); deutscher Text kaeme mit englischer Aussprache. Add-WindowsCapability scheitert ohne Adminrechte. Piper gewaehlt: laeuft lokal (passt zum Rest - WireGuard-only, Secrets in der ini, keine Cloud), kostet nichts, aus PowerShell/Python aufrufbar. Stimme thorsten-medium (de_DE), Real-Time-Faktor 0,08 (4,3 s Audio in 0,36 s). Das ZIP entpackt eine Ebene tiefer als erwartet (tools/piper/piper/piper.exe) - speak.py SUCHT Binary und Modell statt Pfade fest zu verdrahten. Der erste Entwurf scheiterte daran; der Fail-safe meldete die Pfade sauber statt stumm zu bleiben. Drei Modi getestet (Argument, Pipe, --wav). tools/piper/ ist gitignored (Binaries + 60-MB-Modell), speak.py versioniert. v=136. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
33b6b8f629 |
Letzte Trades: 5 -> 10 (User-Wunsch)
Zwei unabhaengige Begrenzungen mussten mitgezogen werden: - engine.snapshot -> history.last_closed_trades(5) -> (10) - app.js -> slice(0, 5) -> slice(0, 10) Nur eine davon zu aendern haette still weiter 5 gezeigt; beide sind jetzt gegenseitig im Kommentar vermerkt. Verifiziert: Snapshot liefert 10 Trades, v=135 ausgeliefert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
da7d8f5b90 |
Stufe 1: voller Entscheidungskontext beim Einstieg + Karte "Manuelle Trades"
Frage: kann der Bot aus den manuellen Trades lernen? Vorpruefung: noch NICHT.
1) Die entscheidenden Merkmale wurden nie gespeichert - beim Einstieg nur 5
Felder, davon ai_sentiment in 1,4 % und news_score in 34 % befuellt.
2) Das naive Lernziel ("wann steigt er ein") braucht unbeschriftete Negative;
brauchbar ist nur "welche Einstiege liefen gut" (Labels ueber P&L).
3) Die scheinbaren Muster sind Einzeltage: Stunde 13:00 zeigt +478 EUR ueber
n=69, davon +382 EUR (80 %) aus den fuenf Trades des 04.08.
Gebaut wurde Stufe 1 - reine Telemetrie, kein Verhalten:
- trades um 16 ctx_*-Spalten erweitert (DB-Backup .bak-2026-08-04, 1.148 Zeilen
unveraendert): p_break_target/-stop, dist_res_atr/dist_sup_atr, structure,
squeeze, htf_trend/h1_trend, spread_atr, session, block_reason, conf_pct,
atr_m5, bias, cone_pos, hour
- log_trade_open haengt die Spalten dynamisch an und ignoriert unbekannte
Schluessel -> aeltere DB ohne Migration laeuft weiter (fail-open)
- Kette: engine._run_analysis -> trader.set_open_context(ctx=) -> log_trade_open
Fallstrick beim Bau: wave_snap existiert in _run_analysis NICHT (nur in
snapshot()). Der erste Entwurf haette einen NameError erzeugt, den das umgebende
except still geschluckt haette - der Kontext waere dauerhaft leer geblieben ohne
dass es auffaellt. Jetzt self.wave.snapshot(); vd zusaetzlich per locals()-Guard.
Verifiziert auf einer DB-KOPIE: alle 16 Spalten korrekt geschrieben, unbekannter
Schluessel ignoriert, Basisfelder unberuehrt. Snapshot liefert manual_stats.
Dashboard-Karte "Manuelle Trades" (#card-manual, v=134): heute / 30 Tage /
gesamt / Bot-Vergleich plus Split mit vs ohne Signal-Deckung. Backend
history.manual_stats(30) mit ~120-s-Cache wie _alignment_cached. Bewusst neutral
gefaerbt und deskriptiv; eine Reifegrad-Zeile nennt die ctx-Abdeckung (heute
0 %), damit die Karte nicht ueberschaetzt wird.
Stufe 2 NICHT gebaut: erst bei ausreichender ctx-Abdeckung messen, was Gewinner
von Verlierern unterscheidet (Fit H1, validiert H2, AUC + Kalibrierung). Ergebnis
waere ein Hinweis im Order-Dialog, ausdruecklich KEIN Auto-Entry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
dcdd53b703 |
Winkel-Beschriftung korrigiert (Zahlen unveraendert) + Spiegeltest bestanden
Anlass: "pruefe die Logik im umgekehrten Fall, fallender Kurs". 1) Spiegeltest bestanden. Mit reversal_enabled=false ist das Verhalten ueber die ganze Ueberdehnungs-Spanne exakt symmetrisch (steigend/LONG <-> fallend/SHORT): gleiche Signale, gleiche Konfidenz, gleicher Anti-Ueberdehnungs-Schnitt bei 3,5. 2) Dabei gefunden: die Winkel-Beschriftung war ueberall invertiert. calc_trend_angle liefert 0 Grad = AUFWAERTS ... 180 = ABWAERTS, also ist ad = angle-90 NEGATIV bei steigendem Kurs. Ein LONG in einem steigenden Markt bekam daher "Winkel gegen EMA" (-10), ein LONG in einem fallenden "Winkel bestaetigt" (+5). ABER: backtest_angle.py benutzt DIESELBE verdrehte Beschriftung (a5_dis = a5 < 90-dead fuer LONG heisst "dagegen", ist aber STEIGEND). Der dokumentierte Befund "dafuer/neutral +0,055 vs dagegen +0,025" bedeutet richtig gelesen: LONG bei FALLENDEM Kurzfrist-Winkel (= Pullback) traegt doppelt so gut. Das ist der mehrfach belegte Pullback-Effekt. => Die Gewichtung war von Anfang an NUMERISCH RICHTIG. Nicht umgedreht. Geaendert wurden nur die Reason-Texte und Kommentare. Verifiziert: Konfidenzwerte vorher/nachher identisch (60/70/75 je Richtung). Lehre: der erste Verdacht "systematisch invertierte Logik" war falsch - die Zahlen stimmten, die Sprache log. Bei einer verdrehten Konvention erst pruefen, ob die MESSUNG dieselbe Verdrehung teilt, bevor man den Code "repariert". Beim Reversal war es anders: dort wies die eigenstaendige Messung das Setup unabhaengig von der Beschriftung als negativ aus. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
1a67944842 |
Reversal-Setup abgeschaltet (User-Entscheidung nach der Messung)
backtest_reversal_angle.py hat den Trigger in JEDER Variante beidhaelftig negativ gemessen (IST -0,122/-0,031 - vorzeichenkorrigiert -0,173/-0,061 - ohne Winkelbedingung -0,099/-0,023). Ausschlag gab aber nicht nur die Zahl: das Setup hebelt ZWEI gemessen POSITIVE Schutzmechanismen aus - die Anti-Ueberdehnung und den M30-Gegen-Trend-Filter (Edge x2). Ein Setup ohne eigenen Edge, das validierte Filter umgeht, ist der unguenstigste Fall. Umsetzung: neuer Schalter [trading] reversal_enabled (Config-Default im Engine false). WICHTIG: der Modul-Default in wave_rec bleibt True - saemtliche Backtests rufen dasselbe _build, ein False-Default haette alle bestehenden Messungen still veraendert. Abgeschaltet wird ausschliesslich im Live-Pfad. Verhaltensaenderung nur im Band |stretch| 3,0-3,5: dort kam vorher ein antizyklisches REV-Signal, jetzt das normale Trendsignal; ab 3,5 greift wie gehabt die Anti-Ueberdehnung. Verifiziert: - 3 Szenarien: ueberkauft+steigend SHORT/WAVE_REV_SHORT -> LONG/WAVE_LONG, ueberverkauft+fallend LONG/WAVE_REV_LONG -> SHORT/WAVE_SHORT, normaler Trend unveraendert - Live nach Neustart: bei 3,18xATR Ueberdehnung jetzt WARTEN/setup=WAVE/ reversal=None statt REV_SHORT; Log "Reversal-Setup AUS" - measurement_reminder CONFIG_DEPS ergaenzt, 11 Werte alle korrekt Die Winkelbedingung wurde bewusst NICHT vorzeichenkorrigiert - die korrigierte Variante misst sich schlechter. Die irrefuehrenden Kommentare sind jetzt als solche markiert. Bounce-Anzeige bleibt unveraendert (nur Warn-Kontext). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
94fbde1dba |
News-Sentiment war gesaettigt — Beweismengen-Gewichtung eingebaut
Anlass: Frage nach X-Anbindung fuer den Copiloten. Vorher geprueft, ob der vorhandene Textstrom ueberhaupt traegt. Er trug nichts, weil der Score kaputt war. calc_news_sentiment bildete ein REINES VERHAELTNIS (bull-bear)/total, ohne Bezug zur Beweismenge. Eine einzige bullische Schlagzeile bei null baerischen ergab +1,00. Diagnose: - 173 von 173 Log-Eintraegen auf +/-1,00 gesaettigt (100 %) - in 100 % der Faelle eine Seite exakt 0 - Median-Beweismenge nur 2,8 gewichtete Headlines - ueber die DB (54.548 Zeilen): 63,9 % auf exakt +1,00 Real am 03.08.: +1,00 waehrend WTI -5,9 % stand. Der Wert trug ein Bit und loeste im Entry-Check dauerhaft falsche "News-Konflikt"-Warnungen aus. Die Keyword-Listen sind NICHT die Ursache (56/48, keine Ueberschneidung). Fix: Shrinkage score = raw * total/(total+4,0). Die 4,0 ist begruendet, nicht optimiert: bei der realen Median-Beweismenge 2,8 bleibt eine einseitige 3-Headline-Lage unter der 0,5-Warnschwelle, ~10 Headlines ergeben 0,71. Zusaetzlich raw_score und evidence im Rueckgabewert, damit unterscheidbar wird ob "ausgewogene Lage" oder "kaum Daten". Leer-Fall liefert dieselben Felder. 6 Szenarien getestet, live verifiziert: bei identischer Beweislage (bull=1.8, bear=0.0) +1,00 -> +0,31. EHRLICH: das repariert die Kalibrierung, nicht die Aussagekraft. Parallel gemessen (Forward-Return 120 min, 38.213 Paare, 84 Tage, 2 Haelften, gegen die Regime-Drift gelesen): der stark-bullische Bucket liegt in BEIDEN Haelften bei null bis negativ, der baerische kippt das Vorzeichen. News-Sentiment ist nicht robust praediktiv. Bleibt Kontext-Chip ohne Verdict-Stimme. Methodik-Falle dokumentiert: der erste Messlauf nutzte candles_m1 (nur ~14 Tage) -> bisect lieferte fuer aeltere Zeitstempel denselben Randwert, alle Forward-Returns exakt 0,0000. Erst der Lauf mit MT5-M5-Bars plus Deckungspruefung war gueltig. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
fe7a1acb97 |
Kurslueckenerkennung: zwei Fehler behoben
User-Meldung "die Kurslueckenerkennung funktioniert nicht richtig". Zwei Fehler
gefunden:
1) Die groesste Luecke des Jahres wurde um 3 Cent verfehlt. Die Definition
verlangte ein lueckenloses Vakuum zwischen den TAGESSPANNEN. Am Wochenende
31.07.->03.08. fiel WTI von Schluss 86,33 auf Eroeffnung 79,76 = -6,57 $ -
unsichtbar, weil Montags Hoch (81,67) das Freitags-Tief (81,64) um 0,03 $
ueberlappte. In einem 24/5-Markt ueberlappen die Tagesspannen fast immer;
die strenge Regel fand im ganzen Jahr nur 5 Gaps.
2) Alle Gap-Datumsangaben waren einen Tag zu frueh: int(b["time"]) minus
_BROKER_OFFSET_S zog 3 h von einer Bar-Zeit ab, die MT5 bereits als naive
Broker-Zeit liefert. Die gemeldete Luecke "2026-07-26" war real der 27.07.
Am Jahreswechsel haette es zusaetzlich den year-Filter verschoben.
Fix: zwei getrennte Gap-Begriffe (kind).
- vacuum = alte strenge Definition. NUR diese speisen zone_lines() ->
_sr_levels -> Wellen-Konfidenz, denn nur auf ihnen wurde
gemessen (backtest_gaps.py). Strategie-Eingang bitgenau
unveraendert: zone_lines() liefert vorher wie nachher [88.288].
- close_open = Schluss->Eroeffnung, das was ein Mensch "Kurslucke" nennt.
REINE ANZEIGE, ab 0,50 $, fuellt auch am selben Tag.
Live: 4 offene Luecken statt 1 (1 Vakuum + 3 Eroeffnungsluecken), darunter
endlich die -6,57-$-Wochenendluecke mit Fill bei 86,33. Frontend kennzeichnet
beide Arten mit Tooltip. v=133.
Bewusst NICHT getan: close_open in die Konfidenz einspeisen - das waere ein
ungemessener Strategie-Eingriff, und der vorhandene Befund beruht auf der
Vakuum-Definition.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
00c78201fa |
KI-Copilot: zwei Prompt-Fehler behoben + kalibrierte Groessen ergaenzt
Diagnose zur Frage "Bias fast immer neutral": es ist NICHT der Prompt, es ist
der Provider. Bruch exakt am 20.07. (DeepSeek-Wechsel) - bis 19.07. war der
Copilot zu 42-90 % gerichtet, ab 21.07. nur noch zu 1,5-9,3 %. Der Prompt war
unveraendert. Und er hedged aus KORREKTER Schlussfolgerung: ~90 % WARTEN-Signal,
negativer Track-Record, plus die Prompt-Anweisung, genau dann NEUTRAL zu sagen.
Gemessen, ob mehr Meinung ueberhaupt Wert haette: KI-LONG n=286 +0,29 $ / 76 %
Treffer, KI-SHORT n=93 -0,02 $ / 55 %. ABER die 286 sind 20 Episoden an 5 Tagen
(Minutentakt-Logger), die 93 sind 16 Episoden -> effektiv n~20 gegen n~16, ein
Regime. Kein Beleg. Deshalb BEWUSST nicht am Prompt gedreht, um Meinung zu
erzwingen; Verdict-Gewicht unveraendert.
Zwei echte Prompt-Fehler behoben (Korrektheit, keine Meinungsmache):
- _SYS beschrieb das Wellen-Signal als "ATR-ZigZag" - es ist EMA12 vs EMA50
- _SYS nannte "TradersUnion-Tachos" als Input - TU ist seit 19.07. raus
Kalibrierte Groessen ergaenzt: _tool_market gab dem Copiloten NUR Wellen-Signal
und Session. Neu: p_break_target / p_break_stop (AUC 0,65 bzw. 0,68-0,72) und
cone (80%-Baender mit der REAL gemessenen Abdeckung 77 %), plus Lese-Anleitung
im Prompt (45-55 % explizit als Muenzwurf markiert).
Zwei Fallen an Live-Daten korrigiert: p_break steht bereits in PROZENT (die
zuerst gebaute x100-Umrechnung haette 300 erzeugt), und die Engine-Felder plus
die engine-Referenz im Agent existierten gar nicht - der Fail-safe haette still
nichts geliefert. Snapshot weist die Werte jetzt nur zu, rechnet sie nicht neu.
DeepSeek max_tokens 4000 -> 8000: das JSON brach regelmaessig mitten im Text ab
("Unterminated string"), real 2x in ~14 Zyklen = ~14 % stille Ausfaelle.
Kerzen/Muster bewusst NICHT eingespeist - die Lehrbuch-Lesart ist hier gemessen
invertiert (langer Koerper im Trend -0,132/-0,042; 2x Volumen -0,117/-0,204;
Muster-Kursziel trifft nur 13-38 %). Roh eingespeist wuerden sie schaden.
Verifiziert: Stub-Test von _tool_market (Werte unveraendert durchgereicht, nur
80%-Baender, ohne Engine kein Absturz); Prozess juenger als beide Dateien.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
20cd04caa7 |
Review-Durchlauf: Telemetrie-Epochen, doppeltes Verdict, Doku-Korrektur
Erster vollstaendiger Durchlauf von docs/review-prompt.md. KEINE Strategie-Aenderung - alles Telemetrie, Doku und toter Code. 1) analyze_divergence.py kannte keine Epochen und war damit selbst driftanfaellig. D0 mischte Vorhersagen des alten und des am 31.07. nachtrainierten P(break)-Modells und meldete dessen Fehlkalibrierung als aktuellen Alarm (das neue Modell hat n=0, Markt seit Fr zu). B las die Prae-Migrations-NULLs von block_reason als blinden Fleck. C druckte bei 0 Zeilen ein "OK", obwohl es fehlende Daten waren. Neu: _EPOCHS + _clamp(). 2) Konsens-Pfeil AR;K: der MQL5-Export rechnete im ~5-s-Takt ein komplettes zweites _verdict(), obwohl der Indikator die Zeile seit v1.33 per Default verwirft. Neu [trading] export_consensus_arrow (Default false). Verifiziert ueber die exportierte CSV: AR;K weg, AR;L und AR;S bleiben. 3) /api/autosqueeze loggt jetzt die Herkunft ([WEB] ...) wie /api/autosignal. Vorher war ein Zustandswechsel nicht als Nutzeraktion belegbar. 4) CLAUDE.md: die Reversal-Kennzahl "OR +0,185 / PF 1,35 / 70 %" stand unkorrigiert an der Fundstelle, die Widerlegung 2000 Zeilen weiter im Legacy-Recheck. Korrektur an die Fundstelle geholt. 5) core/notify.py: zwei tote "import datetime" entfernt (beide Funktionen nutzen _time), funktional nachgetestet. Geprueft und sauber: 0 fehlende Frontend-IDs von 86, nur 2 Config-Schluessel ohne Leser (beide dokumentiert dormant), Snapshot-Median 13 ms und alle DB-Abfragen <13 ms -> keine Performance-Massnahme, 124 Datei- und 83 Funktionsreferenzen in CLAUDE.md stimmen. Zwischenverdacht zurueckgezogen: "block_reason erklaert nur 33 % der WARTEN" war ein Migrations-Artefakt; seit 01.08. 100 % Abdeckung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
89e4af4561 |
HL-Kurs: Rohkurs anzeigen + Basis bei stehendem Broker einfrieren
User-Fund: app.hyperliquid.xyz zeigt WTIOIL-USDC bei 81,392, das Dashboard 86,424. Dahinter steckten zwei Fehler. (1) Falsches Label (vom 01.08.): angezeigt wurde mid_mt5 = HL + Basis, also der auf Pepperstone-Niveau umgerechnete Wert - unter der Beschriftung "HYPERLIQUID KURS". Jetzt steht dort der ROHE HL-Kurs (exakt die Zahl von der HL-Seite); das CFD-Aequivalent ist in den Tooltip gewandert. (2) Die Basis-Korrektur war bei geschlossenem Markt ZIRKULAER. Gegenstueck im HL-Projekt (eigener Commit): die Basis wird jetzt auf dem letzten Stand mit lebendem Broker eingefroren und als basis_stale durchgereicht. Belegt aus leadlag.db: Basis bei lebendem Broker konstant +0,42...+0,58, nach dem Freeze +5,03. Der Wochenend-Move war echt (So 03:00->05:00 von 85,51 auf 80,84, danach 13 h stabil um 81 bei ~600 Messungen/h). Materielle Folge: die offene SHORT-Position (0,57 ab 86,163, TP 84,123) wurde mit -15,02 EUR angezeigt; mit eingefrorener Basis sind es +211 EUR, und der TP liegt 2,3 $ ueber dem echten Niveau. Vorbehalt bleibt (Oracle-Perp) -> weiter "≈". Ausserdem dokumentiert: restart_server.bat hat zweimal still NICHT neu gestartet. Eine korrekt ausgelieferte app.js?v=N belegt NICHTS ueber den geladenen Python-Code (statische Dateien werden je Request von der Platte gelesen). Zuverlaessig nur: Prozess killen, direkt starten, danach an einem NEUEN Snapshot-Feld pruefen. v=132. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
d0f3b78796 |
Muster-Verdict-Gewicht 1,0 -> 0,25 (5%) + Korrektur der adverse15-Anekdote
Muster-Stimme (User-Vorgabe "geben wir dem Muster doch 5%"): _PAT_W = 0.25 statt fest 1,0; "forming" weiter die Haelfte. Empirisch gesetzt: ueber die letzten 4.000 verdict_votes liegt die Gewichtssumme der uebrigen Module im Median bei 4,50 -> Anteil 5,3 % (vorher 18,2 %). Muster hat in 24,7 % der Verdicts ueberhaupt eine Richtung, max. Nadel-Verschiebung 0,053. Reine Anzeige - der Bias steuert keine Order. Korrektur in CLAUDE.md: Die Anekdote zum Abschalten der 15-Minuten-Regel war falsch. "+19,28/+17,60 moeglich" und "32 EUR weiter dagegen" waren MAXIMALE AUSLENKUNG, nicht das, was der Exit gefangen haette. Mit core/exit_model.py nachgerechnet waere der 11:44-Trade OHNE Regel besser gewesen (-21,43 statt -26,31) und der 20:00-Squeeze schlechter (-23,27 statt -13,77). Ueber alle 7 Bot-Trades des 31.07. haette das Abschalten -16,42 EUR gekostet. Die Entscheidung bleibt richtig - sie ruht auf backtest_adverse15_squeeze.py (16/16 Kombinationen in beiden Haelften negativ), nicht auf einem Tag mit n=3. Der Tagesgewinn kam aus Trail 1,5 -> 1,0 (+24,86 EUR auf denselben Trades). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b8bb1d260f |
Fix: Broker-Offset bei geschlossenem Markt (-9,5 h statt +3 h)
`_broker_offset_s()` leitete die Zeitzone aus `tick.time - now` ab. Das misst die Zeitzone nur bei FRISCHEM Tick; steht der Markt, misst es die Veraltung. Real am 01.08. (letzter Tick Fr 23:54): -34210 s -> gerundet -34200 (-9,5 h) statt +10800. Die Pruefung [-12h,+14h] liess das durch. Folgen (die Laufzeit-Uhr war nur das Sichtbare): - open_time 12,5 h in der Zukunft -> Laufzeit 0:00 - Time-Stop-Alter (trailing.py:504) negativ -> 120-min-Stop haette nicht ausgeloest - deal.time-Umrechnung beim externen Close, alle MQL5-Chart-Anker Fix: Offset nur noch aus frischem Tick bestimmen, sonst letzter gueltiger Wert (vorbelegt UTC+3 = dieselbe Konstante wie engine.broker_utc_offset). Frische am bereits bekannten Offset gemessen -> nicht zirkulaer. Schwelle 900 s < halbes Rundungsraster. Zeitzonen-Wechsel wird uebernommen und geloggt. Ausserdem: - market_closed greift sofort nach Neustart: _last_bid_move_ts wird aus dem echten Tick-Alter vorbelegt statt bei null zu starten (vorher 180 s blind) - pollSnapshot: der stille catch umschloss render() -> Render-Fehler wurden lautlos verschluckt, das Dashboard fror ohne Konsolen-Fehler ein. Jetzt ist nur noch der fetch im try. - Header-Labels ausgeschrieben: "PEPPERSTONE KURS" / "HYPERLIQUID KURS" - v=131, CLAUDE.md (Deployment-Drift Fall 4) Verifiziert: market_closed sofort True, tick_age gegen die Rohwerte 0 s Abweichung, open_time -> 31.07. 22:54 (Laufzeit +15,8 h). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
7427c36922 |
Hyperliquid-Kurs neben dem Broker-Kurs + G/V-Schaetzung bei geschlossenem Markt
User: "wenn Pepperstone closed ist trotzdem Kurs und Liquiditaet von
Hyperliquid einbinden" -> nachgeschaerft zu "blende den HL-Kurs NEBEN den
Pepperstone-Kurs ein" (ehrlicher als ein stiller Tausch) -> plus "bei
geschlossenem Markt auch den G/V mit HL berechnen".
Snapshot: hl_live {mid_mt5, hl_mid, basis, age_s, bid/ask, bid_sz/ask_sz,
imb5, trend, slope_per_h, vs_mt5} - IMMER befuellt. mid_mt5 = HL-Mid +
gemessene Basis, also direkt mit dem Broker-Kurs vergleichbar. Dazu
market_closed, tick_age_s, pnl_hl.
core/hl_walls.py liefert jetzt zusaetzlich hl_mid/mid_mt5/age_s.
Dashboard v=129: eigene Header-Box "HL" neben KURS mit Tooltip (Rohkurs,
Basis, Alter, Abweichung). Bei geschlossenem Markt: Label "KURS · ZU",
Session-Zeile "MARKT ZU", und das G/V wechselt auf die HL-Schaetzung, mit
"≈" markiert.
MT5 v1.34: HL;<mt5_aequiv>;<alter>;<bid>;<ask>;<U|D|-> -> bernsteinfarbenes
Label unter Kurs und G/V (InpShowHL/InpHLColor).
DREI SACKGASSEN dokumentiert, damit sie niemand wiederholt:
1) tick_local_ts ist die ABHOLZEIT, nicht das Tick-Alter.
2) tick_server_ts minus _broker_offset_s() ist ZIRKULAER - die
Offset-Funktion leitet den Versatz selbst aus dem letzten Tick ab und
misst bei geschlossenem Markt die Veraltung (-7,41 h statt +3 h); das
Alter hebt sich auf (-347 s).
3) pnl / Kursbewegung als EUR-je-Punkt ergab 155 statt ~86, weil
trader.pnl den Wochenend-Swap enthaelt.
Verwendet wird stattdessen: Markt zu = der Kurs hat sich seit 180 s nicht
BEWEGT (_last_bid/_last_bid_move_ts). Und der G/V nutzt die vorhandene,
korrekte trader.live_pnl(bid, ask) mit dem HL-Kurs +- halbem Spread.
Live verifiziert: market_closed=True nach 198 s, Broker 86.333 eingefroren,
HL 86.349 (7 s alt), Broker-P&L -15,02 -> HL-Schaetzung -14,37 EUR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
6cf2730dc3 |
15-Min-Regel: Squeeze-Trades ausgenommen (gemessen schaedlich)
Analyse der negativen Autotrader-Trades. Von den drei heute per adverse15
geschlossenen Bot-Trades hat die Regel bei EINEM gerettet (Auto-Signal
11:44, -26,31 EUR; danach lief der Kurs 32 EUR weiter dagegen) und bei den
beiden SQUEEZE-Trades zu frueh gekappt (20:15 / 20:36, -13,77 / -28,09 EUR;
danach waeren +19,28 bzw. +17,60 EUR moeglich gewesen - aus candles_m1
nachgerechnet).
Verdacht bestaetigt: die Schwelle 0,5xATR wurde in backtest_auto_signal.py
auf WAVE-SIGNAL-Entries kalibriert und dann auf ALLE Bot-Trades angewandt.
Wieder ein Kalibrierungs-Bruch.
backtest_adverse15_squeeze.py (NEU, 80k M5, 2 Halbjahre, Echtkosten,
Exit-Kern): auf SQUEEZE-Entries schadet die Regel bei JEDER Schwelle in
BEIDEN Haelften:
0,3 -> -25/-38 · 0,5 -> -18/-34 · 0,8 -> -12/-39 · 1,2 -> -5/-18
Monoton, also ist die Regel selbst das Problem, nicht ihre Einstellung.
Ohne Regel H1 -54 / H2 +220, mit 0,5 H1 -72 / H2 +186.
Grund: der Squeeze ist runner-abhaengig (43 % Treffer, Ertrag im Tail) -
ein Schnitt nach 15 min trifft genau den Tail.
Umsetzung: _bot_open_source merkt beim Oeffnen, WOMIT eroeffnet wurde;
_check_adverse15 steigt bei auto_squeeze aus. Mit 7 Szenarien getestet.
Fuer den Auto-Signal-Pfad bleibt die Regel aktiv - dort gemessen ~neutral
(OeR +0,001 mit vs +0,026 ohne), also eine Versicherung mit kleiner Praemie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
81614a3128 |
Richtungs-Pfeile im MT5 statt des Kegels (v1.32) + Handbuch-Muster ergaenzt
PFEILE (User: "anstatt des Trichters einen Pfeil, der die wahrscheinlichste
Kursentwicklung anzeigt"). Randbedingung: die FREIE Richtungsfrage ist
gemessen ein Muenzwurf (analyze_reversal.py, AUC 0,499-0,509 oos, in-sample
nur 0,52). Ein frei schwebender Prognose-Pfeil waere unbelegt - und
gefaehrlicher als der Kegel, weil er ueberzeugender aussieht. Deshalb DREI
Pfeile mit jeweils eigener, benannter Beleglage:
L blau naechstes Level, aus dem kalibrierten P(break)
(AUC 0,65 oos, live 27 % vorhergesagt vs 28 % real)
S neongruen Squeeze-Ausbruch - das EINZIGE validierte Richtungssignal
K grau Konsens der Module - NICHT kalibriert, heisst deshalb
"Konsens" und nicht "Prognose"
L hat ein TOTBAND 45-55 %: dort waagerechter Pfeil "unentschieden", statt
aus einem Muenzwurf eine Richtung zu zeichnen.
MQL5 v1.32: OBJ_ARROWED_LINE + Label an der Spitze. Label heisst ALBL_* und
NICHT T* - sonst zieht RepositionLabels() es an den rechten Rand und loest
es von der Pfeilspitze.
Kegel bleibt im Code und in der Dashboard-Kachel; der Bot exportiert ihn nur
nicht mehr ins Chart ([trading] export_cone=false).
CHARTMUSTER: alle Handbuch-Muster ergaenzt - Dreifach-Top/-Boden, Flagge,
Wimpel, Rechteck, Steigender/Fallender Keil. ALLE mit measured=False, sie
tragen die Verdict-Stimme NICHT: das Gewicht 1,0 stammt aus einem
Kontrolltest, der nur die alten Typen abdeckte. engine._verdict waehlt jetzt
nur Muster mit measured=True.
Bug beim Bau gefunden: der fallende Keil feuerte in 20.000 Bars KEIN
EINZIGES MAL - die Bedingung stand auf dh > dl, bei einem fallenden Keil
faellt aber die OBERE Linie schneller (sonst konvergiert nichts). Beim
Spiegelbild (steigender Keil) stimmte es.
backtest_patterns_v2.py (NEU) misst die neuen Typen - mit dem ECHTEN
Detektor (core.patterns._detect statt einer Nachbildung) und dem
kanonischen Exit, plus Kontrollgruppe "generischer Swing-Bruch".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
3314b6e9b1 |
Flip-Close bekommt Nachrang gegenueber dem S/R-Close (gemessen)
User-Frage "sollten wir den S/R close auch deaktivieren?" -> nein, die
beiden sind gegensaetzlich gemessen. Aber sie konkurrieren seit dem Einbau
um dieselben Trades, und die S/R-Freigabe lief OHNE Flip-Close.
backtest_exit_combo.py (NEU, 80k M5, 2 Halbjahre, Echtkosten, Exit-Kern aus
core/exit_model.py, 5 Varianten auf IDENTISCHEN Entries):
nur S/R-Close H1 +59 · H2 -14 (535/284 S/R-Closes)
nur Flip-Close H1 -1 · H2 -43
BEIDE H1 +56 · H2 -50 (507/252)
BEIDE, Flip nachrangig H1 +62 · H2 -49 (516/260)
KOLLISION BELEGT: der Flip nahm dem S/R-Close 28 bzw. 32 Trades weg
(5-11 %) - genau die, fuer die dieser validiert ist. Mit Nachrang ist es in
BEIDEN Haelften besser als ohne.
Umsetzung: liegt ein S/R-ZIEL <=0,6xATR entfernt (dieselbe Schwelle wie der
Live-Hinweis), haelt der Flip sich zurueck.
[trading] auto_flip_close_subordinate (Default true).
Mit 4 Szenarien getestet: in Reichweite, ausser Reichweite, kein Level,
Nachrang aus.
EHRLICH DAZU: auch mit Nachrang kostet der Flip in H2 rund 35 R gegenueber
"nur S/R-Close" (-49 vs -14). Der Nachrang begrenzt den Schaden, er dreht
ihn nicht um.
METHODIK-FEHLER BEIM BAU, KORRIGIERT: der erste Lauf liess die sequentielle
Sim nach dem Exit bei xb+1 weiterlaufen - dadurch hatte JEDE Variante eine
ANDERE Trade-Folge und die Zahlen waren nicht vergleichbar. Jetzt feste,
geteilte Entry-Liste wie in backtest_pbreak_rvalue.py. (Die zunaechst
gemeldeten Deltas -195/-144 stammten aus diesem konfundierten Lauf.)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
fea91fddb3 |
Auto-Flip-Close gebaut (User-Wunsch) - trotz erneut negativer Messung
User: "schliesse den trade automatisch beim close signal". Dreht die
Empfehlung gegen die offene Position und steht sie >=0,5xATR im Plus ->
close(reason="flip_close").
VORHER NEU GEMESSEN, weil das alte Urteil (backtest_flipclose.py,
16.07.) auf einem VIERTEN Exit-Modell fusste: Trail fest 1,5 (live jetzt
1,0), keine Lock-Phase, kein Time-Stop, kein Initial-TP, _MAXH 288 statt
200, Phasen ueber den Bar-Close statt ueber das High-Water.
backtest_flipclose2.py (80k M5, 2 Halbjahre, Echtkosten, Exit aus
core/exit_model.py) bestaetigt das alte Urteil - deutlicher:
Basis ohne Flip H1 SigmaR -537 · H2 -140
Flip ab 0,0xATR Delta H1 -126 · H2 -221
Flip ab 0,3xATR Delta H1 -77 · H2 -216
Flip ab 0,5xATR Delta H1 -92 · H2 -160 <- mildeste, Default
Flip auch im Minus Delta H1 -205 · H2 -364
JEDE Variante ist in BEIDEN Haelften schlechter. Trefferquote steigt
39 -> 45 %, Ertrag faellt = Gewinner-Kappen (die nachlaufende EMA dreht
oft mitten im Pullback).
Gebaut wurde die mildeste Variante (0,5xATR Mindestgewinn), abschaltbar
ueber [trading] auto_flip_close.
Fuer die Neumessung bekam exit_model.simulate() einen stop_when-Hook
(+ ret_bar), damit die Phasen-Mechanik nicht zum fuenften Mal kopiert
werden musste. Rueckwaertskompatibilitaet verifiziert: ohne Hook bitgenau
identisch (die zunaechst gemeldeten Abweichungen kamen allein aus
LIVE.mult 1,5 -> 1,0, gegengeprueft mit mult=1.5 -> identisch).
Mit 10 synthetischen Szenarien getestet: beide Richtungen, aus, unter
Schwelle, gleichgerichtet, WARTEN, im Minus, flat, Startup-Schonfrist,
Ticket-Dedup - alle korrekt.
B4/B5-Pflicht: Live-Ertrag gegen die Erwartung halten, bei Drift
auto_flip_close=false.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
df092674cb |
Konsens-Zeile korrigiert: falscher Bezug + Nenner passte nicht zu den Chips
User-Fund: "Modul-Konsens: stark LONG · 4/4 Module fuer WARTEN" - dabei sind
9 Module sichtbar. Zwei echte Fehler.
(a) FALSCHER BEZUG: der Text lautete "... Module fuer ${sig}" mit der
HEADLINE als Bezug. Seit dem ref-Fix vom 30.07. zaehlt `agree` bei WARTEN
aber die Uebereinstimmung mit der BIAS-Richtung - deshalb stand dort
"stark LONG ... fuer WARTEN". Die Richtung kommt jetzt als verdict.ref_dir
vom Backend, statt im Frontend aus `bias` nachgebaut zu werden (dort galt
ein +-0,05-Totband, im Backend `bias > 0` - die Nachbildung waere am Rand
auseinandergelaufen; dieselbe Sorte Divergenz wie die fuenf
Deployment-Drift-Faelle desselben Tages).
(b) ANDERER NENNER ALS DIE CHIPS: `total` zaehlt nur Module MIT Aussage
(Gewicht>0, ohne die Welle). Nach den Gewichts-Fixes des Tages schweigen
deutlich mehr Module -> "4/4" bei 9 sichtbaren Chips. Neu ist
verdict.silent (Module mit Gewicht 0) dabei, sodass die Summe aufgeht.
Live verifiziert: "Modul-Konsens: leicht LONG · 3 von 5 stimmberechtigten
fuer LONG (4 ohne Aussage)" - 5 + 4 = 9. Sonderfall "kein Modul mit klarer
Aussage" abgedeckt. v=125.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
367d70eb7a |
Modul-Audit: 5 Inkonsistenzen behoben + Secret-Luecke in .gitignore geschlossen
Systematische Pruefung aller Verdict-Module gegen die Regel "keine Aussage
-> Gewicht 0", dazu Config-, Frontend- und Level-Quellen.
(1) KI-COPILOT - der groesste Rest des Musters. Ein explizites "NEUTRAL"
zaehlte als echte Stimme mit Gewicht 1,0. Gemessen (verdict_votes, n=7.084):
das ist in 93,1 % der Faelle der Zustand (Elliott: 1,3 %) - also der
Normalzustand des Copiloten, kein abgewogenes Urteil. Damit hatte
ausgerechnet das Modul mit der schwaechsten Beleglage
(analyze_verdict_calibration.py: nicht robust praediktiv) den GROESSTEN
daempfenden Einfluss auf die Bias-Nadel.
(2) ELLIOTT analog: Gewicht nur bei gerichtetem Ziel.
Kumulierte Wirkung aller Gewichts-Fixes des Tages:
Oe|bias| 0,370 -> 0,441 -> 0,569 (= 1,54x), betrifft 79,5 % der Zeilen
Live verifiziert: KI "NEUTRAL" -> Gewicht 0,00, bias 2,5/4,5 = 0,556
statt 2,5/5,5 = 0,455.
(3) STALE [zones] SPEISTEN DIE WELLEN-KONFIDENZ - entfernt. _sr_levels zog
beide Kanten jeder [zones]-Zone als S/R-Linien heran: 16 Kanten aus einem
~10 $ TIEFEREN Regime (72,90-77,00 bei Kurs 85,3). Aus dem Chart waren sie
am 14.07. schon entfernt worden, WEIL sie stale sind - in die Konfidenz
liefen sie weiter. Realer Audit-Fall: market.sr hatte gar keine
Widerstaende (M15-Cluster sind in frischen Trends oft leer) -> der
"naechste Widerstand" kam aus der fvg-Zone bei 88,00 (2,66 $ weg), der
echte lag bei 85,315 (0,03 $ weg). Der Abzug "dicht unter Widerstand"
(-12) greift nur innerhalb 0,5xATR und feuerte deshalb NIE.
(4) TOTE CONFIG entfernt: [trading] trail_timeframe (nirgends gelesen, Name
suggeriert faelschlich die Trailing-TF) und die komplette [setups]-Sektion
(11 Schluessel).
(5) raise StopIteration als Sprung in einem breiten except durch ein if
ersetzt - funktionierte, waere aber fragil sobald dort Logging dazukommt.
SICHERHEIT: beim Anlegen des Config-Backups fiel auf, dass .gitignore nur
"oil_widget_config.ini" abdeckt, NICHT "...ini.bak-<datum>". Das Backup lag
ungeschuetzt als untracked im Repo und enthaelt dieselben Live-Keys.
Muster ergaenzt. Gegenprobe: die .example-Datei enthaelt 10 secret-artige
Felder, davon 0 identisch mit der echten ini - alles Platzhalter.
Sauber geblieben: Frontend<->Backend (0 verwaiste Element-IDs), alle
uebrigen Verdict-Gewichte, alle anderen Config-Schluessel.
OFFEN (messpflichtig): die Wellen-Konfidenz aus _draw_levels speisen statt
aus dem Misch-Set - wuerde den -12-Abzug tatsaechlich ausloesen, also die
Konfidenz senken und das 55%-Gate verschieben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
23c68e8837 |
Verdict: M30/H1 bekommen Gewicht 0 ohne Aussage (Bias-Fix Teil 3)
Anlass war die User-Frage "H1 aus der Gesamtempfehlung entfernen, da wir
jetzt mit M30 arbeiten?". Antwort NEIN, aber die Frage hat einen echten
Defekt freigelegt.
Zur Praemisse: auf M30 umgestellt wurde die S/R-LEVEL-QUELLE, nicht die
Zeitebenen-Logik. H1 war nie Basis-TF (tf_max=M30), sondern immer Kontext.
Zur vermuteten Doppelzaehlung - gemessen an verdict_votes (n=7.074):
bei gerichteter Welle stimmt M30 nur zu 14,9 % mit ihr ueberein, H1 zu
47 %, M30 und H1 untereinander nur zu 33,8 %. Keine redundanten Stimmen
(Reversals heben den M30-Filter bewusst auf, und M30 ist meist gar nicht
gerichtet). H1 fliesst zwar auch als Konfluenz-Bonus in die Konfidenz -
aber in eine ANDERE Kennzahl (Ring vs. Nadel), nicht zweimal in dieselbe.
DER ECHTE DEFEKT: add("M30", ...) und add("H1", ...) hatten Gewicht 1,5
UNBEDINGT, auch bei Stimme 0. Damit derselbe Fehler wie beim Wellen-Modul
(Bias-Fix Teil 2 vom 30.07.), hier uebersehen. Eine 0-Stimme heisst
"EMA-Abstand im Totband" = keine Aussage, nicht "neutral" - mit vollem
Gewicht im Nenner zog sie die Bias-Nadel dauerhaft zur Mitte.
Gemessen an 7.074 Verdicts: M30 ist in 57,9 % der Faelle ohne Aussage
(H1 nur 1,8 %). Oe-Bias-Betrag 0,371 -> 0,441, Median-Verstaerkung 1,30x,
in 33,3 % der Zeilen deutlich staerkere Nadel.
Fix: 1.5 if vote != 0 else 0.0 fuer beide. `others` filtert bereits auf
weight>0, die "x/y einig"-Zaehlung zieht damit automatisch mit.
Live verifiziert: M30 "flach" -> Gewicht 0,00, bias -1,5/4,5 = -0,333
statt -1,5/6,0 = -0,250 (genau die gemessene 1,33x-Verstaerkung),
agree 3/5 statt 3/6.
REINE ANZEIGE - die Order-Logik haengt an der Wellen-Headline, nicht am
Bias.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
bb17ecff0a |
Beide offenen Vorschlaege umgesetzt: Trail 1,0 + Legacy-Recheck
VORSCHLAG 1 - Trail-Multiplikator 1,5 -> 1,0 (core/exit_model.py LIVE.mult),
live verifiziert ("AKTIVIERT ... mult=1.0x").
Voller Sweep mit FIXEM SL 2,0 (backtest_trailmult.py, 8 Werte 0,5-3,0):
enger ist MONOTON besser. Wave-Signal H1/H2 SigmaR:
0,5 +1258/+2418 · 0,8 +852/+1668 · 1,0 +80/+1360
1,5 -220/+1305 · 2,0 -394/+1198 · 2,5 -1072/+1327
Optimum am RAND = Warnsignal, deshalb Gegentest auf SQUEEZE-Entries mit
Echtkosten (--squeeze): das Setup lebt von Laeufern, muesste also
dagegenhalten - tut es NICHT (1,0: H1 -0,202/H2 +0,010 · 1,5:
-0,219/-0,032). Deshalb 1,0 (besser als 1,5 in beiden Haelften auf BEIDEN
Signalmengen), aber NICHT 0,5: Randwert, und die Sim modelliert keine
Exit-Slippage - ein engerer Trail loest viel haeufiger aus und ist davon
staerker betroffen (real bis 0,75xATR ueber den Stop).
VORSCHLAG 2 - backtest_legacy_recheck.py (NEU): die beiden Legacy-Befunde
nachgerechnet, die live ECHTE Gates steuern.
EIA-Blackout BESTAETIGT: auch mit echtem Exit + Echtkosten in BEIDEN
Haelften schlechter als der Rest (-0,097 / -0,119). Gate ist gedeckt.
DEAD-HOURS reproduzieren NICHT als selektiver Befund: 19 von 22 Stunden
sind in beiden Haelften negativ, keine robust positive Stunde. Die alte
Auswahl (0-7, 12, 16) ist damit nicht mehr gestuetzt. Praktisch folgenlos
(dead_hours ist leer), aber eine Reaktivierung auf der alten Begruendung
waere nicht gedeckt.
Einschraenkung selbst benannt: der Recheck handelt die UNGEGATETE
EMA-Richtung (ohne min_conf, Breakout-Bestaetigung, HTF-Filter, Raum-Gate).
Fuer den Vergleich neutral, die absoluten Werte sind nicht das Live-Signal.
Konsequenz fuer den TF-Churn-Fix: "WARTEN Richtung 43 %" ist eine
Haeufigkeits-, keine Ertragsgroesse - mehr Signale sind nur dann besser,
wenn die freigegebenen Setups auch tragen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
4c1a68a7e1 |
Stufe 3: geteilter Exit-Kern (core/exit_model.py) + Korrektur der Stufe-1-Begruendung
core/exit_model.py (NEU): LIVE:ExitParams als EINZIGE Quelle der Exit-
Parameter; core/trailing.py leitet _TRAIL_START_ATR, _BREAKEVEN_ATR,
_PHASE4_* und _MULT_BY_TF jetzt davon ab statt eigene Zahlen zu halten.
Aendert jemand LIVE.mult, aendern sich Live-Verhalten UND Messung gemeinsam
-> Deployment-Drift-Fall 3 ist konstruktiv unmoeglich geworden. Dazu die
kanonische simulate() fuer Backtests mit Flags timestop/use_tp, um
Teilmodelle EXPLIZIT zu machen statt zu verstecken.
BEFUNDE BEIM REFACTOR - schlimmer als angenommen:
(1) Es gibt mindestens DREI materiell verschiedene Exit-Modelle:
A) Phasen ~ live (_trailing/_exit/_atrfloor/_candle_fade)
B) EINFACH - _TPTRAIL=0.5, kein Breakeven, kein Lock, kein Time-Stop,
_MAXH=240 (_hourly, _hourly_split, _bounce, _events, _deadhour,
_chopgate)
C) Phasen mit be_on=1.0 statt 1,3 (_breakout, _confluence_angle)
=> Dead-Hours, EIA-Blackout, Bounce, Chop-Gate, Stunden-Analyse und
breakout_k ruhen auf einem Exit, der dem Live-System nicht entspricht.
Bewusst NICHT stillschweigend umgestellt (wuerde historische Schluesse
rueckwirkend aendern); als LEGACY_SIMPLE / LEGACY_BE10 markiert.
(2) Selbst die "Phasen"-Skripte weichen voneinander ab: _trailing hat TP
aber keinen Time-Stop, _candle_fade Time-Stop aber kein TP, _atrfloor
liefert Punkte statt R.
(3) backtest_trailing.py koppelt den Initial-SL an mult (sl = entry -
d*mult*atr) statt fix 2,0.
KORREKTUR DER STUFE-1-BEGRUENDUNG: die "67 % groesserer Einzelverlust" war
ein Artefakt von (3) - dort war der Worst-Case per Konstruktion gleich dem
Multiplikator. Sauber nachgemessen mit fixem SL (backtest_trailmult.py, NEU,
80k Bars, 2 Halbjahre):
Trail 1,0 H1 -73 · H2 +1346 · Worst -2,00
Trail 1,5 H1 -325 · H2 +1294 · Worst -2,00 (live)
Trail 2,0 H1 -446 · H2 +1195 · Worst -2,00
Trail 2,5 H1 -1174 · H2 +1223 · Worst -2,00
Trail 3,0 H1 -1088 · H2 +1397 · Worst -2,00
Der Worst-Case ist bei JEDEM Multiplikator identisch -2,00. Die Entscheidung
bleibt richtig (1,5 schlaegt 2,0 und 2,5 in beiden Haelften), nur die
Tail-Begruendung war falsch.
NEU UND OFFEN: Trail 1,0 schlaegt 1,5 in BEIDEN Haelften - eigener
Vorschlag, bewusst nicht ungefragt umgesetzt.
Aequivalenz verifiziert (500 synthetische Kursreihen je Fall): _candle_fade
und _atrfloor sind bitgenau identisch zur neuen simulate().
Live verifiziert: "AKTIVIERT ATR=0.5796 (M30) mult=1.5x".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
97617cd81d |
Deployment-Drift: Stufe 1 (Trail-mult) + Stufe 2 (Entscheidungs-Telemetrie)
Behebt die strukturelle Schwachstelle, die heute dreimal zugeschlagen hat:
Komponenten werden unter anderen Bedingungen BETRIEBEN als VALIDIERT.
Track B schuetzt gegen Overfitting, nicht gegen Deployment-Drift.
STUFE 1 (core/trailing.py): _MULT_BY_TF durchgehend 1,5 (vorher M15 2,0 /
M30 2,5 / H1 3,0) und _MULT_BREAKOUT_ADD 0,5 -> 0,0. Die Staffelung war nie
gemessen; backtest_trailing.py validiert nur 1,5 und die breiteren Werte
sind dort messbar schlechter (80k Bars, 2 Halbjahre):
mult 1,5 H1 SigmaR -249 · H2 +1252 · Worst -1,50
mult 2,0 H1 SigmaR -412 · H2 +1187 · Worst -2,00
mult 2,5 H1 SigmaR -1367 · H2 +1450 · Worst -2,50
Auf M30 fuhr der Bot also 5,5x schlechteres H1 und einen 67 % groesseren
Einzelverlust; bei Breakouts waren es 3,0 - nie getestet. Relevant, weil die
TF-Heuristik oft auf M15/M30 landet (31.07.: 19 von 33 Phasen).
STUFE 2a (wave_rec/history/engine): jede Empfehlung loggt einen
maschinenlesbaren block_reason - deadband, dead_hour, eia, htf_counter,
stretch, min_conf, breakout_pending, entry_room, no_data, stale. DB migriert
(Backup angelegt). Ohne den war nicht feststellbar, WELCHES der Gates die
93 % WARTEN erzeugt (Backtest-Erwartung ~43 %).
STUFE 2b (analyze_divergence.py, NEU): haelt vier Dinge gegen die
Backtest-Erwartung - A Signal-Verteilung, B Gate-Anteile inkl.
"im Backtest modelliert?", C TF-Wechsel-Rate, D0 Modell-Kalibrierung,
D Merkmals-Drift gegen _PB_MU/_SD.
LEHRE AUS DEM BAU SELBST: die Merkmals-Drift (D) haette den realen Fehler
NICHT gefangen - mom3 lag nur 0,50 Sigma unter mu, bei Gewicht 1,43 wurden
daraus aber -0,71 im Logit (23 % statt 41 % vorhergesagt). Deshalb ist D0
der schaerfere Test und die D-Schwelle auf 0,5 Sigma gesetzt.
Erster Lauf nach dem Fix bestaetigt das Nachtraining live:
D0 = 27,0 % vorhergesagt vs 28,0 % real (vorher 23 vs 41).
Stufe 3 (geteilter Exit-Kern) bleibt offen, spaeter und einzeln.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
0208101707 |
TF-Churn-Fix: Breakout-Bestaetigung ueberlebt TF-Wechsel + Verweildauer
Auslöser: User-Frage warum der Bot die Rally am 31.07. (82,5 -> 84,4 in 2 h) nicht gehandelt hat. Befund: in dem Fenster 99x WARTEN und 1x SHORT - und dieser SHORT wurde am Tief autonom eroeffnet (AUTOSIG, -26,31 EUR, per adverse15 geschlossen). Den LONG machte der User um 11:56 von Hand. Der WARTEN-Anteil ist strukturell zu hoch: Backtest-Erwartung (backtest_dist.py) ~43 % Live letzte 24 h 93,2 % Live letzte 7 Tage 88,0 % Live gesamt (93.599 Zeilen) 78,6 % MECHANISMUS (im Log belegt): _choose_tf setzt den Score einer TF hart auf 0,0, sobald sie ueberdehnt ist - genau das passiert M5 IM Trend. Real am 31.07.: M5 sprang zwischen 0,00 und 1,93, die TF wechselte 33x am Tag (Median-Abstand 5 min). Die 1,2x-Hysterese ist dagegen wirkungslos. Und set_timeframe() verwarf bei JEDEM Wechsel die laufende Breakout- Bestaetigung und verankerte sie beim aktuellen Kurs neu. Bei k=0,3 und ATR_M30~0,53 braucht sie ~0,16 $, der Kurs lief ~0,08 $ je 5 min -> die Bestaetigung konnte rechnerisch nie fertig werden. Gleicher Fehlertyp wie beim P(break)-Modell am selben Tag: backtest_breakout.py hat k=0,3 auf einer FESTEN Zeitebene validiert; live wandert sie - die Bedingung, unter der die Messung gilt, existiert im Betrieb nicht. FIX 1 (wave_rec.set_timeframe): _pend wird nicht mehr zurueckgesetzt. Der Anker gehoert zum Signal, nicht zur Zeitebene; bei Richtungswechsel verankert _confirm_breakout ohnehin neu. FIX 2 (engine._tf_loop): Mindest-Verweildauer [trading] tf_min_dwell_s=900. Verifiziert mit synthetischen Szenarien: Fix 1 - Bestaetigung ueberlebt M5->M30 und feuert LONG, Richtungswechsel verankert korrekt neu; Fix 2 - an der ECHTEN Score-Folge vom 31.07. nachgespielt: 4 Wechsel -> 2. NICHT backtestbar (Backtests laufen auf fester TF, das Churning existiert dort nicht). Begruendung ist "stellt die Bedingung her, unter der die Messung gilt", nicht "gemessen besser". Erfolgskontrolle = WARTEN-Anteil muss sich Richtung ~43 % bewegen. Bewusst nicht behoben: der 0,0-Einbruch des Scores bei Ueberdehnung selbst - das waere eine Aenderung der TF-Bewertung und damit messpflichtig. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
0944b1c13a |
P(break) neu trainiert auf live-spiegelnder Stichprobe (Weg b) - eingebaut
Behebt die am selben Tag gefundene Merkmals-Diskrepanz: das alte Modell war
auf "Anlauf zu einem beim Entry FIXIERTEN Level" trainiert, live waehlt
_draw_levels das Level jede Sekunde neu -> mom3 live 0,15 statt 1,45 ->
Ausgabe immer ~23 % -> Gate seit Inbetriebnahme faktisch nie aktiv.
backtest_pbreak_retrain.py: Stichprobe spiegelt den Live-Pfad (Level
dynamisch mit Hysterese, gesampelt an JEDEM Bar im 0,15xATR-Band, keine
Anlauf-Bedingung). Kontrolle: Merkmalsmittel der Stichprobe (mom6 0,203 /
mom3 0,202) treffen die live rekonstruierten Werte (0,181 / 0,149).
AUC auf dieser Stichprobe (H2, out-of-sample):
ALT-Modell 0,368 (schlechter als Zufall, 19,2 % vs real 39,4 %)
NEU-Modell 0,654 kalibriert
backtest_pbreak_rvalue.py (R-Ertrag, Echtkosten, Baseline = nur Trailing):
NEU schlaegt ALT in BEIDEN Haelften bei JEDER Schwelle. Gegen die Baseline
gewinnt es bei 0,35/0,45/0,55 in beiden (bei 0,60 kippt H1).
Bestwert 0,35: H1 -149 vs -506 (+357), H2 +1308 vs -110 (+1418).
Nebenbefund: das ALTE Modell war in H1 schlechter als gar kein Auto-Close.
EINGEBAUT: neue _PB_MU/_SD/_W (final auf allen 80k gefittet, n=76.542,
Basisrate 37,8 %, nach H1->H2-Validierung; alte Werte als Kommentar) +
sr_close_pbreak 0,55 -> 0,35, Config-Waechter-Anker mitgezogen.
Verifiziert: Chart-Linien zeigen 43 %/36 % statt 8-15 %.
ACHTUNG - invertiert eine alte Projekt-Regel: mom3-Gewicht dreht das
Vorzeichen (+1,4330 -> -0,5420). Alt: "kriecht ans Level -> 26 % Bruch, mit
Schwung -> laufen lassen". Neu: Anlauf-Schub -> 26,5 % (Level absorbiert
ihn und haelt), Schwung weg vom Level -> 51 %. Beides gilt in seiner
Population (fixiertes vs. dynamisches Level); fuer den Live-Pfad gilt die
neue Lesart.
Offen: auch NEU schliesst bei 0,35 noch ~94-97 % der Positionen (waehlt vor
allem den besseren Moment). Touch-Zahl bringt im neuen Modell nichts mehr
(0,652 vs 0,654) - die dynamische Level-Wahl erfasst den Effekt bereits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
d9cb54a52c |
C: Wahrscheinlichkeits-Kegel (kalibriert) + Config-Waechter im Reminder
C - core/cone.py + Kachel #card-cone + MT5 v1.31 (CN;<min>;<lo>;<hi>): "Erwartete Spanne" statt "Kursvorhersage". Der User wollte eingezeichnete Verlaufspfade; bewusst NICHT gebaut - sie suggerieren eine Praezision, die es nicht gibt (Lehre aus analyze_verdict_calibration.py). Der Kegel sagt wie WEIT der Kurs in 30/60/120 min plausibel laeuft, nicht wohin. analyze_cone.py: r(h)=(C[i+h]-C[i])/ATR[i], Fit auf H1, Abdeckung gemessen auf H2 (echtes out-of-sample): 80%-Band -> 76,7 / 76,6 / 75,3 % 90%-Band -> 87,5 / 87,2 / 86,5 % Konsistent ~3-5 Pp ZU ENG. Das wird NICHT weggefittet - Kachel und Tooltip nennen die REAL gemessene Abdeckung, nicht den Nennwert. Damit nach dem P(break)-Modell die zweite kalibriert geprueft Komponente im Projekt. Zentriert auf den aktuellen Kurs, KEINE Drift addiert (Median +-0,0..0,16 xATR = klein gegen die Bandbreite; eine Drift-Korrektur waere eine Richtungsaussage und die ist nicht belegt). Farbe neutral grau, kein gruen/rot. Kein Signal, kein Verdict-Gewicht. MQL5 v1.31: zwei sich oeffnende gepunktete Pfade, verkettet 30->60->120. Startpunkt aus der PX-Zeile - die setzt g_conePx jetzt auch, wenn InpShowPrice aus ist (sonst verliert der Faecher seinen Anker). Config-Waechter in measurement_reminder.py (Antwort auf "sollten wir alle verworfenen Backtests woechentlich neu rechnen?"): NEIN - eine Woche sind ~2000 Bars, und 18 Ideen x 52 Wochen = 936 Tests/Jahr erzeugen bei 5 % Fehlalarmquote ~47 falsche "funktioniert jetzt!" pro Jahr. Stattdessen EREIGNIS-gesteuert: CONFIG_DEPS verankert 8 config-abhaengige Messungen an den Wert, gegen den sie validiert wurden (entry_room_atr 0,6 / sr_close_pbreak 0,55 / breakout_k 0,3 / risk_pct 0 / margin_buffer_pct 95 / adverse_15min_atr 0,5 / auto_signal_min_conf 75 / dead_hours leer). Weicht einer ab, meldet der Timer welche Messung veraltet ist. Numerischer Vergleich, damit 0.60 == 0.6. Mit 5 synthetischen Szenarien getestet. Erledigt ausgetragen: Chartmuster-Kontrolltest (30.07., Muster schlagen die Kontrolle in beiden Haelften +0,022/+0,108). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
03be3b8f5f |
D+A: Klimax-Fade verworfen, Kerzen-Anatomie-Kachel gebaut (reine Anzeige, v=123)
D - backtest_candle_fade.py: der Lead aus backtest_candles.py (Fade der
volumenstarken Klimax-Kerze) faellt im echten Trade-Sim durch. Live-Exit
(SL 2,0/Trail 1,5/BE 1,3/Time-Stop 120') + Echtkosten, mit KONTROLLGRUPPE
"Fade ohne Volumen-Filter" (die Lehre aus backtest_patterns.py).
Kontrolle -0,080 / -0,046
Vol >= 2,0 -0,059 / +0,103
Vol >= 2,5 +0,144 / -0,080
Vol >= 3,0 +0,113 / -0,064
Benachbarte Schwellen exakt gegenlaeufig = Rauschmuster. Die einzige
beidseitig positive Zelle (Vol>=2,0 + Marubozu, +0,036/+0,043) hat n=91/118
bei 7 Varianten = Mehrfachvergleich-Artefakt. 18. verworfener Eingriff.
Wichtigste Lehre: Informations-Ueberschuss != handelbarer Edge. Dieselbe
2,0-Schwelle liefert im Forward-Fenster +0,12/+0,20 beim Fade, im echten
Trade -0,059/+0,103 - die Gegenbewegung ist diffus, der 2xATR-Stop wird
unterwegs getroffen (WR nur 35-40 %). Der Weg zum Ziel zaehlt.
A - core/candles.py + Kachel #card-candles (M5, ~20 s, unter mt5_lock):
Marubozu, Langer Koerper, Langer Docht oben/unten, Spinning Top, Doji,
Engulfing. Schwellen identisch zum Backtest.
Bewusste UI-Entscheidung: die Kachel ist NEUTRAL gefaerbt (keine gruen/rot-
Ampel) und nennt die GEMESSENE Lesart ("Klimax-Kerze - der Kurs laeuft
danach eher GEGEN die Kerze"), nicht die Lehrbuch-Lesart. Eine
Richtungsampel wuerde hier systematisch falsch stupsen - gleiche Korrektur
wie bei der Bounce-Anzeige. Kein Verdict-Gewicht, kein Trigger.
Beim Bau gefunden: mt5_lock ist ein CONTEXT-MANAGER, kein Lock-Objekt -
.acquire()/.release() wirft. Jetzt "with mt5_lock(3.0) as got".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
a6f370ac02 |
Wirtschaftskalender-Blackout + Konsolidierungs-Box beschriftet
core/econ_calendar.py (NEU): High-Impact-News-Fenster als Handels-Sperre. Quelle Forex Factory JSON (kostenlos, kein Key, mit impact-Feld), beide Wochen (thisweek endet Sa, Markt oeffnet So 23:00 -> sonst blinder Fleck), 1x/h im Daemon-Thread, dedupliziert. Filter: High+USD ODER Oil/OPEC-Titel. WICHTIG - nicht gemessen: Events sind zu selten fuer eine 2-Stichproben- Aussage. Das ist die Handbuch-Regel, kein belegter Edge. Deshalb bewusst asymmetrisch: sperrt NUR die autonomen Entries (Auto-Squeeze + Auto-Signal, ohne Dedup-Marker -> feuert nach dem Fenster nach), in der Entry-Checkliste nur "warn" statt "fail". Manuelle Orders bleiben frei. Der gemessene EIA-Blackout (Mi 15:30-16:30) bleibt unabhaengig aktiv und greift auch ohne Netz. Verifiziert: Live-Fetch (EIA korrekt Mi 16:30 Berlin, FOMC/GDP/PCE erkannt) + 4 synthetische Szenarien (5 min vor/nach Event, 50 min davor, disabled). MQL5 v1.30: graue Konsolidierungs-Box beschriftet (User-Frage "was bedeutet die graue Box") - sichtbares Label an der Oberkante, rechtsbuendig wie die uebrigen: "Konsolidierung (10-Bar-Spanne)" bzw. bei Kompression "Konsolidierung - komprimiert, Ausbruch steht bevor". 0 Fehler kompiliert. Frontend v=122: #cal-note in der Meldungen-Karte (laufendes Fenster bzw. Vorwarnung <=60 min). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 4.8
|
7e0d2a4563 |
Verdict: Chartmuster + Orderbuch + Liquiditaets-Trend als Stimmen (v=121)
User-Vorgaben: "beruecksichtige die chartmuster mit in der gesamtempfehlung sobald eins erkannt wird" + "auch der liquiditaetstrend und das orderbuch". MUSTER (Gewicht 1,0 bestaetigt / 0,5 bildet sich) -- vorher den faelligen KONTROLLTEST nachgeholt (stand seit heute im measurement_reminder): Muster H1 +0.206 (Ziel 23%) H2 +0.328 (Ziel 26%) Kontrolle H1 +0.184 (Ziel 19%) H2 +0.220 (Ziel 18%) <- beliebiger Swing-Bruch Delta H1 +0.022 H2 +0.108 Die Muster schlagen die Kontrolle in BEIDEN Haelften, aber der Loewenanteil des Ertrags kommt vom Breakout+Trailing. Deshalb Gewicht 1,0 (wie Elliott/KI), nicht 2,0 (Squeeze). Ziel-Trefferquote bleibt niedrig -> die Stimme sagt Richtungs- tendenz, kein Kursziel. ORDERBUCH-Imbalance + LIQ-TREND (Gewicht je 0,5 = kleinstes im Verdict): ⚠ BEIDE UNGEMESSEN. Die Uebertragbarkeit HL->CFD wird gerade erst erhoben (analyze_bookflow.py, ~3% der Daten). Der Lead-Lag-Test zeigt sogar, dass PEPPERSTONE fuehrt (r=0.525 bei k=-1) und HL folgt -- HL ist Oracle-basierter HIP-3-Perp, strukturell Follower. Daher das kleinste Gewicht. Imbalance-Schwelle _OB_IMB_MIN=0.30, darunter keine Stimme. MITLOGGING: verdict_votes um pattern/pattern_w/orderbook/orderbook_w/liqtrend/ liqtrend_w erweitert (DB migriert, Backup angelegt). Nur so ist in ein paar Wochen datenbasiert entscheidbar, ob die Stimmen bleiben, mehr Gewicht bekommen oder rausfliegen (wie TU 2026-07-06). Frontend: Chips rendern dynamisch (keine Aenderung noetig); NEU wird das GEWICHT im Chip angezeigt und stumme Module (w=0) ausgegraut -- so ist sichtbar, dass Orderbuch/Liq-Trend schwaecher zaehlen als Welle (3,0) oder Squeeze (2,0). Verifiziert live: alle 9 Stimmen korrekt, Bias-Rechnung geprueft (1.5/5.5=0.273), Logging schreibt die neuen Spalten. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 4.8
|
11e13cdb5a |
MQL5 v1.29: Konsolidierungs-Box als Anzeige (CO;lo;hi;tight)
User: "schauen wir uns das mal an" (nach dem verworfenen Konsolidierungs-Backtest). Der Bot exportiert die Spanne der letzten 10 M5-Bars -- exakt die Box, aus der der validierte Squeeze-Ausbruch kommt (wave._squeeze_one liefert jetzt box_hi/box_lo in allen Rueckgaben). Der Indikator zeichnet sie als transparentes blaues Rechteck; ist sie KOMPRIMIERT (<=2.5xATR, also armed/active), wird sie mit doppelter Deckkraft gezeichnet -> "Ausbruch steht bevor" ist auf einen Blick sichtbar. Schalter: InpShowConsol / InpConsolColor / InpConsolAlpha / InpConsolBars. ⚠ REINE ANZEIGE. Alle Konsolidierungs-SETUPS sind gemessen verworfen (backtest_consolidation.py: False Breakout, Distribution, Accumulation, Retest -- inkl. Kontrolltest, der die Distribution-Hypothese kippte). Die Box zeigt WO gestaut wird, nicht WOHIN es geht. Validiert ist ausschliesslich der Ausbruch. Verifiziert: CO;84.105;84.815;0 (0.710$ = 2.68xATR = knapp ueber der Schwelle, daher korrekt als "nicht komprimiert" markiert). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 4.8
|
2bda2680bb |
MQL5 v1.28: G/V der offenen Position unter dem Kurs
User-Wunsch. Der Bot exportiert PL;wert;waehrung, der Indikator zeigt es als OBJ_LABEL direkt unter dem Kurs oben rechts (CORNER_RIGHT_UPPER, Y = Kurs-Y + Schrifthoehe + Abstand), gruen im Plus / rot im Minus. Wert ist NETTO wie im Dashboard: bei Gewinn abzueglich der WHT-Quellensteuer ([trading] wht_pct = 26.375), bei Verlust unveraendert (dort faellt keine an). Ohne offene Position schickt der Bot keine PL-Zeile -> Redraw() raeumt das Label per ObjectsDeleteAll(PFX) automatisch weg. Verifiziert: PL;-20.59;EUR in sr_levels.csv, deckt sich mit dem Dashboard-Netto. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 4.8
|
3a7bd044c0 |
Verdict-Review: Bias-Daempfung durch stumme Welle + agree-Anzeige gefixt
Review der Gesamtempfehlungslogik auf Wunsch des Users ("ueberpruefe die
gesamtempfehlungslogik komplett mit den neuen indikatoren von heute").
Befund 1 (gravierend): Die Regel "Modul ohne Aussage -> Gewicht 0" (2026-07-15
fuer Squeeze/Elliott/KI eingefuehrt) galt NICHT fuer die Welle selbst. Sie stand
mit w=3.0 permanent im Nenner, auch bei WARTEN. Gemessen sind ~91% der letzten
2000 Empfehlungen WARTEN -> die Bias-Nadel war fast immer kuenstlich zur Mitte
gezogen. Realer Fall: bias +0.312 statt +0.625 (Faktor 2).
Fix: weight=0 bei WARTEN.
Befund 2: `agree` nutzte immer die Wellen-Richtung als Referenz -> bei WARTEN
zwangsläufig "0/N", obwohl sich die anderen Module einig waren (real "0/4" bei
2 einigen Modulen). Fix: Referenz = Wellen-Richtung, ersatzweise Bias-Richtung
(real jetzt "2/3").
Beides REINE ANZEIGE, Order-Logik unberuehrt. Mit 6 synthetischen Szenarien
verifiziert + live geprueft.
Nicht geaendert, nur dokumentiert:
- Doppelzaehlung M30/H1 (stecken bereits im Wave-Signal als Filter/Konfluenz)
- Drei divergierende Level-Quellen seit der M30-Umstellung (Supports wichen um
0.65$ ab) -- bewusst, jedes Gate ist auf seine Quelle kalibriert
- toter tu-Parameter
Neue Indikatoren von heute korrekt NICHT im Verdict: Liquiditaets-Waende
(Uebertragbarkeit ungemessen), Liquiditaetszonen + Volume Profile (verworfen),
Chartmuster (nicht reif).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 4.8
|
b23a3d4e5c |
MQL5 v1.25: Durchbruchwahrscheinlichkeit an den S/R-Labels
User-Wunsch. Der Bot haengt P(break) als drittes CSV-Feld an (R;preis;pct / S;preis;pct), der Indikator schreibt es ins Label: "Widerstand 84.536 · Durchbruch 34%" Quelle = dasselbe kalibrierte Logit-Modell wie der S/R-Auto-Close, heute auf die M30-Level nachtrainiert (AUC 0.72 out-of-sample, Kalibrierung geprueft). Richtung: Widerstand = Bruch nach oben (+1), Support = nach unten (-1); Merkmale identisch zu _sr_close_hint/_stop_approach_hint (M5-Momentum, EMA-Richtung, Abstand/ATR). Abschaltbar via InpShowPBreak. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 4.8
|
73712b5ea7 |
Trade-Umrandungen entfernt + Darstellungsfehler behoben (MQL5 v1.22)
User: "entferne die umrandungen fuer trade open und close" + "das bild sieht
komiesch aus" (Screenshot).
(a) Trade-Umrandungen AUS: InpShowTrades=false UND Export im Bot abgeschaltet
([trading] export_trade_marks=false) -- spart auch die DB-Abfrage im
5-s-Export-Takt. Code bleibt reaktivierbar.
(b) Liquiditaets-Trendlinie: RAY_RIGHT entfernt. Eine 60-min-Regression 100 Bars
in die Zukunft zu verlaengern riss die Linie steil ins Bodenlose (im
Screenshot deutlich zu sehen). Sie endet jetzt am aktuellen Rand.
(c) CHART_SHIFT_SIZE auf 12% begrenzt (InpShiftPct). Ohne Begrenzung war der
Shift-Bereich so gross, dass der Kursverlauf links gequetscht stand.
Verifiziert: TR-Zeilen aus sr_levels.csv verschwunden, Rest unveraendert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 4.8
|
03567adf6b |
MT5-Chart v1.18: Trade-Marker, Liquiditaetszonen, Kurs oben rechts + Pfeil-Bugfix
Pfeil-Bugfix (User: "liquiditaetspfeile werden immer noch nicht angezeigt"):
(1) ANCHOR_LEFT ist fuer OBJ_ARROW UNGUELTIG (nur TOP/BOTTOM)
(2) Pfeile sitzen rechts neben der letzten Kerze -> ohne CHART_SHIFT kein
sichtbarer Bereich dort
Blink-Fix (User: "blinken nur manchmal auf"): hl_walls setzte den Cache bei jedem
Fehlschlag auf None -> LQ-Zeilen fehlten -> Indikator loeschte die Pfeile. Jetzt
letzter guter Stand 120s Grace.
Neu (alles reine Anzeige):
- TR;<O|C>;zeit -> Kerze der Eroeffnung HELLGRUEN, des Close DUNKELGRUEN umrandet
- EQ;<H|L>;lo;hi;zeit -> Equal Highs/Lows aus M30-Pivots als goldenes Band +
gestrichelte Kante (wie im User-Referenzbild). Als Signal gemessen verworfen.
- PX;bid -> aktueller Kurs fett oben rechts
- Beschriftung der Liquiditaets-Trendlinie per Default aus (v1.16)
Alles kompiliert und live in sr_levels.csv verifiziert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 4.8
|
919fe61dc3 |
Entry-Checkliste im Order-Dialog + Liquiditaets-Pfeile rechtsbuendig (v=120, MQL5 v1.14)
1) Entry-Checkliste (User: "blende einen Hinweis ein wenn die Checkliste gegen
meine Eroeffnung ist"): engine._entry_checklist prueft 7 Punkte mit Live-Daten
-- Signal-Deckung, HTF-Trend M30+H1, Entry-Raum, News-Konflikt, Kosten,
Verlust-Serie heute (Mental-Check), Nacht-Stunde. Snapshot checklist{long,short},
Anzeige im Bestaetigungs-Dialog, blockt nicht. Kommt jetzt auch bei vorhandenem
Signal (alter Dialog nur bei WARTEN/Gegen-Signal).
Real beim Einbau: beide Richtungen "stop" (11 Verluste heute = 80% des Kontos).
2) MQL5 v1.14 (User: "blende die liquiditaetslinien aus, nur die Pfeile sollen
rechtsbuendig angezeigt werden"): LQ-Linien + Text-Labels raus, nur noch der
Pfeil auf dem Wand-Preis, rechtsbuendig am aktuellen Rand (in RepositionLabels
nachgefuehrt, bleibt beim Scrollen rechts). Details im Tooltip. Pinke
Liquiditaets-Trendlinie unveraendert. Kompiliert.
3) backtest_liquidity_sweep.py (SMC Equal Highs/Lows + Swing Liquidity, Multi-TF-
und Session-Achse): faellt durch -- Details folgen in der Doku.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 4.8
|
b77b3d60f5 |
S/R-Level von M5 auf M30 umgestellt + P(break)-Modell nachtrainiert
User: "DIE S/R Linien liegen oft sehr nahe beieinander" -> Option 2 (beides umstellen, Modell nachtrainieren) gewaehlt. Erst gemessen: backtest_level_tf.py, 80k M5-Bars, 2 Halbjahre, Trades bleiben M5, nur die Level-Quelle variiert. Ergebnis (M30 gewinnt in BEIDEN Haelften): TF AUC(H2) Abstand <1xATR dR bei P<0.55 (H1/H2) M5 0.710 0.61xATR 71% +6698 +7749 (bisher live) M15 0.725 1.16xATR 46% +10138 +12071 M30 0.721 1.95xATR 28% +12424 +13047 <- gewaehlt Die Beschwerde ist damit quantifiziert: 71% der M5-Level lagen naeher als 1xATR. Umsetzung: - wave_rec: _m30_hl gespeichert, neues _pb_levels30 (k=3, letzte 50 M30-Bars = trainingsgleich zum 300-M5-Lookback), im Snapshot. - engine._draw_levels nutzt pb_levels30 (Fallback pb_levels beim Kaltstart); speist Chart, MQL5-CSV, Dashboard UND den P(break)-Auto-Close. - _PB_MU/_PB_SD/_PB_W auf M30 nachtrainiert: out-of-sample validiert (H1->H2), dann auf allen 80k gefittet (34771 Touches, Kalibrierung 23/25, 38/36, 58/59, 86/87). Merkmale bleiben M5. Alte M5-Werte als Kommentar (Rueckweg). - NICHT mitveraendert: Entry-Raum-Gate nutzt weiter M5-pb_levels (entry_room_atr=0.6 ist darauf kalibriert). Verifiziert live: R/S 84.617/83.722 = 2.9xATR Abstand (vorher 0.28xATR), M30-Pivots 4/7 statt M5 27/31, keine Fehler im Log. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 4.8
|
06b37a1474 |
Liquiditaets-Waende: Richtungs-Pfeil + pinke Liquiditaets-Trendlinie (v1.13)
User-Wunsch: "Kennzeiche die Liquiditaetslinie mit einem Pfeil in welche richtung
die linie den Kurs treibt. Zeichne mir eine Trendlnie in pink im mt5 auf basis
der liquiditaet ein".
(a) Pfeil je Wand in Wirkrichtung (Lesart "die Wand haelt": Nachfrage stuetzt hoch,
Angebot deckelt runter); groessere Wand dicker + "<<". CSV-Format erweitert:
LQ;<B|A>;preis;size;<U|D>;<1|0>.
WICHTIG: Pfeilrichtung ist INTERPRETATION, nicht gemessen -- die Gegenthese
("Liquidity Grab", Kurs laeuft ZUR Wand) ist genauso verbreitet. Klaert
analyze_bookflow.py Frage 3.
(b) Pinke Liquiditaets-Trendlinie LT;t1;p1;t2;p2;<U|D>: Regression ueber den
VOLUMENGEWICHTETEN Wand-Schwerpunkt der letzten 60 min. Zeigt, wohin das
Gewicht der RUHENDEN Orders wandert -- nicht der gehandelte Kurs.
Zeiten im Bot in Broker-Zeit umgerechnet, Preise basis-korrigiert.
HL /api/walls liefert jetzt arrow_bid/arrow_ask/dominant/trend.
Verifiziert: LQ;B;84.182;2441;U;1 / LQ;A;84.223;2441;D;0 /
LT;1785427175;84.135;1785430664;83.978;D in sr_levels.csv. Indikator kompiliert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|