docs(savepoint): v4.0-rc6 — leerer Bildschirm und zwei weitere Container-Wurzeln

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

SAVEPOINT.md

@@ -1,6 +1,73 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v4.0-rc5 — **Rippy rippt** (29.08.2026)
+## Aktueller Stand: v4.0-rc6 — leerer Bildschirm behoben (29.08.2026)
+
+> **Dein Befund war zweimal richtig und einmal irreführend:** Der Bildschirm
+> war wirklich leer — aber der Rip lief. Man sah ihn nur nie.
+
+### Der leere Hintergrund
+
+Nachgestellt auf einem Testdienst hier, nicht bei dir. Nach dem Klick auf
+„Rippen starten" stand in der Browser-Konsole:
+
+    TypeError: Cannot read properties of undefined (reading 'toUpperCase')
+
+Und währenddessen, direkt an der Schnittstelle gemessen:
+
+    status: processing · progress: 12
+
+**Er startet also sehr wohl.** Die Oberfläche war nur weg, bevor sie es zeigen
+konnte.
+
+Die Ursache: Das Ereignis „Job angelegt" trug nur Status, Fortschritt, Titel
+und Fehler — **keinen Typ**. Die Oberfläche fügt so einen halben Job in ihre
+Liste ein, das Live-Log liest `job.type.toUpperCase()`, und React baut bei
+einem Fehler im Zeichnen den **ganzen** Baum ab. Eine Fehlergrenze, die das
+auffängt, gab es in diesem Projekt nirgends — deshalb leerer Bildschirm ohne
+jede Meldung.
+
+Drei Reparaturen, weil es drei Fehler waren:
+
+1. **Das Ereignis trägt den Job** — Typ, Laufwerk und Startzeit fahren mit.
+   Sie ändern sich nie, kosten also kein zusätzliches Ereignis; ohne die
+   Startzeit stand in der Jobliste sekundenlang „Invalid Date".
+2. **Die Oberfläche verträgt sein Fehlen.** Zeile 108 derselben Datei hatte
+   die Absicherung längst, Zeile 48 nicht.
+3. **Eine Fehlergrenze.** Jetzt steht da, was los ist, die Navigation bleibt
+   bedienbar, und der Hinweis sagt das Wichtigste: *laufende Rips gehen
+   weiter*.
+
+Warum es niemand gefunden hat: Die Tests reichten der Vergleichsfunktion
+immer ihre eigenen Wörterbücher herein — **die Kurzform selbst war nie
+geprüft.** Jetzt bewacht ein Vertrag die Felder mechanisch.
+
+### Der zweite Fund: `F:\app\temp`
+
+Beim Aufräumen des Testlaufs fand ich 436 MB Rohdaten in einem Ordner namens
+`app` auf dem Laufwerk, von dem Rippy gerade lief. Zwei weitere
+Container-Wurzeln:
+
+    RAW_DIR    = /app/temp/raw
+    MEDIA_ROOT = /app/media
+
+Und schlimmer als der falsche Standard: Die Prüfung verwarf **auch eine
+ausdrückliche Wahl**. `D:\Roh` liegt nicht unter `/app/media`, also fiel es
+still zurück.
+
+**Damit kam der Arbeitsordner, den du gestern bestellt hast, unter Windows nie
+an.** Der Dialog zeigte ihn, das Setzen ging, der Worker ignorierte ihn — ohne
+ein Wort. Dasselbe galt fürs Ziel: Deine UNC-Freigabe liegt unter keiner
+lokalen Wurzel, die fertige Datei wäre in `X:\app\media\bluray` gelandet.
+
+Jetzt kommen beide Wurzeln aus dem Betrieb. Im Container ändert sich nichts.
+
+### Aufgeräumt
+
+Ich habe für die Prüfung zweimal einen echten Rip auf deinem Laufwerk
+gestartet und beide sofort abgebrochen. Die 436 MB Rohdaten und der Ordner
+`F:\app` sind entfernt, die Testdienste beendet.
+
+## Letzter Stand davor: v4.0-rc5 — **Rippy rippt** (29.08.2026)
 
 > **Der erste bewiesene Rip unter Windows.** Dein Fehlerbericht enthielt drei
 > Fehler auf einmal — alle drei gefunden, behoben und an deinem Laufwerk