Pipeline-Stufe 1 automatisiert: requirements, pre-commit-Hook, ruff

Nach Web-Recherche zum 2026er-Python-Standard umgesetzt, aber gefiltert: von
uv/Ruff/pyproject/CI passt hier nur, was zu einer Einzelmaschine mit
GUI-gebundenem MT5 und Live-Geld passt.

(1) requirements.txt (Laufzeit) + requirements-dev.txt (Werkzeuge/Messung),
    Versionen gepinnt. Bis dahin gab es GAR KEINE Liste — nach einem
    Maschinenausfall waere die Rekonstruktion Raten gewesen. Per AST ueber
    core/, server.py, tools/ ermittelt statt geraten.

(2) tools/pre_commit.py faehrt vor jedem Commit check_nfalle + pytest (~5 s).
    Einrichten: python tools/pre_commit.py --install. Notausgang
    'git commit --no-verify' ist Absicht.
    Bewusst OHNE das pre-commit-Framework: dessen Nutzen ist
    Werkzeug-Versionierung ueber mehrere Maschinen. Hier gibt es eine, und es
    wuerde eine ZWEITE ruff-Version in einer isolierten Umgebung installieren —
    genau die Divergenz 'Pruefumgebung != Laufumgebung', die heute schon einmal
    zugeschlagen hat.

(3) Ruff statt pyflakes (--select F821), ganzer Scan in 2,1 s. KEIN
    ruff format — das wuerde 161 Dateien umformatieren, darunter alle
    Backtests, und die Migrations-Regel verletzen.

⚠ VIERTER Fall der Klasse 'Erfolg melden, wo nichts geprueft wurde', und nur
durch den Test aufgefallen: --select F821,E999 laesst ruff 0.16 komplett
abbrechen (E999 wurde entfernt, Exit 2); die Meldung geht nach stderr, und weil
ich den Rueckgabecode nicht pruefte, meldete die Stufe 'keine undefinierten
Namen' — ohne irgendetwas geprueft zu haben. Ein absichtlich eingebauter
F821-Fehler kam glatt durch den Hook. Behoben: nur F821, und Exit 2 loest jetzt
den pyflakes-Rueckfall aus.

Beide Richtungen verifiziert: mit Fehler stoppt der Hook den Commit, ohne ist
er gruen. Der Test-Commit wurde zurueckgenommen (war nur lokal, ahead 1).

Nicht umgesetzt: Gitea Actions (Runner auf derselben Maschine wie der Live-Bot,
kein Mehrwert bei 5 s Pruefzeit), Container/Blue-Green (MT5 braucht eine
Desktop-Sitzung, EINE Broker-Verbindung), mypy/ty (kaum Annotationen).

Struktureller Fund: core/engine.py importiert backtest_breakout_squeeze — ein
Backtest ist Teil des LIVE-Abhaengigkeitsgraphen.

CLAUDE.md

@@ -402,6 +402,46 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   ⚠ **Lehre:** die naheliegende Antwort („numpy") war die falsche. Ein Profil
   kostet zwei Minuten und hätte diese Bremse jederzeit gezeigt — sie lag seit
   Monaten in jedem gegateten Backtest.
+- **⚠⚠ PIPELINE-STUFE 1 IST JETZT AUTOMATISCH — `pre-commit`-Hook (2026-08-07).**
+  Nach einer Web-Recherche zum 2026er-Python-Standard umgesetzt, aber **gefiltert**:
+  von uv/Ruff/pyproject/CI ist hier nur das sinnvoll, was zu einer Einzelmaschine
+  mit GUI-gebundenem MT5 und Live-Geld passt.
+  **(1) Abhängigkeiten festgehalten** — `requirements.txt` (Laufzeit) und
+  `requirements-dev.txt` (Werkzeuge/Messung), **Versionen gepinnt**. ⚠ Bis dahin
+  gab es **gar keine** Liste; nach einem Maschinenausfall wäre die Rekonstruktion
+  Raten gewesen. Ermittelt per AST über `core/`, `server.py`, `tools/` — nicht
+  geraten.
+  **(2) `tools/pre_commit.py`** fährt vor jedem Commit `check_nfalle` + `pytest`
+  (~5 s). Einrichten: `python tools/pre_commit.py --install`. Notausgang
+  `git commit --no-verify` ist Absicht — eine Prüfung, die einen dringenden Fix
+  blockiert, wird sonst deinstalliert.
+  ⚠ **Bewusst OHNE das `pre-commit`-Framework**: dessen Nutzen ist Werkzeug-
+  Versionierung über mehrere Maschinen. Hier gibt es eine. Es würde stattdessen
+  eine ZWEITE ruff-Version in einer isolierten Umgebung installieren — genau die
+  Divergenz „Prüfumgebung ≠ Laufumgebung", die heute schon einmal zugeschlagen hat.
+  **(3) Ruff statt pyflakes** (`ruff check --select F821`) — gleiche Befunde,
+  ganzer Scan in 2,1 s. ⚠ **Kein `ruff format`**: das würde 161 Dateien
+  umformatieren, darunter alle Backtests → Migrations-Regel verletzt.
+  ⚠⚠ **VIERTER Fall der Fehlerklasse „Erfolg melden, wo nichts geprüft wurde" —
+  und diesmal fiel er nur durch einen Test auf.** `--select F821,E999` lässt ruff
+  0.16 **komplett abbrechen** („Rule E999 was removed", Exit 2); die Meldung geht
+  nach stderr, und weil ich den **Rückgabecode nicht prüfte**, meldete die Stufe
+  „keine undefinierten Namen" — obwohl sie **gar nichts** geprüft hatte. Ein
+  absichtlich eingebauter `F821`-Fehler kam **glatt durch den Hook**. Behoben:
+  nur `F821`, und **Exit 2 = Werkzeugfehler** löst jetzt den pyflakes-Rückfall aus
+  statt als „sauber" zu gelten.
+  ✅ **Beide Richtungen verifiziert** (wie beim Deploy-Skript): mit eingebautem
+  Fehler → Hook **stoppt** den Commit; ohne → grün. Der Test-Commit wurde
+  zurückgenommen (war nur lokal).
+  ⚠ **Nicht umgesetzt und warum:** *Gitea Actions* — der Runner liefe auf
+  derselben Maschine wie der Live-Bot und konkurrierte um CPU, bei 5 s Prüfzeit
+  ohne Mehrwert gegenüber dem Hook. *Container/Blue-Green* — unmöglich, MT5
+  braucht eine Desktop-Sitzung, und es gibt EINE Broker-Verbindung.
+  *mypy/ty* — kaum Annotationen vorhanden, grosser Aufwand für wenig Ertrag.
+  ⚠ **Struktureller Fund dabei:** `core/engine.py:3527` importiert
+  **`backtest_breakout_squeeze`** (ebenso `weekly_review.py`). Ein Backtest ist
+  damit Teil des **Live**-Abhängigkeitsgraphen — „Backtests sind nur Doku" stimmt
+  nicht, ein Fehler dort kann den laufenden Bot treffen.
 - **⚠⚠ TEST-SUITE (`pytest`, `tests/`, seit 2026-08-07) — 17 Tests, ~1 s.**
   Im Projekt sind über Monate **dutzende Szenario-Tests** entstanden („mit 10
   Szenarien getestet", „mit 18 synthetischen Szenarien"), alle als