Changes touching this path

• the two deposit plan-execute pairs become one plan_deposits over a RemoteKind that carries both halves of 1042's widening, so the three path accessors go private and the forge-vs-relay rule is a predicate a test can reach instead of a doc comment b3e21d6d · dbf3dbe6…
• a deposit plan builds the tree it ships once instead of once per custody lane, and the first act had to be an instrument that could see the difference: no counter a land can read moved over a repeated whole-graph pass, so Work::GraphSorts now tallies ChangeGraph::in_order and is gated at 0% beside the object pair and store_file_reads, reading 8 on the gated fixture and one string across the drift pin repetitions. THE TICKET ASKED FOR THE TALLY TO REUSE Work::TreeWalks INSIDE finalized_tree and for ADR 0073 to re-decide that exclusion, and that was refused rather than followed: tree_walks counts a whole-tree FILESYSTEM walk of a working tree and this is a graph pass, and the in-process tier links loot-core and never loot-cli while nothing in loot-core outside its own tests calls the deposit lanes, so a tally there would have read zero on that tier anyway and the pin would have stayed green while its stated reason went false. the exclusion therefore stands unmoved on its own measurement, and the ADR records the trigger that did not fire rather than a re-decision it did not force. measured in the counter and not in wall clock: a forge plan over a fixture carrying an embargoed path, a Restricted path and the Internal default read 3 sorts before and 1 after, a relay plan 2 before and 1 after, the three lanes now taking the finalized tree as an argument plan_deposits builds once. the tips membership test inside that build became a set lookup rather than a Vec scan, which no counter can see and which is named as such rather than claimed. red under mutation, counts read each time: the shared build removed so each lane derives its own again failed the new pin (0 passed and 1 failed, graph_sorts 3 against 1, and with the forge arm relaxed the relay arm failed at 2 against 1), the tally dropped from in_order failed the anti-vacuity pin (10 passed and 1 failed) and the new pin (0 passed and 1 failed), and graph_sorts dropped from gate::COUNTERS failed four at once (7 passed and 4 failed), each restored to 11 and 1 passed. the two generated membership sentences in CONTEXT.md and HUNT-PERF.md are pasted by hand as their pins demanded, the hand-written workspace width in verbs/mod.rs moves to 390, the visibility census gains the two argument bindings the by-reference lanes create, and a count in loot-count that was wrong in the commit that wrote it is replaced by the property. no migration, no wire or format byte moves and no host behaviour moves, so this owes no deploy, though the gate records a new metric from the next land. the workspace suite is green (4174 passed over 132 binaries, 8 ignored) (#2225) fe6a089f · dbf3dbe6…diff
• the sentence written to replace a deleted list names the definer instead of counting, and the fix-up is read back under the rule it enforces: ADR 0073 said the gated work counters were the object pair and a further one at each amendment since, which is false because the #1903 amendment added none, so the clause now names measure::WORK_COUNTERS and stops. every other count beside a set that can grow is replaced by what decides membership rather than by a corrected number - the first nine and the six artifact counters and the other three Work variants in gate::COUNTERS become every row WORK_COUNTERS does not name, the Tally Display doc shows one label=value per Work::ALL entry and an ellipsis instead of hand-listing the labels, the deposit lane counts point at kind.widens, and the landed proposal state points at store::ProposalState. THE SWEEP MISSED THREE COPIES OF ITS OWN ITEMS and they are corrected here too, because a corrected claim left standing in a second copy is how #1903 shipped one stale: the three lanes sentence in loot-core custody and again in its test, and the ADR 0075 three terminal states sentence duplicated in a forge server test. two code fixes ride along: #2174 landed the wire_state doc inside the propose withdraw doc comment, so the may_propose rationale documented the wrong function and the route documented nothing, and the stale-tip refusal was broken across source lines with no continuation, so an operator read the indentation of the source in the middle of the message. ONE ITEM IS CORRECTED RATHER THAN FOLLOWED: the ticket reads that literal as carrying a newline, and on the tree it is a single line carrying two runs of collapsed indentation, so the rendering defect is real and its shape is runs of spaces rather than a break. red under mutation, counts read each time: the continuations removed so the break rides in the string again failed the strengthened pin (0 passed and 1 failed, the panic printing the refusal across three lines), restored to 1 passed. the CONTEXT rewrap is a pure reflow, identical byte count and identical word stream, so the generated membership sentence and its pin are untouched. no migration, no wire or format byte moves and no host behaviour moves, so this owes no deploy. the workspace suite is green (4174 passed, 0 failed, 8 ignored) (#2234) f7721acb · dbf3dbe6…diff
• the push-time deposit plan asks the deposit ledger before its standing lanes ask any seal, so a push that ships nothing no longer pays a cold store read per held path for rows already deposited: plan_standing narrows the shipped tree by the ledger in place, one retain applied once, and hands the restricted and internal lanes that narrowed tree, which keeps the loot-core lanes remote-blind and plans the same deposits because each lane decides an entry on that entry and what this position holds at its address. measured cold on 66 standing rows at a forge, counts read each time: 66 disk reads with the ledger empty, as before; 50 with 16 rows delivered, where it read 66; 0 gets and 0 disk reads with every row delivered, where it read 66 of each. the plan is pinned field for field on an empty, a partly full and a full ledger holding rows at another remote and for another recipient, green before and after. red under mutation, each restored to green: the old lanes-first order (22 passed and 1 failed, the cost pin at 66 against 50), the dedupe ignoring the remote (20 and 3, pitch.md dropped), ignoring the recipient (21 and 2, f00.md dropped), no dedupe (19 and 4). the timed lane is not narrowed, its dedupe being per recipient. custody.rs, ADR 0012 in a fifteenth amendment and CONTEXT.md record what it costs now. no migration, format byte or wire byte moves, so this owes no deploy. the workspace suite is green (4402 passed over 139 binaries, 13 ignored) (#2208) 5149e99f · dbf3dbe6…diff
• the review-sweep fix-up over #2325, #2207 and #2208. a proposal landed close is bound to the tip it was decided for, on both stores: ingest decided the landing outside the transaction and each store closed the row on state open alone, so a revision through record_proposal between the decision and the transaction, which leaves the row open and moves no ref and so is invisible to generation_expected, was closed landed at a tip nobody landed. the rows proposals_this_push_lands hands the store already carry the tip decided on, and the Postgres close now adds tip_version = $4 and the memory close compares the tip, the binding a decline has; no other writer closes a row this way. a new conformance case, a revision between the landing decision and the ingest stays open, runs on each store: red first on the memory store (1 passed and 1 failed, the pg half skipping without a database) and on Postgres 18 with the tip term defeated (106 passed and 1 failed), green with it (107 passed). CONTEXT.md, store.rs, pg/meta.rs, memory.rs, ingest.rs and ADR 0075 stop calling the CAS the whole of the soundness. false sentences fixed: ADR 0012 eleventh amendment now says the ledger ran after the lanes until #2208, and the fifteenth names the plan pin as the fixture where the timed walk reads one seal, measured by hand; the plan pin now deposits every row it plans at another forge as well as the Restricted row at a relay, so dropping the remote from the dedupe empties the plan rather than dropping pitch.md alone (20 passed and 3 failed, all six rows gone), restored green (23 passed); Route::ALL is written by a routes macro from the enum variant list, so a variant added to Route is in it with no second edit, checked by adding a probe variant, and the http.rs sentence states that. the --decline refusal says the handle reads as a change id, and the Judged census doc says it sees only the Spawner. no migration, format byte or wire byte moves; the landed close is live once the forge is redeployed. the workspace suite is green under bash ci/local.sh against Postgres 18 (4404 passed over 138 binaries, 13 ignored; site live suites 7 files passed) (#2347) facefe81 · dbf3dbe6…diff
• loot runner add enrols a runner and every push to a forge keeps it current, the second land of #2130 (ADR 0091 §3, §4): add registers the row on the forge first, which judges it, then writes the runner's key into .loot/runners, and when it minted the key writes a home file under .loot/runner-homes/ in ADR 0059's KEY=VALUE dialect with the forge URL, name, kinds, pubkey and private seed, and deposits through the same route a push takes. a push to a forge reads the repo's runner rows from /runners/list and seals a key-only grant, DagRepo::grant_key_only, for each held Restricted or Internal key inside each live runner's scope, filed through /runners/deposit and deduped by the (remote, oid, pubkey) ledger, written only once a batch is delivered; an embargoed key is never deposited, since grant_key_only reads the keyring and not the escrow, and a forge that will not answer the list is a note and not a failed push. ⚠ the #2162 amendment put a runner in .loot/peers, which is also the burn-trust set, the unquarantined grantors and every timed grant's recipients, so the runner file is its own and only the attester trust reads it, keeping the operator's trusted-but-not-a-recipient decision by construction; ADR 0091 records the correction. the scope always reaches .lootpipeline, added when left out. the verb census moves: README 88 verbs, 146 usage lines, ADR 0066 at 88 dispatched and 51 refusing the flag, PROSE_ONLY_CEILING 51 to 52 with its reason, the placeholder census and the site verb list. red under eleven named mutations, each restored, counts read each time: the key-only grant falling back to the escrow (0 passed and 1 failed), and 1 passed and 1 failed over the two workspace tests for no scope filter, no ledger check, a retired runner planned, no Internal lane, the ledger written before delivery, the attester trust ignoring the runner file and the runner file read from peers, five of which also went 0 and 1 end to end, as did the runner written into .loot/peers, a push depositing nothing to runners and the pipeline file left out of the scope. the loot-cli, loot-core, loot-identity and loot-net suites green but for two census tests fixed since, and the site gate green at 842 passed (#2130) 37a00dd9 · dbf3dbe6…diff

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.