[sanity]

Problem

The unified mail delegate (#364) holds identities, contacts and local state behind an origin-scoped, per-item compare-and-swap protocol, and does signing and decryption itself. The UI still talks to the two v0.2.x delegates (identity-management, mail-local-state), keeps identity seeds in page memory, and relies on a permission-overlay pump and empty-response acks.

Approach

Switch the UI to the unified delegate in layers, each compiling and tested:

1. Release freeze (30066eb). The migration from the v0.2.x delegates lands in the next PR of this chain, so .release-freeze makes scripts/release.sh refuse to run until it does; scripts/release-freeze_test.sh (in CI) shows the refusal.

2. Client (7b0cba3, ui/src/mail_delegate/).

   • Request ids are random, and each call waits for the one response carrying its id. A call with no answer is Unknown, never "absent".
   • Two backends:
     • The node. It registers the candidate delegate once per page load with the pinned v0.2 cipher/nonce, then sends.
     • Offline. The delegate's own code runs in the page over an in-memory store, so offline tests exercise the real protocol rules.

3. Typed operations (d1c1ae2, mail_delegate::ops).

   • Identities: create/import/update/confirm, plus paged delete, which repeats on Continue without asking again.
   • Items: paging, and a read-merge-write that retries a lost compare-and-swap.
   • v1 crypto: decrypt, seal, authority and removal signing (hashes ascending), and the v1 AFT parameters.
   • Exports, and grant revocation.

   Tests pin interop with the UI's own v1 crypto both ways: the delegate decrypts what the v0.2 client encrypts, and the v0.2 client opens and verifies what the delegate seals.

4. Contacts (9c8767a, 2f712d2, 2f99f82, 0deea6d, ui/src/app/contact_store.rs). Loading runs in a root-scoped task; a scoped spawn panicked inside node_comms. Each loaded contact's inbox is primed (Cross-node send fails silently with 'missing contract parameters'; UI shows 'Sent' #191), as the reload path did before.

   • One Contact item per contact, keyed by address.
   • The address book updates immediately, and writes persist from a spawn_forever task; a refused or unanswered write shows a toast.
   • Contacts load at startup.

5. Revoke export permission (a5b461b). Settings → Backup & restore gets "Remembered export permission", which sends RevokeExportGrant.

   • Fixes toasts pushed from detached tasks: push_toast uses use_context, so from a spawn_forever task it panicked silently. push_toast_detached uses the root's queue.
   • ui/tests/export-permission.spec.ts runs it against the in-page delegate; it failed before the fix.

6. Identities and crypto in the delegate (0ffc1fe). The page holds no private key.

   • Sending seals once in the delegate; the assignment hash is taken from that same ciphertext, which is the one stored.
   • Inbox states are decrypted by the delegate in a task (never in node_comms, which delivers the delegate's answers). Whole-state updates keep what is already decrypted; a removal that lands mid-decryption wins.
   • Removals (ascending hashes), settings changes, and new, self-healed or migrated inbox states are signed by the delegate. A migrated inbox advertising another encryption key is no longer re-signed (the delegate signs only with its own key); it is reported instead.
   • Delegate work that the node loop needs (listing identities, migration markers, token-generator parameters, initial inbox state) runs in tasks that hand results back as NodeActions (app/identity_store.rs).
   • Migration markers (Deliberate inbox/AFT WASM bump → per-identity state migration (future) #213/Inbox migration: improvements for robustness #251) live in each identity's IdentitySettings item; the loader records them before any migration GET is dispatched.

7. Identity lifecycle (0ffc1fe, 27857d7).

   • Create: the delegate creates the identity and returns its recovery key once (Reply::CreatedIdentity, golden line appended, guard mutation in check-guards-fail.sh; the delegate test checks both halves of the returned key), so sign-up keeps its backup step. Discarding at that step deletes the identity (the delegate asks).
   • Restore (key or JSON) is ImportIdentity{UserRestore}; rename is UpdateIdentity; delete loops on Continue.
   • Backup modal and Settings reveal the key through the consented ExportRecoveryKey (ExportedKeyPanel); the key lives only in that panel's resource.
   • Offline builds seed the example identities in the in-page delegate.

8. Local state as items (2c16e6e, ui/src/local_state/items.rs). Drafts, sent, kept and archived messages, read/deleted marks and settings are items owned by the identity's address; the v0.2.x local-state delegate is no longer used.

   • Received-message ids are blake3(ciphertext)[..16], so marks stay on the right message across reloads and reordering. Drafts and sent use their UUID bytes.
   • Deviation: the UI keeps a u64 message id rather than widening it across ~20 call sites: the first 8 bytes of the 16-byte item id, top bit cleared (local_state::RECEIVED_ID_LIMIT; the top half is reserved for folded own-Sent rows). Two of one identity's n messages share a UI id with probability about n²/2^64 (~5×10⁻¹² at 10,000 messages); writes use the full 16 bytes. Ids carry no time: nothing orders on them.
   • Each write returns on the delegate's acknowledgement. The WriteTracker count and the old delegate's empty-response-as-ack handling are gone; "Deleting…" / "Archiving…" resolve on the write's own answer, and the write is never raced against a timer (dropping it could leave a multi-step write half done).
   • Settings merge field by field, nested, over compare-and-swap, so two tabs changing different settings keep both.
   • Local state loads after the identities are announced, outside the node loop, and is merged into what the page already holds (see 12); delivery-state writes triggered from the node loop run detached (awaiting the delegate there would deadlock).

9. Removals (fec6fec). The permission pump that answered the node's own permission prompts, its policy helpers, the pending-recipient tracking it read, and the Settings card that edited saved decisions. The node asks the user now; the stored fields stay decodable but nothing acts on them.

10. Deletion progress and detached toasts (1dd39a8). Deleting a large identity shows "Deleting identity x… N items left", updated per page. Toasts pushed from detached tasks (local-state write failures, identity loading, migration landed, delete failure) go to the app root's queue instead of use_context, which panics outside a component.

11. e2e step 3 (0551137). Proves the mail delegate ran on the node from the node's own log: the first-run "Module cache miss — compiling" line naming the committed candidate's code hash. (A UI log::info line goes to the browser console only, never the gateway log.)

12. Startup load, id partition, storybook (ba8092c). Three regressions from 8 and 6:

    • Persistence layer: sent/deleted messages don't survive refresh or session #286 (live node: an identity's row vanished after it was created). The startup load listed the identities, then loaded their local state (one delegate round trip per item) before announcing them, and the announcement replaced the identity list wholesale, dropping one created in between. Identities are now announced first and upserted; local state loads afterwards and is merged: only the identities the load read are replaced, and global settings only if nothing in the page changed them since the load began.
    • Reply fails when recipient added sender under a different local nickname #289 (live node: "Add to address book" never shown). Hash ids sat above SENT_FOLD_ID_BASE (1 << 48), so every received message passed for a folded own-Sent row. Received ids now have the top bit cleared and folded rows use the top half. An audit of the other id uses found every ordering is by time (one stale "newest root_id" comment fixed).
    • Offline storybook. The storybook host builds a second User, whose example identities the in-page delegate already held; the second create was refused as a conflict and the expect panicked before the story rendered. Existing example identities are reused.

13. Offline deletion and CI coverage (fb78336). The offline build deleted an identity from page memory only, so the in-page delegate kept it. Both builds now delete through one loop (identity_store::delete_with_progress). cargo make test also runs the UI's library tests in the offline build, which CI never did, so the in-page delegate's tests (mail_delegate::local) now run there.

14. Review round 1 hardening (1dda377..8f39920):

    • Releases: every production publish path (release.sh, publish-email, publish-container, publish-production) runs scripts/check-release-freeze.sh first. The freeze test never runs a release.
    • Archive: the inbox removal waits for the archived copy's acknowledgement.
    • Key material: loading fetches none. Token-generator delegates are registered at first use. Recovery keys and restored seeds are held in wiped memory, and restore input is size-capped.
    • Correctness: rename takes the delegate's ack, decryption retries entries past the reply budget, consented calls outwait the delegate's prompt, and unreadable migration markers are never overwritten.
    • Concurrency: a failed or cancelled delegate registration is retried, a racing write never undoes a delete, read marks are sent once, and an early delivery state is kept. A deleted identity's cached state doesn't pass to a new identity under the same alias.

Status: in review

Transitional exposure until step C: V1AftParams returns the v1 token-generator delegate's parameters, which carry the identity's ML-DSA signing seed, to code running in the Mail page. The page now asks for them only on the send path. The buffer the delegate returns is zeroized, but decoding it into stdlib DelegateParameters/Parameters and handing it to the node's client API makes plain copies that live across the send path's awaits and are freed, not wiped. Consent does not cover this op. Step C removes it, together with the anti-flood tokens, before any release, and the release freeze stops a publish before then.

Review round 1 is fully addressed. The last items:

• Startup merge: every change to the local-state snapshot goes through one apply, and while a load runs it is journaled; the load is applied under the journal. A draft saved meanwhile stays, a Sent row deleted meanwhile stays deleted, a settings change keeps the fields it changed, and a deleted or renamed identity is not brought back.
• Interrupted deletion: Op::ListDeletingIdentities (appended) lists identities whose approved deletion has not finished; Your identities offers "Finish deleting", which does not ask again. A deletion that may be partly done says so ("may be incomplete; it will finish when you retry") instead of "was not deleted", and a restore of such an identity says to finish the deletion first.
• Offline coverage: the in-page delegate runs with v1-transition, and the local-state writes and load are tested against it. The UI's call sites still persist only in node builds (the offline store lives for one page and its example messages are not delegate items).
• Hardening: a dropped call's waiter is removed and a reply with no waiter is not decoded; local-delegate with use-node is a compile error.
• Not changed: the local-state cache stays keyed by alias. Re-keying it by address would change the frozen wire-v1 LocalState shape and about 20 accessors; delete and rename already move or drop the cached state, and the startup merge now honours both.
• No change needed, now tested: an identity created but never confirmed (the tab closed in between) has its inbox and AFT record re-published by the existing own-contract self-heal on the next load (First send to a recipient hangs recipient node, all contract GETs fail #288): the node answers the load's GETs NotFound and the own-contract arms re-PUT them. A live-node test reloads at the reveal step and checks this (round 5). Its token-generator delegate is registered on first send, and Settings shows the "not backed up" banner until its key is saved.

Deferred to B3: the confirm-identity prompt for unconfirmed identities before send/publish (ops::confirm_identity is ready; only the migration produces unconfirmed identities).

Deferred to C: the AFT token-generator delegate's registration handling (token_generator_management and the v0.2.x identity-creation plumbing it drives). The node's empty answer to its RegisterDelegate is a real answer, and it all goes with the anti-flood tokens.

Review round 2 fixes (9c59c89..778c689):

• Identity-scoped local state, item owners and the early-delivery stash are keyed by the identity's address, not its alias. Writes after a rename persist, and finishing an old identity's deletion never touches a new identity with the same alias. Rename no longer moves state.
• A contact is persisted only after the address book accepts it. Stored contacts whose aliases clash, with each other or with your identity, all load as alias~<address prefix> with a warning.
• An archive's inbox removal targets the inbox it was made in, even if you switch identity while the archive is being confirmed.
• Decryptions from a superseded inbox state are dropped, in-flight decryptions are not repeated, and per-message failure codes are kept: unreadable messages are not asked for again, and a failed call is retried with backoff.
• Journaling starts before identities are announced, so changes made while unfinished deletions are listed are replayed.
• A late autosave or read mark never recreates a discarded draft or a deleted message's kept copy. This uses the page's discard tombstone and the stored deleted flag (the flag covers read marks in other tabs; drafts across tabs are covered in round 3). Delegate tombstones were not added, because they need their own pruning index.
• An identity-index entry left by a half-finished deletion is pruned when deletions are listed and before a new identity is stored.
• "Finish deleting" runs one attempt at a time. (Read-mark retries are reworked in round 3.)
• push_toast from a spawn_forever task (Dioxus root scope) falls back to the root queue instead of asserting.
• An unanswered prompt: the node's empty answer at its 60 s timeout already ends the waiting call. It is now reported as unanswered rather than declined.

Review round 3 fixes (778c689..4790208), each with a test shown failing without it:

• A draft discarded or sent in another tab is not brought back by this page's autosave (a sent draft could otherwise reappear and be sent twice). The page remembers the drafts it has seen stored; a save that finds one missing writes nothing, and the compose sheet stops autosaving and says so.
• A read mark is never re-sent by renders. The read-mark task retries a transient failure (no answer, busy, conflict) up to 3 times with backoff; a failure that remains is reported once.
• An identity arriving after a stored contact with the same alias moves the contact to its clash label instead of overwriting it, whichever loads first. The suggested-alias fallback no longer resolves an ambiguous alias (a relabelled contact, or two contacts suggesting one name).
• "Finish deleting" re-renders when a deletion starts or ends: its state is a signal.
• A failed prune of recordless identity-index entries no longer fails ListDeletingIdentities; the prune runs again on the next listing. Delegate change: guard mutation added, candidate rebuilt.
• Tests that were missing or vacuous: forgetting a deleted identity is asserted on its address key; the startup journal order (announce_then_merge); the archive removal target through store_then with an identity switch mid-wait (DeferredRemoval::pick, which also turns an unloaded inbox into an error rather than a panic); and a live-node test that a renamed identity's draft and settings persist across reload (R10).

Review round 4 fixes (4790208..1af39c9), each with a test shown failing without it:

• An archive's or delete's inbox removal finds the inbox by the identity that owns it, as the folder view does, never by its position in the inbox list (which is the order inbox states arrived). With two or more identities the old lookup could pick another identity's inbox, match nothing there, and leave the message in its own inbox. The tests list inboxes in arrival order with the other identity's first.
• A draft records the address of the recipient chosen for it (since round 5, the recipient's identity address rather than their inbox contract id), and is sent to that address only. If the To field has since come to name a different key (an identity created later under a contact's name) or the recorded recipient was removed, the send is refused with a message and the user chooses again. A draft from older data without a recorded address is resolved once when opened; an ambiguous name asks the user.
• Before sending, a draft this page saw stored is checked against the delegate: if another tab sent or discarded it, the send is refused, so it cannot be sent twice. The banner no longer offers to send it from here.
• Relabelled contacts are tracked explicitly, not recognised by a ~ in the label (a contact named bob~work is an ordinary contact); a clash label never overwrites an entry that already holds it; forgetting an identity forgets its seen drafts and recorded recipients.
• The live-node rename test waits for the sheet's data-autosave="saved" (set once the delegate acknowledges what is on screen) instead of sleeping.

Review round 5 fixes (1af39c9..9ea757f), each with a test shown failing without it:

• One send at a time per compose sheet. Send checks the draft with the delegate first, and a second click during that round trip could send the message twice. The first click claims the send; the button is disabled and reads "Sending…" until it settles. Two tabs sending the same draft within a couple of round trips can still both pass the check; that window is documented at the check, with claim-before-send (a compare-and-swap delete, undone if the send fails) as the way to close it.
• Typed or picked names are never refused as ambiguous. The refusal applied to fresh typing and autocomplete picks, so a name could become impossible to send to (your identity that took a contact's name; a new contact reusing a name two contacts had clashed on). They now resolve to the entry that holds the name. Only a reopened draft with no recorded address whose name has become ambiguous starts unresolved, and sending it asks the user to choose.
• Drafts record the recipient's key, not their inbox contract. The inbox contract id depends on the inbox contract's code, so a new inbox generation (step C) would have refused every saved draft. A draft now records the recipient's identity address (fmail-addr: + address_of(vk)), and the inbox is resolved from the key at send time. "No longer in your address book" and "couldn't work out who this was addressed to" are told apart.
• Messages are removed by id without assuming the list is sorted. A single removal binary-searched a list kept in arrival order with hash ids, so most archives and deletes left the row in the model. Audited the other ordering assumptions in ui/src: thread groups sort by time first, delegate paging reads a sorted index, and the removal payload is sorted on purpose.
• An identity whose deletion began leaves the page. After a deletion that failed past its first page, the delegate hides and refuses the identity; both builds now drop it from the page (by address, signing it out if open) when it is listed as unfinished, so only "Finish deleting" remains and nothing is left after finishing.
• Clash labels can't land on another stored contact's name, an identity's name or a label already given out (a contact was silently dropped on insert). Removing one of two contacts that clashed on a name gives the other its name back without a reload, unless an identity holds it.

Testing

• Round 5: UI tests 339 in the default build, 346 offline; clippy clean (-D warnings) natively and on wasm32 for both builds. Red→green, by re-applying the old behaviour: the double-click guard; the ambiguity refusal (three address-book tests); contract-id recording (two); the binary-search removal; the page keeping a partly deleted identity; the bare clash label; no rename-back on removal. New live-node test: an identity left at the reveal step gets both contracts on the next load, and a further load finds them. No delegate or protocol code changed in this round.

• Round 4: UI tests 330 in the default build, 337 offline. The removal tests fail against the positional lookup; the recipient and relabel tests (address book) and the send-check and recorded-address tests (in-page delegate) all fail with their fix removed. These UI checks were run by hand; check-guards-fail.sh covers the delegate and protocol.

• Round 1, last items (each shown failing against the code it guards): six startup-merge tests (removing the journal replay fails all six); V1AftParams offline equals the v0.2 client's encoding (fails with the feature off); five local-state persistence tests against the in-page delegate (archive-before-remove fails when the removal ignores the outcome); an interrupted deletion is listed and finishes without asking (delegate test plus a guard mutation) and the same through the in-page delegate; deletion and restore failure texts; a dropped call leaves no waiter. UI tests now: 309 in the default build, 310 offline. Delegate: 65 tests.

• UI library tests (earlier rounds): 282 in the default build, 273 offline (--no-default-features --features example-data,no-sync, now in cargo make test). Offline runs exercise signing, decryption and deletion through the real (in-page) delegate. New in this round, each shown failing against the code it guards:

  • a startup load replaces only the identities it read and keeps a settings change made meanwhile (red against the wholesale replace);
  • received ids stay below the folded-row range (red without the mask);
  • a thread is ordered by time even with anti-chronological ids;
  • a large identity reports what is left after each page until it is gone (red when progress is not reported).

• Playwright (offline): mail-delegate-identity.spec.ts: the key shown at creation is the one a later reveal exports, and leaves the page when the panel closes; a deleted identity's key restores it as new with the same fingerprint (red against the in-memory-only delete). Existing specs cover restore by key and JSON, the backup panel, delete confirmation and revoke. threads-storybook.spec.ts passes again.

• e2e-real-node: Persistence layer: sent/deleted messages don't survive refresh or session #286 and Reply fails when recipient added sender under a different local nickname #289 pass again; new: two tabs changing different settings keep both. Two tabs can't share a delegate offline (each page has its own), hence the live test.

• Delegate: 64 tests with and without v1-transition, including the_recovery_key_comes_back_on_creation_only; protocol golden test covers reply_created_identity.

• Candidate WASM (now 7fLRKWh2hrQkNctnDzBnVUxzn4nQcwcZ3NgJ3jN7L3mQ); check-delegate-candidate.sh, check-frozen-artifacts.sh, check-frozen-immutable.sh and check-guards-fail.sh pass.

• Strict clippy (-D warnings): the workspace and the offline UI build.

• Release freeze: scripts/release-freeze_test.sh.

Round 7: host-fault runs

Every earlier round found another bug of one class: an outcome the host cannot report (a failed read looks exactly like an absent key; a write or a reply may or may not have landed) treated as success, failure or absence. No test could reach it, because the in-memory host never failed.

The harness (delegates/mail-delegate/src/tests/faults.rs, env.rs):

• MemEnv can now fail calls, seeded and deterministic: reads that miss, writes and removals the host refuses, per-call chance or the Nth call on a key. The host model is that a failed read is transient (an immediate re-read succeeds).
• Seeded runs drive create, import, rename, delete-with-Continue, item put/delete/get/list and the identity listings, with lost replies. They then heal with faults off and check:
  • identity records and index entries agree (no unlisted key, no leaked slot);
  • no marker that licenses a prune outlives its create or deletion;
  • a deleted identity leaves nothing;
  • every item is indexed under a stored owner, and every entry names a stored item;
  • no acknowledged write is lost and no acknowledged delete undone;
  • no generation is handed out twice.
• The default is 300 seeds × 60 ops (FAULT_SEEDS, FAULT_OPS, FAULT_RATE); seeds that failed earlier are pinned.

What it found. Before the fixes, 219 of 300 seeds broke an invariant. After them, none of 300 at a 6% fault rate, and none of 2000 × 80 ops at 6% or at 20%. The bugs:

• A missed read could destroy data. One missed read of the generation counter reused a generation; of an index, rewrote it without its entries; of a record, let a create overwrite it or a prune unindex a live key. The store now confirms every miss with an immediate re-read.
• Space::del returned Ok on a miss while the key stayed. It now removes the key anyway, and Ok means gone.
• A create whose write and undo both failed leaked an identity slot for good. The "entry may have no record" marker is now written before the slot is claimed.
• A deletion answered Deleted while its marker, which names the address, could remain. The retry now finishes it without a prompt.
• An item index entry whose record was gone held a cap slot. Listing now frees it.

UI items from the same review (each with a test that fails without it):

• Identities are selected by id, not by position, so removing one from the middle no longer selects the wrong identity or panics.
• A rename now reaches user.identities too, and a rename with no answer is judged by re-reading the identity.
• Message marks are reclaimed only after a second non-empty inbox state, against every message any state held, and never for a mark written mid-reclaim.
• One lost read no longer makes a draft "gone elsewhere" (the send check, autosave and the item delete helper re-read).
• A delegate error naming no delegate is the token generator's while one of its requests is in flight, and never ends a call holding a consent prompt open.
• Stored contacts sharing a signing key are all kept on load, and mail to that key is refused until the user deletes the wrong one. This supersedes round 6's "settle by the name typed".
• A deleted message's copies go before its "deleted" mark.

Round 7, continued (live-node failures and the remaining should-fix items):

• "A renamed identity's draft and settings persist across reload" failed 3 of 4 e2e runs from a51fd85 on. The startup load lists identities, then prepares each one (a delegate round trip apiece) before announcing them, so its snapshot could land after a rename. Applying it replaced the entry with the same address, bringing the OLD alias back; the new alias then named no identity, and every draft, sent and settings write under it failed with "no identity" (autosave stuck at pending). A listing now never overwrites an entry the page holds at a newer delegate generation (Identity::upsert; test a_stale_identity_snapshot_does_not_undo_a_rename, red before). A failed autosave now shows as failed with a Retry instead of staying pending (367b056).
• "An identity left at the reveal step gets its contracts on the next load" failed twice. The test reloaded as soon as the self-heal was logged, which happens before the PUT is sent, so a reload could cancel it and the next load rightly self-healed again. The UI now logs when the node acknowledges a self-heal PUT, and when it loads the AFT record; the test waits for both acknowledgements, then for both contracts to be found, before its checks (9571d95, 93ccdc9).
• Startup loads (identities, local mail state) retry, then say to reload; an unknown unfinished-deletions listing is reported. A lost create not listed yet is re-checked before "not created". A reached storage limit is named in the failure toast. A failed publish keeps the identity on the page and lets the self-heal publish its contracts. Acknowledged writes drop their optimistic copies of message bodies (9099a7d, 3dad39a).
• Not changed: a lost create is still matched by alias. The delegate refuses duplicate live aliases atomically, so the only mismatch is another tab of the same app creating that same alias first, and the user is then shown their own identity of that name through the consented export. The reasoning is at after_lost_create (904025c).

Round 8: keys that stay unreadable, and the UI's identity bookkeeping

Delegate. freenet-core reports a secret it cannot read or decrypt as
"not found", on every read. The fault runs now model that too: one
present key at a time goes persistently unreadable
(invariants_hold_while_a_key_stays_unreadable). Before the fixes, 34 of
300 seeds broke an invariant; after, 0 of 2000 at 6% faults / 2%
blindness and at 20% / 10%.

• The generation counter is kept in two copies (read as the larger, both
  written or the call fails), and write_if never goes below the record
  it replaces.
• Every index has an existence marker (xm/): an index that reads as
  absent once written is Busy, never rebuilt from nothing.
• A create never writes over, or rolls back the index entry of, a listed
  record that reads as absent; a delete removes the record whether or
  not it reads; an approved deletion of an unreadable identity runs the
  full cascade.
• Markers are typed. Only a failed create (f) or an approved deletion
  (d) licenses dropping a recordless entry, and only d skips the
  deletion prompt; a create's leftover marker licenses nothing. Items
  get the same pending markers (pi/).
• A failure after an op already wrote something is reported as
  Internal (may have happened), never Busy/Conflict/NotFound.
• A recordless entry under a create's marker (record write, rollback and
  three tries at marking it failed all refused) was kept as a slot leak.
  Round 9 frees it (below).

UI.

• New and imported identities get page-unique ids (all were id 0, so
  selecting the second acted as the first).
• Resolving a contact key conflict rewrites the one stored record to the
  kept contact instead of deleting it.
• A deleted identity is unrouted and its page bookkeeping cleared; sends
  resolve the sender by address, and a sender that is not routed is an
  error the user sees, with the draft kept.
• Closing the compose sheet saves its last edit (X7). The close fix was
  right; its live test was intermittent because it reloaded the page while
  the close's save was still in flight, which ends the save with the page.
  Evidence, the test repeated 6 times in CI: reloading at once, 2 of 6
  lost the edit; waiting 5 s first, 6 of 6 kept it. A user who closes
  compose and reloads at once hits the same window, so draft saves in
  flight are now counted page-wide (pending_saves), published as
  data-pending-saves on the document element, and the page asks the
  browser to warn before leaving while any is pending (best effort in a
  sandboxed frame). The close flush is built before its task runs, so a
  sheet closed at once still flushes. The live test now waits for
  data-pending-saves="0" before reloading: 6 of 6 passed with the fix,
  and 6 of 6 failed with the flush disabled.
• Keyless node errors are attributed to the token generator only while
  a token call actually waits (60 s at most).

Also from round 8:

• Stale message marks are reclaimed when updates arrive only as deltas
  (X8): the page reclaims once it has seen the current state (a whole
  state the node pushed, one fetched after a live delta, which the first
  delta asks for, or two different fetched states). Two copies of the
  same state count once.
• A settings change that removes a map key persists the removal (X10).
• Removing a contact and adding it back keeps it (X11): writes for one
  contact run in order, and a save creates the contact again if a
  deletion lands between its read and its put.
• Nits: the conflicting-keys toast says sending is refused; a new test
  covers a refused delete on the read-miss path; a comment records the
  cost of delete's confirming re-read.
• cargo make test-e2e-real-node takes extra Playwright options through
  E2E_PLAYWRIGHT_ARGS (e.g. --repeat-each=6 --grep=closes.is.saved).

Nothing from round 8 is open.

Round 9: getting back from storage that stays unreadable

Round 8 made the delegate safe while a key stays unreadable; round 9
gives the user a way back.

Delegate and protocol (Op::RepairIndex, FailureCode::Unreadable,
appended with golden lines):

• An identity whose record cannot be read is restored by importing its
  keys again (the same address means the same seeds), and can be deleted
  after the usual prompt.
• RepairIndex resets an index that cannot be read: the identity list,
  or one kind's list for one identity. It asks every time ("Repair" /
  "Cancel"), is namespaced like every op, and is refused while the index
  reads. Records stay stored; nothing can list them (the delegate never
  lists the host), so identities come back by importing them again.
• A listed item that cannot be read is reported as Unreadable, and a
  create replaces it without touching its index entry.
• Deletion bookkeeping may use a small reserve past the budget, and a
  write that does not grow the store is never refused, so a full store
  can still be shrunk.
• A create that never finished (only its marker left, the record
  confirmed absent) frees its slot on the next listing. The fault runs
  now require zero leaked slots at every rate; the one record allowed to
  stay unlisted is the run's unreadable one, which the run restores by
  import where it holds the keys.
• A wider sweep (2000 seeds x 80 ops at 6%, 10% and 20%, transient and
  unreadable-key) found two more, fixed and pinned: a deletion marker
  that could neither be read nor removed was reported gone (a key the op
  itself wrote must now be confirmed removed), and an index created but
  left marked "may be absent" was rebuilt from nothing once it stopped
  reading.

UI.

• When the identity list keeps reading as unreadable, Your identities
  offers "Repair storage" (the consented RepairIndex), then asks the
  user to restore each identity from its recovery key.
• Unreadable settings load as defaults and the next save replaces them;
  deleting an unreadable item works; an unreadable draft still counts as
  stored. The user is told once.
• A rename re-keys the identity's own address-book entry, and a rename
  onto a contact's name is refused.
• A draft discarded during the startup load keeps its tombstone.
• The startup contact load keeps contacts the page changed meanwhile.
• Delivery states waiting for a Sent item are forgotten by address (the
  key they are stored under).
• A late answer to an expired token call no longer ends a newer call's
  window; Send/Discard no longer fire a close-save of the removed draft.

Item lists other than the identity list are repairable through the
delegate, but the UI does not offer it yet: it would need to say which
list (drafts, sent, archive...) lost what.

Round 10

• Sends across a reload (Persistence layer: sent/deleted messages don't survive refresh or session #286): a queued send now counts as unfinished page work until its inbox update is answered, failed or swept, so leaving the page warns. Sent rows that an earlier page session left Pending, with nothing in this page waiting on them, are marked failed after the startup load, with one notice that they may still have arrived. They are not resent: re-sealing makes a new ciphertext, so a message that did go out would arrive twice.
• Deleting an identity: an approved deletion records its approval before it touches the record, so a restore or migration import can't undo it if the record stops reading mid-deletion. Only a deletion marker counts as approval, so a create's leftover marker can't make an identity undeletable. A list that can't be read no longer blocks the deletion: it is forgotten, and everything else is removed, keys included.
• Unreadable data: a contact that can't be read can be replaced and removed. One of an identity's lists that can't be read loads as empty, and "Your identities" offers to repair it; the consent prompt names the list and its owner. Migration markers that can't be read stay unknown and are never written back.
• Contacts during the startup load: a write queued behind another for the same contact is journalled when it is made, so the load can't bring back a removed contact.
• Store: a key that reads as absent gets three removal attempts before its delete counts as done (fault seed 1284 had a deleted contact come back). A key that can't be read and whose removal is refused every time can't be told from an absent one through the host API.
• Fault check: the one record allowed to be stored but unlisted is the record that was unreadable during the run. That is intended: an unreadable record can't be told from an absent one, and importing its keys restores it (asserted by importing_keys_restores_a_listed_identity_whose_record_cannot_be_read). The harness now also tries to import an identity whose deletion has started, and fails the run if it comes back.
• Guards: new guards for each round-10 delegate fix, and a restored guard for failed-create slot reclamation.

https://claude.ai/code/session_01Xxpwzvt4ucaGfbeCr77Jns

[AI-assisted - Claude]

[sanity]

Review summary (Full tier + security + data-loss: UI switch-over to the key-holding delegate)

Thirteen review rounds on this PR.

• Rounds 1–2: Codex plus blind Claude lenses (security/key custody, data-loss/concurrency, code-first/testing).
• Rounds 3–11: an adversarial re-check of each fix round, plus an independent whole-PR bug hunt.
• Codex ran in rounds 1, 2 and 5. In the other rounds it was out of quota (now until Nov 4), so per policy additional Claude lenses substituted, and the substitute whole-PR lens was told to look specifically for the bug class Codex had been finding.
• The last whole-PR pass found no data-loss, key-leak or stuck-UI issue. The last re-check found the storage protocol clean; its two remaining items are fixed in the final commits, which I reviewed.

What changed because of review (highlights):

• Release freeze: .release-freeze gates release.sh and every publish task. The test override needs an explicit test flag, and the freeze test can't reach a real release.
• Key custody: the page holds no identity seeds. The anti-flood token generator's seed is fetched only on the send path, zeroized and redacted, and goes away with the anti-flood tokens later in the chain. Recovery keys are shown once at creation; later reveals need consent.
• Data safety:
  • archive waits for the stored copy before the inbox removal;
  • drafts record the recipient's key, not an alias;
  • drafts sent or discarded in another tab are refused;
  • in-flight writes warn before leaving the page;
  • startup merges replay changes made during the load;
  • deletes can't be undone by racing writes;
  • identity state and routing are keyed by address, not alias.
• Storage robustness:
  • a seeded fault-injection harness drives the delegate with transient and persistent read misses and refused writes, checking invariants after healing (index ↔ record ↔ marker consistency, no leaked slots, no lost acknowledged writes, never stuck at the storage cap);
  • it found and drove fixes for over a dozen bugs no reviewer had spotted;
  • CI runs a 2,000-seed sweep at a 20% fault rate on every PR.
• Recoverability: unreadable records restore from recovery keys; a consent-gated repair rebuilds an unreadable list; unreadable items can be replaced; deletes work at the storage cap; usage recounts instead of blocking.
• Guards: scripts/check-guards-fail.sh runs every guard against a mutation and requires its named test to fail. Two vacuous guards were caught and fixed along the way.

Final round: a last fault-harness finding (a seeded run leaked an identity slot) turned out to be a real bug: restoring over an unreadable record deleted it before taking a generation number, so a refused counter write stranded the slot. Fixed by overwriting in place, pinned by tests that replay the original faults as a script (not a seed), and re-checked clean.

Follow-ups noted for the next PR:

• three stale doc comments in store.rs about the transient over-count (bytes also run high, not only keys);
• a guard for an under-count mutation in write_over_unusable.
  Neither affects correctness: the recount corrects the over-count, and CI's candidate check pins the binary to this source.

Known and tracked: #367, an intermittent live-node failure where a folder click sometimes leaves the view on Inbox (about 1 in 86 runs; no data involved). Instrumentation is in place to pin it down on the next occurrence.

Deferred by design:

• the migration of v0.2.x delegate data, and the confirm-identity prompt for migrated identities (next PR in the chain);
• removal of the anti-flood tokens (later in the chain).
  The release freeze keeps main unreleasable until migration lands.

Shipped bytes: none. The delegate is a committed candidate, nothing is published, and releases are frozen.

[AI-assisted - Claude]