Build the /chat console that drives the Ox Alpha stress fleet #55

Project

Stress testing Ox Alpha

Priority

This issue is the active first slice. Build and verify it locally before you push it to main. Do not make the first implementation depend on computer fan-out, the provider overflow router, or the Sarah conversation state.

Context

Issue #36 shipped an operator-gated /chat placeholder. Replace that placeholder with an independent Ox Alpha chat console. Sarah remains at /sarah; reuse its shared components and proven interaction patterns, but do not copy its large LiveView or share Sarah-specific state, voice, persona, work queue, or tool routing.

The shared component library already includes the full AI Elements surface. Compose the new page from those modules instead of introducing a second chat component system.

Implementation order

1. Local conversation slice

• Keep /chat behind the existing operator gate.
• Create a small, independent LiveView and conversation domain boundary for Ox Alpha.
• Render the transcript with OpenAgentsWeb.AI.Conversation: conversation, conversation_content, message, message_content, message actions, suggestions, shimmer, and the return-to-newest control.
• Render the composer with OpenAgentsWeb.AI.PromptInput: prompt_input, prompt_input_textarea, toolbar, submit, and queue primitives only where the behavior exists.
• Render model reasoning with OpenAgentsWeb.AI.Reasoning.reasoning; reserve chain-of-thought steps, tools, tasks, plans, and checkpoints for structured events that the backend actually emits. Never fabricate reasoning or progress.
• Give the empty state useful Ox Alpha prompt suggestions and state clearly that the console is operator-only.
• Use one fixed model label, Ox Alpha, and the provider slug stealth/ox-alpha. Do not add a general model picker.

2. OpenRouter streaming

• Add a server-side, OpenAI-compatible provider adapter for OpenRouter. Never expose provider keys to the browser.
• Stream assistant text and available reasoning events into the independent transcript.
• Support cancellation and prevent a stale stream from writing into a newer turn.
• Show explicit retryable states for 429, 503, transport interruption, and malformed provider events. Preserve the user prompt when a request fails.
• Record the provider lane, latency, request identifiers, and usage returned by the provider. Do not guess at missing usage fields.

3. Usage and provider evidence

• Use OpenAgentsWeb.AI.Evidence.context for context-window and token usage when the provider reports it.
• Show input, output, reasoning, and cached-token counts separately when available.
• Show which provider lane served the response and its latency.
• Keep aggregate fleet throughput out of the initial message composer; add it only after the measurements in #40 and the router in #56 provide trustworthy data.

4. Dispatch integration

After the single-chat slice works, add a per-message or per-conversation action that creates a durable dispatch receipt and hands the context to the orchestrator in #41. The UI must show admission, runtime, checkpoint, completion, and failure states from the cloud-computer contract instead of optimistic placeholders.

Local acceptance criteria

• /chat opens as an operator-only page with no Sarah conversation data.
• A text prompt streams a real Ox Alpha response from OpenRouter through the server.
• Reasoning appears only when the provider returns a supported reasoning event.
• The operator can stop an active response.
• 429, 503, transport interruption, and malformed stream failures produce accessible, retryable error states without losing the prompt.
• Transcript pinning, keyboard submission, focus, reduced motion, light and dark palettes, narrow layouts, and long code blocks work.
• The browser console has no errors.
• LiveView tests cover empty, streaming, completed, cancelled, and failed states by stable DOM IDs. Provider tests use captured fixtures and do not call a live provider.
• mix precommit passes before any push.

Later acceptance criteria

• Usage and lane attribution are visible when supplied by the provider.
• A dispatch creates a durable run receipt and links to its cloud-computer state.
• The console can display multiple concurrent runs without conflating their messages or receipts.

Non-goals for the first slice

• No multi-tenant chat.
• No voice mode.
• No general model picker.
• No computer fan-out.
• No provider failover.
• No reuse of Sarah-specific conversation state or its full ChatLive implementation.