Engine room: first-time setup

Every node has room for exactly one engine room: a locked-down agent endpoint that is the node’s governance surface — the one place its access posture (which machines and agents may reach what) gets set. It is an ordinary hosted agent in substrate, and an extraordinary one in lifecycle: it comes online only for a human who proves a subnet code, and it is never reachable the way other endpoints are.

Setting one up is three steps: ceremony → bring-up → briefing.

1. The ceremony — bind an anchor subnet and an adapter

spt endpoint engine-room <subnet> --adapter <adapter-id>

This creates the engine-room record (or resets an existing one), binding the two facts nothing else can change: its anchor subnet (whose codes will gate bring-up) and its harness adapter (the agent runtime that hosts its mind).

• The subnet must already be joined on this node, and the adapter registered (spt adapter list) — the ceremony refuses otherwise, because an engine room bound to material it cannot verify or run would only fail later.
• Creating a first record needs no elevation — run the ceremony early in a node’s life; the unelevated window closes permanently at the first run.
• Resetting an existing record must run in an elevated shell (it rebinds a live governance surface).
• Neither form can be run by a hosted agent. The ceremony refuses when it detects one — this is a surface reserved for the human at the machine.

2. Bring-up — attach with a subnet code

spt rc engine-room

A bare attach opens an interactive prompt for the anchor subnet’s current six-digit code — either the member code or the admin code is accepted (read it from your authenticator app), though which of the two you use decides one further thing, below. The prompt names the node whose engine room is coming up and the subnet whose code answers it, so an operator holding codes for several subnets can see which one to reach for. Esc cancels. --code <CODE> passes it directly, with one caveat: a code typed on the command line is readable by other processes on the machine while it is still valid, so prefer the prompt.

Wrong codes are counted against a persistent, exponentially backing-off ledger, and repeated failures raise a notification — the gate cannot be quietly brute-forced.

Bringing up with the admin code empowers the seat

Which of the two codes you use decides one further thing. Pass the admin code and the seat is empowered for the engine room’s anchor subnet the moment it is taken — you can set that subnet’s control-surface modes (spt api access-refresh <anchor-subnet> engine-room) without proving the same admin code a second time through spt api empower. Pass the member code and nothing is granted: the room comes up exactly as it always did.

This is not a new authority. It is the same credential, proved once instead of twice — the admin key you just typed at the gate is the admin key empower would have asked you for.

• Scope: the anchor subnet only. Any other subnet still needs an explicit spt api empower <subnet> engine-room --admin-code <CODE>. Bringing the room up never grants authority over a subnet it is not anchored in.
• Lifetime: identical to an explicit empower. It lasts until the session ends or the controller detaches; detaching drops it, and re-attaching re-proves it. There is nothing extra to revoke.
• Attach or take, same gate, same grant. A local --take passes the same code gate the incumbent did, so it earns the same empowerment.
• It is never silent, and it is never early. The grant is written when the seat is actually taken — the bring-up first says only that the room is up, and the sentence about holding its controls (with the grant) follows once your attach is established. An empowered seat that said nothing would be indistinguishable from an ordinary one until a mode change unexpectedly succeeded; a seat that announced a grant before anyone was at the controls would be worse, because that sentence would sometimes be false.

Bring-up fails closed if the bound adapter is missing: an engine room that cannot host its own mind does not come online half-formed.

3. The briefing — what you are holding

The moment a controller is seated — not a moment earlier — the engine room’s session receives a system-authored briefing message: what the engine room can do, what it is answerable for, the node’s exact current access posture, any pending subnet-mode declarations, and the full ruleset table.

If the bring-up that admitted you proved the admin code, the briefing opens by saying so — the grant is stated before the capability list, because it changes what that list means for this seat: access-refresh is spendable here without an empower first, and a reader who met that fact after the menu would already have decided it needed a code it does not need. An ordinary bring-up says nothing at that point, which is the absence itself rather than a reassurance. Both surfaces — the attach line and this briefing — state the grant in one shared sentence, so they cannot drift into two accounts of one fact.

While your terminal is attached the engine room is online; detaching drops its access posture (inbound refused, every empowerment revoked, no longer advertised) while the hosted session keeps running for the next attach. A local take-over of the controls passes the same code gate the incumbent did, and is loud.

What the engine room refuses, always

• Remote attach, from any node.
• Read-only viewing (--view), even locally.
• All inbound messages except replies to its own outbound, and knocks, which land in its inbox and wait there whether or not it is online.
• Deletion: purging it resets the record instead (elevated shells only) — a node can never be left without a way back to a governance surface.