the install page names v0.4.24 now that the artifacts and the detector have landed, which is the condition the constant own comment states: RELEASE_TAG is deliberately not moved by a release cut because it names what dl.millerbyte.com can serve rather than what the workspace is versioned at, and v0.4.24 reached the public bucket in one finalize pass shipping three of five triples with the two darwin ones carried forward on the signed manifest platform_pins, after which the published detector installed it anonymously through all four surfaces and read back loot 0.4.24 exactly, and a hand download of the windows zip matched the published sha256.sum and printed loot 0.4.24. DARWIN_CARRY_TAG is deliberately left at v0.4.14 because the macOS rows are served by that carried pin and not by this tag. release-pin.net.test.ts ran live against the CDN rather than returning early (3 passed), and the site gate is green from the lane with nothing recorded. no migration, no wire or format byte moves and no host behaviour moves, but the published install page changes, so this owes a site deploy (#2276) ad12626e · dbf3dbe6…
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.