메뉴
When to use deterministic server-side WebSocket signals instead of client-side heuristics for UI state transitions
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | deterministic-ws-signals |
| description | When to use deterministic server-side WebSocket signals instead of client-side heuristics for UI state transitions |
When the client needs to know about server-side state transitions (e.g., new sampling turn, new message bubble), always use a deterministic server-emitted WebSocket event rather than client-side heuristics (time gaps, content analysis).
The server knows exactly when state changes occur. Client-side heuristics — time-based gap detection, content-based analysis — are fragile and produce inconsistent behavior across different network conditions and workloads.
Emit a lightweight event (e.g., agent:response_start) synchronously before the async operation begins. WebSocket in-order delivery guarantees the event arrives before any data from the new state.
// Server-side: emit signal before starting new turn
ws.emit('agent:response_start', { agentId, turnId });
await agent.processNextTurn(); // data follows the signal
How the multi-backend adapter system works — AgentAdapter interface, ACP protocol, session resume, and how to add new provider adapters
When debugging why an agent has the wrong provider/model, or when modifying agent creation or delegation flows.
How to get agents to use group chats for peer coordination in flightdeck-based crews. Covers hub-and-spoke anti-pattern, auto-grouping triggers, and file-lock-linked groups. Use when setting up multi-agent crews with 3+ agents or diagnosing why agents aren't collaborating directly.
When fetching from the `/coordination/activity` API and you only need specific action types (e.g., `progress_update`, `task_completed`, `delegated`).
When fetching activity data for UI display, or debugging why activity-based features show empty/stale data.
Architecture decisions and patterns from Flightdeck development (Phases 2–4). Covers feature architecture, state management, component patterns, and API design.