Die vorigen Durchgaenge waren Handarbeit und liefen nur, wenn jemand daran
dachte. Jetzt sind alle drei automatisiert.
JAVASCRIPT - DIE RENDER-PROBE DECKTE 2 VON 15 FUNKTIONEN AB.
render_check.mjs schnitt per Regex genau ZWEI Funktionen heraus (renderM15,
renderBrk). renderKontext und 13 weitere waren nie abgedeckt - und genau dort
ist mir heute der d-statt-snap-Beinahefehler unterlaufen. Die Probe haette ihn
DURCHGELASSEN.
Neu geschrieben: die komplette app.js laeuft in einem VM-Kontext gegen ein
Minimal-DOM, jede render*-Funktion wird aufgerufen - zweimal, mit dem Fixture
UND mit einem leeren Snapshot (der Kaltstart, in dem jedes Feld fehlt).
13 Funktionen laufen durch. Mutationsprobe mit genau dem heutigen Fehler:
4 Treffer, waehrend node --check NICHTS meldet - der blinde Fleck ist damit zu.
Kein npm, kein jsdom: das DOM ist eine Attrappe von 20 Zeilen, Pruef- und
Laufumgebung bleiben derselbe Parser.
ZWEI NEUE STUFEN, beide mutationsgeprueft:
F) ELEMENT-IDs - JS gegen HTML. Stand: 133 IDs, keine verwaist, keine doppelt.
Kommentare werden vorher entfernt, sonst waeren die Beispiele im
Kopfkommentar zwei Dauer-Fehlalarme (die Lehre vom Linter).
G) ABHAENGIGKEITEN - jeder Import aus server.py/core/ gegen requirements.txt.
Stand: 39 Dateien, alle 9 externen Importe aufgefuehrt, keine Versionsdrift.
UND DIE PIPELINE HAT SICH SELBST ERWISCHT: mein erster Entwurf von Stufe G
importierte `ast` nicht. Der stille except-continue liess JEDE Datei
durchfallen, und die Stufe meldete "alle 0 externen Laufzeit-Importe sind
aufgefuehrt" - ein gruener Haken, hinter dem nichts geprueft wurde. Fuenfte
Wiederholung dieser Fehlerklasse. Gefangen hat es ruff F821 in derselben
Pipeline. Behoben doppelt: Import ergaenzt UND Plausibilitaetspruefung (weniger
Dateien gelesen als vorhanden oder 0 Importe -> Befund).
SLOTS - keine neuen Defekte, drei Punkte praezisiert:
· Kein geteilter Modul-Zustand. Die modulweiten Container in trailing.py und
trader.py sind reine Nachschlagetabellen, kein global-Statement. Die beiden
Instanzen sind tatsaechlich unabhaengig - Voraussetzung des ganzen Umbaus.
· set_sltp bleibt Slot-1-only, verhaelt sich aber SICHER: liegt nur eine
BRK-Position, gibt modify_sltp einen Fehlertext zurueck. Es fasst NICHT die
falsche Position an. Bekannte Grenze, kein Fehler.
· trail_brk.enabled wird nicht persistiert; _rebind_brk schaltet es nach einem
Neustart bedingungslos ein. Sichere Richtung, bewusst so gelassen.
BIBLIOTHEKEN: nichts fehlt, nichts driftet. pandas/scikit-learn stehen in
requirements-dev und werden in 0 Dateien importiert (so dokumentiert); numba,
joblib, tqdm, pandas_ta, rich, httpx sind Beifang und ungenutzt - kein
Handlungsbedarf, sie stehen nicht im Laufzeit-Pfad.
Struktureller Rest benannt: engine.py importiert weekly_review und
measurement_reminder, zwei Skripte der obersten Ebene - dieselbe Klasse wie der
frueher direkte backtest-Import. Hier entschaerft, weil lazy und in try, mit
sichtbarer Fehlermeldung. In Stufe G als projekteigen ausgenommen, mit
Begruendung im Code.
Pipeline jetzt A A2 A3 B B2 C C2 D E F G - alle gruen, 97 Tests, deployt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
