The paths nobody walks in a normal week
Lesson 6 describes how a guest soul is made and promoted. Making a soul, promoting one, removing one, losing a note, a Mac that cannot reach the store: these are the paths a normal week never touches, which is exactly why they hide bugs. When the vault moved into Soul Vault (memory track, lessons 12 to 15), each one was run for real on the live store on 2026-11-10, with a throwaway soul and a throwaway guest made through cwkPippa's own creation path: a guest created, then promoted, since promotion is the family's only way to make a new soul while the house is running. The identity probe ran before, after, and after the throwaways were gone.
Creation passed as it stood: each vault landed in the store as one commit, each loaded its own identity in a fresh private 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 was unchanged. Four other paths failed. Each was fixed with a test that failed first.
A name that answered from the wrong vault
A promoted soul and the guest vault it came from share one slug: the soul's own vault, and guest-souls/<slug> kept as its lineage. The trial deleted the promoted soul's identity note. Its vault then dropped out of the soul list, and its name fell through to the guest vault: the client and a fresh WebUI conversation both loaded the guest's identity as if it were the soul's, labeled validated, and the daily canary stayed green. That is the worst kind of failure this design knows, a fluent answer as somebody else (memory track, lesson 14).
Now the store keeps listing a vault whose identity note it once held, or whose instructions are gone, so the name stays that vault's, and loading it fails as identity_document_missing naming the missing note, on every surface. Health names it under incomplete_vaults. cwkPippa's dispatcher excludes an incomplete soul from active work without rewriting the stored selection, so it comes back when the note does. A guest vault that shares a promoted soul's slug answers only by its vault name.
The canary that checked one soul
The canary had loaded one real soul and called the store whole. It now has a step that loads every soul and guest from its own vault and reads the store's list of incomplete ones (every_soul_whole), and a step that gives a fixture soul a guest vault of its own slug, breaks the soul on purpose and requires its name to fail rather than fall through (own_vault_only). Proved live: the canary went red naming the soul and the note, the alert reached Dad's Telegram through Watchfire, the note was written back, and two clean passes resolved it.
Nothing could remove a soul
There was no way to remove a soul at all. Now there is one, and only by a human's hand: soul-vault delete-soul NAME --confirm NAME in Soul Vault, and in cwkPippa remove_soul, DELETE /api/souls/{id} and a script, which take the vault or vaults, the registry rows, the voice binding, and the avatar folders creation made when they are empty. A family soul with its own class in the code is refused; Dad's word is the approval. And a removed vault had left things behind: an outside edit the store was holding for one of its notes could be neither applied nor discarded and would have alerted forever, and every other Mac kept the notes and bundles it had verified. Both go with the vault now: a Mac drops a vault's copies when the canonical store's vault list no longer names it (never on an offline read). The store's history is never deleted: the 42 revisions the throwaway souls went through are still there.
Contract v7: no write deletes the note that says who a soul is
The trial left one rule standing that it could not fix inside one child: the identity note could still be deleted by the ordinary delete path; only the soul-editing door refused it. A rule every vault needs is a contract change (memory track, lesson 12), so it went to Dad, who approved the recommendation the same evening (나머진 추천대로 해, "do the rest as recommended", 2026-11-10 17:56 KST). Root contract v7 puts the rule in the write template itself: a delete of a vault's identity note is refused as policy_denied, before compare-and-swap and whoever the actor is, Dad included. Because every door that deletes a note is that template (a delete, a batch, a move, an outside deletion being applied, a request from another Mac, which is refused twice: by the caller's template before anything is sent, and by the canonical store's), the rule needs no second copy anywhere. The note can still be replaced by an ordinary write, and removing a whole soul still works, through its own primitive, by a human. A new canary step, identity_note_stays, tries the forbidden delete every day.
From another Mac, two more
Running the canary from a Mac that does not hold the store's tree found two bugs that had been there all along. A removal sent from another Mac named the bare slug, and by slug the soul answers, so removing guest-souls/<slug> from any Mac but the canonical one would have removed the soul instead of the guest vault that was named. The records showed no real soul had been hit; the one real removal of a promoted pair ran on the canonical Mac. The request now carries the vault's own name. And the canary's cleanup put a slash in its request ids, which Delta's write call does not carry, so two guest fixtures never left the live store until they were removed by hand the same minute. The tests' fake Delta now refuses every request id the real one refuses.