docs(savepoint): v3.14 - Durchsicht, mit den zwei eigenen Fehlschluessen

SAVEPOINT bekommt den Stand v3.14: der unwirksame Platten-Schutz zuerst
(wichtigster Fund), dann die gemessenen Werte, das Gebaute, die vier toten
Endpunkte als Entscheidungsvorlage - und ein Abschnitt "SOFORT ENTSCHEIDEN".

Der laufende Akira-Encode wird beim Fertigwerden mit dem DEPLOYTEN, alten
Code versuchen, 75 GB in 37 GB zu kopieren. keepOriginal steht auf true, und
den Wert hat die Aufgabe beim Start gelesen - jetzt umstellen aendert daran
nichts mehr. Der Savepoint nennt die drei Optionen mit Empfehlung.

Zwei Richtigstellungen an v3.13, beide durch Messung:
- "progress=99 ist ein Altwert aus dem Absturz" war falsch. Beide Startpfade
  setzen auf 0; der Wert kam frisch vom Scan-Durchlauf. Ein Bug, kein Ueberrest.
- Die Erwartung, _original_aufheben werde nur warnen, war falsch - siehe
  EXDEV-Fund im vorigen Commit.

Ehrlich als OFFEN markiert: Was die Platte am 25.07. mittags fuellte, ist
NICHT belegt. Es gibt keine Kopier-Reste, kein original-Verzeichnis und
keinen einzigen Log-Eintrag von _original_aufheben, das in beiden Zweigen
loggt. Der Mechanismus ist jetzt bewiesen, sein Zuschlagen an jenem Tag
nicht. Lieber offen lassen als eine dritte Vermutung aufstellen.

AGENTS bekommt Etappe 19 und einen neuen Abschnitt, der das wiederkehrende
Muster benennt: nicht aus einem Zustandswert auf einen Mechanismus
schliessen - vier belegte Faelle. Plus die Umkehrung, die diese Sitzung
gekostet hat: gleiches st_dev heisst NICHT gleicher Mount. Was ausprobierbar
ist, wird ausprobiert statt vorhergesagt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-07-25 21:05:38 +02:00
parent ef0a574a70
commit 574354131c
2 changed files with 179 additions and 1 deletions
+17
View File
@@ -66,4 +66,21 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
-**Etappe 18 (v3.11):** 4K-UHD gelöst — `makemkvcon` holt Schlüssel
unter Linux nie, unter Windows schon; Schlüsselspeicher übernehmbar.
Akira-UHD geht auf der VM auf (`TCOUNT:5`, bewiesen)
-**Etappe 19 (v3.14):** Durchsicht Frontend/Backend — vier Placebos weg
(Fortschritt log, Auswurf tat nichts, „Alle Tracks" konnte nichts, Encoder
wurden behauptet statt gemessen), Zombie-Erkennung gebaut, Pfad-Prüfung
gehärtet, und der Platten-Schutz aus `c065967` als **unwirksam** entlarvt
- 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe
## Was diese Sitzungen wiederholt gekostet hat
**Nicht aus einem Zustandswert auf einen Mechanismus schließen.** Vorgefallen:
aus „kein Schlüssel da" → „Server abgeschaltet" (falsch), aus Status
`transcoding` → „Celery hat neu zugestellt" (falsch), aus `progress=99`
„Altwert aus dem Absturz" (falsch — ein Bug), aus gleichem `st_dev`
`os.rename` funktioniert" (falsch — der Kernel vergleicht den Mount).
Jedes Mal hätte eine Messung von unter einer Minute gereicht.
**Und die Umkehrung gilt genauso:** gleiches `st_dev` heißt NICHT gleicher
Mount. Wo eine Eigenschaft ausprobierbar ist, probiere sie aus, statt sie
vorherzusagen.