Changes touching this path

• loot 0.4.23: loot-cli and loot-forge move to 0.4.23 with their two lock entries, the first public release since 0.4.22 and the one that carries the seal-over-tree-entry arc, where every site that acted on a change tree entry unsigned visibility field now asks the seal instead (#2185 the three acting sites, #2188 the timed deposit lane, #2187 the push-time deposit plan, #2196 the git bridge projection, #2203 the git-side ingest, #2205 both grant doors and #2212 the sync ingest door, with #2206 and #2214 measuring and correcting the prose behind them), beside the forge runner and job tables (#2157, ADR 0091, migration 0018), the owner side of a proposal (#2162, ADR 0075), the pre-land gate learning which stream a doctest reports on and refusing a cargo it could not start (#2084, #2140, #2199, #2066), a patch that carries the ending of the line it shows (#2005), the relay mailbox taking the door the relay already writes objects through (#2112), and every other land since 3cfbe9b, 30 in all, the first of which is the RELEASE_TAG move that published 0.4.22 (#2147). format major stays at 14, format.rs has no diff at all in the range, and both live hosts answer format_major 14 over /info, so ADR 0066 has nothing to sequence. the top forge migration is now 0018_runner_and_job.sql where the 0.4.22 cut said 0017, so unlike the last release this one DOES owe a schema step: 0018 is include_str-ed into MIGRATIONS and rides the forge binary, so the forge deploys BEFORE the site. the Known Issues page is re-reviewed by running the 0.4.23 binary in a throwaway home, with HOME and USERPROFILE and XDG_CONFIG_HOME and XDG_CACHE_HOME all redirected into a temp directory and a local loot-relayd for the pull half, rather than by re-reading source: the one entry reproduces word for word, change xoxokopy has descendants - v1 edits only a tip (childless) change at exit 1, while loot edit on the tip reopens version 0101b025 as the working change, so it stays. the custody prose was re-run rather than re-read as well: once loot lock cleared the session, status, log, diff, grep, surface, whoami, describe and push each refused with the ADR 0068 message while lock and unlock still ran, a wrong LOOT_PASSPHRASE said so and was ignored, the session file held loot-unlock v2 and machine and sealed hex with the passphrase own hex in no file under the config directory, loot id phrase refused both a pipe and a redirect with no override, loot undo refused across the push barrier in the words the page quotes, and loot burn printed the never-pushed and pushed tiers with one line per disclosed host. ONE CLAIM IS CORRECTED, and it had rotted without an edit: the locked-pull paragraph read since {REVIEWED_AGAINST} the ingest writes down the claim it could not check, which was exact when #2089 wrote it at v0.4.21 and false one cut later, .loot/stale-disk-unverified being in the v0.4.21 tag and absent from v0.4.20, so it is the literal v0.4.21 now, for the reason the session-file boundary is the literal v0.4.17; the behaviour itself was re-run and holds, a locked pull leaving the receiving disk on the old bytes and parking .loot/stale-disk-unverified while the rehome its note names materialized the arrived version after unlock. REVIEWED_AGAINST moves to v0.4.23 and LAST_REVIEWED to 2026-09-21. 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 NOT re-recorded, because no ceiling has to move: all 62 surfaces are under theirs, /known-issues is +7 B against a 208896 B ceiling, and the one figure worth a reader eye is /privacy at +586 vs recorded with 907 B of headroom, which is not this cut own since nothing here touches that page. the site gate is green in the lane (tsc, the build, 669 passed and 62 skipped over 61 files, and the budget), the workspace suite is green (4140 passed over 132 binaries, 8 ignored, 0 failed) and cargo build --release --locked validates the lock edit (loot 0.4.23 from the lane binary, and loot-forge 0.4.23 built beside it) 078d5ce1 · 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.