Changes touching this path

• the Tickets view keeps the forge objects it reads in a browser cache and reads no code manifest: the list, a ticket read whole and the answers now take each object an IndexedDB cache in the vault database holds by content address, once the core has decoded the entry as the object at that address, and ask the forge /fetch only for the rest, so a repeat visit moves only new objects. an entry is a sync frame holding one object, ciphertext only, and an object whose key rode in the forge answer is not kept; the cache is bounded at 32 MiB, evicts the least recently used, is wiped with the vault, and reads as empty where storage is missing. the workbench asked for the whole head manifest on every entry and opened the explorer first, so a Tickets visit moved the whole tree, about 376 KB gzip as the ticket measured it: a view now has an ahead hook the shell runs beside the repo header, Files asks for the manifest there and Tickets for its route, and the shell opens the side panel of the view it was entered at, so a History link now opens the History panel; the list fetch starts from a manifest only when one is already held. pinned in vitest: a repeat visit asks the forge for nothing, a partial hit asks only for the misses, a damaged entry and an entry of another object are refused and asked for again, no keyed object is kept, a write lands only while the vault holds the identity, no storage asks every time, and a Tickets entry reads the route asked ahead and no manifest; and in loot-wasm, what an entry is and what it refuses. red under named mutations, each restored: the cache read skipped (3 failed and 11 passed), every want fetched on a miss (2 and 12), entries held unchecked (1 and 13), the list fetch loading the manifest (2 and 12), the entry view ignoring the document (1 and 13), the vault check dropped (1 and 11), an entry held under any address (1 failed and 3 passed in cargo, 1 and 10 in vitest), and keyed objects kept (1 and 3 in cargo, 1 and 10 in vitest). cargo test green, 4886 passed over 144 test result lines with 15 ignored, and the site gate green at 925 passed. owes a site deploy (qqypkwst) b7bcb3b5 · dbf3dbe6…
• the Tickets list read opens its keys in batches while the object cache is read, in slices that yield to the page, and its cache read no longer waits for the unlock or for a write: loot_codec::envelope::unwrap_envelopes checks many signatures in one batch verification and verifies each alone when the batch does not hold, loot-wasm openSealedGrants passes each grant the gates of openSealedGrant over it, and Keyring.keysFor opens the keys of the list through it 32 at a time and asks keyForSettled for the rest; the object cache read is read-only and the write after it marks what was used, the entries of the list are read as soon as the route answers, under the identity the vault record names, and the read yields every 8 ms (pace.ts). measured in headless chrome over the 2,161 list objects of this repo: key opening 283 to 295 ms before and 205 to 208 after, the longest task 362 to 379 ms before and 80 to 81 after, which is the fold call and stays one task, and the cache read 138 to 177 ms before and 38 to 48 after. the read leaves the measures tickets.unlock, tickets.engine, tickets.cache-read, tickets.keys and tickets.fold. refusal.tsx now states that loot-wasm exports no encrypt, held by a test to the generated surface, where it listed the exports. red under named mutations, each restored: keysFor without the batch (1 failed and 22 passed), without the lone asks after it (1 and 22), a pacer that never yields (1 and 1), a yield to the microtask queue (1 and 1), a cache read that marks uses (1 and 2), a mark for an entry gone (1 and 2), eviction before the marks (1 and 2), the read ahead ignored (1 and 15), read ahead under any identity (1 and 15), keys opened after the objects (1 and 15), no fold measure (1 and 15), an encrypt export (1 failed of 1), a batch that passes unchecked (0 passed and 1 failed in cargo), and openSealedGrants over unverified envelopes (0 and 1 in cargo, 1 and 22 in vitest over the rebuilt wasm). cargo test green, 4888 passed over 144 test result lines with 15 ignored, the site gate green at 958 passed, and the SDK suite 176 passed. CONTEXT.md says so. the wasm gains merlin for the batch, 16.6 KB gzip. owes a site deploy (nqrklwsv) 2bc00291 · dbf3dbe6…diff
• a file open asks for its entry and then the blob store, where it asked for the entry, a presign and then the blob store: /api/private/blob mints the ciphertext URL in its answer through mintFor, the presign route gate over the row its tier answered and the same 60 s life, and openEntry fetches from it while more than URL_SPARE_SECONDS of that life is left and asks the presign route otherwise, never before the keyring has answered; the entry route already read one path by key since nyvxmxqz. a file open keeps the ciphertext it fetched in the object cache under the blob store origin, up to a sixteenth of the cache, and a file whose ciphertext it holds opens with the entry request alone, once that ciphertext opens as the object at its address. a read of the Tickets list again after a write asks the route again and folds the objects and keys the list shown was opened from, asking the cache, the forge and the keyring only for what the new head names that they lack, where it asked for the whole list. quick open shows each view list as it arrives, where it waited for the Tickets index. a file open leaves files.entry, files.key, files.cache-read, files.ciphertext, files.decode and files.open. pinned in vitest: a file open 3 requests before and 2 after, a file the cache holds 1, and a read again after a write of one file 8 objects and 8 keys asked for before and 1 and 1 after. red under named mutations, each restored: the carried URL never used (2 failed and 6 passed), used past its spare (1 and 7), fetched before the key (4 and 4), the cache not read (3 and 5), a refused entry not fetched again (1 and 7), no bound on what is kept (1 and 7), no ciphertext measure (1 and 7), the blob route minting no URL (1 and 2), a burned row minted for (1 and 2), a shallow entry minted for (1 and 2), the read again taking nothing from the list shown (3 and 21), asking the keyring for every key (2 and 22), folding only what it fetched (2 and 22), fetching nothing new (2 and 22), quick open waiting for every list (2 and 1), in the order of arrival (1 and 2), and updating once stopped (1 and 2). cargo test green, 4897 passed over 144 test result lines with 15 ignored, and the site gate green at 998 passed. CONTEXT.md says so. owes a site deploy (yvtvstwu) d5f588e8 · dbf3dbe6…diff
• a refusal of a moved position now names each file another command moved, read off the fields of PositionState and of the draft slots, each destructured whole, where it named the heads, then the working change, and otherwise the conflict record, so a move of the settled ledger alone was named as the conflict record, and the draft check named every move its working change, a move of the pending handle included; a pool item whose run panicked is caught and finished, so the land test gate no longer names it as running until the pool ends, and the first such panic is carried out once the rest finish; a Tickets entry from Files while the manifest is still loading asks the list fetch from that manifest once it answers, unless the route answered first, where it asked only from a manifest already held. pinned: a_refusal_names_the_settled_ledger_when_only_it_moved, and the heads named in a_save_that_moved_the_position_refuses_over_a_newer_one, in loot-core; a_finalize_refused_over_a_moved_tip_names_the_heads, the arm tnlrmsmo named, and a_retry_over_unchanged_inputs_signs_the_version_id_the_refusal_left, which pins its version id claim, in loot-cli; a_panicked_item_is_not_named_as_still_running; and two site tests of a manifest in flight. red under named mutations, each restored, failed and passed: the ledger named as the conflict record (1 and 1), an unmoved working change named (2 and 0), the position check off (1 and 2), the pending handle named as the working change (1 and 2), a load that lets the pending handle win (1 and 2), the panic uncaught (1 and 14), a panicked item left unfinished (1 and 4), the panic not carried out (1 and 0), and of 29 site tests: an in-flight manifest ignored (1 and 28), a read that always waits for it (1 and 28, on a timeout), and no stop check (1 and 28). the ownership message is left at /wants for a pusher the custody list admits, decided and noted in forge_push.rs. doc fixes: save_to and persist no longer say each shared artifact merges, burned_under_lock names its lock as one of BURN_LOCKS, the disk record settles say what defines their callers, the grant cursor reads say what is pinned, the object cache says a repeat visit fetches a published object again and that the per-file bound is no share of the cache, vault.ts says what openDevice is exported for, the qktqvvzr sentences in CONTEXT.md and the land-change skill carry the dock condition, gc_keep_set names the leak a refused finalize leaves, .gitignore names .lootignore, and rewrap leftovers in orchestrator.rs, CONTEXT.md, workflow.md and grants.rs are joined. cargo test green, 4938 passed over 144 test result lines with 15 ignored, and the site gate green at 1028 passed. also closes qpxmrnxm and tzuxsroy. owes a site deploy (oxuypvlz) f557daaf · 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.