INSTANCE-AXES grill — Round 3

Code facts read at main d3c90499. Answers save in this browser; "Copy answers" gives Markdown to paste back.

Recorded from Round 2

R2-1 (a), shells follow active, with your correction: a suspended instance is never active, so nothing is "spooled to the active instance while it is suspended". A shell never messages a non-active instance. When no owner instance is active, the shell's outbound payload spools until an active owner instance comes online or is detected.
R2-2 goes one step further: #346 moves the trust warning into now-signal.
R2-3 a same-id message never steals active. R2-4 the busy report with a USER_INPUT payload is the user-input trigger. R2-5 the auto-suspend CLI + docs go into request A, and the release note says auto-suspend turns on fleet-wide.

Round 3

R3-1Active can now be VACANT. What fills it?

Your R2-1 correction makes this an invariant: active ⇒ warm and online. Suspend is manual today (CONTEXT.md: "a subcommand can suspend an endpoint from anywhere"), so it can hit the active instance. A crash or node-down can take the active instance offline. Either way the owner can have no active instance while dormant siblings are up, and your shell rule makes that window visible: shell traffic spools for as long as it lasts.

Round 1 applied the "no active sibling ⇒ take active" rule (Q4) at boot only. Q1(a) says attaching a suspended instance lands it dormant. If active is vacant, a woken instance would still land dormant and the spool would keep waiting.

Two choices:

(a) No auto-pass. Vacating active never promotes a dormant sibling. The "no active sibling ⇒ take active" rule fires at every transition into warm (boot, wake, attach), not only at boot. Otherwise active stays vacant until a trigger (user input, spt wake, a stealing message, a handoff).
(b) Auto-pass. Vacating active immediately promotes an online dormant sibling (which one needs a tie-break rule).

Recommended: (a). Active keeps meaning "where the attention is". (b) hands shell traffic and stealing-class messages to an instance nobody is driving, which is exactly what the split exists to prevent. Q1(a) is amended only for the vacant case: an attach during a vacancy takes active.

Your answer

R3-2The shell outbound spool: where does it live, and what goes in it?

Today the only spool is at the receiver's perch: a send to an offline perch spools there. That cannot serve your rule, because with no active instance the shell does not know which instance, or which node, will be the receiver. Sensory today is never spooled and never leaves the node.

Recommended:

The spool lives on the shell's own node, sender side.
Every shell→owner kind spools, sensory included, in send order, under the existing spool bounds (no new cap).
It drains when an active claim for the owner becomes visible to the shell's node. The claim is announced subnet-wide as an edge transition, and the drain goes to that instance, local or remote.
A payload that never drains is covered by the existing bounds. The spool adds no TTL.

Your answer

R3-3Which request carries shell routing?

R2-1(a) is a real new leg: cross-node shell→owner routing, cross-node sensory, and the sender-side spool from R3-2. It consumes the #345 resolver ("which instance is active").

(a) New request C, ordered after #345 and parallel to B: A → #345 → {B, C}.
(b) Fold it into B (handoff + dormant restriction). B is already the request that decides who may talk.

Recommended: (a). It is the largest leg in the milestone and has its own two-host acceptance (shell on node A, active on node B). Separating it lets B land without waiting on it.

Your answer

R3-4#346: trust warning → now-signal. Scope and shape

What the warning rides today (releases#170, ruled 2026-08-19): mostly a trust-warning attribute on the delivered message's own envelope. It reaches the agent in one arrival, and the adapter must surface it ("for this attribute, being ignored is the failure"). The standalone system-authored delivery (wan.rs:1073) is only the fail-safe for bodies that are already typed envelopes, and that fail-safe is the frame R2-2 was about.

#346 retires both carriers. The R2-2 question disappears: there is no trust-warning frame left to classify. It does reverse #170's carrier ruling, so the new shape needs stating:

Recommended:

#346 joins INSTANCE-AXES. It is independent of A/#345/B/C and can run in parallel. It is BACKLOG today, so taking it in is your greenlight.
A new now-signal category, TRUST_WARNINGS. Each entry names the sender and the msg-id it concerns, because it no longer arrives attached to that message.
The cadence and override rules are unchanged. The cadence "delivered" claim moves to render time: the first now-signal poll that shows the entry.
It surfaces on the session(s) of the instance that received the message. Under Q2 that is the instance the message just made active.
The envelope attribute and the fail-safe delivery are both removed in the same release. The receiver-composed class-strip stays for mnemonics-json, and it also keeps stripping an inbound trust-warning so an old sender cannot plant one. Public envelope docs + the adapter note (perri, emphasys) say the attribute is gone.
Trade-off, stated plainly: an adapter that does not poll now-signal would never show the warning. Now-signal polling is already required by the adapter contract, so this is the same obligation #170 placed on the attribute, moved to a surface adapters already handle generically.

Your answer

+Anything else

Once these are answered I run /domain-modeling to amend CONTEXT.md, mint A, B (and C if R3-3a) via alchemy, link #345 and #346, and create the INSTANCE-AXES milestone.

Notes for doyle