feat(web): steer a queued message (SDK harnesses)

[serena-ruan]

Related issue

N/A

Summary

• Adds a per-row steer (send-now) button to the composer's "Queued" strip.
  Clicking it POSTs that message immediately instead of waiting for the idle
  flush. On an SDK harness the server live-injects it into the running turn (no
  interrupt — it folds in at the agent's next breakpoint); the optimistic bubble
  promotes on POST.
• It sends to the agent captured at enqueue time and can jump ahead of earlier
  queued messages (steer = "this one, now").
• Scoped to SDK harnesses. Native terminals buffer & drain rather than
  inject mid-turn, so the steer button is hidden there
  (isNativeTerminalSession) until that path lands — tracked in
  docs/QUEUE_STEER_DESIGN.md.
• Fourth step of the queue+steer design; native steer + reorder still to come.

Test Plan

• Unit (web, vitest): chatStore.test.ts covers steerMessage (sends the
  chosen message now, to its enqueue-time agent, out of FIFO order; no-op on a
  missing id). QueuedMessagesStrip.test.tsx covers the steer button appearing
  only when onSteer is provided and invoking it with the row's queueId. 255
  passing.
• Gates: npm run type-check, tests, prettier all pass.

Demo

Type of change

• Bug fix
• Feature
• UI / frontend change
• Refactor / chore
• Docs
• Test / CI
• Breaking change

Test coverage

• Unit tests added / updated
• Integration tests added / updated
• E2E tests added / updated
• Manual verification completed
• Existing tests cover this change
• Not applicable

Coverage notes

steerMessage and the strip's steer button (presence + queueId wiring) are
covered by unit tests; the mid-turn delivery reuses the server's existing
live-injection path (send() while streaming), already exercised elsewhere.

This pull request and its description were written by Isaac.

[omnigent-ci]

Polly AI Review

Review: feat(web): steer a queued message (SDK harnesses)

1. Blocking issues

None. The change is small, additive, and the core steerMessage reducer is correct: it resolves the agent (target.agentId ?? boundAgentId), no-ops safely when the id is missing or no agent is available, and removes the message from the queue before the async send() so a concurrent maybeFlushQueuedHead can't double-send it. The onSteer prop is optional and correctly gated off for native-terminal sessions.

2. Security vulnerabilities

None. No new network surface, auth boundary, deserialization, or injection path — steerMessage reuses the existing send() flow, which already handles the streaming/live-inject case. No dependency or lockfile changes.

3. Non-blocking notes

• Destination is the current conversation, not the message's captured one. steerMessage forwards the enqueue-time agentId, but send() pins its destination to get().conversationId (submitConversationId), not target.conversationId. In practice the strip filters rows to the active conversation (QueuedMessagesStrip messages={queuedMessages.filter(... === conversationId)}), so a steered row's conversationId always equals the current one and this is safe today. Still, steerMessage itself has no conversation guard, so a future non-UI caller passing a cross-conversation queueId would send that text into the wrong session. A cheap guard (skip/relocate when target.conversationId !== get().conversationId) would make the reducer robust independent of the caller. Worth a one-line comment at minimum.
• No failure feedback on the steer path. void s.send(...) fire-and-forgets; the message is already removed from the queue optimistically. If the POST fails, send()'s own catch rolls back the pending bubble and surfaces an error block, so the user isn't left silent — but the message is not returned to the queue, so a failed steer is lost from the strip. This matches the existing maybeFlushQueuedHead behavior, so it's consistent, not a regression; flagging only as an edge case.
• Test coverage is solid for what changed (out-of-FIFO send to enqueue-time agent, missing-id no-op, button presence gated on onSteer, queueId wiring). The mid-turn live-injection itself isn't covered here, but it reuses the already-exercised streaming send() path, as the description notes.
• Demo is a TODO placeholder. Per repo PR conventions this is a UI change, so a short clip is expected before merge — worth resolving the <!-- TODO --> in the description.

4. Summary

A clean, well-scoped fourth step in the queue+steer series. The reducer correctly captures the enqueue-time agent, removes-before-send to avoid a double-flush race, and cleanly gates the button off for native terminals. No correctness, contract, or security problems in the diff. The only substantive design note is that steerMessage relies on the UI filter rather than its own guard to keep steering within the active conversation — safe today, worth hardening. Approvable once the demo placeholder is addressed per repo PR conventions.

---

_{Automated review by Polly · workflow run}

[github-actions]

🏷️ Doc impact: needs-doc-update

Adds a user-facing "Steer" button to queued messages in the web chat UI (send-now mid-turn), a new interaction that changes how users manage the client-side message queue and should be reflected in web UI docs.

Drafting a docs PR to omnigent-ai/omnigent-site (staged on 0.5-docs until release)…

_{Auto-classified on merge. Set the label manually before merging to override. · run}