feat(transport): transport SSOT phase 1 — server-authoritative state

[dimakis]

Summary

• Transport SSOT Phase 1: client reads running state exclusively from server session_state_changed events
• Replaces SET_RUNNING action with SESSION_STATE_CHANGED — running derived from state === 'running'
• Removes syncRunningState() REST polling (state events make it unnecessary)
• Removes running field from reconnected and session_switched server messages
• Migrates server-side is_active readers to use state column (handleReconnect, connection-registry, query-loop)
• Net -360 lines — more dead code removed than new code added

Dead code removed

• SET_RUNNING action type and reducer case
• syncRunningState() function and runningSyncInFlight flag
• running field in reconnected summaries and session_switched messages
• markSessionInactive() call in query-loop (redundant with setSessionState)
• SET_RUNNING dispatches from 8 protocol parser handlers

Context

Design doc: PR #430 (design/transport-ssot branch)
Depends on: PR #431 (P0 foundation)
Telos: 97361f814c5f54df

Test plan

• 351 tests pass across modified test files (protocol-parser, store, ws-handler-v2, event-store, connection-registry)
• TypeScript build passes (no new errors, only pre-existing worktree symlink issues)
• Centaur review
• Verify running state syncs correctly on phone + laptop (reconnect, session switch, foreground return)
• Verify stop button works (handleStop dispatches SESSION_STATE_CHANGED)

🤖 Generated with Claude Code

[dimakis]

Centaur Review

Found 7 issue(s) (1 critical) (4 warning).

server/ws-handler-v2.ts

The migration from SET_RUNNING to SESSION_STATE_CHANGED is well-structured but has a critical gap: handleSwitchSession removes the running field without adding event replay, leaving clients unable to determine session state for 0–5 seconds after switching sessions.

• 🔴 regressions (L407): handleSwitchSession no longer sends running state, but also does not replay events. The client depends on session_state_changed events for running state, yet switch_session only sends metadata — no event replay occurs. The periodic sync (5s interval) is the only fallback, leaving a 0–5s window where the client has no idea if the target session is running. Reconnect correctly replays events; switch should too, or retain running in the response until event replay is added. [fixable]

frontend/src/pages/ChatView.tsx

The migration from SET_RUNNING to SESSION_STATE_CHANGED is well-structured but has a critical gap: handleSwitchSession removes the running field without adding event replay, leaving clients unable to determine session state for 0–5 seconds after switching sessions.

• 🟡 regressions (L188): handleStop dispatches { type: 'SESSION_STATE_CHANGED', state: 'idle' } client-side — an optimistic update that contradicts the PR's stated goal of server-authoritative state. If the server doesn't honor the stop (e.g., query already completing), the client is wrong until the next server event. The old SET_RUNNING was equally optimistic, so this isn't a new bug, but it should be documented or replaced with server-only state flow in P2. [fixable]

packages/client/src/store.ts

The migration from SET_RUNNING to SESSION_STATE_CHANGED is well-structured but has a critical gap: handleSwitchSession removes the running field without adding event replay, leaving clients unable to determine session state for 0–5 seconds after switching sessions.

• 🟡 regressions (L704): Foreground recovery (_foreground handler) removed syncRunningState() without a replacement. If the app is backgrounded while a session ends, the session_state_changed event may be lost (WS was disconnected). The client returns to foreground with stale running: true and no polling to correct it. The periodic sync may eventually deliver the event, but there's a meaningful gap. [fixable]
• 🟡 regressions (L361): Pending send timer no longer sets running: true before sending a queued message. When session_end fires with pending messages, the UI briefly shows idle (running=false from session_end) then flips to running once the server echoes session_state_changed. This creates a visible flash/stutter between turns. The old optimistic SET_RUNNING avoided this. [fixable]

packages/client/__tests__/protocol-parser.test.ts

The migration from SET_RUNNING to SESSION_STATE_CHANGED is well-structured but has a critical gap: handleSwitchSession removes the running field without adding event replay, leaving clients unable to determine session state for 0–5 seconds after switching sessions.

• 🟡 missing_tests (L268): No test verifies the new session_state_changed → SESSION_STATE_CHANGED dispatch in the protocol parser. The test for the session_state_changed case was presumably in the P0 PR, but this PR changes its behavior from no-op to dispatching an action — that new behavior should have a dedicated test here. [fixable]
• 🔵 style (L624): The reconnected test section was reduced from 6 tests to 1, removing validation for edge cases (no currentSessionId, undefined sessions, invalid shapes). While reconnected no longer dispatches SET_RUNNING, the handler still calls onReconnected() — the defensive validation tests for malformed sessions payloads had standalone value and didn't depend on SET_RUNNING. [fixable]

server/query-loop.ts

The migration from SET_RUNNING to SESSION_STATE_CHANGED is well-structured but has a critical gap: handleSwitchSession removes the running field without adding event replay, leaving clients unable to determine session state for 0–5 seconds after switching sessions.

• 🔵 bugs (L1400): Removed markSessionInactive() call, relying on setSessionState('ENDED', ...) which internally syncs is_active = 0. This is correct — the markSessionInactive method on EventStore is now dead code in production (only called from tests). Consider removing the method to avoid confusion, or leave for P2 cleanup. [fixable]