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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user