Changes touching this path

• the workbench keeps the head manifest and the Tickets route answer at rest between visits, sealed with AES-GCM under the vault record wrap key with the entry key as additional data and the repo named by a digest, and asks again with If-None-Match: both routes tag their answer with the sha256 of its body and answer 304 with no body to that tag, a weakened one included, so a repeat visit downloads nothing while the answer is unchanged; a digest rather than the head or version, because a manifest row published flag and the repo header move while those do not. an entry is written only once this tab holds an unlock and while the vault holds the record it was sealed under, checked in the writing transaction, and Lock, sign-out and a change of user wipe it with the seed; the device database moves to version 6. the decrypted fold is not kept. red under named mutations, each restored: plaintext at rest (5 failed and 13 passed), no additional data (1 and 17), the key without the repo (2 and 16), the repo named as plaintext (1 and 17), the wipe skipping the store (4 and 14), no record check in the write (1 and 17), no live check (1 and 17), kept before the unlock (1 and 17), no tag sent (2 and 16), a 304 passed through (1 and 17), the server comparing strongly (1 and 17), the server tagging the version alone (1 and 17), and in the first reads the manifest or the tickets route asked without the cache, or every selector asked through it (each 1 failed and 4 passed). site gate green at 1138 passed; cargo test green, 5018 passed over 144 test result lines with 15 ignored. owes a site deploy (lnmntzxw) 0a84402e · dbf3dbe6…

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.