No explicit lifecycle to retire/remove an identity — need a sync-safe shutdown/archive/rm flow

[schickling-assistant]

LAYOUT.md covers how an identity comes into being (folder creation is explicitly "for the implementation to decide" under Identity bootstrap UX), but there is no defined way to end one. The CLI verb set (message, status, task, journal, sync, members, overview) has no identity-level teardown, and the convention says nothing about retiring or removing an identity. In a long-lived shared root this gap shows up fast: ephemeral / short-lived session identities accumulate with no clean way to wind one down.

There are really three escalating needs here, and they're distinct:

1. shutdown (transient) — "this identity is going away for now." Partly covered: coord mcp writes offline on SIGTERM/SIGINT/transport close. But there's no CLI to deliberately take a still-alive identity offline as a lifecycle step, and offline doesn't distinguish "temporarily gone" from "done forever."
2. archive / retire (durable, keep history) — "this identity is finished; keep its inbox/archive/tasks/journal readable, but stop treating it as live." Today a retired identity that just stops refreshing status drifts to unknown and then reads as offline — indistinguishable from a crashed-but-coming-back peer or one that never existed.
3. rm (remove entirely) — "delete this identity and its folder."

The load-bearing subtlety: sync resurrection

rm is the one that can't be expressed within the convention today. The documented sync floor is plain bidirectional rsync with no --delete:

rsync -a $COORD_ROOT/  peer:$COORD_ROOT/
rsync -a peer:$COORD_ROOT/  $COORD_ROOT/

So rm -rf $COORD_ROOT/<id> on one machine does not converge — the next pull from any peer that still has the folder resurrects the whole identity, inbox and all. This is exactly the resurrection problem the "Archive is the tombstone" rule already solves for individual messages (archive/X.md exists ⇒ inbox/X.md must not, restored by sweep) — but there is no equivalent tombstone at identity granularity. Removing an identity therefore requires either nuking it on every machine simultaneously (no coordination primitive for that) or it comes back on the next sync.

Secondary semantics to pin down

• Pending inbox at retire time — drain-first, reject, or leave the messages stranded in a retired folder?
• members / overview reporting — a retired identity needs a distinct state, not silent collapse into offline/unknown (absence-of-evidence) which already means three other things.
• Addressing — should sending to a retired/removed identity warn or error, or is the inbox simply no longer a valid drop target?
• Hierarchy (issue Support nested / hierarchical members (member identity as a path) #1) — retiring a parent persona.session-1 vs. its children persona.session-1.child-7: cascade, or independent?
• Reserved names — a tombstone marker file would need to be reserved (it sits at the identity-folder root next to status/name).

Suggested direction

Add an identity-level tombstone analogous to the message tombstone — e.g. a single-writer, synced <identity>/retired (or tombstone) marker — so the lifecycle stays expressible under plain bidirectional rsync:

• sweep honors the marker and converges a removal across machines (tombstone-everywhere → then trim), the same shape as the message invariant.
• members / overview report a distinct retired state instead of collapsing to offline.
• optionally, the inbox stops being a valid drop target while the marker is present.

That could be surfaced as a coord identity shutdown | archive | rm <id> verb family (the three levels above) over the one marker convention, keeping rsync convergence trivial and not adding a second protocol.

(Filed from a downstream multi-host deployment with many short-lived session identities sharing one root — there's currently no convergent way to wind one down.)