diff --git a/SAVEPOINT.md b/SAVEPOINT.md
index 243dede..7d539ee 100644
--- a/SAVEPOINT.md
+++ b/SAVEPOINT.md
@@ -1,6 +1,72 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v3.12 — Preset je Disc-Typ (25.07.2026)
+## Aktueller Stand: v3.13 — ÜBERGABE (25.07.2026, 18:05)
+
+> Dieser Block ist eine Übergabe an die nächste Sitzung. Er trennt bewusst
+> **gemessen** von **vermutet** — in dieser Sitzung wurden zwei Behauptungen
+> aufgestellt, die sich als falsch erwiesen (siehe „Vertrauensnotiz" unten).
+> Im Zweifel: selbst nachmessen, nicht diesem Dokument glauben.
+
+### GEMESSEN, Stand 18:05 (alles per Befehl auf der VM geprüft)
+
+- **Container:** api/postgres/redis/ui/worker alle `Up`, api + postgres +
+  redis `healthy`.
+- **Platte:** `/dev/sda2` 148 G, 105 G belegt, **37 G frei** (75 %).
+- **Läuft gerade:** `HandBrakeCLI --input
+  /app/temp/raw/73b89777-…/title_t00.mkv --output
+  "/app/media/movies/Akira (1988)/title_t00.mkv" --preset
+  "H.265 MKV 2160p60 4K" --all-audio --all-subtitles`
+- **Job `73b89777-a808-426f-8159-d406d27d0ec8`:** `status='transcoding'`,
+  `progress=99` (⚠️ **Altwert aus dem Absturz, NICHT der echte Fortschritt** —
+  der Lauf hat um 18:02 begonnen), `disc_type='uhd'`,
+  `output_path='/app/media/movies/Akira (1988)'`.
+- **Dateien:** `…/Akira (1988)/title_t00.mkv` ist **0 Bytes** (HandBrake hat
+  die vorherige 1080p-Fassung beim Start gekürzt und schreibt gerade neu).
+  Roh-Rip `/app/temp/raw/73b89777-…/` = **75 GB, unversehrt.**
+- **Git:** `8bb075c` ist HEAD und deployt. Davor `c065967`, `e84afc1`,
+  `f449c4e`, `0935766`. Alle Ampeln waren grün.
+- **Schlüsselspeicher:** 604 Disc-Schlüssel, `/system/keystore` antwortet.
+- **NAS:** `//192.168.178.62/rippy` auf `/srv/rippy/media/rippy` gemountet,
+  erreichbar, **2311 GB frei**. Wird als Ablageziel gelistet.
+
+### WAS ALS NÄCHSTES ANSTEHT
+
+1. **Ausgang des 4K-Laufs prüfen.** Erwartung, die noch NICHT bewiesen ist:
+   Der Job endet **erfolgreich**, und „Original behalten" (Setting steht auf
+   `true`) meldet nur eine **Warnung**, weil 75 GB nicht neben 37 GB freien
+   Platz passen. Genau dieser Pfad ist neu (`_original_aufheben` in
+   `tasks.py`) und in der Praxis noch nie gelaufen. Wenn er hält, ist der
+   Ausfall von heute Mittag strukturell behoben.
+2. **Zombie-Erkennung fehlt (gefunden, NICHT gebaut).** Nach dem Absturz stand
+   der Job auf `transcoding 96 %`, obwohl weder ein Prozess lief noch etwas in
+   den Celery-Queues stand (beide `llen` = 0). Folge: keine Anzeige, kein
+   Download, und der „Neu komprimieren"-Knopf fehlt, weil
+   `_kann_neu_komprimieren` (main.py) `status == "failed"` verlangt. Der
+   Worker sollte beim Start solche Leichen erkennen und ehrlich auf `failed`
+   setzen.
+3. **`keepOriginal` steht auf `true`** — von dieser Sitzung gesetzt, um den
+   4K-Rohschnitt zu retten. Bewusst entscheiden, ob das so bleibt: mit
+   Arbeitsverzeichnis auf der NAS-Freigabe wäre es ein reines Umhängen statt
+   einer Vollkopie.
+4. **75 GB Rohschnitt** liegen weiter in `/app/temp/raw/73b89777-…`. Nach
+   erfolgreichem 4K-Lauf entscheiden, ob er weg kann.
+
+### VERTRAUENSNOTIZ — zwei Fehlschlüsse dieser Sitzung
+
+- **„MakeMKVs Schlüssel-Kanal ist abgeschaltet"** — falsch. Stützte sich auf
+  zwei tote Hostnamen aus alten Forumsbeiträgen, die MakeMKV längst nicht mehr
+  benutzt. Richtig: `makemkvcon` unter **Linux** fragt nie, die
+  **Windows**-Version schon. Korrigiert in v3.11.
+- **„Celery hat die Aufgabe nach dem Deploy erneut zugestellt"** — falsch.
+  Aus dem Status `transcoding` geraten, ohne Prozesse oder Queues zu prüfen.
+  Es war ein Zombie-Eintrag (Punkt 2 oben).
+
+Beide Male war das Muster dasselbe: **aus einem Zustandswert auf einen
+Mechanismus geschlossen, statt den Mechanismus zu messen.**
+
+---
+
+## Vorheriger Stand: v3.12 — Preset je Disc-Typ (25.07.2026)
 
 - **Der Fund:** Beim ersten echten UHD-Rip aufgefallen — die Kompression
   fragte den Disc-Typ **gar nicht**: `preset = einstellungen.get(