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>

CLAUDE.md

@@ -259,6 +259,30 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   Anteil, WR-Verfall, PF<1, Einzelverlust). **Wöchentlich** laufen lassen (B4/B5).
 - **Vor „fertig":** immer `python -m py_compile <datei>`; JS grob via Klammern-
   Balance prüfen (kein node im Env).
+- **✅ STUFE 5 DER PIPELINE IST JETZT EIN SKRIPT (`tools/deploy.py`, 2026-08-07).**
+  Ersetzt das von Hand zusammengesetzte „killen, starten, warten, nachsehen" und
+  macht die dokumentierte Schwachstelle prüfbar.
+  ```
+  python tools/deploy.py --feld <snapshot_feld>   # Neustart + Beweis
+  python tools/deploy.py --nur-pruefen            # nichts anfassen, nur Zustand
+  python tools/deploy.py --hl                     # HL-Dashboard (8001) mitnehmen
+  ```
+  Fünf Schritte, **Rückgabecode 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 Lücken in die
+  Datensammlung). **(2)** starten und warten, bis `/api/snapshot` **wirklich**
+  antwortet. **(3)** **genau EINE** Instanz je Port. **(4)** `--feld` prüfen.
+  **(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** über den
+  geladenen Python-Code. Ein neues Snapshot-Feld ist der einzige belastbare
+  Beweis — genau daran fiel der Fehler 2026-08-02 auf (`hl_live.basis_stale`).
+  Ohne `--feld` sagt das Skript das ausdrücklich dazu.
+  ✅ **Beide Richtungen geprüft**: mit `--feld rec_track` → „Python-Code ist neu",
+  Exit 0; mit einem erfundenen Feld → „FEHLT — der alte Code läuft weiter!",
+  **Exit 1**. Eine Prüfung, die nicht scheitern kann, wäre wertlos.
 - **⚠⚠ DER ENGPASS DES PROJEKTS WAR NIE DIE MATHEMATIK — er war eine
   quadratische Schleife (Profil 2026-08-07, ~9 min → 8,9 s).** Anlass war die
   Frage nach numpy. Statt zu vermuten wurde profiliert, und das Ergebnis war ein