Changes touching this path

• Forge publish ingest: file the published key the bundle already carries (#499) 417aaf83 · dbf3dbe6…
• Give the forge an operator channel, with one redaction rule (#522) f9ca9f91 · dbf3dbe6…diff
• the forge stops shipping keys for retracted publications, and publication finally has a producer (#709) ddcf4de9 · dbf3dbe6…diff
• a bundle stops carrying the address it can derive from the bytes beside it, and the bump is 12 to 13 rather than the 11 to 12 the ticket names, because #1539 already took 11 to 12 on main and has never shipped - every tag through v0.4.20-deploy.2 still reads 11. Reusing 12 for a second layout was rejected on measurement rather than taste: read_version can only compare numbers, so two incompatible layouts under one major is exactly the misparse the marker exists to prevent, and pinning the constant at 12 while writing the v13 layout turns bundle-codec tests red with the decoder taking the legacy arm on bytes it wrote itself. No count is given for those reds on purpose - the experiment was run twice and answered differently the second time, which is the whole reason this repo does not write a number it has not just measured. ADR 0019's own amendment says every layout change bumps the major, and two majors between releases has precedent - v8, v9 and v10 all first shipped in v0.2.0 - so a major is not a release label. The encoder stops writing the 32-byte address and the decoder derives blake3 of nonce and ciphertext for every major; the v12-and-earlier declaration is parsed for cursor correctness and DROPPED rather than checked, which is the treatment v5 gives the v4 escrow section and v10 the v9 purge lane, and dropping is the stronger choice because a checked claim still has to decide what to do on disagreement while a discarded one cannot reach any outcome, so the compat lane cannot carry the attack either. The grant_ids lever is taken but NOT as the ticket frames it: the list really is a pure function of vis plus the world marker, and rebuilding it on decode would still be wrong, because that synthesises an authorization token from an invariant nothing enforces on a hand-built SealedObject - so it becomes a two-bit flag byte carrying exactly what the pre-v13 wire could carry, with unknown bits REFUSED rather than masked, since a silently narrowed holder list is how an object stops being published with nobody told. bundle_bytes falls 45,757 to 37,857, minus 17.27 percent, and the figure reconciles to the byte: 200 addresses at 32, plus 180 Internal objects at 8, plus 20 Restricted at 3. The ticket's own baseline of 45,753 was stale by the four bytes #1539's rename count added, and its estimate for the grant half comes in at 3.28 percent rather than 3.5 because the fixture makes every tenth file Restricted, whose holder list #521 had already reduced to a bare zero count; the address half lands at 13.99 against the ticket's 14.0. This is a safety change and not only a size one, so it is pinned on both sides: a hand-built v12 frame declaring one address over bytes that hash elsewhere must arrive at its true hash, led by a positive control because refused and impossible look identical from outside and only one is the claim, and a byte-flip sweep over a real v13 bundle - deliberately not a round trip, which passes whether or not the address is derived - asserting every decode that survives yields a key equal to the hash of the bytes read beside it. Restoring the declared address executes the attack and prints it: one bit flipped at offset 11 and the object separates from its content, ac4373d5 against ad4373d5. A golden is added for the object lane because a field REORDER passes the width test and fails only the golden, and that lane had no frozen bytes at any version. The forge's shipped-under-the-wrong-address refusal is DELETED rather than left standing, which is the riskiest edit here: decoded objs has exactly one constructor and its keys are now obj.address() by construction, so the branch is unreachable from any input, and a refusal nobody can show is doing anything would read to the next maintainer as the thing keeping mislabelled bytes out of the blob store - what actually keeps them out is one layer down and pinned there. VERDICT_CONTRACT moves with the major and no machine-output column does, which is stated in the version history so a consumer pinning contract 12 knows to move and knows the columns are identical (#1384) Perf-Baseline: reset FORMAT_MAJOR 12 to 13 orphans every recorded point; bundle_bytes 45757 to 37857 is the intended -7900 from #1384 1c22e8ad · dbf3dbe6…diff
• a forge push declares the delta past the heads the forge itself names rather than the whole history: declare_forge_heads built its bundle with have = &[] while the RefState it had just read for the CAS generation carried heads it read no other field of, so every push re-encoded and re-POSTed every finalized change in the repo, each with its whole manifest (#288), however little had moved. this is push own #728 move made on the route a forge declares heads on, and the forge side needed nothing built: prepare resolves against already-stowed state and the completeness refusal is over the changes in the bundle, so a change the /stow batches defer is one the push is introducing, which nothing the forge declares reaches, and it still rides. a declared head this position does not hold expands to nothing because the closure walk filters its seeds, so it subtracts nothing and whatever only it would have covered is sent as before, which is the safe direction since /ingest writes content-addressed change rows. WHAT IS GIVEN UP IS NAMED RATHER THAN LEFT TO BE FOUND LATER: the ANYONE key lane no longer re-presents a key for every published object in the history on every push, so a publication row missing for history already ingested no longer heals on the next push of anything; the steady state is untouched, published_key being global and append-only and publication being per oid and repo with a terminal retraction, both written by the ingest that first carries the change. measured twice and both readings live in the tree rather than out of repo: on the real binary against a real forge the /ingest request body of a push moving one change over a 7-change history of 16 paths reads 8880 B before and 2104 B after, and on the bundle at two depths over 24 paths the empty have reads 12039 B over 8 changes and 22615 B over 16 while the scoped arm reads 2817 B over 1 change at both, so the before figure grows with the history where the after one does not. red under mutation, counts read each time: the helper made to ignore its have failed both pins (30 passed and 1 failed in the sync unit tests, 11 passed and 1 failed in forge_push), the call site made to pass the empty have again failed only the wire pin as designed (31 passed and 0 failed in the unit tests, 11 passed and 1 failed in forge_push, reading 8880 B against the 7906 B of the first push), and the deep fixture made no deeper than the shallow one failed the growth control (30 passed and 1 failed, 12039 B then 12039 B), each restored to 31 and 12 passed with 0 failed. the now-false prose is corrected where it stood: RemoteSync haves and declared_heads, the loot-forge ingest and publish module docs, the publish re-verification comment, two forge test comments, the ADR 0024 amendment and the CONTEXT Ingest entry. no migration, no wire or format byte moves and no host behaviour moves, but what a client sends at /ingest moves, so this rides the next release and owes no deploy. the workspace suite is green (4142 passed over 132 binaries, 8 ignored) (#2222) 22beae44 · dbf3dbe6…diff
• landed becomes a state something actually writes, and the walk that decides it had to see the push's own changes: ADR 0075 declares three terminal proposal states and until now close_proposal's only non-test caller was propose::withdraw, so landed - the one that is nobody's act, the work being in ref_head - was unreachable and a row read open over work the repo had already taken. ingest now closes the proposals its declared head set lands, decided OUTSIDE the transaction because IngestTxn is assembled and validated outside so the transaction stays pure writes after the CAS, and that same CAS is what makes the decision sound rather than racy: generation_expected pins exactly the head set the walk assumed, so an interleaved push fails the swap and takes the closes down with it. the ticket and ADR 0092's predecessor both said this needed nothing new because walk already reports an empty extent for a landed tip, and that is true of the STORED graph and the stored graph is the wrong one: a maintainer lands a proposal by MERGING it, so the change making the tip an ancestor of the new head set rides in this bundle and is not in the store yet, and walking stored edges alone closes nothing on exactly the push this exists for. the walk overlays the prepared changes' parent edges and is red without that overlay. only open rows are candidates and the store applies the decided row only over an open one, so a proposal that went terminal between the decision and the commit keeps its own declaration and its own date - a push cannot overwrite a withdrawal it never saw, asserted in the conformance suite against both stores rather than in one. a repo with no open proposal reads its proposal rows and stops without fetching the graph at all, which is every push to every repo never proposed to. red under mutation, counts read each time: the prepared overlay dropped, so the merge in this bundle lands nothing (421 passed and 1 failed, restored to 422). the SQL is new so it was run rather than read: bash ci/local.sh against a throwaway Postgres, where pg::tests::an_ingest_closes_the_proposals_it_declares_landed passes beside its memory twin and 166 pg tests ran, so the UPDATE was parsed by a real server rather than only by a text test. no migration, no wire or format byte moves, and the forge behaviour moves, so this rides the next deploy (#2177) fb7c63c8 · dbf3dbe6…diff
• the forge keeps the attestations a push carries and serves them back with their change, where until now it kept none: ingest never read the bundle attestation lane and every bundle serve built carried an empty one, so a tag, a note or a sign-off pushed to a forge was gone and the push said nothing, while a relay was never affected because its store is a DagRepo. the rules are the engine own two and none is new: an /ingest keeps an attestation that verifies and whose change rides the same bundle and drops the rest without failing the push, and a pull serves one only with its change in the bundle being sent, so a caller already holding a change is not re-sent its attestations and a metadata-private repo needs no new rule. /stow keeps none, because it is also a proposer path and a stranger attestation must not write into the owner repo. migration 0019 adds the attestation table, repo-scoped, keyed on the engine dedupe triple so a re-push is a no-op and the first signature stands, with row security enabled and bound by the 0017 policy, and it joins the rls census, whose doc still said eight tables with ten listed and whose shipped-policy check named migrations by index - it now reads every migration from 0017 on. the driver sorts role COLLATE C, because the reference store orders by bytes and a text column otherwise sorts by the cluster collation. a bundle that sends changes pays one more batched read, so the two offer-cost pins move from 4 to 5 and a no-op pull still asks nothing. a late attestation on an already-pushed change still does not travel - that is #2251, in the engine and on every host - and a pin refuses the forge keeping one outside the bundle so that widening is done on purpose. red under mutation, counts read each time: keeping unverified attestations (0 passed and 1 failed), keeping them outside the bundle (0 passed and 1 failed), serving none (0 passed and 1 failed), a read that ignores the ask and a last-signature-wins upsert (1 passed and 1 failed each, the pg stamp skipping off-cluster), each restored to 1 and 2 passed; and on a throwaway Postgres 18 the COLLATE dropped failed the ordering case (0 passed and 1 failed) where the unmutated arm had passed, restored byte for byte. bash ci/local.sh is green against Postgres 18 (4200 passed over 134 binaries, 9 ignored), after one unrelated loot-cli flake on its first run, filed as #2258. migration 0019 rides the forge binary and nothing on the wire or in a format moves, so this owes a forge deploy (#2250) 97ace3ec · dbf3dbe6…diff
• the kinds trailer on /ingest and /propose and the job creation it drives, with the wake-up sender; the runner-deposit reap is not built. loot_net::forge::HeadDeclaration and ProposalClaim gain kinds: a push declares the kinds of the on main steps of its live heads and a proposal the kinds of the on change steps of its tip, read by pipeline::declared_kinds from the .lootpipeline each version holds, as one trailing byte in Kind::ALL order that is not written when nothing is declared, so a payload declaring nothing is byte-identical to the one an older client signs; a decoder reads the byte iff bytes remain, and a bit this build cannot name is dropped. FORMAT_MINOR is not bumped, per the 2026-09-22 comment on the ticket that overrides step 1 of its body (a minor bump makes persist_codec rewrite every store graph file, the #2180 finding), and adding_the_kinds_moves_neither_format_constant pins both constants; a new client payload decodes on a frozen copy of the old decoder and an old client payload decodes here as declaring nothing. /ingest makes a main job per declared head and declared kind, less those on file, inside the ref-moving transaction (IngestTxn::jobs on both stores, with a conformance case run on memory and on Postgres), and /propose makes a change job per declared kind for the tip once the proposal row stands; member is the author of the version classified by AccessClass::of and approved is a verifying pipeline/approve from a key require_pusher admits, both read once at creation. after the commit each live runner whose row covers a created job kind and carries a URL is woken through jobs::Wake, whose HttpWake calls loot_net::runners::send_wake: the URL checked as registration checks it, the send refused if any resolved address is one registration would refuse (refused_wake_address, which both ask), the checked address pinned, no redirect followed, the request bounded by WAKE_TIMEOUT_SECS. the ticket said the site TypeScript client learns the field, and no code under site or sdk encodes an /ingest or /propose payload, so nothing there changed. the reap is recorded as unbuilt in the ADR 0091 #2159 amendment: grant_inbox is keyed by recipient alone while runner, ref_head, proposal and job are bound to one repo under migration 0017, so a reap run per repo cannot see an address live in another repo the same runner key serves, and how to scope it is a decision left to the reap ticket; nothing writes a runner deposit before #2130. measured: the trailer is one byte when a kind is declared and none otherwise, and ingest::job_cost pins that a push declaring nothing makes no call for jobs and that job creation reads per declared head, not per kind. red under mutation, counts read each time, each 0 passed and 1 failed on a filter selecting its one pin unless said otherwise: the trailer written before the heads, the trailer read unconditionally, the trailer always written, FORMAT_MINOR at 1, every kind made rather than the declared ones (through the push route, the proposal handler and the binary end to end, each), a wake-up sent to every row with a URL, a wake-up sent before the commit, member never set, approved by any attester, the memory ingest dropping jobs, the memory ingest overwriting them, the Postgres ingest dropping them (through bash ci/local.sh, 461 passed and 1 failed in loot-forge), only the first resolved address checked, the binary declaring the kinds of every trigger, the push declaring nothing, approved read once per kind, and the no-kind early return removed; each restored to green. no migration, no format byte and no published wording moves; the forge binary changes, so a forge makes jobs only once it is redeployed, and a forge older than this still accepts a client that declares kinds. the workspace suite is green under bash ci/local.sh against Postgres 18 (4345 passed over 137 binaries, 12 ignored) (#2159) 09cefc35 · 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.