Module protocol 

Wire format (ServerMsg / ClientMsg) for WS /v1/operators/:sid/ws. Wire format (= S↔C JSON message schema) for WS /v1/operators/:sid/ws.

ServerMsg = 4 messages the server pushes to the client (Ask / HookBefore / HookAfter / Spawn). ClientMsg = 4 messages the client replies with (Answer / HookAck / SpawnAck / SpawnHalt).

Layer 2 audit (issue #7): halt vs error separation across verbs

spawn_halt was added to disambiguate a controlled halt from a real worker error on the spawn_ack axis. The other client verbs were audited for the same shape:

• answer (SeniorBridge.ask reply): carries value only — no ok / failure axis exists. A “halt during a question” would already be expressible by replying with a value that the middleware treats as an abort signal (e.g. null or a domain-specific sentinel). No sibling answer_halt is added.
• hook_ack (SpawnHook.before OK/NG): ok = false here is a genuine gate rejection — that is the entire purpose of the hook, not a mix-signal. There is no confusion to fix; no hook_halt is added.
• spawn_ack: the subject of layer 1. spawn_halt handles it. For the parent module’s message-flow figure, see the doc of mod.rs.

PendingReply is the intermediate representation delivered over the internal oneshot reply channel, used to resolve a ClientMsg (arriving from a client) against the session’s pending HashMap keyed by req_id. See session::WSOperatorSession::resolve_pending for details.

Enums

ClientMsg

Client → server reply messages on WS /v1/operators/:sid/ws. Each variant resolves the pending oneshot registered under its req_id (see super::session::WSOperatorSession::resolve_pending).

ServerMsg

Server → client push messages on WS /v1/operators/:sid/ws. Each variant pairs with a ClientMsg reply carrying the same req_id (except HookAfter, which is fire-and-forget).