Automatischer Push: 8 Datei(en) geändert

- .vault-tools/trading-plattform-pruefung/LIESMICH.md
- .vault-tools/trading-plattform-pruefung/abbau_alpaca_lesen.py
- .vault-tools/trading-plattform-pruefung/abbau_glattstellen.sh
- .vault-tools/trading-plattform-pruefung/abbau_ibkr_lesen.sh
- .vault-tools/trading-plattform-pruefung/abbau_restbestand.py
- .vault-tools/trading-plattform-pruefung/abbau_restbestand_angriffe.py
- .vault-tools/trading-plattform-pruefung/abbau_restbestand_einrichten.ps1
- AI/Regelwerk/windows-shell.md

Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py.

Co-Authored-By: Claude Opus 5 <[email protected]>

.vault-tools/trading-plattform-pruefung/LIESMICH.md

@@ -5,7 +5,7 @@ title: "Trading Plattform: Prüfwerkzeuge des Koordinators fürs Dashboard"
 summary: "Eigener Lauf mit echten Daten zum Dashboard der Trading Plattform — Vergleich der Endpunkte gegen Vollparse und pandas, zwei WebSocket-Verbindungen, Browser-Lauf und Wiederaufbau mit Playwright, gefahrlose Proben der zwei Skripte, Mutantenläufe. Entstanden 2026-09-17 (Teil 3b), erweitert 2026-09-18 (Teil 10: Anmeldung, Angriffsfälle, Beobachtung, Kerzenlatenz), bewusst nicht im Projekt-Repo."
 tags: [vault-tools, trading-plattform]
 created: 2026-09-17
-updated: 2026-09-24
+updated: 2026-10-08
 ---
 
 # Prüfwerkzeuge fürs Dashboard der Trading Plattform
@@ -179,3 +179,18 @@ Nach dem Umzug auf den Docker-Host (Hyper-V-VM) prüft der Host selbst: `deploy/
 | `abendkontrolle_ibkr_python_angriffe.py` | seit der Prüfung vom 2026-09-26 mit zweiter Sperre: `IBKR_ORDNER` zeigt ins Leere; dazu dichtet `rueckweg_aapl_angriffe.py` seither `WSL` und `WSL_SKRIPT` im Modul `rueckweg_aapl` ab, und `abendkontrolle_angriffe.py` räumt seinen leeren Ordner im Temp wieder weg. Sonst: vier Fälle ohne Netz für `--ibkr-python` von `abendkontrolle_wsl.py`: Schalter, Vorgabe `IBKR_PY`, `ibkr_pruefen.py lesen` läuft mit dem genannten Interpreter (Ersatzskript im Wegwerf-Ordner), der Ablauf reicht den Schalter weiter | `python abendkontrolle_ibkr_python_angriffe.py` in WSL im Venv |
 
 Was es nicht tut: Es prüft nicht, ob der Host die Kontrolle überhaupt fährt — bleibt sie dort aus, steht jeden Abend „noch kein Ergebnis“ in der Notiz, und das ist der Hinweis. Steht `-QuelleIbkr` falsch, fällt das nicht immer auf: Prüft die Aufgabe den Teil ibkr in WSL, obwohl die Instanz schon auf dem Host läuft, meldet sie ihn dort nur leise als „nicht gestartet“, weil der Zeitgeber in WSL aus ist. Ein Anmelde-Lauf zwischen 22:30 und dem Ende der Prüfung auf dem Host bekommt einmal „noch kein Ergebnis“, weil die Frist `FRUEHESTENS` für beide Quellen gilt (die Mutanten suchen genau diese Zeile).
+
+## Paket AB (2026-10-07): Abbau des Restbestands nach dem Netzschalter-Abriss
+
+Am 2026-10-07 um 20:13 beendete ein Druck auf den Netzschalter beide Paper-Runner mitten im Handel, ohne Glattstellen. Pascal am selben Abend: am 2026-10-08 soweit es geht alles verkaufen, Testläufe bis Dienstag gestoppt. Die Zeitgeber `trading-paper.timer` und `trading-paper-ibkr.timer` sind seitdem aus, die Abendkontrolle ebenfalls; die Meldung dieses Werkzeugs ist in der Pause das einzige Netz. Plan im Projekt: `docs/plans/2026-10-07-paket-ab-abbau-restbestand/`.
+
+| Datei | Was sie tut | Aufruf |
+|---|---|---|
+| `abbau_restbestand.py` | Windows-Seite. Im Modus `scharf` nur zwischen 2026-10-08 15:40 und 2026-10-09 21:45: Runner-Units über `systemctl show` (nur `LoadState=loaded` mit `inactive` oder `failed` gilt als stehend), Marktuhr, beide Bestände; je Instanz mit Position oder offener Order genau ein Glattstellen über `abbau_glattstellen.sh`; nach 30 s beide Bestände neu; Ergebnis in `data/paper/abbau/abbau.json` und `abbau.log` im Projekt, mit `"flach": true` enden alle späteren Läufe still; bei Eingriff, Befund oder dem ersten "flach" eine Zeile in der Tagesnotiz und eine Meldung mit hoher Priorität. Fail-closed: laufender oder nicht geladener Runner, unlesbarer Zustand, unlesbare Marktuhr oder unlesbarer Bestand heißt nicht angefasst, mit Befund; Markt zu oder weniger als 10 min bis Schluss heißt nichts, ohne Meldung. `wsl()` setzt `WSL_UTF8=1` und entfernt NUL; Befunde aus Ausnahmen nennen nur den Typ, der Traceback steht nur in `abbau.log`. `--modus lesen` fährt nur die lesenden Aufrufe, auch außerhalb des Fensters, und schreibt nichts; ohne `--modus` Exit 2 | `python abbau_restbestand.py --modus lesen`; `scharf` nur über die Aufgabe |
+| `abbau_glattstellen.sh` | WSL. Liest das Bestätigungswort aus `config/killswitch.toml` der Instanz, wählt den Broker ausdrücklich (`--broker alpaca` oder `--broker ibkr`) und ruft genau einmal `scripts/killswitch.py glattstellen` im Instanzordner mit deren Venv. Die Ausgabe geht durch einen Filter: das Wort wird `[wort]`, dann `ohne_kontonummer()` (Kontonummern als `[konto]`, dann `maskiere()`), dann jede Dezimalzahl `[x]`. Kennt keinen echten Ordner, der Aufrufer nennt ihn. `--broker attrappe` ersetzt die Wahl, nur für die Probe in einer Wegwerfkopie | `bash abbau_glattstellen.sh <instanz> <instanzordner> [--broker attrappe]` in WSL, Instanz `alpaca` oder `ibkr` |
+| `abbau_alpaca_lesen.py` | WSL, Venv `~/venvs/trading`: Marktuhr, Positionen (nur Symbol und Stück) und Zahl der offenen Orders des Alpaca-Kontos als eine JSON-Zeile; Fehlertexte durch `ohne_kontonummer()` und die Dezimalmaske | nur über `abbau_restbestand.py`; von Hand `python abbau_alpaca_lesen.py --projekt <alpaca-ordner>` |
+| `abbau_ibkr_lesen.sh` | WSL: `scripts/ibkr_pruefen.py lesen` im IBKR-Ordner mit `~/venvs/trading-ibkr` (Client-ID 12, lesend), nie `orderweg` | nur über `abbau_restbestand.py` |
+| `abbau_restbestand_angriffe.py` | Angriffsfälle als Funktionen `test_*`, lauffähig als Skript und unter pytest (für `mutanten_lauf.py`). Abgedichtet: alle Pfade nach draußen zeigen ins Leere, `wsl()` ist durch eine zählende Attrappe ersetzt, im Fall zu `wsl()` selbst auch `subprocess.run`. Die Fälle `test_wsl_*` fahren den echten Wrapper und die Venvs gegen Wegwerf-Instanzordner mit falschem `killswitch.py`, erfundenem Wort, erfundener Kontonummer und erfundenen Beträgen; unter Windows übersprungen | unter Windows `python -I -X utf8 abbau_restbestand_angriffe.py`, in WSL `~/venvs/trading/bin/python -I abbau_restbestand_angriffe.py`; Mutanten: `mutanten.toml` im Planordner |
+| `abbau_restbestand_einrichten.ps1` | Aufgabe "Trading Plattform - Abbau Restbestand": Do 2026-10-08 15:45, 16:15, 17:00, 19:00, 21:00, Ersatz Fr 2026-10-09 15:45, 16:30, 19:00 und fünf Minuten nach jeder Anmeldung; nur angemeldet, Zeitlimit 45 min, keine zweite Instanz; druckt nach dem Registrieren die Einstellungen | `powershell -NoProfile -File abbau_restbestand_einrichten.ps1 [-Aktion entfernen]` |
+
+Was es nicht tut: Es gibt keinen Killswitch frei. Jede angefasste Instanz steht danach auf `gesperrt`, Freigeben bleibt Pascal (`scripts/killswitch.py freigeben`). Es hat keinen eigenen Ordercode und keine Sperrdatei gegen einen zweiten Lauf von Hand; die Aufgabe selbst startet keine zweite Instanz. Während des Aufrufs steht das Wort in WSL in der Prozessliste von `killswitch.py`, dessen Schnittstelle es als Argument nimmt. Ob `wsl.exe --exec` eine Meldung mit Leerzeichen so weitergibt wie ein Skript mit Argumenten, war vor dem ersten scharfen Lauf nicht gemessen; was die Meldung ergab, steht in der Notizzeile unter "Meldung ans Telefon". Nach dem 2026-10-09 wird die Aufgabe mit `-Aktion entfernen` abgebaut.