Changes touching this path

• loot ticket and loot tickets read the ticket-only changes on the forge that have not landed, as a layer between landed main and this position (ADR 0098 §6, the overlay): forge_view asks the default remote for its heads when it answers as a forge, loads what the shared graph holds and stows the rest in memory through the relay append-only ingest, after which the handle refuses to persist, so no head, pointer or conflict of any position moves and #2390 is untouched; a head is overlaid only when every forge-only change it reaches passes the land judgment and its tree matches its base outside tickets/, and the layer holds only what that line wrote under tickets/. a write reads the ticket it names through the same layer, so a web ticket takes a comment before it lands, and a ticket the forge moved to another space is refused as #2454 refuses one landed main moved. every ticket leaf and loot tickets take --offline; a read says on stderr what it took from the forge or why it read locally (no forge, unreachable, --offline), human rows mark forge tickets, and a forge file this identity cannot open reads as an S row naming loot pull-grants in the primary. the bundles a read fetched are recorded in .loot/forge-view, a new position-owned store artifact excluded from undo, and a read inside forge_view::FRESH_SECS answers from it without asking. ADR 0098, the spec §6 note, CONTEXT.md and the usage lines say so, and the Workspace width census moves to 411. pinned against an in-process forge with a second clone of the identity as the web writer; red under named mutations, each restored: a read persisting what it stowed (0 passed and 1 failed), the persist guard off (0 and 1), --offline ignored (0 and 1), the judgment not read and the tree property off (each 0 and 1 over the judgment pin, and together 0 and 1 over the end-to-end pin, which each alone leaves green since the other still keeps a code write out), the layer ignoring its base (0 and 1), no forge_elsewhere (0 and 1), the record never fresh (0 and 1), a sealed forge file not counted (0 and 1), the layer not folded (0 and 1), and a leaf or the listing without --offline (0 and 1 each). cargo test green, 4707 passed over 143 binaries with 13 ignored. client only, no deploy (#2430) 8ca351c0 · dbf3dbe6…
• 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…diff
• 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
• the Tickets view on the private workbench, verdict E of #2411 (ADR 0094, ADR 0098 §1): a view module, its VIEWS line, routes for tickets, tickets/<id> and tickets/q/<query>, and a read route, /api/private/tickets, that answers the files the forge head holds under tickets/ as paths and addresses and each ticket path first touch in the head history with its generation. the browser fetches the objects from the forge by address, opens them with the session keys and folds them in wasm with loot_ticket::fold, the fold loot ticket now folds through too, moved out of loot-cli (ticket_read.rs: readTickets, ticketWants, ticketKinds), so the web reads a ticket as the CLI does and in the same causal order. the page is the conversation page for every ticket and map, a timeline ending in the resolution card, a comment and resolve composer and a right rail; the panel with search, saved views, maps, labels and kinds; and on a map a Conversation and Board switch whose board lays out Waiting, Frontier, In a lane and Resolved under the decisions so far, where a drop onto a card is a wait-on. sealed tickets are withheld rows, and each control names its loot ticket command. a write publishes one change through the SDK publish, now publishTicketWith over an injected core (sdk/src/ticket-publish.ts, assertStowAccepted moved to stow.ts); the pending bar holds writes in flight, and a collision shows both versions and asks. a session whose key is not the namespace owner reads, and lanes, which the web cannot see, are said to be so. connect-src is not widened, since the forge origin it names covers the repo endpoints, pinned by a CSP test, and a built private route loaded in headless Chrome under the enforced policy loaded the view and the wasm core with no violation but the control fetch meant to be refused. public surfaces grow by 229 to 236 B gzip, the route definitions. red under ten named mutations, each restored: the least touch taken as the latest (0 passed and 1 failed), the timeline ordered by name (0 and 1), waiting ignoring closure (0 and 1), the shared fold ignoring a label removal (0 and 2, the CLI label test and the browser read test), a touch outside the head history kept (1 failed and 2 passed), a generation counting a parent never sent (1 and 2), the board waiting column taking the frontier (1 failed and 7 passed), any session writing (1 and 7), an own key held without unsealing (1 failed and 16 passed), and the parent edges swapped in the read route SQL (1 failed and 78 passed over the live Postgres suites). cargo test green, 4739 passed over 145 binaries with 13 ignored, the site gate green at 856 passed, the live Postgres suites at 79 passed, and the SDK suite at 153 passed. owes a site deploy (#2432) 94447d12 · dbf3dbe6…diff
• a web ticket write no longer fails the land in a repo holding a Restricted path outside tickets/, and a fold keeps the holders main records (map #2422): the wire redacts a Restricted path holder list (#521), so the browser change carries each such path as Restricted([]), and forge_fold compared entries with ==, so the operator first web ticket read as writing docs/pitch/zk-host.md and every land after it would fail closed. what a change writes, what two lines collide on and what a forge head changes outside tickets/ now compare address and seal (forge_fold::same_entry over Visibility::same_seal, #1005). a fold no longer takes such a change as it is: its merge records fold_tree, the side that wrote each path since the fork and main own entry elsewhere, read off addresses and opening nothing, which replaces merge_tips in mint_fold_merge, a descendant is taken as it is only when that is the tree it holds, and fold_onto refuses a tip that does not record the main entry outside tickets/, address and seal alike. read against the live forge, the judgment takes the operator change (1 forge-only change, 0 refused, the overlay reads 1 and keeps out 0) and the fold merges it with 0 paths outside tickets/ recorded otherwise. item 4 found no defect in the web read: a native run of the browser read over the live head with the mailbox keys lists the ticket open with nothing unopened, and nothing was changed for it. pinned by a judgment and fold test and a fold_tree test in forge_fold, a forge_view test where a browser-filed ticket over a held path reads in the browser and in a lane, and two loot-first land tests that build the ticket with the browser builder over a base holding a Restricted path, one taken in at the intake and one racing the sync, each asserting main keeps the holders. red under named mutations, each restored: entries compared with == (21 passed and 3 failed over forge_fold and forge_view, 0 and 2 over the land tests), a descendant always taken as it is (22 and 1, 1 and 1), that and the fold check relaxed to same_seal (22 and 1, 1 and 1), and fold_tree taking the web entry where main did not write (21 and 2, 0 and 2). cargo test green, 4744 passed over 145 binaries with 13 ignored. no site change and no deploy owed; this land runs with the lane-built loot-first and loot (#2488) d27f227f · 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
• 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
• the Tickets view first load fetches each ticket meta, labels and waits-on edges instead of every ticket file, and reads the rest when it is shown: loot_wasm ticket_read gains Reach, whose List, Tickets and Answers name the files that read (the list), read_tickets (a ticket whole, when its page shows it) and answers (the gist of a resolved ticket, when a row, a card or the decisions of a map show it) each open, and wants names them; the list carries a comment count, a path fact, and each map its resolved children, whose answers are its decisions, from the new loot_ticket fold::resolved_children and fold::answer, which fold::decisions now reads through in the order it opened files before. each of these /fetch requests sends the heads the list was read at as its have, so the head change node stays at the forge; the forge_view parity test now fetches each read that way from its test forge and asserts that no change node rides and that only the objects asked for do. an attachment opens from the read of its ticket. over the perf hunt dump of this tracker the first load asks for 2,161 objects and keys instead of 5,484, a sync answer of 493,894 B instead of 5,697,392 B and 511,513 B of plaintext instead of 10,309,763 B, and the 15 resolved rows of the home page add 15 objects and 7,952 B. pinned in site/test/workbench-tickets-read.test.ts over a fixture tracker the core seals, and in 3 ticket_read unit tests. red under named mutations, each restored: over the 2 read tests, the first load asking for every ticket file (1 passed and 1 failed), no have (0 and 2), gists fetched again (1 and 1), a whole read asking for the list files (1 and 1); over the 3 ticket_read tests, List naming every file (2 and 1), the list folding bodies (2 and 1), the list without waits-on edges (2 and 1), the last resolution taken as the answer (2 and 1); and the parity test with an empty have (0 and 1). cargo test green, 4785 passed over 145 binaries with 13 ignored, and the site gate green at 883 passed. owes a site deploy (vrxsvlsy) 77cc7fe7 · 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.