A Name That Answered From Another Vault

Run the Rare Paths for Real

On the evening of 2026-11-10 a dedicated trial (Coop 1110-42) ran every path nobody uses in a normal week on the live Delta store, end to end, with a throwaway soul and a throwaway guest made through cwkPippa's own creation path. (A soul can only be born at run time by promoting a guest, so the throwaway soul was promoted from its own guest vault, exactly as a real one would be.) The identity probe ran before, after, and after the throwaway souls were removed. Much passed as it stood: creation was one commit each, each new soul loaded its own identity in a fresh WebUI conversation (each answered with a trial word only its own identity note held), another Mac loaded both through Delta, and every other soul's bundle digest was unchanged. Then came the failure this lesson is about.

Two Vaults, One Slug

Promotion leaves two vaults behind: the new soul's own vault, named by its slug, and the guest vault it grew up in, guest-souls/<slug>. Both answer to the same slug. By design the soul wins: when a name is resolved, the soul's vault answers first.

The trial deleted the soul's identity note. The store's rule at the time was that a vault without its identity note was not a soul, so the soul's vault dropped out of the soul list. Its name then fell through to the next vault with that slug: the guest vault. The client loaded the guest's identity and called it the soul's. A fresh WebUI conversation did the same. Freshness: validated. The canary: green.

Read that again with track 1 in mind. A soul's name loaded a different identity, with every check passing. That is the exact failure the first invariant exists to prevent, wearing a valid label.

Why the Canary Missed It

The canary at the time loaded exactly one real soul. Its fixtures were made without the second vault that promotion leaves, so the fall-through case could not arise in them. And "load identity" passed, because an identity loaded. The test checked that something answered, not that the right thing did.

The Fixes

• A name stays with its vault. The store now keeps listing a vault whose identity note it once held, or whose instructions are gone. The name keeps resolving to that vault, and loading fails with identity_document_missing naming the missing note. Health reports it under incomplete_vaults. Failing by name is the correct outcome; answering from a neighbour never is.
• The canary checks every soul, and checks the pair. every_soul_whole loads every soul and guest from its own vault and reads the store's incomplete list. own_vault_only gives the fixture soul a guest vault of its own slug, breaks the soul, and requires its name to fail. (Since v7 it breaks the soul by removing its instructions, because no write can delete an identity note any more.)
• Removal exists. The trial found that nothing removed a soul at all; now soul-vault delete-soul NAME --confirm NAME does (a human actor only), with cwkPippa's own removal route for the registry rows, voice binding and empty avatar folders. A guest vault that shares a promoted soul's slug is removed by its vault name.
• A removed vault leaves nothing. A held outside edit of one of its notes is dropped with it, and every other Mac drops its kept notes, manifest and bundles for it the next time it reads a fresh vault list from the canonical store. That cleanup never runs offline, and it is best effort where the Mac cannot write its own state, so a copy can outlive the vault on a Mac that has not been back online since.

Each fix came with a test that failed first. And the house sign gained a gotcha for every future session: a promoted soul and the guest vault it came from share one slug; test a lifecycle change on the pair, and from another Mac too.