Commit Graph
3 Commits
Author SHA1 Message Date
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>
2026-08-10 06:36:02 +02:00
Axel HocksandClaude Opus 5 0ab79f1876 Code-Pruefung ans Deployment haengen, nicht nur an den Commit
User-Frage "wird die Pipeline bei jedem Deployment ausgefuehrt?". Antwort war
NEIN:
  git commit          check_nfalle + pytest (Hook installiert)
  tools/deploy.py     prueft nur den LAUFENDEN Server, nicht den Code
  restart_server.bat  gar nichts
  Aufgabe OilTradingServer -> start_server_hidden.vbs   gar nichts

Commit und Deployment sind zwei Ereignisse und fallen beliebig auseinander:
eine geaenderte, nie committete Datei ging ueber restart_server.bat ungeprueft
live; nach einem Reboot startet die Aufgabe, was auf der Platte liegt.

"Der Server kommt hoch" ist kein Ersatz: die beiden log.-NameError in
core/trader.py sassen MONATE in except-Zweigen (einer seit dem Initial-Commit),
und der Server startete jedes Mal sauber.

deploy.py bekommt Schritt 0: check_nfalle + pytest VOR dem Kill, bei Rot
Abbruch mit Rueckgabecode 1. Die Reihenfolge ist der Punkt - ein laufender,
funktionierender Server darf fuer kaputten Code nicht abgeschossen werden.
Notausgang --ohne-pruefung.

Beide Richtungen verifiziert: mit eingebautem F821-Fehler -> ABBRUCH, Exit 1,
Server-PID vorher/nachher identisch (20892), der Prozess wurde nachweislich
nicht angefasst. Ohne Fehler laeuft es durch.

BEWUSST NICHT in restart_server.bat und die Aufgabenplanung - das sind
WIEDERANLAUF-Pfade. Wuerde ein fehlschlagender Test dort den Start verhindern,
staende eine offene Position ohne Trailing, Time-Stop und Notfall-Stop da, nur
mit dem Broker-SL. Eine Pruefung, die den Bot offline laesst, ist schlimmer als
der Fehler, den sie sucht. Der Batch gibt stattdessen einen Hinweis aus und
verweist auf deploy.py.

Regel: absichtliches Deployment blockieren, Wiederanlauf niemals.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 12:02:08 +02:00
Axel HocksandClaude Opus 5 4cbb1f1db5 tools/deploy.py: Stufe 5 der Pipeline ist jetzt ein pruefbares Skript
Ersetzt das von Hand zusammengesetzte "killen, starten, warten, nachsehen" —
und macht die dokumentierte Schwachstelle der Pipeline pruefbar.

Fuenf Schritte, Rueckgabecode 0 nur wenn alle durchlaufen (verkettbar):
  1. Prozess GEZIELT AM PORT beenden — nicht per *server.py*-Muster wie
     restart_server.bat, das trifft auch das HL-Dashboard auf 8001 (real: es
     wurde bei jedem MT5-Neustart still mit-erschlagen und riss die Luecken in
     die Lead-Lag- und Order-Flow-Datensammlung).
  2. starten und warten, bis /api/snapshot WIRKLICH antwortet.
  3. genau EINE Instanz je Port.
  4. --feld <name> pruefen.
  5. Log AB DER STARTPOSITION auf ERROR/Traceback.

Schritt 4 ist der Kern: restart_server.bat hat zweimal still nicht neu
gestartet, und weil statische Dateien je Request frisch von der Platte gelesen
werden, belegt eine korrekt ausgelieferte app.js?v=N gar nichts ueber den
geladenen Python-Code. Ein neues Snapshot-Feld ist der einzige belastbare
Beweis — genau daran fiel der Fehler am 02.08. auf (hl_live.basis_stale). Ohne
--feld sagt das Skript ausdruecklich, dass der Beweis fehlt.

Beide Richtungen geprueft:
  --feld rec_track                 -> "Python-Code ist neu", Exit 0
  --feld dieses_feld_gibt_es_nicht -> "FEHLT - der alte Code laeuft weiter!",
                                      Exit 1
Eine Pruefung, die nicht scheitern kann, waere wertlos.

Aufrufe:
  python tools/deploy.py --feld <snapshot_feld>
  python tools/deploy.py --nur-pruefen
  python tools/deploy.py --hl

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 06:28:30 +02:00