The Sentence That Could Never Have Been True
Until this version, track 3's lesson on the channel said that a change the owner asks for after an upload is a new render that replaces the upload. It reads like an ordinary production promise, and it describes something the platform does not offer: there is no way to swap the movie under an existing video's address. A new movie is a new video, with its own address, its own receipts and its own history. So the real question was never how to replace an upload. It was what to do with the old one, and with everything the workshop had recorded about it, once a better one goes up.
Two corrections on the Spain trip forced the answer inside two days. On 2026-10-21 the cut of the Frigiliana day let the voice read the owner's “one of us”, written in Hangul, as “one of earth”. The corrected cut went up as a new private video, and the first stayed private as revision 1. On 2026-10-22 the Nerja day placed phone photos of two restaurants he had also photographed with his own camera, and he said so plainly: “최고의 맛집들이라고 하고 아이폰 사진 쓰는 게 미안하다” (“Calling them the best places to eat and then using iPhone photos, that's a shame”). The camera cut went up as a new private video with the same approved script and the same voices. Both sessions built a revisions/r01/ folder by hand and renamed the old upload record to out/upload-r01.json. Nothing recorded which video replaced which, and the guard that stopped a second upload was, in the code's own later words, a filename.
An Upload Is Immutable
Review 5 (2026-10-22, 63bc75e) turned the habit into a mechanism, and it started from a refusal. Every check that asks whether a production is uploaded now reads one function, which lists only the current upload records, and two stages refuse on its answer. video will not render while a current upload exists: “uploaded movies are immutable … a corrected cut is a revision”. upload will not send a different movie over an existing record, and run again on the same movie it never sends a second copy; where the cover is gated, it repairs and reads back only that video's cover. The record of what went up cannot be overwritten by accident, because nothing will write over it.
The Revision Moves the Evidence Aside
A correction is a command that needs the owner: pipeline.py revise --slug … --note … --said … --source-ref …. Without his actual words and where he said them it refuses, because a revision is his request, never a request to keep working. It then moves the whole receipt set of the superseded upload into the next free revisions/rNN/, under the same relative paths: the upload record and its page, the cover's delivery receipt, retry log and exports, the movie's validation, quality, QA and glyph readback records, the watch notes, the authored manifest, and the uploaded movie file whose bytes the record names, so that video can render the corrected cut in its place. What it never moves is the production's ground: the edit, the presentation layer, the frozen intake and material, the audio, the picture, the accepted cover pictures and every audit history.
The care is in the order. The record, superseded.json with complete: false, is written before the first move, and the upload records move last, so the production keeps reading as uploaded until the whole set is aside; a run that stops part way is finished by the next call, in the same folder. Files move by a rename on one volume, never by a copy followed by a delete, and across volumes the command refuses rather than risk a half-moved set. A target that already exists is never overwritten. A cover retry still running on one of those uploads blocks the revision until it ends.
When the corrected cut goes up, the upload stage stamps it on the revision as the successor, one per language. A successor already named is never overwritten, and naming the superseded video as its own successor is refused. The delivery projection then marks every superseded row with its revision and its successor. The two folders built by hand on October 21 and 22 are still read, their successors inferred from the next upload in the same language.
The Old Video Stays, and a Deletion Is Observed
The superseded video stays on the platform exactly as it was. At first that was not a choice. The owner published the Nerja camera cut, deleted the superseded one himself, and said why it had to be him: “피파는 삭제 권한 없어서 어차피 못 지우더라고. 삭제는 아빠가 해야해” (“Pippa has no permission to delete, so she couldn't anyway. Deleting is mine to do”). Pippa's upload account can upload, set privacy and set covers; it cannot delete.
Baseline 1.9 of the procedure (2026-10-22, c4ab71b) made that a rule about records as much as about rights. When a revision supersedes an upload, Pippa leaves the old video alone, tells him which video is his to delete, and reports it as pending on him; revise prints exactly that. A deletion is recorded only from evidence, his own words or beacon delivery --reconcile observing the video gone, never because a deletion was asked for, and never in a sentence where Pippa removed something. The Nerja record has that shape: the reconcile observed the old video as deleted, and no record says Pippa took it down.
Why the History Has to Survive
Lesson 5 of this track argued that once a person approves a result, regeneration stops being reproduction, and the approved film has to be sealed. A correction is the same argument one step later, at delivery. The superseded upload was a delivered fact: it was watched, its cover was read back, a link to it may have travelled. Overwriting its records would make the workshop's history say that the corrected cut was the only one ever made. The procedure forbids exactly that in its own words: archived movies and old approvals are never rewritten to look as if they had followed a rule introduced later. So the revision folder keeps the old upload's evidence whole, the successor stamp says what followed it, and the delivery projection says what the platform shows today. Three facts, three receipts (track 7, lesson 5).