02: Control plane (WS connect/events/calls)

Control UI and CLI primarily talk to the Gateway via WebSocket. Thinking in three primitives makes debugging much faster:

1. connect: handshake + auth
2. event: continuous event stream
3. call: method invocation (often quick ACK; results stream via events)

1) connect: why the first frame matters

Key takeaways:

• the first frame establishes identity and auth context
• pairing/remote boundaries determine who can connect and what methods are allowed

See:

• Gateway protocol
• Security
• Pairing

2) event: why replies stream

A common pattern: chat.send returns a runId quickly, while the actual reply arrives as streamed events.

Benefits:

• streaming fits multi-client UIs naturally
• long tasks can report progress, tool calls, and errors over time
• retries/failover remain traceable under the same runId semantics

See:

• Control UI
• Streaming

3) call: how to make a minimal repro

When you suspect an issue at the “method call” layer:

• reproduce via CLI on the same WS path (reduce UI variables)
• keep inputs fixed and follow one runId through the event sequence

See:

• CLI: gateway
• Logging