Candidate B renders the whole repository to open one file, and the closure-scoped renderer that answers it does not exist

File identity was settled on candidate B -- origin anchors. Content operations carry no file field; a `FileCreate`'s OpId is the file and mints an origin anchor; a file is the subtree beneath one origin in a single repository-wide Fugue forest; routing ceases to exist as a step. The trial that decided it was large and the verdict was not close: 60,000 operations, 8,959 cross-file moves, zero anomalies, against candidate A tearing concurrent edits at file boundaries. The note that recommended B also stated the strongest argument against it, and did not soften it: "Candidate B makes the *ordering* global, not merely the claim register ... Taken literally that means opening one file in a repository of ten thousand requires resolving every anchor in the repository, and it means a partial clone cannot even enumerate a file's operations, let alone render them" (`file_identity.md` §6). The answer offered was design work owed rather than work done. The scope a renderer actually needs is not the repository but the closure of one file's origin anchor under the claim register -- the file's own operations plus anything that has moved in or out, transitively -- which degenerates to "the file's own operations" for any file no cross-file move has ever touched, which is most files most of the time. The note is explicit about the sequencing it wanted: "A closure-scoped renderer is a precondition for candidate B at scale, and it should be designed before `fe2o3_ore` is changed, not after. If it turns out not to work, that is the argument that reopens this note." `fe2o3_ore` was changed. The migration landed the same night the decision was taken, and the closure-scoped renderer was not designed first. This is therefore the one open item in the record that can reopen a shipped decision, and it is listed as such at `file_identity.md` §8 item 1: "The closure-scoped renderer. Section 6's counter-argument. Until it is designed, candidate B renders the repository to open a file. This is the item that could reopen the recommendation." It is also not academic any more. The forge renders the whole repository on every page (see the snapshot proposal), and cloud residency and partial clone are both on the roadmap. Deciding it takes a design for the closure computation, a statement of what an anchor into absent content resolves to -- `sequence_with_move.md` §8 item 5 says that debt explicitly -- and a measurement on a repository large enough for the difference to show. 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.