Changes touching this path
- loot 0.4.22: loot-cli and loot-forge move to 0.4.22 with their two lock entries, the first public release since 0.4.21 and the one that carries the seek follow-ups, a fetch depth the hosts honour (#2123), the browser SDK bounded read (#2124) and the seek cache cap with --gc (#2125), beside the pipeline verb (#2127) and every land since 3039521e. format major stays at 14 and both live hosts already report 14, so ADR 0066 has nothing to sequence here, and the top forge migration is still 0017, so this release owes no schema step; the relay and the forge still deploy before the site, since #2123 is what the SDK bounded read refuses without. the Known Issues page is re-reviewed by running the 0.4.22 binary in a sandboxed home rather than by re-reading source: loot edit on an older change refuses with change tlqyroot has descendants, v1 edits only a tip (childless) change, word for word and exit 1, while on the tip it reopens the version as the working change, so the one entry stays as written; loot seek --gc --dry-run in that sandboxed home lists no positions and the defaults. REVIEWED_AGAINST moves to v0.4.22 and LAST_REVIEWED to 2026-09-20. RELEASE_TAG is deliberately NOT moved: it names what dl.millerbyte.com can serve, and this release has reached nothing yet. the site byte budget is re-recorded: NOT re-recorded, because no ceiling has to move: every one of the 62 surfaces is under its ceiling, and the uniform +150 to +170 B on every surface is #2127 CLI row in the shared docs chunk they all fetch, one growth and not sixty-two, and not this cut own; the site gate is green in the lane (669 passed and 62 skipped over 61 files). the workspace suite is green at the base (4023 passed over 126 binaries, 7 ignored, on the #2125 lane a commit below, and this land gate runs it again) and cargo build --release --locked validates the lock edit (loot 0.4.22 from the lane binary, and loot-forge 0.4.22 built beside it, refusing to open its storage without its URL, which is its answer outside a deploy)
8b4aa08f · 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.