The page's own example passed the journal mtime. Measured 2026-11-04: a chain
using it fell straight through its wait loop, because status only asks whether
the section has scanned since that epoch and the section had been walked earlier
the same day. The verify that followed read a database that had not yet processed
that day's renames — a false success, which is the direction that gets believed.
The duplicate-prune, TV-duplicate, Ghibli and promo-clip holds went out of the
array trash on Frank's word: ~1.2 TB back. This replaces the three "purge pending
Frank's word" rows with what happened.
Two procedures the page did not carry:
- The purge gate. `REAL: 0` in both databases only says no row points at a moved
path; it says nothing about whether the film survived. Every held file needs a
same-work carrier in the live library at >= its size, re-derived at purge time,
because the relayout renames folders AND keeper files, accents defeat ASCII
matching (Nausicaä), and a carrier is usually another container at another
size. That supersedes the 2026-11-01 "re-verify by size" law, which is exactly
the test that reports survivors as lost.
- The purge mechanics. The repo purger acts on a root's own .AGENTTRASH and
nothing else, so a partial purge is staged into a scratch root while the
unapproved buckets sit parked at the array root as .HOLD-<date>-*.
./tests/run.sh: 824 assertions, all pass.
dank