Phase 8 of docs/multiple-profiles.md: the seams of Phases 1 through 7 in a
row, through the real view models on an in-memory database with a real key
store.
A is made from a phrase through the create view model and the seed writer,
the way Landing makes the first profile: both files written, and listed
once as a profile with a wallet attached, under the wallet's id, with the
credential's key. A is opened with a node behind it -- a PhoenixBusiness
that was never started, which is enough to make it one the switch has to
stop. B's npub is signed in from inside through the sign-in view model; the
switch stops A's node, B is open and read-only, the machine routes it from
its placeholder, and nothing was ever started for a public key. A kind 1
queued for A while B is open waits three seconds unsigned; back to A, and
it goes out, with nothing more stopped since B had no node. C is created
from inside through the bare-key writer: a key, not a second wallet, routed,
with no node, and the switch to it stops A's node again. C and B are
forgotten through ForgetIdentity with the view model's writers, the default
is cleared and the selector reset: A is listed alone, its credential is the
only entry left in the file, B's and C's account rows went with them, and A
itself cannot be forgotten because a wallet is attached. Then a fresh view
model over the same directory, which is what a cold boot is: the repair
finds nothing to do, A is listed from its credential rather than derived,
and StartupChoice opens it without asking.
A navigation state is matched to a profile by whichever step it is at --
UnsignedProfile, UnqueuedProfileSynchronization, UnannouncedProfile through
the event the broadcast request names, ProfileLoaded -- because with the
notary running, A's account moves from unsigned to announced-pending while
the test looks, and what the test asserts is whose account it is, not which
step it reached.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pulled-From: curated/curated@88577bb5c3
72b9d3d2ed