User-Vorgabe: die hinterlegten Muster-Bilder sollen je Minuten-Chart das
gerade entstehende Muster zeigen, M1 und M5 zusaetzlich in der Meldungskarte.
BILDER: 15 Vorlagen aus /Chartmuster, 436-611 KB je Stueck (7,5 MB gesamt).
Das Dashboard uebertraegt ~14 KB je Snapshot ueber WireGuard - ein Originalbild
waere das 40-fache. Verkleinert auf 520 px / JPEG q80 nach web/muster/:
7,5 MB -> 379 KB (Faktor 20), im Frontend zusaetzlich loading="lazy".
Die Originale sind gitignored, nur die Web-Fassungen kommen ins Repo.
DETEKTOR: core/patterns.py bekommt die Zeitebene als PARAMETER. Der Default
bleibt M30 und damit bitgleich - `PatternDetector()` speist das Verdict-Gewicht
0,25, eine stille Verschiebung dort waere eine Strategie-Aenderung durch die
Hintertuer. Daneben laufen vier weitere Instanzen (M1/M5/M15/H1) mit
gestaffelten Refresh-Zeiten (20/25/35/60 s), damit sie den mt5_lock nicht im
Pulk belegen. Sie haben KEINE Stimme.
Neu Snapshot `patterns_tf`: je Zeitebene das STAERKSTE Muster (bestaetigte vor
sich bildenden, dann Symmetrie-Guete; ungueltige fallen raus) samt Bildnamen
ueber die Karte `patterns.BILD`.
Doppeltop/-boden, Dreifach-Top/-Boden und Flagge bull/baer teilen sich je ein
Bild (die Vorlagen zeigen beide Richtungen); `inv_cup` bekommt KEINS - lieber
kein Bild als ein falsches.
⚠⚠ REINE ANZEIGE, und das steht auch dran. Die Muster-Klasse ist als SIGNAL
gemessen und verworfen (Ziel-Trefferquote nur 13-38 %, backtest_patterns.py),
und auf M1 ist sie am schwaechsten: dort liegt der Spread bei 0,319xATR, ein
Muster ueber wenige Bars ist weitgehend Rauschen. Kein Verdict-Gewicht, kein
Trade-Trigger; die Tooltips nennen die Messung.
⚠ Beim Bau zwei eigene Fehler gefangen: (1) ich hatte die Feldnamen GERATEN -
es heisst `type`, nicht `typ`, und der Status ist "confirmed"/"forming"/
"invalidated". Ein falscher Schluessel haette still None geliefert, die Karte
waere leer geblieben ohne jede Fehlermeldung. (2) Der Emoji-Surrogat-Abbruch
zum sechsten Mal - die .tmp-Regel hat app.js erneut gerettet (0 Bytes verhindert),
danach mit literalen Zeichen statt \u-Escapes geschrieben.
Live verifiziert: M1 Doppelboden, M5 Tasse+Henkel, M15 aufsteigendes Dreieck,
M30 Doppeltop; alle Bilder HTTP 200 (22-28 KB). Pipeline A-G gruen, 97 Tests,
14 render*-Funktionen laufen durch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach dem Schliessen der Position ausgefuehrt. Der Trade schloss mit rund -152 EUR
(Equity 877 -> 725) -- genau die Groessenordnung, die diese Aenderung adressiert.
margin_buffer_pct in ini UND runtime_state auf 40. Bei 725 EUR freier Margin
sind das ~0,41 statt ~0,97 Lot, Risiko je 2xATR-Stop ~20 statt ~46 EUR. Gilt
fuer alle neuen Positionen, auch die autonomen.
Beide Stellen angeglichen: set_margin_pct persistiert als 'margin_pct' (nicht
'margin_buffer_pct'), _load_runtime_state (Z.487) laeuft nach dem ini-Lesen
(Z.176) und gewinnt. Die ini wurde mitgezogen, damit ein geloeschtes
runtime_state.json nicht still auf 95 % zurueckfaellt.
Karte #card-brk live: squeeze_b5 liefert n=11/20, ratio 0,14, PF 0,39,
-173,46 EUR. Deploy ueber tools/deploy.py --feld squeeze_b5, alle fuenf Schritte
gruen.
Offen bleibt Punkt 2 der User-Idee (50 % Reserve): technisch moeglich, aber
Kern-Umbau und gegen die Messung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Zweites eingereichtes Buch, anderes Genre: Co-Piloten, No-Code-Bots, Scanner,
Agenten-Pipelines. Triage gegen den Projektstand: 10 von 12 Kapitel-Konzepten
sind gebaut (Copilot, Circuit-Breaker, Logs, Slippage-Messung, Dedup,
Tagesreport, Provider-Fallback) oder gemessen verworfen (Muster, Momentum,
Sentiment). Alt-Daten und Rebalancing sind fuer einen WTI-CFD gegenstandslos.
DIE EINE ECHTE LUECKE: Kap. 9.2 empfiehlt WALK-FORWARD, dieses Projekt prueft
mit ZWEI STICHPROBEN -- das Wort kommt in CLAUDE.md nie vor. Zwei Haelften haben
genau zwei Vorzeichen; ein Setup, das in der Haelfte aller Zeitbloecke negativ
ist, kann trotzdem 'beidhaelftig positiv' aussehen. Genau so ist das
P(break)-Modell ausgefallen (H1->H2 AUC 0,715, live 0,368).
Gemessen am Squeeze, gleiche Daten/Regel/Exit, variiert nur die Zeitaufteilung:
2 Haelften: H1 -0,134 / H2 +0,036
8 Bloecke: - - - + + + - + = 4 von 8 positiv, Spanne -0,301 .. +0,214
Die einzigen zwei Bloecke mit KI ohne Null sind BEIDE negativ. Kein Block ist
gesichert positiv. Die Haelften-Sicht verdeckt nichts, zeigt aber auch nichts.
Keine Code-Aenderung: die 2-Stichproben-Regel bleibt die Mindesthuerde (sie hat
28 Eingriffe korrekt abgewiesen), ist aber eine Aussage ueber zwei Regime, nicht
ueber Stabilitaet ueber die Zeit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
