docs: SAVEPOINT v4.0-rc2 — Windows ist ein eigenes Produkt

Die drei Befunde des Commanders und was dahinter steckte, plus der teuerste
Fund des Tages: %ProgramFiles(x86)% wurde auf einer echten Maschine NIE
aufgeloest, weil der Test genau die Schreibweise einspritzte, die im Muster
stand. Er war gruener als die Wirklichkeit.

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

SAVEPOINT.md

@@ -1,6 +1,78 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v4.0-rc — Windows ist ein echtes Programm (28.08.2026)
+## Aktueller Stand: v4.0-rc2 — Windows ist ein eigenes Produkt (28.08.2026)
+
+> **Rippy für Windows ist keine Docker-Installation im Fenster mehr.** Es
+> weiß, worauf es läuft, es fragt beim Einrichten, und es bringt seine
+> Werkzeuge mit.
+
+### ZUSTAND, gemessen
+
+| | |
+|---|---|
+| Repo | `151376a` auf `main` |
+| **Ampel** | **GRÜN** |
+| Tests | **698 grün** + 18 übersprungen (Sitzungsbeginn: 378) |
+| `RippySetup.exe` | **56,4 MB**, liegt auf dem Desktop |
+| Laufwerk | **am PC** — `\.\G:`, BLU-RAY, bereit |
+| MakeMKV | **nicht mehr installiert** (siehe unten) |
+
+### Was der Commander gemeldet hat — und was dahinter steckte
+
+**1. „Du hast quasi nur die Docker-Installation für Windows gebaut."**
+
+Im Windows-Fenster stand `Worker erreichbar: 0 von 1`, `Container-Platte:
+unbekannt`, `Prüfen: docker compose ps`. Kein Satz davon ergibt dort einen
+Sinn.
+
+Die Ursache war nicht die Anzeige: **Das UI hat nie erfahren, worauf es
+läuft.** `GET /betrieb` meldet jetzt FÄHIGKEITEN (`externe_worker`,
+`freigaben_einhaengen`, `container_pfade`, `werkzeuge_verwalten`) — kein
+Modus-Name, weil das UI sonst aus einem Namen auf Verhalten schließen müsste.
+Dashboard, Einstellungen und Anleitung richten sich danach.
+
+**2. „Beim Setup passiert gar nichts."**
+
+Jetzt: acht Voraussetzungs-Prüfungen, Zielordner UND Ablage zur Wahl, Port,
+drei Schalter. Nur ein FEHLER blockiert, eine Warnung nicht — und jeder
+Befund sagt, was zu tun ist.
+
+**3. „Handbrake und MakeMKV MÜSSEN mitgeliefert werden."**
+
+HandBrakeCLI liegt bei (GPL-2 erlaubt es), MakeMKV wird beim Einrichten vom
+Hersteller geholt (proprietär, keine Weitergabe erlaubt).
+
+### Drei Fehler, die nur die andere Plattform zeigte
+
+`os.path` richtet sich nach der laufenden Maschine — falsch überall dort, wo
+über Pfade einer ANDEREN gerechnet wird:
+
+* `katalog.py` baute `C:\Program Files (x86)\MakeMKV/makemkvcon64.exe`
+* `verknuepfungen.py` gab für den `.lnk`-Arbeitsordner einen leeren String
+* `betrieb.py` hielt `D:` und `E:` für dasselbe Laufwerk
+
+Dreimal dasselbe Muster. Jetzt an EINER Stelle: `rippy/pfade.py`, mit der
+Regel im Kopf — **der Pfad entscheidet, nicht der Rechner.**
+
+### Und der teuerste Befund des Tages
+
+`%ProgramFiles(x86)%` wurde auf einer echten Maschine **nie** aufgelöst.
+Windows legt Umgebungsvariablen GROSS in `os.environ` ab, das Muster stand
+hübsch geschrieben, der Vergleich war exakt. Die bekannten Installationsorte
+fielen aus der Kandidatenliste; MakeMKV wurde nur über die Registry gefunden.
+
+Aufgefallen ist es erst, als zum ersten Mal eine ECHTE Umgebung eingesetzt
+wurde. Der Test spritzte genau die Schreibweise ein, die im Muster stand —
+**er war grüner als die Wirklichkeit.**
+
+### ⚠️ MakeMKV ist auf dem Commander-PC nicht mehr installiert
+
+Weder Dateien noch Registry-Eintrag. Weder die Deinstallation noch die
+Werkzeug-Kette fassen fremde Programme an — vermutlich hat der Commander es
+selbst entfernt, um den Fall „MakeMKV fehlt" zu testen (dazu hatte ich
+geraten). Der Assistent zeigt ihn korrekt als Warnung mit Ausweg.
+
+## Letzter Stand davor: v4.0-rc — Windows ist ein echtes Programm (28.08.2026)
 
 > **Rippy läuft auf Windows ohne Docker, in einem eigenen Fenster, findet und
 > aktualisiert seine Werkzeuge selbst — und meldet sich bei Windows an wie