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.

requirements.txt

@@ -0,0 +1,40 @@
+# LAUFZEIT-Abhaengigkeiten des Bots (server.py + core/).
+#
+# ⚠ WOZU: bis 2026-08-07 gab es GAR KEINE Abhaengigkeitsliste. Stirbt die
+# Maschine, waere die Rekonstruktion Raten gewesen — bei einem System, das
+# echtes Geld bewegt, die groesste Luecke der Pipeline.
+#
+# ⚠ Versionen sind GEPINNT, nicht offen. Ein stiller Minor-Sprung (z. B. bei
+# `MetaTrader5` oder `fastapi`) kann den laufenden Bot brechen; das faellt dann
+# nachts auf, nicht beim Update. Bewusst aktualisieren statt zufaellig erben.
+#
+# Installation auf einer frischen Maschine:
+#   python -m pip install -r requirements.txt
+#
+# ⚠ Erzeugt aus dem LAUFENDEN Stand (pip freeze, gefiltert auf die real
+# importierten Pakete — ermittelt per AST ueber core/, server.py, tools/).
+# Nicht handgepflegt raten: bei neuen Importen hier nachtragen.
+
+# ── Broker-Anbindung (Windows-only, kein Ersatz moeglich) ────────────────
+MetaTrader5==5.0.5735
+
+# ── Web-Backend fuer die Mobile-PWA (Port 8000) ──────────────────────────
+fastapi==0.137.1
+uvicorn==0.49.0
+websockets==16.0          # WS-Push /ws
+# starlette/pydantic kommen als fastapi-Abhaengigkeiten, hier zur Nachvollzieh-
+# barkeit gepinnt (sonst waehlt pip beim Neuaufbau evtl. andere Versionen)
+starlette==1.3.1
+pydantic==2.13.3
+
+# ── Nachrichten, Kalender, Uebersetzung ──────────────────────────────────
+requests==2.33.1
+beautifulsoup4==4.14.3    # importiert als `bs4`
+feedparser==6.0.12
+deep-translator==1.11.4
+
+# ── KI-Copilot (LLM-Provider) ────────────────────────────────────────────
+# ⚠ Beide Clients sind eingebunden; aktiv ist laut `[agent] provider` nur einer.
+# Die z.ai-/DeepSeek-/Kimi-Endpunkte laufen ueber den openai-kompatiblen Client.
+anthropic==0.99.0
+openai==2.34.0