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…
• 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
• the Tickets view asks the consent a web write needs, and moves, attaches and shows attachments (map ztrnpqko): a write the core builds only with consent waits in the pending list while a sheet asks, publish naming each file that becomes world-readable for good beside a per-device do not show this again, which a notice above the view turns back on, demote naming who gains access and reveal refusing a secret-shaped name with an override, neither of which can be silenced, and a silenced device gives publish consent itself once per write; a composer on a public ticket shows a public badge either way. the rail moves a ticket to the spaces the head rules define, read by loot_wasm::ticket::spaces with the rule deciding each, and when they define none but internal it says so with the lines to add. the conversation takes a dropped or picked file, refused over ATTACHMENT_CAP before it is read, and an attachment opens through ticket_read::attachment: an image by its byte signature as a blob: URL in an img, the private CSP img-src widened by blob: alone, text by its declared extension escaped in a pre, and anything else a download of application/octet-stream. the filter term frontier becomes unblocked, frontier:<map> is the map frontier the core read, and a query holding the bare word redirects 301, /tickets/q/frontier to unblocked. ADR 0098 §11, the spec and CONTEXT.md record it. pinned natively (the spaces offered, a lockout group left out, internal alone with the lines to add, the attachment bytes the browser opens) and in the site. red under named mutations, each restored: img-src without blob: (41 passed and 2 failed), a quiet device dropping the demote question (42 and 1), the reveal question silenced (42 and 1), do not show this again beside every question (42 and 1), svg shown as text (42 and 1), an image judged by its name (42 and 1), a download typed text/html (42 and 1), an iframe preview (41 and 2), frontier:<map> read as map:<map> (42 and 1), no redirect (42 and 1), the badge off a public ticket (42 and 1), the internal-only note never shown (42 and 1), a lockout group offered (0 and 1), only the current space offered (0 and 1), the whole a/ file answered as the attachment (0 and 1). cargo test green, 4758 passed over 144 binaries with 13 ignored, the site gate green at 877 passed, and a CSP-enforced headless Chrome load of the built tickets routes with no violation, a blob: image loaded and a foreign image refused. owes a site deploy (vsropolo) 75a3eeb3 · 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.