Changes touching this path
- the relay store goes behind a RelayStorage seam, the SigV4 driver moves to its own crate, and an object-store relay is a second deployable the CLI never ships (#38)
330df915 · dbf3dbe6… - a bucket-backed relay reaps, because the anchor is when the bytes last landed in the store and the store is what answers it, and the reap itself moves behind the seam so the standing exemption is one rule both backends run (#1166)
39e1e1eb · dbf3dbe6…diff - the anchor refresh and the deposit race become shared contract rules every relay backend must answer, the reap report has one renderer instead of a drifted hand-copy, and a rule that is written but never asked is now a test failure (#1223)
d31bf81e · dbf3dbe6…diff - the reap window becomes a struct a transposition cannot compile against, the reap-cost rule says at most three like the ADR it pins, the hand-rolled base64 gets its reason, and ADR 0070 admits its refinement in its Status block (#1263)
ff6d4344 · dbf3dbe6…diff - the pull declaration becomes an enum a subset cannot alias through, which also stops a fresh clone re-downloading the full delta every batch, the wire timing line gets named fields, and the reap window scalar stops sharing its name with the pair type (#1284)
3b657494 · dbf3dbe6…diff - the argv door stops being per-binary and becomes one module in loot-net that every binary asks, and flag_value is deleted rather than widened - zero definitions remain workspace-wide, which turns the class is closed from a claim into a deletion. the recorded reasoning this ticket pointed at refused widening a shared reader, which is a different act: it argued a reader must not be taught a new spelling because that changes parsing everywhere at once, and its own third bullet diagnoses the hole as this binary having no gate, so it points at giving the binary the gate and leaving one reader. per-server spec tables were rejected as a second door, the thing this class exists to prevent, and a new crate was rejected because every binary already has loot-net in its graph and the module is pure std, so the odd thing about the home is its name and not its coupling. the destructive half is demonstrated against real binaries and seeded stores rather than argued: a before binary built by reverting only the readers reaps a real blob under reap-grants --older-than 30 --dir store --addr --apply, because --addr is never consulted in reap mode so nothing else in the line looks wrong, and it forges the window under --addr --older-than 1 --older-than 3650 --apply, reading one day where the operator wrote 3650 - after, the first refuses with nothing has been destroyed and the second keeps the grant. the forge enters migrate mode, the superuser DDL path, under --addr --migrate and now treats it as an address. this ticket's own headline argv is corrected rather than repeated: --dir --apply is destructive only under the s3 backend, since on fs both binaries stop at is_relay, and the fs-reachable variant is the one it did not name. loot-first's private reader is in scope and gone too, because land declares two valued flags and --allow-publish --pr 12 --pr 9 landed the PR nobody typed. an early forge pin stayed green through the revert, since the bug was never in the traversal but in what main asked, so the call site was extracted and re-proved red; and two further destructive readers are reported and not fixed, one of which takes a size operand as its scratch directory and recursively deletes under it (#1628)
089f8dda · 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.