docs: SAVEPOINT v4.0-beta — V2-0 bis V2-3 stehen, Laufwerk fehlt an der VM

Vier Etappen gebaut und deployt, Polling ist weg (121 Anfragen/min je Tab
-> ~2 einmalige Abrufe), SSE-Strom live belegt.

Wichtig fuer die naechste Sitzung: Das optische Laufwerk haengt NICHT mehr
an der VM. Rippy laeuft als reine Komprimier-Maschine. Und der Vorfall,
der das aufgedeckt hat, ist dokumentiert — ein devices:-Eintrag in compose
ist eine Startbedingung, und die hat api, worker und ui stillgelegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SAVEPOINT.md

@@ -1,6 +1,95 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v4.0-alpha — Rippy v2 beginnt, Etappe V2-0 steht (28.08.2026)
+## Aktueller Stand: v4.0-beta — V2-0 bis V2-3 stehen, Polling ist weg (28.08.2026)
+
+> **Vier Etappen gebaut, alle gruen, alles deployt.** Und ein Vorfall, den es
+> ohne den Deploy nie gegeben haette — der aber eine echte Altlast aufgedeckt hat.
+
+### ZUSTAND, gemessen
+
+| | |
+|---|---|
+| Repo | `05ab655` auf `main` |
+| VM | **deployt und laufend** — alle 5 Container up, UI 200, API 200 |
+| Tests | **378 gruen** + 3 uebersprungen (Sitzungsbeginn: 301) |
+| Ereignis-Waechter live | `gesund: true`, `alter_sekunden: 0.8` |
+| SSE-Strom live | `event: snapshot` mit vollem Job-Datensatz belegt |
+| Doppelte Module | **0** (Sitzungsbeginn: 6) |
+| UI-Taktgeber | **7 von 9 weg** — 121 Anfragen/min je Tab -> ~2 einmalige Abrufe |
+
+### ⚠️ DAS OPTISCHE LAUFWERK HAENGT NICHT MEHR AN DER VM
+
+`ls /dev/sr*` findet nichts, `lsscsi` ist leer. Rippy laeuft deshalb gerade als
+**reine Komprimier-Maschine** — das ist ein vorgesehener Betriebsfall, aber
+rippen kann sie so nicht. Wieder anstecken (Proxmox-USB-Passthrough), dann:
+
+    ./deploy/geraete-override.sh && docker compose -p rippy up -d
+
+### DER VORFALL: ein fehlendes Laufwerk legte ALLES stumm
+
+Der Deploy von V2-3 brach mit:
+
+    Error response from daemon: error gathering device information while
+    adding custom device "/dev/sr0": no such file or directory
+
+Danach waren api, worker UND ui unten; nur postgres und redis liefen. Ein
+`devices:`-Eintrag in compose ist eine **Startbedingung** — und keiner der drei
+Container braucht zum STARTEN ein Laufwerk.
+
+**Der Widerspruch war aelter als der Vorfall:** `install.sh` sagt bei fehlendem
+Laufwerk ausdruecklich *„laeuft trotzdem durch, dann ist das eine reine
+KOMPRIMIER-Maschine"* — `docker-compose.yml` sah das anders. Jeder Deploy nach
+einem Abstecken haette das ausgeloest.
+
+**Behoben an der Ursache:** `devices:` ist aus `docker-compose.yml` raus.
+`deploy/geraete-override.sh` ermittelt die Knoten dieses Hosts (sr + passender
+sg ueber die SCSI-Adresse in /sys abgeglichen, Logik aus install.sh uebernommen)
+und schreibt `docker-compose.override.yml` — die zieht Compose von allein dazu.
+Das Skript schreibt die Datei **auch dann, wenn kein Laufwerk da ist**; sonst
+bliebe eine alte Override mit /dev/sr0 liegen und der Fehler waere derselbe, nur
+schwerer zu finden (die Datei ist gitignored, taucht also in keinem Diff auf).
+`deploy.sh` ruft es vor dem Start auf.
+
+### Gebaut in dieser Sitzung
+
+- **V2-0** Monorepo: drei Zwillingsdateien zusammengefuehrt
+- **V2-1** die vier Ports, ein Store (db.py x2 -> rippy/store), ein
+  Laufwerks-Treiber (der Auswurf lag zweimal da, mit VERSCHIEDENEN Vertraegen)
+- **V2-2** SQLite hinter demselben Port, Auftrags-Queue mit Lease
+  (ersetzt die Zombie-Jagd), Konfigurationsschicht mit einer Praezedenz
+- **V2-3** Ereignis-Bus, SSE-Endpunkt `/events`, Waechter als Bruecke zum
+  Worker, UI auf den Strom umgestellt
+
+### Vier Fehler, die unterwegs gefunden wurden
+
+1. **`try/except ImportError` haette einen falschen Modulpfad verschluckt** —
+   auf Linux haette der Worker still jeden Rip verweigert. Waechter:
+   `src/rippy/test_paket.py` (beim Wegnehmen des Moduls rot gesehen).
+2. **`gui.py` von CRLF auf LF gekippt** — 1520 Zeilen Diff fuer eine Zeile.
+   Mein Schreib-Helfer las im Textmodus. Zurueckgedreht.
+3. **Ampel-Lauf 170 rot**: Mein Snapshot-Test brauchte eine Datenbank, die
+   Ampel hat keine. Im Container nachgestellt (Python 3.12, ohne DB): 402 gruen.
+4. **`asyncio.get_event_loop()` in einem Worker-Thread** — das ist NICHT die
+   laufende Schleife, die Coroutine waere nie gelaufen. Schleife wird jetzt im
+   Startup festgehalten.
+
+Dazu zwei Formatfehler: `/logs` bildet `ts` -> `timestamp` ab, mein Snapshot
+lieferte die rohe DB-Zeile (haette „Invalid Date" gezeigt, NUR im Live-Betrieb);
+und ein Docstring versprach eine Ereignis-Reihenfolge, die der Code nicht hielt.
+
+### WAS ALS NAECHSTES ANSTEHT
+
+- [ ] **Laufwerk wieder an die VM** (oder klaeren, wo es ist) — ohne das kann
+      Rippy nicht rippen, und der Windows-Treiber aus V2-4 laesst sich ohne
+      echtes Laufwerk nicht beweisen, nur behaupten.
+- [ ] **V2-4 Windows**: Win32-Treiber, Dienst + Tray, PyInstaller-EXE.
+      Inno Setup ist auf dem Commander-PC nicht installiert — die EXE kommt
+      per PyInstaller (womit auch die bestehende RippyWorkerSetup.exe gebaut ist).
+- [ ] **V2-5 Docker neu**: ein Image, drei Profile, Host-Mounts statt
+      Container-Mounts.
+- [ ] **V2-7**: neue Funktionen inkl. Schluesselkette in drei Stufen.
+
+## Letzter Stand davor: v4.0-alpha — Rippy v2 beginnt, Etappe V2-0 steht (28.08.2026)
 
 > **Zwei Dinge sind passiert: Das Konzept für Rippy v2 liegt vor und ist vom
 > Commander entschieden — und die erste Etappe ist gebaut, geprüft und grün.**