Stem augments the shipping protocol. No existing blob becomes invalid, no existing URL stops resolving, and no document, comment or contact changes identity in a way a reader can observe. The team's chosen method is the one recorded for HM26: migration happens transparently inside the indexer, where old data is signature-validated as it is and then converted into the records the new indexer expects, while new data goes straight through. The original blobs stay in the store, so every signature remains verifiable forever.

The roadmap records two decisions the migration implements rather than questions it reopens.

Sub-document capability scoping as a product feature. Path-scoped and non-recursive capabilities are discontinued; invitations are to a space's home only, and a writer of a space is a writer of the whole space. The migration keeps an existing path-scoped WRITER as a write grant on that one migrated node, because the grant is harmless and the data exists, but the apps stop issuing anything but whole-space grants, and the roadmap's expectation that such grants are "trashed" in spirit holds: nobody should rely on them.

The no_recursive and is_exact flags. They were never implemented by the daemon and have no counterpart.

Two HM24 fields lose their meaning rather than being discarded: generation and genesisBlob on a Ref. The migration uses them to group the Refs of one path by life (each generation and genesis becomes its own node, sharing the name) and to order each life's Refs into a prev chain (by timestamp, then CID), and then forgets them, because node ids are never reused.

A migrated node's id is derived the same way a Stem id is: from the CID of a signed blob, here the earliest Ref blob of the path and genesis. There is no reserved namespace and no special creation rule; a migrated node is protected by the ordinary rule that updating an existing node needs write on it. Migrated nodes can be renamed, moved, granted on, tombstoned and redirected like any other node, and a rename changes their pretty path exactly as it would for a new node, which is the point.

A migrated node whose parent path never had a Ref (an "orphan" in the team's discussion) is placed under a derived parent node that the migration creates with a tombstone target and the parent's name, so the child keeps its pretty path and an admin can adopt it by publishing a Node blob for the derived parent with real state.

A Stem daemon accepts HM24 blobs for the length of the transition and converts them on the way in. A client that still publishes Refs, Capabilities, Comments, Profiles and Contacts therefore keeps working against a Stem daemon, with these effects:

A Ref it publishes for path P becomes a Node blob for the node whose pretty path is P, when the daemon can resolve one; if no node has that path, the Ref becomes a creating blob and its own CID is the new node's id. A Ref whose genesis differs from the node's starts a new node sharing the name, as a recreated document does today. Spaces that have adopted Stem clients should not be written to by HM24 clients.

A Capability it publishes becomes a grant as the table in the runtime model says.

A private Ref it publishes yields a node with access: own.

Reading is unaffected: the read APIs return documents, comments and profiles as before, with the node id added to every response.

A Stem client talking to an HM24 daemon does not work; the protocol id changes (see below) so the two never attempt to sync. The SDK and CLI gain Node and Grant emission behind a version switch; the Seed app follows.

Daemon with the migration box and the new protocol id. All derived tables are rebuilt by a reindex at upgrade. Sync between upgraded daemons uses the Stem RPCs; an upgraded daemon does not sync with an HM24 daemon. Sites upgrade first, then desktops, with the gateway's web app serving reads throughout.

Clients emit Stem blobs. The SDK, CLI, agents runtime and app switch to publishing Node, Grant, Revocation, Group and Snapshot blobs. Documents created from now on get ids derived from their creating Node blobs. Grants replace the capability flows in the app; the owner is prompted once per space to issue a sync grant to its declared site.

HM24 emission is disabled. Clients stop producing Refs and Capabilities. The daemon keeps accepting them for stored data and for any straggling client, and keeps converting them, indefinitely: there is no second migration.

Optional re-signing. A device of the owner may re-sign migrated derived records as real Node and Grant blobs so that a Stem-only peer can hold the space without the HM24 originals. This is an open item, below.

The protocol id moves from /hypermedia/0.9.x to /hypermedia/1.0. Exact-match negotiation, which today prevents daemon generations from syncing with each other, is what makes step 1 safe.