6ed8980eab40db7235551dbac359d2b30c5f195a
77
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Axel HocksandClaude Opus 5
|
0966caf1b8 |
G/V-Trennung geprueft: Adoptions-Sperre riss bei JEDEM Neustart auf
User: "ueberpruefe ob wirklich die G/V und G/V BRK Anzeigen stimmen, besonders bei gleichzeitig laufenden Trades. Die Anzeige darf jeweils nur den eigenen Slot anzeigen." FRONTEND SAUBER: #hdr-pnl liest nur d.position, #hdr-pnl-brk nur d.position_brk - keine Summe, kein Fallback. Aber das ist die falsche Stelle zum Suchen: stehen im Backend beide Felder auf derselben Position, kann keine Anzeige das mehr richten. Geprueft wurde deshalb die AUSWAHL in TradeManager._refresh_locked. ⚠⚠ FUND 1 - die Sperrliste kannte nur zwei von DREI Quellen eines BRK-Tickets: trader_brk.ticket ✅ nur im Speicher _pending_tickets ✅ nur im Speicher _brk_restore ❌ FEHLTE - und nur das ueberlebt den Neustart Nach einem Neustart sind die ersten beiden leer, und die Reihenfolge im _pos_loop besiegelt es: trader.refresh() laeuft DREI Zeilen vor _rebind_brk(). Slot 1 greift die BRK-Position also, bevor sie zurueckgebunden werden kann. _rebind_brk erkennt das zwar und bricht ab - damit ist der Schaden aber nur festgestellt, nicht behoben: die BRK-Position haengt am falschen Slot, ihr G/V steht links statt rechts, und "G/V BRK" zeigt "—". Danach sieht alles normal aus, was es besonders schwer sichtbar macht. Behoben ueber getattr(..., None), also unabhaengig davon, WANN das Attribut gesetzt wird - genau die Reihenfolge-Falle, die in zwei Tagen zweimal zugeschlagen hat. ✅✅ FUND 2 - zwei verschiedene Rechnungen nebeneinander. Bei geschlossenem Markt zeigt Slot 1 seit dem 01.08. eine HL-Schaetzung (pnl_hl), der BRK-Slot bekam die nie und zeigte den EINGEFRORENEN Broker-Wert, ohne dass man es der Anzeige ansieht. Neu pnl_hl_brk, mit ≈ markiert. Geprueft statt angenommen, dass _tick_size/_tick_value am BRK-Slot gesetzt sind. ✅ day_pl.open summiert korrekt BEIDE Slots - die Summe gehoert dorthin, die Trennung in die beiden G/V-Felder. BELEG - tests/test_slot_gv.py, 6 Tests auf dem ECHTEN TradeManager (Broker gestubbt): zwei Positionen gleichzeitig je im eigenen Slot · Slot 1 adoptiert die BRK-Position nicht · Pending-Fill wird nicht weggeschnappt · der BRK-Slot adoptiert nie · plus die Regressionsprobe, die den alten Zustand festhaelt. NEUE PIPELINE-STUFE E (tools/check_slots.py): die Sperrliste muss alle drei Namen erwaehnen. Mutationsprobe: Merker entfernt -> Exit 1. ⚠⚠ Ehrlich zur Arbeitsteilung: der pytest belegt den MECHANISMUS, baut die Lambda aber selbst nach und bleibt bei der Mutation gruen. Erst die statische Stufe belegt, dass die ENGINE sie richtig verdrahtet. Keine der beiden allein haette gereicht. ⚠⚠ NEBENBEFUND, korrigiert: mein Schreib-Helfer hat SECHS Dateien still von LF auf CRLF gedreht (io.open(...,"w") uebersetzt auf Windows). Mein erster Check mit `grep -c $'\r$'` meldete faelschlich 0 - erst die BYTE-Zaehlung zeigte 8959 CR in CLAUDE.md. Alle sechs auf LF zurueckgesetzt. core.autocrlf=true haette es im Repo normalisiert, im Arbeitsbaum aber nicht. Live verifiziert: Slot 1 T=50396824 (+10,34), BRK flat, day_pl.open 10,34 - kein gemeinsames Ticket. Deploy mit --feld pnl_hl_brk, alle 5 Schritte gruen. ⚠ Noch nicht beobachtet: ein Neustart MIT offener BRK-Position - der Fall, den der Fix adressiert. v=201. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3e275e7515 |
Slot-Close-Knoepfe groesser und in CLOSE-Farbe; grosser CLOSE-Knopf entfernt
User-Wunsch, drei Teile.
(1) GROESSER: font-size 0.72 -> 1rem, Polster 0.17/0.33 -> 0.39/0.61rem, fett.
(2) FARBE wie der bisherige CLOSE-Knopf: background #2d2000, color var(--accent),
Rahmen #4a3600 - derselbe Bernstein-Ton, damit "schliessen" ueberall gleich
aussieht.
(3) Grosser CLOSE-Knopf aus der Aktionsleiste ENTFERNT.
⚠⚠ DER HAKEN AN (3), geprueft bevor entfernt: der Knopf hatte ZWEI Aufgaben im
Render, nicht nur das Klicken - `disabled`, wenn keine Position offen ist, und
BLINKEN beim Close-Alarm (`closeBtn.classList.toggle("blink", closeAlert)`).
Haette ich ihn nur aus der HTML geloescht, waere der Alarm still geworden: nur
noch Ton, keine Sichtbarkeit. Beides ist mitgezogen:
- `close-main` ist disabled, wenn Slot 1 leer ist; `close-brk`, wenn BRK leer
ist (vorher gab es diese Unterscheidung gar nicht)
- `.px-close.blink` nutzt dieselbe `blkClose`-Keyframe wie vorher, und weil
die Farben identisch sind, sieht das Blinken exakt aus wie zuvor
⚠ Es blinkt NUR der Slot-1-Knopf: dort entstehen `sr_close_hint` und der
Flip-Alarm. Ein blinkender BRK-Knopf ohne Anlass waere ein Fehlsignal.
FUNKTIONAL GEPRUEFT (drei Zustaende gegen ein Minimal-DOM):
hasPos=1 hasBrk=0 alarm=0 -> main aktiv, brk gesperrt, kein Blinken
hasPos=0 hasBrk=1 alarm=1 -> main gesperrt, brk aktiv, Blinken
hasPos=1 hasBrk=1 alarm=1 -> beide aktiv, Blinken
0 verbliebene `data-side="close"`-Referenzen in JS und HTML.
⚠ `.btn.close` und `.btn.close.blink` bleiben in der CSS stehen - ungenutzt,
aber harmlos, und sie machen ein Zurueckholen des grossen Knopfs zu einer
Ein-Zeilen-Sache.
v=200 (HTML, JS, style.css und der Cache-Waechter `data-html-v` alle
gleichgezogen und am ausgelieferten Stand verifiziert).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
54bcc9f81d |
Cache-Waechter: die Seite meldet selbst, wenn HTML und JS nicht zusammenpassen
User: "die buttons werden nicht angezeigt" (Close-Knoepfe an den G/V-Anzeigen).
DIAGNOSE: serverseitig war alles korrekt - HTML, CSS und JS werden mit v=199
ausgeliefert, der Knopf steht im gelieferten Markup, die CSS-Regel ist da, und
KEINE andere Regel versteckt ihn (globale button-Regeln gibt es nicht, .px setzt
nur Schrift). Der Server sendet no-store, und last-modified stimmt mit der
Platte ueberein. Es bleibt der Browser-Cache.
⚠⚠ URSACHE IST STRUKTURELL, nicht einmalig: `index.html` wird vom `?v=`-Bump
NICHT gebustet - nur app.js und style.css. Trifft neues JS auf eine alte,
gecachte HTML, fehlen die neuen Elemente. Das Auffang-`$` verhindert den
Absturz, aber die Anzeige ist STILL unvollstaendig. Real jetzt zum zweiten Mal:
19.08. (M5-/RSI-Zeile) und 20.08. (diese Knoepfe) - beide Male sah der Server
korrekt aus und der Browser zeigte Altes, und beide Male habe ich es von Hand
diagnostizieren muessen.
GEBAUT: `<body data-html-v="199">` plus eine Konstante `_JS_V` in app.js. Weichen
sie ab, blendet die Seite unten ein rotes Band ein ("Alte Seite im Cache, HTML
v198, JS v199 - hier tippen zum Neuladen"); ein Tipp darauf laedt mit frischem
Query-String neu.
⚠ Bewusst SICHTBAR statt nur Konsole - die sieht am Handy niemand.
⚠ Die Version wird beim `?v=`-Bump aus der HTML gelesen, muss also nicht getrennt
gepflegt werden.
BEIDE RICHTUNGEN VERIFIZIERT: HTML v198 gegen JS v199 -> Banner erscheint;
gleiche Version -> kein Banner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
d881636e1b |
Close-Knopf je Slot, direkt vor der jeweiligen G/V-Anzeige
User-Wunsch. Zwei Slots heissen zwei Close-Moeglichkeiten - bisher gab es nur
den grossen CLOSE-Knopf, und der schliesst seit heute BEIDE. Neu je ein kleines
✕ vor "G/V" (Slot 1) und vor "G/V · BRK", rechtsbuendig gespiegelt.
BACKEND: `engine.close(slot=None)` - None/"" = beide (Verhalten des grossen
Knopfs, unveraendert), "main" = nur Slot 1, "brk" = nur der Breakout-Autotrader.
`POST /api/order {"side":"close","slot":"brk"}` reicht ihn durch; ohne `slot`
ist das Verhalten bitgleich zu vorher.
⚠ Sicherheitsabfrage NUR im Minus - dieselbe Regel wie beim grossen Knopf: im
Plus direkt schliessen, im Minus nachfragen. Hartes Blockieren ist im Projekt
verworfen, aber ein versehentlicher Klick soll kein Geld kosten.
⚠⚠ EIGENER FEHLER auf dem Weg, gefunden bevor er live ging: mein erster Entwurf
las den P&L aus `_letzterSnap` - eine Variable, die es NICHT gab. Das ist exakt
der ReferenceError, der am 19.08. den halben Render abgeschossen hat, nur
diesmal im Klick-Pfad (er waere erst beim Druecken geknallt, also genau dann,
wenn man schliessen will). Behoben durch `letzterSnap`, das `_applySnapshot`
jetzt fuehrt - die Variable fehlte im Projekt tatsaechlich, Klick-Handler hatten
bisher keinen Zugriff auf den aktuellen Zustand.
Verifiziert: 2 Knoepfe im ausgelieferten HTML, span/div/button ausgeglichen,
keine doppelten IDs, node --check, Render-Probe, 91 Tests und die volle Pipeline
gruen. Deploy verifiziert (v=199).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
d59d0eeaee |
TP-Anzeige entwirrt: doppelten Wert entfernt, Init-Formel ehrlich beschriftet
User-Frage "unterscheidet sich TP von TP1, TP2 oder TP3?" - sie deckte zwei
Fehler auf, beide von mir aus der vorigen Aenderung.
⚠ ZUERST DIE SACHE SELBST: der TP WIRD nachgezogen, aber nach DREI Formeln:
Init Entry ± 3,5xATR fest, gibt dem Trade Luft
Trail Bestkurs ∓ 0,5xATR zieht mit dem Hoch mit
Lock Bestkurs ∓ 0,3xATR sehr eng am Hoch
immer mindestens Entry ± 0,5xATR (schliesst nie im Verlust)
Er springt beim Phasenwechsel also von WEIT VOR dem Kurs auf KNAPP HINTER das
Hoch - ab Phase Trail ist er faktisch ein zweiter, engerer Ausstieg ueber dem
Stop. 63 TP-Setzungen im Log bestaetigen das.
① BEHOBEN - "TP2 · Trailing" in der Trade-Leiste zeigte DENSELBEN Wert wie das
Feld "TP" daneben. Eine Zahl doppelt. Entfernt; uebrig bleiben TP1 (Level)
und TP3 (Kegel) als das, was sie sind: Orientierungsmarken, die der
Broker-TP NICHT kennt. Das Feld "TP" bleibt editierbar.
② BEHOBEN - im M15-Setup-Block stand "TP2: ... (3,5xATR - das Trailing fuehrt
ihn nach)". Das war irrefuehrend: 3,5xATR ist NUR die Init-Formel, und ab
Phase Trail laeuft der TP nach einer anderen Regel. Jetzt: "Init-Ziel
3,5xATR - ab Phase Trail zieht der TP an den Bestkurs heran, ∓0,5xATR".
Verifiziert: 0 verbliebene tb-tp2-Referenzen in JS und HTML, span/div
ausgeglichen, keine doppelten IDs, node --check und Render-Probe gruen.
Reine Frontend-Aenderung (v=197), kein Neustart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
5925d9a527 |
Trade-Leiste: TP1/TP2/TP3 + Setup-Block "Entry Zone / SL / TP1-3" in der M15-Karte
User-Wunsch, mit einer Vorlage im Format "USOIL BUY SETUP: Entry Zone / Stop
Loss / Take Profit 1-3".
(1) TRADE-LEISTE — drei Anzeige-Boxen fuer die LAUFENDE Position:
TP1 · Level naechstes STEHENDES M30-Level in Trade-Richtung + P(haelt)
TP2 · Trailing der Broker-TP, den `core/trailing.py` dynamisch fuehrt
TP3 · Kegel Obergrenze des 80-%-Bandes auf 120 min (core/cone.py)
Live gegengerechnet: 85.745 (67 % haelt) / 86.634 / 86.153 (trifft 75 %).
(2) M15-KARTE — Setup-Block im Format der Vorlage, direkt unter dem Banner:
Richtung · Entry Zone (Level ± 0,15xATR) · Stop Loss (2,0xATR_M15) ·
TP1 (Gegenlevel) · TP2 (3,5xATR) · TP3 (Kegel 120').
Blendet sich aus, wenn kein Veto, keine Zone oder kein ATR vorliegt -
aktuell ist genau das der Fall (M30 flach -> kein Veto -> keine erlaubte
Richtung), und das ist korrektes Verhalten, kein Fehler.
⚠⚠ DREI LEITPLANKEN, damit daraus keine Prognose wird:
- Die RICHTUNG kommt ausschliesslich aus dem VETO (erlaubte Richtung). Die
Karte gibt weiterhin KEINE Richtungsprognose ab - die ist ueber 1.071
Live-Episoden als Muenzwurf gemessen (48-51 %). Ohne Veto: kein Block.
- Die drei TP sind ANZEIGE, nichts davon geht an den Broker. Ein FESTER TP am
Gegenlevel ist der staerkste Gewinner-Kappen-Beleg des Projekts: er drehte
den Squeeze von +0,102/+0,108 auf -0,066/-0,004 (backtest_trailing_sr.py).
Deshalb steht an TP2 ausdruecklich, dass das Trailing ihn nachfuehrt.
- NICHTS wird neu gerechnet - Zonen, ATR und Kegel stehen im Snapshot. Ein
zweiter Rechenweg waere die Divergenz-Falle (dreimal zugeschlagen).
- Neutral gerahmt, nicht gruen/rot: der Block sagt WO, nicht OB.
Die 0,15xATR der Entry Zone sind die im Projekt gemessene "Beruehrung"
(dieselbe Schwelle wie `at_level` im S/R-Hinweis), nicht geraten.
Reine Frontend-Aenderung (v=195), kein Neustart. node --check, Render-Probe und
die volle Pipeline gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
c33227664c |
Trade-Leiste: Auto-Close-Feld entfernt (war doppelt)
User-Wunsch. Der Schalter existierte zweimal: in der Trade-Leiste und seit dem 19.08. als Knopf "S/R" in der Aktionsleiste. Die Aktionsleisten-Variante ist die brauchbarere - die Trade-Leiste erscheint NUR bei offener Position, man konnte den Auto-Close dort also gar nicht VOR einem Trade setzen. Genau deshalb war der zweite Knopf am 19.08. dazugekommen. Entfernt: das `<span class="tb-field">` mit `#srclose-btn`, der Render-Block, der seinen Zustand schrieb, und der onclick-Handler. `srAuto` bleibt - es speist weiter den Knopf `btn-sr` und die Hinweistexte. ⚠ Die beiden JS-Zugriffe haetten dank Auffang-`$` keinen Absturz erzeugt, aber sie waeren toter Code gewesen, der je ID eine Konsolen-Warnung ausloest. Deshalb mitentfernt statt liegengelassen: 0 Treffer in app.js UND index.html. Backend, Endpoint /api/srclose und der Zustand `auto_sr_close` unveraendert. Reine Frontend-Aenderung (v=193), kein Neustart. node --check und die Render-Probe (Stufe B2) gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e01ecde3a3 |
Order-Knopf warnt sichtbar, wenn der Raum zum Ziel-Level fehlt
User: "und wieder am Widerstand geschlossen. Das ist kein Zufall mehr."
⚠⚠ ZUERST DER AUSSCHLUSS - im Exit gibt es KEINEN S/R-Anker:
- S/R-Auto-Close ist seit 19.08. aus
- `trail.set_sr(...)` uebergibt die Level zwar, aber `_sr_data` wird in
core/trailing.py NIRGENDS benutzt (toter Parameter)
- Trailing-Stop = Bestkurs ∓ 1,0xATR, TP = Entry ± 3,5xATR - beides reines ATR
Kein Codepfad kann an einem Level schliessen.
DIE URSACHE LIEGT AM EINSTIEG, und sie ist in der eigenen Telemetrie sichtbar
(ctx_dist_res_atr / ctx_dist_sup_atr, Abstand zum ZIEL-Level beim Eroeffnen):
19.08 20:00 BUY 0,25xATR -5,44
19.08 20:05 BUY 0,29xATR -4,20
19.08 20:11 BUY 0,46xATR -23,29
19.08 20:59 SELL 0,52xATR -4,47
19.08 21:18 BUY -0,03xATR -0,67 (Widerstand bereits ueberschritten)
FUENF von zwoelf Trades unter dem Gate 0,6, zusammen -38,07 EUR.
Der Kurs erreicht das Level nach wenigen Cent, dreht, und der Trail (1xATR
dahinter) nimmt mit. Der Exit SIEHT nach "am Widerstand" aus, weil der EINSTIEG
dort lag. Genau das misst entry_room_atr: OeR -0,119/-0,067 bei PF 0,42/0,66 -
79 % Trefferquote und trotzdem Verlust, weil der Gewinn am Level gedeckelt ist
und der Verlust bis zum Stop laeuft.
Warum es niemand sah: `entry_room` blockt nur die EMPFEHLUNG, manuelle Orders
laufen ungehindert (so gewollt, Uebersteuerungen liefen 68 % WR). Seit dem
Entfernen des Entry-Dialogs (11.08.) fehlte die Zahl im Moment des Klicks; sie
stand nur in Gate ③b - und das ist seit gestern im zugeklappten Akkordeon.
GEBAUT: der Order-Knopf selbst wird markiert (Umriss in Akzentfarbe, gedaempfte
Flaeche, Raum-Zahl fett), sobald `frei === false`. Live gegengeprueft: bei Raum
0,04 / 0,28 xATR sind beide Knoepfe gewarnt.
⚠ KEIN Block, KEINE Abfrage - sichtbar machen, nicht bevormunden.
⚠ Die Zahl wird NICHT neu gerechnet; `rm` liegt bereits vor. Ein zweiter
Rechenweg waere die Divergenz-Falle, die im Projekt dreimal zugeschlagen hat.
⚠ Der Knopf hat keine id, sondern data-side - deshalb ueber `closest()` statt
ueber eine ID (erster Versuch griff ins Leere).
Reine Frontend-Aenderung (v=192), kein Neustart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
834bd0bba3 |
Header: eigene G/V-Box fuer den BRK-Slot, rechts neben dem ersten
User-Wunsch. Seit dem Zwei-Slot-Umbau vom 19.08. kann der Breakout-Autotrader parallel zu manuellen und M15-Trades eine eigene Position halten - im Header war davon nichts zu sehen. Neue Box "G/V · BRK" (#hdr-pnl-brk) direkt neben "G/V", mit Ticket, Lots, Einstieg und Trailing-Zustand im Tooltip. Zeigt "—", wenn BRK nichts haelt. ⚠ BEWUSST ZWEI BOXEN statt einer Summe: die Slots gehoeren verschiedenen Populationen (Mensch +1,56 gegen autonom -4,71 EUR/Lot), und sie in EINEM Feld zusammenzurechnen wuerde genau die Trennung verwischen, fuer die der zweite Slot ueberhaupt gebaut wurde. Die SUMME steht dort, wo der User sie angefragt hat: im TAG P/L. Geprueft statt angenommen - `day_pl["open"]` summiert seit dem 19.08. bereits beide Slots (engine.py:4537), es war also nichts nachzuruesten. Live gegengerechnet: Slot 1 +4,18 / BRK leer / day_pl.open 4,18. Die WHT-Behandlung ist identisch zur ersten Box (Abzug nur auf Gewinne) - eine zweite Rechenart im selben Header waere eine Divergenz, die niemand erwartet. Reine Frontend-Aenderung (v=191), kein Neustart. div 87/87 ausgeglichen, keine doppelten IDs, node --check und die Render-Probe gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
d3d613068c |
M15-Karte: Pruefkette als Akkordeon in drei Abschnitten
User-Wunsch. Die Karte war auf zehn Zeilen gewachsen und dominierte das Dashboard; jetzt sind sie in drei aufklappbare Gruppen sortiert: ① - ④ Pruefkette (offen) Bias · Kosten · Zone · Reichweite ⑤ Kontext - Motor · M5 · RSI (zu) Motor/Raum · M5-Zustand · RSI ⑥ - ⑦ Selbstmessung · Ausfuehrung · Veto (zu) Track · Exec · Veto Das Status-Banner bleibt IMMER sichtbar - es ist die eine Zeile, die eine Handlungsaussage traegt, und es bestaetigt ausdruecklich auch das Nicht-Handeln. ⚠⚠ NATIVES <details>/<summary>, kein JS fuer das Klappen. Entscheidend ist, dass die Elemente IM DOM bleiben: der Render schreibt weiter in alle zehn IDs, auch wenn ein Abschnitt zugeklappt ist. Ein Container, der die Elemente ENTFERNT, haette den Render abbrechen lassen - genau der Ausfall von gestern Abend, als ein ReferenceError in renderM15 das halbe Dashboard auf "—" stehen liess. JS macht nur EINES: den Auf-/Zu-Zustand in localStorage merken. Ohne das waere jeder Reload ein Rueckschritt - und die Seite wird bei jedem ?v=-Bump neu geladen. Faellt localStorage aus (privater Modus), greift der Default. Verifiziert: 10 m15-Items unveraendert vorhanden, keine doppelten IDs, div 86/86 und details 3/3 ausgeglichen, node --check gruen, Render-Probe (Stufe B2) gruen. Reine Frontend-Aenderung (v=190), kein Neustart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5684589878 |
FIX: SL/TP-Feld rundete auf 2 Nachkommastellen - Stop verschob sich beim Speichern
User: "SL war auf 84,86 laut Dashboard" (nach dem Close von T=50360258).
ZWEI BEFUNDE, und der zweite ist der eigentliche:
(1) Die 84,86 gehoerten zum NAECHSTEN Trade. Der geschlossene T=50360258 hatte
SL 84,776; 26 s spaeter lief bereits T=50360505 mit SL 84,863. Kein Fehler,
nur Verwechslung durch die schnelle Folge.
(2) ABER dabei faellt ein echter Anzeigefehler auf: das SL/TP-Feld der
Trade-Leiste formatierte mit `fmt(x, 2)`. WTI notiert DREISTELLIG - aus dem
echten Stop 84,776 wurde die Anzeige 84,78.
⚠⚠ Das ist nicht kosmetisch: das Feld ist BESCHREIBBAR, und ein Enter darauf
schickt den gerundeten Wert per /api/sltp an den Broker. Der Stop verschiebt
sich also still um bis zu 0,5 Cent - bei einem Trail von 11 Cent (ATR_M5
0,1104 in dieser Nacht) sind das 5 % der Distanz. Zusaetzlich schaltet
/api/sltp das Trailing ab, der Nutzer wuerde also einen leicht falschen Stop
festschreiben und die Nachfuehrung verlieren.
Behoben auf 3 Stellen. Gegengeprueft, dass es kein weiteres Preisfeld mit
`, 2)` gibt.
Reine Frontend-Aenderung (v=189), kein Neustart. node --check und die neue
Render-Probe (Stufe B2) gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
95b22e2add |
FIX: Render brach ab - RSI-Zeile griff im falschen Scope zu (Dashboard kaputt)
User-Screenshot: sechs leere "—"-Zeilen in der M15-Karte unter Gate ④ und eine
komplett leere Breakout-Karte.
URSACHE, mein Fehler von heute Abend: `renderM15(s)` bekommt NUR `m15_setup`.
Meine RSI-Zeile griff aber auf `d.market.rsi_m15` zu - `d` existiert in diesem
Scope nicht. ReferenceError mitten im Render: alles ab der Fehlerstelle blieb
auf dem Initialwert "—", und die danach gerufenen Renderer (u.a. renderBrk)
liefen gar nicht mehr. Genau die Signatur im Screenshot.
⚠⚠ WARUM DIE PIPELINE ES DURCHGELASSEN HAT: `node --check` prueft nur SYNTAX.
Ein ReferenceError ist syntaktisch einwandfrei. Python hat dafuer ruff F821 -
fuer JS gab es nichts Vergleichbares. Das ist die Luecke, nicht ein
Einzelversehen: es ist der ZWEITE Fall derselben Klasse heute (vorhin `d5.m5`
statt `s.m5`, den hatte ich beim Bauen selbst bemerkt).
BEHOBEN: renderM15(s, snap) bekommt den vollen Snapshot mit, Aufrufer angepasst,
Zugriff auf ((snap||{}).market||{}).rsi_m15. Ein Kommentar an der Signatur haelt
fest, warum `d.` dort verboten ist.
NEU: tools/render_check.mjs - laesst renderM15 und renderBrk gegen ein
Minimal-DOM mit einem ECHTEN Snapshot laufen und meldet jede Exception.
Mutationsprobe bestanden: Fehler zurueckgebaut -> "❌ d is not defined",
zurueck -> gruen. Alle vier Zeilen rendern wieder korrekt (RSI, M5-Kontext,
Gate ③b, BRK-Position).
v=188, damit der Browser das Update sicher zieht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
3839fd5dc0 |
RSI-Zeile im Dashboard - reine Anzeige, bewusst ohne Ampel
User-Wunsch nach der Messung. `market.rsi_m15` stand bereits im Snapshot (core/mt5data.py:246 ruft calc_rsi), es ist also eine reine Frontend-Aenderung (v=187), kein Neustart, die offene Position unberuehrt. ⚠⚠ BEWUSST NEUTRAL und OHNE gruen/rot: die Lehrbuch-Lesart ist am selben Tag gemessen und durchgefallen (backtest_rsi_v2.py: 24 Zellen ueber 80k M5-Bars und 2 Halbjahre, KEINE besteht, vier sind signifikant negativ; auch die Umkehrung traegt standalone nicht). Eine Ampel wuerde hier systematisch falsch stupsen - dieselbe Korrektur wie bei der Kerzen-Anatomie (Lehrbuch-Lesart invertiert) und bei der Ueberdehnungs-Anzeige, die aus genau diesem Grund "Ueberdehnung" heisst und nicht "Bounce". Die Zeile NENNT die Zone (hoch / mittleres Band / tief), bewertet sie aber nicht. Der Tooltip traegt die Messung samt Skriptnamen und den Hinweis, dass der WIRKSAME Teil - der Pullback-Effekt - im Bot bereits ueber die EMA-Distanz laeuft (Konfidenz-Bonus "tiefer Pullback" +15) und ueber die Ueberdehnung. RSI waere dort eine zweite Verpackung derselben Aussage. Kein Verdict-Gewicht, kein Trade-Trigger. Verifiziert: div ausgeglichen, keine doppelten IDs, node --check gruen, v=187 ausgeliefert, Live-Wert 38,2 -> "mittleres Band". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
33cc451e52 |
Globales Einsatz-Feld zurueck - es steuert die MANUELLEN Trades
User: "der einsatz wird immer noch nicht uebernommen, siehe aktueller trade", danach Wahl von Variante A. DIAGNOSE - kein Defekt, sondern eine Luecke, die ich selbst gerissen habe. Der laufende Trade war setup=WAVE, also MANUELL; Slot 2 leer; und die Logzeile "Einsatz fuer <pfad>" existierte kein einziges Mal. Die Pfad-Felder wirken ausschliesslich auf die beiden AUTONOMEN Pfade - M15 ist aus, BRK hat seit dem Einbau nicht gefeuert (Circuit-Breaker hat heute dreimal ausgeloest). Das Feld hatte also nie eine Gelegenheit zu greifen. Manuelle Trades laufen bewusst auf dem GLOBALEN Wert (der Mensch ist die gemessen bessere Population, +1,56 gegen -4,71 EUR/Lot - seine Groesse gehoert ihm). Nur: das globale Feld war am 19.08. auf Wunsch entfernt worden, und danach kamen die Pfad-Felder dazu. Damit hatte ausgerechnet die Schraube, die die eigenen Eroeffnungen steuert, keine UI mehr - erreichbar nur noch ueber die ini plus Neustart. Das habe ich beim Bau der Pfad-Felder nicht mitgedacht. Behoben: Feld "Einsatz global %" als drittes in derselben Zeile. Endpoint /api/marginpct, set_margin_pct und die Persistenz existierten bereits - reine Frontend-Aenderung (v=186), kein Neustart, die offene Position unberuehrt. ⚠ Semantik bewusst ANDERS als bei den Pfad-Feldern: dort heisst leer/0 ausdruecklich "globaler Wert", hier gibt es kein "aus" - ein Einsatz MUSS gelten. Deshalb echte Untergrenze 1 statt der 0-Semantik. Verifiziert: 45 gesetzt -> Snapshot -> persistiert -> zurueck auf 40; span 51/51 ausgeglichen, keine doppelten IDs, node --check gruen, v=186 ausgeliefert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5593f270cc |
Dashboard-Zeile fuer Slot 2 + Doku des Zwei-Slot-Umbaus
Die vom Breakout-Trader gehaltene Position ist jetzt sichtbar (#brk-pos in der Breakout-Karte): Richtung, Lots, Einstieg, P&L - und vor allem der Trailing-Zustand. ⚠ Der Trailing-Hinweis ist der wichtigste Teil der Zeile: steht er auf "⚠ TRAILING AUS - nur Broker-SL!", laeuft der Trade in der gemessen DURCHGEFALLENEN SL-only-Variante (backtest_brk_slonly.py: alle zehn Konfidenzintervalle enthalten die Null, Trefferquote faellt 40 -> 21 %). Ohne diese Anzeige waere das im Betrieb nicht bemerkbar - genau Deployment-Drift Fall 8 (nicht die Strategie driftet, sondern ihre Beobachtbarkeit). Richtung wird aus SL/TP abgeleitet statt ein weiteres Snapshot-Feld zu bauen - place_stop setzt immer einen SL. Damit bleibt es eine reine Frontend-Aenderung (v=185), kein Neustart noetig, die offene Position unberuehrt. Verifiziert: v=185 wird ausgeliefert, div 85/85 ausgeglichen, keine doppelten IDs, keine verwaisten JS-Referenzen, node --check gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
027267063d |
Einsatz-je-Pfad-Feld war nicht bedienbar - auf das bewaehrte Muster umgebaut
User: "Einsatz je Pfad kann ich nichts eingeben".
URSACHE - mein erster Entwurf hat ein EIGENES Markup erfunden, statt das zu
nehmen, das im Projekt nachweislich funktioniert. Zwei Fehler darin:
(1) KEIN `inputmode`. Alle funktionierenden Felder des Projekts (SL, TP,
Gewinn-Close, Notfall-Close) tragen `inputmode="decimal"` - am Handy
erscheint sonst keine brauchbare Zahlentastatur. Das allein macht ein Feld
praktisch unbedienbar, obwohl es sichtbar und technisch "aktiv" ist.
(2) Die Inputs steckten in einem <b> innerhalb einer `.kv`-Zeile. `.kv` ist
`display:flex; align-items:baseline` und fuer das Muster
<span>Label</span><b>Wert</b> gebaut - also fuer TEXT, nicht fuer
Formularelemente.
BEHOBEN: identisches Markup wie die Trade-Leiste (`.tb-row` > `.tb-field` mit
<label> ueber <input>), plus `inputmode="decimal"` und `placeholder="global"`
statt "BRK"/"M15" - das macht zugleich sichtbar, was LEER bedeutet.
Zusaetzlich den Render gehaertet, damit der 1-s-Snapshot die Eingabe nicht
fressen kann: Feld mit Fokus wird gar nicht angefasst, und geschrieben wird nur
bei tatsaechlicher Aenderung (eine Zuweisung setzt sonst auch bei identischem
Text die Cursorposition zurueck).
⚠ LEHRE, die ueber diesen Fall hinausgeht: es gab in derselben Datei vier
funktionierende Vorbilder, und ich habe keines davon angesehen, bevor ich ein
neues Muster erfunden habe. Beim Hinzufuegen eines Bedienelements gehoert das
vorhandene Muster kopiert - dieselbe Klasse wie die dokumentierte Regel, beim
Wiederverwenden eines Backtest-Kerns die Live-KONFIGURATION mitzukopieren.
Reine Frontend-Aenderung (HTML/CSS/JS + v=184) - kein Neustart noetig, statische
Dateien werden je Request frisch von der Platte gelesen. Verifiziert: Tags
ausgeglichen (div 84/84, span 49/49), keine doppelten IDs, node --check gruen,
beide Felder mit inputmode im ausgelieferten HTML, v=184 wird ausgeliefert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
7915e171d0 |
M5-Kontextzeile in der M15-Karte statt einer eigenen M5-Setup-Karte
User fragte nach einer M1- oder M5-Setup-Karte und hat der hier gebauten
Variante zugestimmt: eine reine ZUSTANDS-Zeile, ohne Richtung und ohne Banner.
WARUM KEINE ZWEITE KARTE - und diesmal entscheidet eine frische Messung, nicht
eine Meinung. Die entkoppelte Selbstmessung der BESTEHENDEN Karte steht bei
n=342 (gruen + gerichtet, ab dem Hysterese-Stichtag 12.08.):
30 min 53,5 % KI [48,2 .. 58,8] -> enthaelt 50 %
60 min 49,3 % KI [44,0 .. 54,5] -> enthaelt 50 %, liegt DARUNTER
Am 12.08. war die Bedingung fuer ein Ja VORAB fixiert worden: ">=350 Faelle,
Trefferquote ueber 50 %, KI ohne die 50". Die Stichprobe ist jetzt da, die
Bedingung ist NICHT erfuellt. Das ist kein "noch zu wenig Daten" mehr.
Dazu die Messung vom 13.08.: als Handelsregel faellt die Karte durch
(backtest_m15_auto.py, OeR -0,162/-0,094, beide KI ohne Null, schlechter als
die HTF-Richtung UND schlechter als ihr eigenes Gegenteil).
M1 scheitert zusaetzlich an der Arithmetik: Spread/ATR Median 0,319 gegen 0,193
(M5) und 0,104 (M15). Feiner aufloesen macht die EINZIGE gemessene Staerke der
M15-Karte - die Kosten - monoton schlechter. Um 01:00 ist der Spread
1,051xATR_M1, also groesser als die mittlere Kerze; und die M1-Historie ist bei
80 Tagen gedeckelt, zwei Stichproben laegen im selben Regime.
GEBAUT ist deshalb Zustand ohne Urteil: Squeeze-Lage (armiert/Ausbruch/keine
Kompression + Box), Kosten in xATR_M5 mit den Schwellen aus
backtest_realcosts.py (Median 0,193, ab 0,32 Kostenfalle) und der ATR.
Der M5-RAUM wird bewusst NICHT wiederholt - Gate 3b rechnet ohnehin auf M5.
⚠ NUR ZUSAMMENGESETZT, nichts neu gerechnet: wave.squeeze und bid/ask/ATR_M5
stehen im Snapshot ohnehin. Ein zweiter Rechenweg war der Fehler des
Konsens-Pfeils (komplettes zweites _verdict im 5-s-Takt) und ist die Quelle
jeder Divergenz zwischen Karte und Chart.
⚠ Kein Verdict-Gewicht, kein Trade-Trigger, keine Farbampel - dieselbe
Zurueckhaltung wie bei der Kerzen-Anatomie und der Ueberdehnungs-Anzeige.
Live verifiziert: "M5 · keine Kompression (Box 3.52xATR) · Kosten 0.15xATR_M5
guenstig · ATR 0.165". Deploy ueber tools/deploy.py --feld m15_setup.m5
(Punktpfad), alle 5 Schritte gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
0a465f9258 |
Einsatz-Prozentsatz je autonomem Pfad (BRK / M15) + Dashboard-Feld
User: "Baue ein Eingabefeld im Dashboard ein in welchem ich das Margin Verhaeltnis von M15 / BRK manuell setzen kann". ⚠⚠ EHRLICHE EINORDNUNG, weil die Umsetzung NICHT ist, wonach es klingt: eine GLEICHZEITIGE Aufteilung (z.B. 40 % manuell / 50 % reserviert fuer BRK) ist heute nicht baubar. Der Bot haelt EINE Position - _check_auto_squeeze feuert "nur FLAT", und Trailing, Notfall-Stop, S/R-Close, Time-Stop und Breaker verwalten je EINE Position (42 Einzel-Positions-Annahmen in engine.py, 25 in trader.py). Mit zwei Positionen auf demselben Symbol haengt der GESAMTE Schutz-Stack an einer davon, die andere liefe ungeschuetzt. Das ist kein Aufwands-, sondern ein Sicherheitsargument. GEBAUT ist deshalb das, was heute wirkt und dieselbe Frage beantwortet: je Pfad ein eigener Einsatz-Prozentsatz. 0 = globaler Wert (bisheriges Verhalten). Quellen-abhaengig verdrahtet wie die SL-Zeitebene seit 05.08.: _open() setzt config.MARGIN_BUFFER fuer die Dauer des einen Aufrufs und stellt ihn im finally-Zweig zurueck. Manuelle Trades bleiben beim globalen Wert (der Mensch ist die gemessen bessere Population, +1,56 gegen -4,71 EUR/Lot). ⚠ Direkt gesetzt statt ueber set_margin_buffer(): das loggt je Trade eine Zeile UND wuerde den globalen Wert dauerhaft ueberschreiben. ⚠⚠ ZWEI ECHTE FEHLER VOM LINTER GEFANGEN, die py_compile durchgewinkt hat: "config" war in engine.py gar nicht importiert (nur Einzelnamen via "from core.config import ..."), und in server.py hiess die Engine "eng" statt "app.state.engine". Beide sassen in Pfaden, die erst beim ERSTEN autonomen Trade bzw. beim ersten Klick gefeuert haetten - also genau die Klasse, fuer die ruff F821 am 07.08. eingebaut wurde. ⚠ Frontend: $streng statt $, weil LEER hier ausdruecklich 0 = "global" bedeutet und nicht "unveraendert"; mit dem Auffang-Element waere .value undefined -> NaN -> null. Der Render ueberschreibt das Feld nicht, solange es den Fokus hat (sonst frisst der 1-s-Snapshot die laufende Eingabe). ⚠ Beim Committen selbst zweimal danebengegriffen, beides dokumentiert weil es Fehlerklassen sind: (a) Backticks in einer Bash-Commit-Nachricht werden als Kommando-Substitution ausgefuehrt und loeschen die eingeklammerten Namen aus dem Text; (b) ein Bash-Pfad (/c/Users/...) an Python uebergeben schlaegt fehl, und "git commit --amend -F <fehlende Datei>" nahm daraufhin eine STALE COMMIT_EDITMSG - die Nachricht eines fremden Commits. Der Code war davon nie betroffen (Arbeitsbaum sauber, Remote synchron), nur die Beschriftung. Ende-zu-Ende geprueft: 50/25 gesetzt -> Snapshot -> persistiert; 150 abgelehnt; 0/0 zurueck. Deploy ueber tools/deploy.py --feld margin_brk, alle 5 Schritte. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
bd65bdaad0 |
M15-Auto-Entry gebaut (Default AUS) -- gegen die Messung, auf User-Wunsch
User wollte den Auto-Trade testen, nach vollstaendiger Information ueber die
Beleglage. backtest_m15_auto.py (13.08.): die gehandelte Lesart ist in BEIDEN
Halbjahren negativ (OeR -0,162/-0,094, PF 0,72/0,84), beide KI schliessen die
Null aus, Nachbarn monoton schlechter, und sie ist schlechter als die
HTF-Richtung UND als ihr eigenes Gegenteil. Live entkoppelt 46,8 % Treffer.
_check_auto_m15 im _pos_loop: Ausloeser gruen + gerichtet, Richtung exakt wie im
Backtest (auf->LONG, ab->SHORT), Dedup 1x je Episode ueber (Richtung, Level),
nur FLAT, Setup-Tag AUTOM15_*. Erbt die VOLLE Guard-Kette ueber
_auto_guard('m15') -- der Parameter war laut Docstring genau dafuer vorgesehen,
nachgebaut wurde nichts.
Abweichung ausdruecklich benannt: gemessen wurde der Einstieg AM Level mit Fill
bei Beruehrung, gebaut ist der Markt-Einstieg. Der ist hier mehrfach als der
schlechtere gemessen -- die Live-Zahlen sind eher noch unter -0,16/-0,09 zu
erwarten.
Abbruchregel VORAB fixiert: nach >=20 AUTOM15_*-Trades Verhaeltnis < 1,0 ODER
PF < 1 -> auto_m15 = false. Dieselbe Latte wie B5, damit sie nicht nachtraeglich
wandert.
Verifiziert: Toggle, Snapshot-Felder, Deploy mit --feld auto_m15, ruff F821
(neuer Code sitzt in einem except -- der dokumentierte blinde Fleck), 85 Tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
eedef26673 |
Close-Alarm hoerbar vom Empfehlungston getrennt (v=180)
User: 'beim akustischen Signal blinkt der Close-Button nicht'. Code und CSS sind korrekt -- Blinken und Close-Ton haengen an derselben Variablen (closeAlert) und koennen nicht auseinanderlaufen. Der gehoerte Ton war der EMPFEHLUNGSton, der nur bei FLAT spielt und sich alle 30 s wiederholt; CLOSE blieb dabei korrekt dunkel, weil es nichts zu schliessen gibt. Der eigentliche Fehler ist die Aehnlichkeit: SHORT-Empfehlung 780->520 Hz und Close-Alarm 880->620 Hz sind beide fallende Zweiklaenge, nur ~100 Hz auseinander. Der Close-Alarm ist jetzt DREI kurze Pulse auf gleicher Tonhoehe (1046 Hz) -- Rhythmus unterscheidet zuverlaessiger als Tonhoehe. Keine Logikaenderung, nur die Klangfarbe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
d9ff48b5be |
Knopf 'STOPP' in 'CIRCUIT BREAKER' umbenannt (v=179)
Nur Beschriftung: Button-Label, Toast-Text und die beiden Tooltip-Varianten. Funktion, Endpunkt und Persistenz unveraendert. Dazu eine CSS-Zeile, damit das laengere Label auf schmalen Displays umbricht statt ueberzulaufen -- sechs Knoepfe teilen sich die Leistenbreite. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
c0293ece01 |
S/R-Auto-Close-Schalter in die Aktionsleiste + Doku nachgetragen (v=178)
Den S/R-Schalter gab es nur in der Trade-Leiste -- die ist aber nur bei OFFENER Position sichtbar, also genau dann nicht, wenn man ihn VOR einem Trade setzen will. Jetzt zusaetzlich in der Aktionsleiste neben STOPP. Der alte Knopf bleibt; beide lesen auto_sr_close aus demselben Snapshot und koennen nicht auseinanderlaufen. Live getestet: aus -> an, Endzustand AN. Ausserdem die Doku zu den heutigen UI-/Telegram-Aenderungen nachgetragen, die beim vorigen Versuch am Encoding-Fehler gescheitert war -- inklusive der Lehre: Emoji nie als getrennte Unicode-Escapes, immer erst nach .tmp schreiben und die Groesse gegen das Original pruefen, und eine Syntaxpruefung ersetzt die Groessenpruefung nicht (eine leere Datei besteht node --check und jeden Hook). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e48ad80c0a |
UI aufgeraeumt + Telegram auf Closes reduziert (v=177)
Vier User-Vorgaben:
1. Einsatz-Felder entfernt. Backend bleibt vollstaendig -- Folge: der
Prozentsatz ist ohne UI nur ueber ini + Neustart aenderbar.
2. BRK-Schalter entfernt, dafuer STOPP (Circuit-Breaker). Bewusster Tausch mit
Konsequenz: der An/Aus-Schalter des AUTONOMEN Pfads ist aus der App weg (nur
noch POST bzw. ini), sein Zustand bleibt in der Breakout-Karte sichtbar.
Dafuer ist die Notbremse bedienbar, die am 17.08. real ausgeloest hat.
set_circuit_breaker + POST /api/circuit + runtime_state (cb_limit_pct,
cb_remember -- ohne das Gedaechtnis waere die Prozentzahl nach einmal
Ausschalten fuer immer weg).
3. Telegram nur noch bei geschlossenen Trades: EINE Filterstelle vor
_send_telegram_roh statt 17 Einzeleingriffe, _TG_ERLAUBT = ('Trade
geschlossen',). Umkehren = Liste erweitern. Tages-/Wochenreport wird nur auf
dem Telegram-Weg still, die E-Mail laeuft weiter.
EINE Ausnahme mit Bypass: '<ok_word> FEHLGESCHLAGEN' beim Notfall-Close --
dort ist die Position NICHT zu und es braucht eine Handeingabe.
Verifiziert: /api/circuit vorher 405, nachher 200; Toggle aus->an->8 %/57,94 EUR
persistiert; 85 Tests, node --check, check_nfalle gruen; 0 verwaiste
JS-Referenzen; genau eine Instanz je Port.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
30cb77b795 |
Breakout-Karte vorbereitet (inaktiv bis Neustart) + Bewertung der Margin-Idee
User-Idee: 40 % Margin manuell, 50 % fuer Breakout reservieren, neue Karte. Bewertung: (1) 40 % ist der groesste gemessene Hebel (MaxDD 82,8 %) und ein Schalter ohne Neustart. (2) Reserve ist technisch moeglich (Konto ist RETAIL_HEDGING), aber _check_auto_squeeze feuert 'nur FLAT' und engine.py hat 17 Einzel-Positions-Annahmen -- Kern-Umbau, kein Parameter. Zudem steht die Zuteilung gegen die Messung: autonom -4,71 EUR/Lot gegen Mensch +1,56 EUR/Lot. Live-Befund macht (1) dringlich: freie Margin -6,21 EUR, Margin-Level 99,3 %. Es gibt derzeit nichts zu reservieren. Gebaut (inaktiv): history.fetch_squeeze_since, engine._squeeze_b5_cached (120 s gecacht), Snapshot-Feld squeeze_b5, Karte #card-brk. Eigenes Fenster ab 01.08. -- squeeze_monitor.live rechnet ueber alle 42 Trades, B5 zaehlt 11. Die Karte zeigt beide Zahlen, weil der Monitor 'ontrack' aus der MECHANIK meldet, waehrend live Verhaeltnis 0,14 / PF 0,39 steht. Live aendert sich nichts: Karte ist hidden, renderBrk blendet sie aus solange squeeze_b5 fehlt. Aktiv nach dem naechsten Neustart (wartet auf den Trade). BEINAHE-SCHADEN: ein UnicodeEncodeError liess web/app.js mit 0 Bytes zurueck. node --check bestand trotzdem -- eine leere Datei ist gueltiges JS. Gefangen hat es erst der Groessenvergleich. Neue Regel: erst .tmp schreiben, Groesse pruefen, dann os.replace. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
af5190cf9e |
Raum je Richtung auf die Order-Knoepfe (v=175)
Gemessen auf 27 eigenen manuellen Trades: Raum < 0,6xATR zum naechsten Level in Trade-Richtung = 79 % Trefferquote und trotzdem -7,57 bzw. -11,51 EUR/Lot. Das ist die Klein-Close-Falle (Gewinn am Level gedeckelt, Verlust laeuft bis zum Stop), ueber 80k Bars als PF 0,42/0,66 belegt. Die Zahl stand nur in Gate 3b der M15-Karte -- seit dem Entfernen des Entry-Dialogs am 11.08. war sie im Moment des Klicks unsichtbar. Jetzt als zweite Zeile auf dem LONG-/SHORT-Knopf, bernstein unter dem Gate. REINE ANZEIGE: kein Block, keine Sperre, kein Dialog -- Uebersteuerungen laufen gemessen 68 % WR. Kein Backend, kein Neustart: die Daten lagen bereits im Snapshot (m15_setup.motor.raum) und werden NICHT neu gerechnet. Bewusst kein eigener Layout-Block, weil #actions ein flex ohne wrap ist. Verifiziert: node --check als Modul, check_nfalle sauber, beide IDs im ausgelieferten HTML, live LONG 0,07xATR (unter Gate) / SHORT 1,49xATR. 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
|
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
|
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
|
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
|
47c596ed70 |
M15-Karte: Gate 3b zeigt Motor-Block + RAUM je Richtung
Anlass Trade #49671601 (-87,03 EUR). Die Praemisse "SL trotz LONG- Empfehlung" stimmte nicht: 138 Zeilen zwischen Ein- und Ausstieg, 100 % WARTEN (entry_room 76 %, breakout_pending 19 %, min_conf 5 %). Gesehen wurde "verboten: SHORT" - ein Veto. Dritter Fall derselben Veto->Richtung-Umwandlung in dieser Karte (Code 08.08., Geometrie 10.08. frueh, jetzt die Lesart). Der eigentliche Befund: entry_room und Gate 3 lesen DIESELBE Tatsache ("ein Level ist nah") mit umgekehrtem Vorzeichen. Beide gemessen, beide richtig - ueber verschiedene Trades (Markt-Einstieg mit dem Level als Hindernis vs. ruhende Order AM Level). Die Karte zeigte nur die gruene Haelfte; die Block-Grund-Zeile war mit der Gesamtempfehlung verschwunden. Gebaut: Zeile 3b (#m15-motor) mit block_reason im Klartext + Raum je Richtung. Reine Anzeige. Das Status-Banner bleibt bewusst unveraendert - es auf gelb zu ziehen waere eine Strategie-Aenderung, und die einzige Live-Zahl dafuer (-9,91 vs +3,24 EUR/Lot, n=76) hat ein KI, das die Null enthaelt. - wave_rec.room_info(): EINE Implementierung fuer Gate und Anzeige, _room_gate rechnet jetzt darueber (kein Nachbau) - tests/test_room_info.py: Bitgleichheit ueber 2.000 Zufallslagen x 3 Signale, Gate feuerte >300x; Grenzfall-Test fuer die Rundung - v=160 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5474c2be61 |
Gate 4 der M15-Karte: Ziel nur noch in der ERLAUBTEN Richtung
User-Fund: Karte zeigte "verboten SHORT" (= LONG erlaubt) UND ein Ziel 0,15 $ UNTER dem Kurs. Die Arithmetik war korrekt - aber fuer die verbotene Richtung. Ursache: das Ziel war schlicht das entferntere der beiden Level (max nach gap), ohne Richtungspruefung. Strukturell steckte dahinter ein Fade-Trade (Gegenlevel als Ziel = Mean Reversion) in einer Kette, deren Gate 2 ein Trendfilter ist - zwei unvereinbare Konzepte. Damit derselbe Fehler, wegen dem die Gesamtempfehlung entfernt wurde: aus einem VERBOT wird ueber die Hintertuer wieder eine RICHTUNG. Fix nach der gemessenen Population (backtest_m15_gates.py): Einstieg am naechstgelegenen Level, Richtung = die vom HTF erlaubte. Ein Ziel nur, wenn es jenseits dieses Einstiegs in der erlaubten Richtung liegt; sonst "kein Ziel" mit Grund statt einer erfundenen Zahl. Richtung steht jetzt im Anzeigetext. - tests/test_m15_ziel.py (6 Tests, Invariante ueber 32 Konstellationen) - Mutationsprobe: alte Zeile zurueck -> 4 von 6 Tests fallen - deploy.py --feld unterstuetzt jetzt Punktpfade (m15_setup.ziel_grund) - v=159 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
b8705e297f |
Kegel mit Adaptive Conformal Inference nachkalibriert (v=158)
Der Kegel war seit dem 31.07. dokumentiert 3-5 Pp ZU ENG - 80 % nominal gegen
real 76,7 / 76,6 / 75,3 % - und blieb es, weil Nachfitten das Problem nur
verschiebt. ACI justiert stattdessen ONLINE nach jedem aufgeloesten Fenster und
konvergiert nachweislich gegen die Zielabdeckung, auch unter Drift.
EHRLICH ZUR BAUART: die Lehrbuch-Form justiert alpha und schlaegt das Quantil
nach. Hier liegt nur eine feste Quantil-Tabelle vor, kein Verteilungsobjekt -
umgesetzt ist die multiplikative Variante:
s <- s * exp(gamma * (1{verfehlt} - alpha_ziel)), gamma 0,02, Deckel 0,7-2,0
Dieselbe Regelungsidee, aber die Konvergenz-GARANTIE der Originalform ist damit
nicht woertlich uebertragen.
Verifiziert: bei exakt 20 % Verfehlern bleibt die Skala bei 1,0000 - der
Fixpunkt stimmt. Simulation aus der dokumentierten Lage (76,6 %): nach ~50
Checks um 80 %. Die Skala pendelt um das Ziel statt exakt zu treffen - das ist
das bekannte ACI-Verhalten (garantiert ist die Langfrist-Abdeckung).
NICHT-UEBERLAPPEND geloggt (neue Tabelle cone_checks): ein 120-min-Fenster alle
5 min waere 24-fach ueberlappend - genau die Cluster-Verzerrung, an der
analyze_hl_funding.py aufgelaufen ist und die die Faelligkeitsbedingung
pbreak_accuracy_v2 um das Zehnfache danebenliegen liess. Je Horizont startet ein
neuer Check erst, wenn der vorige ablief -> 48/24/12 Checks je Tag.
Neustart-fest ueber runtime_state.json. build() ohne skalen liefert bitgenau die
alten Werte (additiv geprueft).
ZWEI EIGENE PLATZIERUNGSFEHLER, beide gefangen: der Lade-Block landete zuerst
HINTER den except-Klauseln von _load_runtime_state, wo st nicht mehr existiert;
und beim M15-Setup landete ein Block mitten in einem mehrzeiligen Aufruf. Der
erste waere stillschweigend nie gelaufen - gefunden nur, weil ich die Funktion
danach gelesen habe statt dem gruenen py_compile zu trauen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
86c432f791 |
M15-Karte misst sich selbst + Ausfuehrungsqualitaet sichtbar (v=157)
Nach Web-Recherche umgesetzt, Punkte 2 und 3 der Wahl. SELBSTMESSUNG (neue Tabelle m15_states): die Karte hatte KEINE Rueckkopplung - geprueft, es gab kein Logging. Das war die auffaelligste Luecke: jeder Ausfall, der in diesem Projekt je aufgedeckt wurde, kam aus einer Rueckkopplung (pbreak_predictions entlarvte den Modellausfall LIVE, was kein Backtest konnte; der B4-Monitor die Squeeze-Drift). Die Karte haette monatelang falsch stehen koennen. Neu: eine Zeile je ZUSTANDSWECHSEL, nach 30/60 min gegen candles_m1 ausgewertet, Ergebnis als Zeile 6 in der Karte. Gewertet wird die LESART, nicht der Status, und nur die gerichtete (45-55 % zaehlt nicht mit). Gegen 50 % lesen. Nur bei Wechsel, nie je Tick - sonst dieselbe Cluster-Verzerrung, die am 07.08. elf widerlegte Hypothesen ausgeloest hat. Live verifiziert: 1 Zeile trotz laufendem Sekundentakt. AUSFUEHRUNGSQUALITAET (Zeile 7): analyze_squeeze_entry_gap.py existiert seit dem 05.08. und misst die TCA-Kennzahl (Arrival-Price-Slippage) - niemand hat je hineingesehen. Dabei war das der einzige Erfolgsmassstab des Stop-Order-Umbaus und zugleich der groesste je gemessene Hebel (+0,32 R). Jetzt steht der Zaehlstand in der Karte: 3 von 12 Bot-Trades seit dem Umbau. NICHT gebaut: der Kegel mit Adaptive Conformal Inference. Er ist mit 76,7/76,6/75,3 % gegen 80 % Nennwert dokumentiert zu eng, und ACI waere die Standardmethode (adjustiert online, garantiert Konvergenz auch unter Drift). Bleibt offen. BEIM BAU EIN NAMEERROR IM 1-SEKUNDEN-PFAD, VOM LINTER GEFANGEN: der erste Entwurf berechnete _m15 in _run_analysis und benutzte es in snapshot(); dort gibt es weder market noch wave_snap. py_compile sieht das NICHT, ruff F821 meldete 4 Befunde. Genau die Fehlerklasse, fuer die der Linter am 07.08. eingebaut wurde - und der erste echte Fang. Zweiter Fehler beim Verschieben: der Block landete mitten in einem mehrzeiligen Aufruf. Beide behoben. DB-Backup: oil_widget_history.db.bak-2026-08-08-m15states Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
5ddbe07066 |
Gate 3 mit Richtungs-Lesart - bedingt auf das Level, keine freie Prognose (v=156)
User-Frage: kann die Karte eine Wahrscheinlichkeit fuer steigenden oder fallenden Kurs rechnen? FREI: nein, und das ist gemessen. analyze_reversal.py hat genau das gebaut (logistische Regression, 8 kausale Merkmale, 5 Ereignis-Definitionen): AUC 0,499-0,509 out-of-sample und IN-SAMPLE nur 0,52. Die zweite Zahl ist die entscheidende - das Modell erklaert nicht einmal seine eigenen Trainingsdaten. Kein Overfitting, sondern keine Information vorhanden. Dazu Live-Richtung 48-51 % ueber 1.071 Episoden, Meta-Labeling AUC 0,508/0,479. BEDINGT: ja, und die Zahl ist schon da. P(break) fragt nicht "wohin geht der Kurs", sondern "haelt DIESE Struktur" - bedingt auf ein reales Objekt mit Orders dahinter, AUC 0,65 out-of-sample. Gate 3 formuliert das jetzt aus: Widerstand 77.784 (1,27xATR) -> 56 % Abprall, eher abwaerts Support 77.098 (0,90xATR) -> 65 % Abprall, eher aufwaerts 45-55 % bekommt BEWUSST keine Richtung - dort ist die Zahl ein Muenzwurf, und daraus einen Pfeil zu machen waere derselbe Fehler, den die MQL5-Pfeile schon einmal vermieden haben. Tooltip nennt die Beleglage und die aktuelle Fehlkalibrierung (~7 Pp zu niedrig). Logik mit 6 Faellen geprueft (Widerstand/Support x hoch/niedrig/Muenzwurf). Nebenbefund: node --check hat einen Syntaxfehler gefangen - ein gerades " als schliessendes deutsches Anfuehrungszeichen beendete den String. Genau die in CLAUDE.md dokumentierte Falle; die heute eingebaute Pruefung hat sie sofort gemeldet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
30830d76b1 |
M15-Karte: Bias war ein Richtungsgeber - korrigiert zum Veto (v=155)
Tagestest an 07.08. (test_m15_karte_tag.py) deckt einen strukturellen Fehler in meiner eigenen Karte auf. Rohzahlen: 92 M15-Bars, davon 46 (50 %) auf GRUEN. Entkoppelt auf zusammenhaengende Bloecke bleiben 13 Setup-Episoden - und ALLE 13 waren LONG, an einem Tag, der von 78,399 auf 77,383 FIEL (-1,016 $). Trefferquote 0 %, OeR -0,753, SumR -9,79. Ursache ist nicht Pech, sondern ein Denkfehler: gemessen ist "gegen den M30-Trend zu handeln halbiert den Edge" - eine VERBOTS-Aussage. Ich hatte daraus "M30+H1 einig -> Bias LONG" gemacht, also einen Richtungsgeber. Exakt der Fehler, wegen dem die Gesamtempfehlung entfernt wurde (Richtung dort 48-51 % Treffer). Die nachlaufende EMA zeigt im Trendtag stur in die alte Richtung - dokumentiert seit analyze_signal_live.py. Korrigiert: das Feld liefert nur noch, welche Richtung VERBOTEN ist (bias.verboten); bias.richtung ist dauerhaft None. Das Banner nennt keine Richtung mehr: "BEDINGUNGEN OK @ 77,098 - Order ANS LEVEL, nicht zum Markt - SHORT vermeiden" Zwei weitere Befunde aus demselben Test, offen dokumentiert: - Das Kosten-Gate blockte 0 von 92 Bars. Auf M15 liegt Spread/ATR bei ~0,10, die Schwelle bei 0,32 - das Gate ist dort faktisch dekorativ. - Die strengere Bias-Variante (M30 UND H1) unterscheidet sich kaum von der laxen (46 gegen 47 gruene Bars) - die Zusatzstrenge kostet nichts, bringt aber auch nichts. Auch ein Fehler in meinem TEST, dokumentiert: der erste Lauf zaehlte 46 fortlaufende Bars als 46 Trades und meldete 7 % Trefferquote - eine Bewegung 46-mal gezaehlt. Erst die Entkopplung auf Episoden macht die Zahl lesbar. WARNUNG zur Beweiskraft: EIN Tag ist kein Edge-Nachweis. Belastbar ist hier nicht die Trefferquote, sondern der MECHANISMUS - und der ist aus zwei Halbjahren dokumentiert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
e5adfc9757 |
Slippage vs Vola-Regime gemessen + Ziel-Erreichbarkeit gebaut (v=154)
MESSUNG (analyze_slippage_vola.py, 337 SL-Closes): die Exit-Slippage steigt MONOTON ueber alle vier Delta-ATR-Quartile: 0,39-0,91 Schaetzer 0,0200 $ 0,91-1,08 0,0390 $ 1,08-1,26 0,0645 $ 1,26-2,39 0,0839 $ Faktor 4,19x Mechanismus stimmig: die Slip-RATE bleibt flach (20-23 %), die GROESSE waechst (0,094 -> 0,396 $). Es rutscht nicht oefter, sondern weiter. ABER: der Bootstrap auf die DIFFERENZ oben-unten ergibt [-0,012 ... +0,183] - enthaelt die Null. Bei n=85 je Quartil NICHT statistisch belegt. Meine vorab fixierte Regel (Faktor >=2 UND monoton) war damit unterspezifiziert - sie haette ein Konfidenzintervall verlangen muessen. Konsequenz: gebaut als reiner HINWEIS im Kosten-Gate, kein Gate, und die Beschriftung sagt "historisch ~4x hoeher", nicht "belegt". ZIEL-ERREICHBARKEIT (Vorschlag 3, Decay-Clock): reine Geometrie auf dem kalibrierten Kegel - passt das Gegenlevel noch in das 80-%-Band des jeweiligen Horizonts? Live: Ziel 77,784 (0,401 $) liegt im 120'-Kegel, nicht im 30'/60'. Die im Vorschlag mitgedachte Annahme "je laenger, desto eher bricht es" ist BEWUSST NICHT eingebaut - sie ist nicht belegt (Touch-Zahl: umgekehrtes U auf 4 Live-Tagen, im Backtest +0,010 AUC, nach dem Nachtrainieren gar nichts mehr). Umsetzung ohne zweiten MT5-Fetch: _vola_regime puffert den ATR_M15 aus dem ohnehin laufenden Turn-Fetch (deque, ~5 h). Kaltstart liefert datr=null statt zu raten - live verifiziert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
44955bf70a |
M15-Karte "Setup-Bereitschaft" gebaut - Ersatz der Gesamtempfehlung (v=153)
Nach drei negativen M15-Messungen (Squeeze-Einstieg, VWAP-Baender, Exit-ATR) steht fest: auf M15 traegt keine Richtungsquelle. Gebaut ist deshalb bewusst KEINE Empfehlung, sondern eine sequenzielle Gate-Kette: [1 HTF-BIAS M30/H1] -> [2 KOSTEN Spread/ATR_M15] -> [3 LEVEL & KEGEL] -> Order AM LEVEL Der Unterschied zur alten Karte ist grundsaetzlich: dort wurden Stimmen zu einem Bias VERRECHNET (gemessen 48-51 % Treffer), hier muss jedes Gate EINZELN passieren. Ein gefallenes Gate laesst sich nicht durch ein anderes ausgleichen. Nur belegte Bausteine: HTF-Trend (einziger robuster Filter, Edge x2), Kosten (M15 gemessen 0,104 gegen M5 0,193), naechstes stehendes Level + P(break), Kegel (out-of-sample kalibriert, 80-%-Band trifft 77 %), Veto (-6,60 EUR/Lot). Status-Banner: SETUP BEREIT / WARTEN AUF LEVEL / KEIN TRADE. Es bestaetigt ausdruecklich auch das NICHT-Handeln - die gemessene Kern-Leckage sind diskretionaere Abweichungen. Die Order-Buttons werden BEWUSST NICHT gesperrt (gegen den Vorschlag "ausgrauen"): hartes Blockieren wurde im Projekt verworfen, und User-Uebersteuerungen liefen gemessen 68 % WR. Umsetzung: engine._m15_setup() setzt nur zusammen, was der Snapshot ohnehin erzeugt. Neu gerechnet wird allein das M15-Kosten-Verhaeltnis und P(break) fuer das naechste Level. Dafuer veroeffentlicht wave_rec jetzt tf_atr (ADDITIV) - der ATR je Zeitebene wurde im Turn-Fetch laengst berechnet, war aber nirgends abrufbar. P(break)-Merkmale bleiben auf M5 (Modell ist darauf trainiert, Fix 2026-07-13). Mit 5 Szenarien getestet (alles passt, Bias uneinig, Kosten teuer, Level zu weit, Kaltstart ohne ATR_M15 -> kein Absturz), live verifiziert ueber deploy.py --feld m15_setup. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
30c8616280 |
Gesamtempfehlung entfernt (User-Entscheidung 2026-08-08)
"Funktioniert so leider nicht, entferne es komplett - wir bauen etwas Neues."
Entfernt: Headline, Konfidenz-Ring, Bias-Nadel, Modul-Chips, Konsens-Zeile,
Block-Gruende. Dazu renderVerdict(), die zugehoerigen 24 CSS-Regeln,
docs/gesamtempfehlung.md und die Snapshot-Felder `verdict` + `block_mix`.
Die Aggregation war reine ANZEIGE - vor dem Loeschen belegt: die Order-Logik
haengt an `wave_signal` bzw. `checklist`, nicht am Verdict (Blinken app.js:821,
Order-Dialog 1312/1366/1391). Orders, Alarme und das gemessene Veto
(-6,60 EUR/Lot) sind unberuehrt.
BEHALTEN (sassen nur in derselben Karte, je eigene Beleglage, User-Entscheidung):
Zeitebenen-Ampel #wave-turns - war aus der Welle-Karte dorthin verschoben
Erwartete Spanne #kx-cone - out-of-sample kalibriert, trifft real ~77 %
Selbstkalibrierung #kx-selfcal - misst das Wellen-Signal, das bleibt
HL-Kontext #hl-note - lief in renderVerdict mit, schreibt aber in
die Meldungen-Karte
Sie stehen jetzt in der neuen, schlanken Karte "Marktkontext" (#card-kontext).
IDs von vd- auf kx- umbenannt, damit keine tote Nomenklatur zurueckbleibt.
verdict_votes wird WEITER geloggt (User-Entscheidung): `_verdict()` bleibt
bestehen und laeuft 1x/min fuer die Telemetrie sowie fuer den optionalen
MQL5-Konsens-Pfeil. Aus dem 1-s-Snapshot ist es raus - dort waere es Arbeit fuer
eine Anzeige, die es nicht mehr gibt.
Verifiziert: node --check gruen, 34 Tests gruen, 0 verwaiste $("id")-Zugriffe
(die zwei Treffer 'neu'/'x' stehen in Kommentaren), CSS-Klammern ausgeglichen
(287/287), @media und @keyframes intakt. Zeile 1572 (_SQM_VERDICT[d.verdict])
ist der SQUEEZE-MONITOR-Verdict und bleibt.
Asset-Version v=152.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
59e9498237 |
G/V-Lag: 1-s-Fallback + ehrlicher Verbindungspunkt (v=151)
Zuerst gemessen, dann gedreht - und das Backend war NICHT das Problem: /api/snapshot 75 Abrufe in 20 s -> 21 verschiedene ts = ~1/s WebSocket-Push direkt am Socket gemessen: Median 1,04 s (min 1,00 max 1,06) G/V-Aenderungen Ø 1,44 s - das ist der Markt, keine Verzoegerung Die ganze Server-Kette liefert bereits 1 s. Der Lag entsteht erst am Handy: bricht der WebSocket STILL weg (WireGuard-Aussetzer, App-Wechsel), traegt nur noch der REST-Poll - und der stand auf 4 s. POLL_MS 4000 -> 1000, aber mit Sperre: solange der WS liefert (lastWsMs, Fenster WS_FRISCH_MS=2200 ms), ueberspringt der Poll den Abruf. Kein zusaetzlicher Verkehr im Normalfall. Denkfehler, den erst die Simulation zeigte: der erste Entwurf las die WS-Frische aus lastRecvMs (jede Quelle) - damit drosselte sich der Poll SELBST und kam bei totem WS nur auf 2,9 s statt 1 s. Jetzt zwei getrennte Uhren. Simuliert: WS gesund -> 0 Zusatz-Abrufe, max. Alter 0,9 s. WS tot -> 1/s, max. Alter 0,9 s. WS traege (5 s) -> max. 2,9 s. Vorher bei totem WS: 4,0 s. Der Verbindungspunkt log: er wurde nur bei sock.onclose auf "off" gesetzt, aber genau der Fall, der den Lag erzeugt, feuert KEIN onclose - der Socket haengt still, der Punkt blieb gruen. Neu .dot.stale (bernstein, pulsierend) ab 3,5 s ohne frischen Snapshot: gemessen wird, was ANKOMMT, nicht was der Socket ueber sich behauptet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
3e8fa9fea8 |
Auffang-Element in app.js: ein fehlendes Element bricht nicht mehr den Render
Gemessen: 95 direkte $("id")-Zugriffe, 0 davon abgesichert - obwohl die Regel
"neue Elemente per const el = $(..); if (el) {..}" seit 01.08. in CLAUDE.md
steht. Eine Regel mit 0 Prozent Befolgung ist keine Regel, also loest es jetzt
der Code an EINER Stelle statt an 95.
$() gibt bei fehlendem Element ein detachiertes <span> zurueck statt null,
plus einmalige console.warn je ID (kein stiller Fallback - das war der
catch{}-Fehler in pollSnapshot).
?. war NICHT die Loesung: 80 der 95 Zugriffe sind Zuweisungen, und
$("x")?.y = v ist ein Syntaxfehler.
$streng() ist der wichtige Teil. Alle Eingabefelder sind type="number", und
leer heisst dort ausdruecklich "Stop entfernen" (sl: null). Mit dem
Auffang-Element waere .value undefined -> parseFloat NaN -> JSON.stringify
macht daraus wieder null: eine fehlende Eingabemaske haette den Broker-SL
einer laufenden Position stillschweigend geloescht. Betroffen war genau eine
Funktion (sendSltp); setSrMin/setEmg/setManualMargin/setMarginPct fangen NaN
bereits ab (geprueft, nicht angenommen).
Beide Richtungen an einem Minimal-DOM verifiziert, das eine alte index.html
simuliert: mit der alten $-Definition bricht der Render beim ZWEITEN Feld ab,
mit der neuen laeuft er durch. Der Order-Pfad bricht in beiden Faellen sauber
ab.
Asset-Version v=149 -> v=150.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
5a89544a27 |
tools/check_nfalle.py: Scan gegen die \n-Falle — Projekt ist sauber
Auftrag "ueberpruefe alle dateien auf \n-Falle". Die Falle: ueber ein
Shell-Heredoc geschriebener Code macht aus einem gemeinten \n einen ECHTEN
Zeilenumbruch mitten im String-Literal. Heute zweimal passiert (Telegram-Text
in engine.py, Reminder-Eintrag in measurement_reminder.py).
Der Scan prueft in beide Richtungen:
A) kompiliert alle .py (161 Dateien) — sauber
B) JS: unabgeschlossene String-Literale — app.js sauber
C) UMGEKEHRT: literales \n als sichtbarer Text in HTML-title= und Markdown
— alle sauber
D) Signatur der beiden heutigen Faelle (Zeile endet offen, naechste besteht
nur aus einem Quote) — keine
⚠ Fehlalarm im Scanner selbst gefunden und behoben: Quotes zu ZAEHLEN meldet
'"' als offenes Literal (gueltiges JS mit einem Anfuehrungszeichen darin, real
in app.js). Der Scan verfolgt jetzt zeichenweise den AKTIVEN Quote-Typ.
Die betroffene app.js-Stelle trotzdem aufgeraeumt: schliessendes
Anfuehrungszeichen jetzt als U+201C statt ueber eine Konkatenation mit '"'.
Regel in CLAUDE.md ergaenzt: mehrzeilige Strings mit \n nicht per Heredoc
schreiben, sondern ueber den Edit-Weg.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
4155afb434 |
Widerspruch "stark LONG" bei WARTEN aufgeloest (v=149)
User-Fund: Headline "◌ WARTEN · M30", darunter "stark LONG · 2 von 2
stimmberechtigten fuer LONG (7 ohne Aussage)". Beide Zahlen stimmten, die
Kombination war irrefuehrend. Zwei Ursachen:
(1) Die Headline nannte den Grund nicht. Er stand im Snapshot
(wave_signal.block = min_conf, conf 49 gegen 55 % — die Welle HATTE eine
LONG-Richtung, ihr fehlten sechs Punkte), gerendert wurde er aber nur bei
breakout_pending. ⚠ Meine Luecke vom 06.08.: ich habe die Tages-Verteilung
(#vd-blocks) gebaut und den AKTUELLEN Grund vergessen. Jetzt Mapping fuer
alle neun Gate-Codes an der Headline.
(2) "2 von 2" las sich wie Einstimmigkeit — es waren 2 von 7 sichtbaren
Modulen (H1 1,5 und Liq-Trend 0,5), und die Welle, die als einzige die
Order steuert, war nicht dabei. bias=1,0 ist arithmetisch korrekt, aber die
Basis war winzig. Das Entmachten von Elliott/Orderbuch hat das Problem
nicht erzeugt, aber verschaerft.
Neu: Zeile fuehrt mit der Basis, "stark/leicht" entfaellt solange weniger
als die Haelfte der Module spricht, stumme Welle wird ausdruecklich genannt.
Live gegengerechnet:
"◌ WARTEN · M30 · Konfidenz 49 % < 55 % — Setup zu schwach"
"2 von 7 Modulen sprechen, alle fuer LONG · die Welle ... schweigt"
Reine Anzeige — Gewichte, Gates und Order-Logik unveraendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
cf94679022 |
Setup- und Lauf-Zeile aus den Meldungen entfernt (v=148)
Beide .kv-Zeilen samt JS-Zuweisungen (wave-setup, wave-move) raus. Das Setup
steht ohnehin in der Verdict-Headline und den Gruenden, der "Lauf" beschrieb
die Vergangenheit ohne Handlungsbezug.
⚠ Fallstrick beim Entfernen, korrigiert: die Zeile
`const w = d.wave_signal || {}, ws = ...` stand direkt ueber der
Setup-Zuweisung und ist zunaechst mit rausgefallen — `w` wird aber weiter
unten noch achtmal gebraucht (Gruende, Button-Blinken, Close-Alarm,
News-Konflikt). Ein ReferenceError mitten in render() bricht den GESAMTEN
Render ab und friert das Dashboard ein.
Gegenprobe ergaenzt: alle $("id")-Zugriffe der app.js gegen die IDs der
index.html geprueft — 0 verwaiste Referenzen. Klammern-Balance ok,
v=148 ausgeliefert, eine Instanz auf 8000.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Axel HocksandClaude Opus 5
|
caa937f87d |
Gesamtempfehlung: nur noch Module mit Stimmrecht · Tooltips ueberall (v=147)
· Modul-Chips: neues `used`-Flag in _verdict.add(). used=False = dauerhaft entmachtet (Elliott, Orderbuch — beide heute gemessen ohne Inhalt), das Frontend filtert sie aus. ⚠ Sie bleiben im Snapshot und in verdict_votes: log_verdict_votes speist daraus die Telemetrie und die 25.000-Verdict-Messung braucht die Reihe weiter. Ausgeblendet wird die Anzeige, nicht die Messung. Module mit weight=0 aus SITUATIVER Stille (Welle bei WARTEN, Squeeze ohne Ausbruch) bleiben sichtbar. · #vd-note (Muenzwurf-Hinweistext) entfernt, samt CSS. Die Aussage steht weiter im Karten-Tooltip. · Tooltips auf allen Dashboard-Anzeigen (59 title-Attribute): Karten, Header-Boxen, Trade-Leiste, Anzeige-Elemente. Wo eine Messung existiert, steht sie drin. Gesetzt ueber set_tooltips.py — idempotent, ergaenzt nur fehlende title=. Verifiziert: keine Anzeige mehr ohne Tooltip, keine doppelten IDs, Tag-Balance ok, v=147 ausgeliefert, Elliott/Orderbuch used=False, eine Instanz auf 8000. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Axel HocksandClaude Opus 5
|
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
|
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
|
e55b866f29 |
Kachel "Erwartete Spanne" entfernt, Kernwerte komprimiert in die Gesamtempfehlung
User-Vorgabe. #card-cone/#cone-list raus; neu die einzeilige #vd-cone unter der Bias-Nadel: "erwartete Spanne · 30' 75,99-76,77 · 60' ... · trifft 77 %". Gezeigt wird nur noch das 80-%-Band je Horizont; das enge 50-%-Band und der Erklaer-Absatz stecken im title. Platzierung und Farbe sind Absicht: die Zeile steht UNTER der Nadel und ist neutral/randlos - sie zeigt Streuung, nicht Richtung, und darf optisch nicht mit dem Bias konkurrieren. Beschriftet bleibt sie mit der REAL gemessenen Abdeckung (~77 %), nicht mit dem Nennwert 80 %. Backend unveraendert aktiv (core/cone.py, Snapshot cone, MT5-Export CN;...). Verifiziert am ausgelieferten HTML: card-cone weg, vd-cone da, keine verwaisten JS-Referenzen, Klammern-Balance ok. v=140. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |