Nothing is ever lost, and a public forge needs an exception for secrets and legal removal

Ore's history only grows. That is the model, it is what makes `undo` a new edit rather than a rewrite, and it is what makes the git mirror append-only by construction. It also means there is no way to take something out. A secret committed by accident, or content that must be removed for legal reasons, is in the log for as long as the log exists, and every replica that has ever synced has a copy. The relay note named this as its first open question and did not attempt an answer: "The obliteration exception to 'nothing is ever lost' -- required for secrets and legal removal, named in §4.2 -- needs its own note before the public tier ships; Lore's two-phase, file-scoped design is the precedent to study" (`relay_transport.md` §10 item 1). The condition attached to it has now been met without the note being written. The public tier has shipped: Oregami has been live at `https://oregami.oxegen.io` since 2026-08-14, behind Steel on jarrah. It holds nothing yet, which is why this has cost nothing yet, and the moment it hosts a real repository the exception stops being hypothetical. The credential-leak history in this tree is directly relevant -- a key was committed to a public repository on 2026-07-10 and three separate sessions each scrubbed a different copy of the file while leaving the history untouched -- and the lesson recorded from it was that removing a file does not remove it from a repository's history. There is a second, sharper form of the problem peculiar to Ore. Obliteration in git is hard because objects are content-addressed and referenced by descendants. In Ore an operation is referenced by every later anchor that names its content, so removing an operation is not deleting a blob; it is deleting something the render is a function of. Whatever the design turns out to be, it must say what a render does when an anchor names content that has been obliterated, which is the same question `sequence_with_move.md` §8 item 5 asks about a partial clone. What deciding it takes: a design note of its own, studying Lore's two-phase file-scoped obliteration, stating what the flag surface says when it happens, and stating what a replica that has already synced is expected to do about it. Transcribed from the project record on 2026-08-14. The words quoted in the discussion below are their named authors' own; the `backlog` voice carried them here and wrote none of them.