Changes touching this path

• the browser builds, seals, signs and publishes a ticket write as one change on the forge head (ADR 0098 §1, §5): the .lootattributes dialect moves from loot-cli policy.rs into loot_codec::attributes, which policy.rs wraps to count the parse, and the tracker file substrate (ids, the file format, layout, the Policy check, the values a write takes and what each write puts in a ticket directory) moves from ticket.rs into a new loot-ticket crate that ticket.rs writes through, so the CLI and the wasm core share one implementation. loot-wasm ticket::build (buildTicketChange) takes the forge /fetch answer holding the head, the generation /ref read it at, .lootattributes and the ticket meta as plaintext and one write of new, comment, resolve, label, wait or edit, refuses what a capture refuses with no override and an embargoed rule, seals each file uncompressed under its first-matching rule, and signs one change on the head under the subject ticket <id>: <verb>, handing back the stow and ingest envelopes, a self-grant per unpublished key for the forge mailbox and the wrapped keys; the fixed ingest and ref fields move to loot_codec::forge_ref, which loot-net writes through. the SDK publishTicket stows, deposits the grants and ingests the change as the only head of the forge, building it again on a 409 or 412, a new ticket keeping its id, up to attempts times. pinned against an in-process forge by four forge_view tests (a clone reads a browser ticket after pull and pull-grants with the CLI fold and a lane reads it through the overlay, a restricted write reads S without the grant, a raced write is rebuilt on the new head, a write the rules do not place is refused) and by an SDK behaviour suite against loot-forge --dev and the release loot, 3 passed; red under eight named mutations, each restored: the subject carrying the write (0 passed and 1 failed), a restricted rule sealed internal (0 and 1), no grant deposited (0 and 1), the policy check skipped (0 and 1), a retry minting a new id (0 and 1), the change not naming the head (0 and 1), meta headers out of order in loot-ticket (37 and 2), and the wrapper not counting the parse (1 and 1). cargo test green, 4713 passed over 145 binaries with 13 ignored, and the SDK gate green with npm test at 148 passed. move and attach are not built for the browser. client only, no deploy (#2431) 24e58969 · dbf3dbe6…
• review sweep 3 fix-up over #2430 and #2431 (map #2422): the browser ticket builder reads the rules and the ticket files a write answers to from the head it builds on instead of taking them from its caller as text, where a stale or forged .lootattributes handed in could publish what the head rules do not. loot-wasm ticket::reads names the objects a write reads on the head (.lootattributes, and the meta of the ticket it writes to with its body for an edit), the caller fetches them by address, and ticket::build opens each itself under the forge key lane or a key the session keyring holds, inflating a compressed one with a host zstd the caller passes (ADR 0040); a file it reads that no key opens refuses the write. an edit carries what the head held at each file it rewrites, and built again on a moved head that holds another version it answers a collision with both versions and builds nothing, while an append rebuilds freely (ADR 0098 §9, the browser half). the SDK publishTicket takes keyFor in place of context, resolves with the collision rather than publishing, reads again when the head moves between /ref and /fetch, and reports a 401 or 403 at /stow as an AuthError through assertStowAccepted. loot-ticket holds space_in, and its comment, resolution, label and wait files check their own values; the wasm lockout refusal is RepoError::Lockout; forge_fold keeps differs_outside_tickets alone. the spec §0 amendment records what #2430 and #2431 added past it, and CONTEXT.md, ADR 0098 and the SDK README say what changed. red under ten named mutations, each restored: unopenable rules read as none (0 passed and 1 failed), rules not read from the head (0 and 1), a copy handed over taken for the head file (0 and 2), meta not read (0 and 1), no collision check (0 and 1), an append compared like an edit (0 and 1), no inflate (12 and 3), a /ref to /fetch race refused (1 failed and 4 skipped in the SDK suite), a rebuild without its base (1 failed and 4 skipped), and a /stow refusal as transport (1 passed and 2 failed). cargo test green, 4728 passed over 144 binaries with 13 ignored, and the SDK gate green with npm test at 153 passed. client only, no deploy (#2479) 4efb1baa · dbf3dbe6…diff
• a web ticket write stows its objects and its change rides the ingest alone, so an attempt whose ingest lost the race never reaches another reader as a change (ADR 0098 §5): the forge files a change a /stow carries into its graph, and an unbounded pull serves every change that graph holds past the history of the caller, so before this a lost race left the attempt on the forge, a later pull merged it with the head, and a clone read the map meta from either side of that merge depending on the run. loot-wasm ticket::build now stows the objects without the change and the /ingest envelope carries it, so a refused write leaves objects no change names, which no pull serves. the forge is untouched, which keeps the unbounded pull that recovers a head a push dropped (#2426) and the stowed stack a proposal holds, and owes no deploy. ADR 0098 §5 is corrected in place, with CONTEXT.md, the tickets spec, the SDK README and the publishTicket doc. pinned natively by a forge_view test, where a fresh clone and a clone from before the race each hold the forge head alone and read its meta, and in the SDK collision behaviour test, where a fresh clone log lacks the attempt and its heads are the racer alone. red under named mutations, each restored: the stow carrying the change again (0 passed and 1 failed natively, 4 passed and 1 failed in the SDK tickets suite) and the ingest without the change (11 passed and 5 failed over forge_view). cargo test green, 4738 passed over 144 binaries with 13 ignored, and the SDK gate green with npm test at 153 passed (#2481) c9fe9b32 · dbf3dbe6…diff
• review sweep 4 fix-up over the live Tickets view (#2432) and the web ticket write (#2479, #2481), map #2422: no document key, href or URL of the view carries decrypted text any more, where a label in the panel opened a query whose URL held the label. a query is its own URL only when addressOnly finds every term an address, and any other, a label, a kind the ticket format does not name or a word typed into the search, is a search held in the workbench cache under a random handle that its key and URL carry instead (route tickets/s/<handle>), pinned by a render of the panel navigation, the lists, every ticket page and the board over a marked fold whose links and asked-for documents are scanned for the mark. an /ingest whose answer is lost, a thrown request or a 5xx, is settled by asking instead of read as not published: the SDK publish re-reads /ref, calls it published when the head is the change, sends the same built change again while the head is at the generation it was built on, and when the head moved asks an unbounded /fetch past its base whether the forge holds the change, which it does only when an ingest of it committed, building again only when not. until then the write reads unknown, the site asks until it knows, and an UnsettledIngestError names the change when the checks run out. the page asks before it unloads while a write has not settled. the board gains verdict E Take, which copies loot lane new --ticket <id>, on each frontier card and on a next in causal order callout. AGENTS.md states what the site build reads outside site/ as a property, site-main.yml paths gain sdk/src, loot-hygiene, loot-ticket and Cargo.toml, CONTEXT.md Stow-first publish and ADR 0098 §1 and §5 say what is true now, the member tier read of /api/private/tickets is pinned through forge_member_*, the keyring wait is Keyring.keyForSettled, data.ts uses lib/identity/bytes.ts, and the map kind is MAP_KIND. red under named mutations, each restored: a label opened as a query (1 failed and 6 passed), a label term taken as an address (3 and 4), unknown counted as settled (2 and 5), no beforeunload listener (1 and 6), no callout (1 and 6), no Take on a card (1 and 6), a lost answer read as a refusal (4 failed and 4 passed over the fake-transport suite, 3 and 5 against a real forge), a head at its generation rebuilt instead of resent (2 and 6), a moved head always taken as holding the change (1 and 7) and never (1 and 7 against a real forge), the keyring answering a lock without waiting (1 and 10), and the member read through the owner relation (1 failed and 79 passed over the live Postgres suites). the site gate green at 863 passed, the live Postgres suites at 80 passed, the SDK suite at 161 passed, and a CSP-enforced headless Chrome load of the built search, query and ticket routes met no violation but the control fetch. no Rust changed. owes a site deploy (#2486) 016ab4c2 · dbf3dbe6…diff
• web move and attach, and the consent a web write needs (map ztrnpqko): the browser ticket builder takes move, which opens each file of the ticket the head holds outside the new space and seals it again for its path there byte for byte, removing the old path and keeping each file name so the history keeps its order, and attach, the declared name over the bytes. consent is an input per path: publish for each path the change writes that the rules publish, demote for each path a move writes out of a group to internal, to public, or to a group the rules cannot show names no one new, and reveal for an attachment path under a secret-shaped name. a write missing any builds nothing and answers each path and why, and a write built again is handed back the event names its first build drew, so it writes the paths consented to. a move out of a group into public asks demote as well as publish, which the CLI move does not, since a device may silence the publish question. the 10 MiB cap is loot_ticket::ATTACHMENT_CAP in the shared writer, so loot ticket attach refuses the same file, and is_secret_name with its set moved from loot-cli policy.rs to loot_codec::attributes, which builds for wasm32. publishTicketWith resolves a write missing consent as a consent outcome before anything reaches the forge, with the consent that answers it and the write to publish again, and the Tickets view shows it as not taken, saying why, until vsropolo asks. ADR 0098 §11, the spec and CONTEXT.md record it. pinned natively against an in-process forge over rules like this repo, with a Restricted path outside tickets/: a move into tickets/security/ and out into tickets/public/ read in order by a clone, the browser read and a lane, each consent refused and then given, the cap, and an attachment the CLI reads byte for byte. red under named mutations, each restored: publish never asked (5 passed and 2 failed), demote never asked (5 and 2), reveal never asked (6 and 1), no cap (0 and 1 in loot-ticket, 0 and 2 in loot-cli), a move drawing fresh names (0 and 1), a move keeping the old paths (0 and 1), an attachment losing a byte (0 and 1), and in the SDK the consent outcome not surfaced (18 and 2), the names not handed back (19 and 1) and the consent not passed (19 and 1). cargo test green, 4757 passed over 144 binaries with 13 ignored, the SDK suite at 176 passed with a lane release build, and the site gate green at 863 passed. owes a site deploy, and the primary binaries a rebuild (wyllqvzy) 73f4a22a · 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.