Step 3: Read-only Overseer wired to voice

[heavygee]

Goal

Stand up the Overseer as a real conversational entity with its own hub session-equivalent, give it a read-only tool set over the events/inbox substrate, route a dedicated voice surface to it, and write convo turns back into the events table. It can inform, not yet dispatch.

Spec

• docs/plans/2026-06-03-overseer-build-sequence.md Step 3 (primary), incl. the read-only tool set table
• docs/plans/2026-06-03-overseer-contracts.md §2 (worker state model + the three views), §11 (provenance for Overseer speech), §1 (convo_turn event)
• docs/plans/2026-06-03-overseer-framing.md "chief of staff not JARVIS" (persona), "The decision channel"
• docs/plans/2026-06-03-overseer-prioritization.md §9 (attention budget modes)

Acceptance

• Overseer is a real conversational entity with its own session-equivalent in the hub.
• Read-only tool set available (all read-only; no dispatch, confirm, or state mutation): query_events, query_inbox, get_session_state, get_session_recent_output, get_worker_health, explain_priority, list_active_workers.
• Voice entry reuses the existing voice-entry affordance where practical but routes to the Overseer on a dedicated Overseer surface (distinct from per-session voice). Chrome-level relocation is deferred to Step 5 (Step 5: Chrome-button move + per-session button retirement #27).
• Voice convos with the Overseer written into the events table as event_type = convo_turn.
• get_worker_health distinguishes worker_reported_state / hub_observed_state / overseer_inferred_state (contracts §2) so "are you sure?" surfaces the underlying signals.

Out of scope

• Any dispatch, confirm, or state mutation — that is Step 4 (Step 4: Disagreement-capable Overseer + voice dispatch with confirm #26).
• Chrome-button relocation + per-session button retirement — Step 5 (Step 5: Chrome-button move + per-session button retirement #27).
• Standing-order autonomy (Stage 2, post-MVP).

Dependencies

• Blocks: Step 4: Disagreement-capable Overseer + voice dispatch with confirm #26 (dispatch builds on reliable read-only visibility)
• Blocked by: Step 2.5: Inbox substrate + dumb v1 ordering + operator-action logging #23 (inbox to query), Step 2.75: Replay harness v0 + CI gate #24 (Steps 3-4 ship behind the harness)
• Part of: Fleet Overseer architecture — umbrella #19

Suggested PR breakdown

2-3 PRs: Overseer entity + session-equivalent; read-only tool set; voice route + convo_turn writeback.

Risks

• The persona is harder than the plumbing. Chief-of-staff authority, knows-when-to-push-back, never sycophantic, never robotic — treat persona as a distinct workstream with its own iteration cycle, not a footnote.
• The disagreement protocol is a persona+capability problem entangled together. Gate Step 4 (Step 4: Disagreement-capable Overseer + voice dispatch with confirm #26) until this step has demonstrated reliable visibility into worker state; otherwise pushbacks will be wrong and the operator learns to dismiss them.
• Failure modes to avoid by design: "Slack with a posh accent", "Narrating log file".

Implementer note: defer-and-split

This issue is an umbrella covering 2-3 PRs (see suggested breakdown above). Before writing code, file sub-issues here for each PR you intend to open, then close those sub-issues as their PRs merge. This keeps issue-to-PR mapping 1:1 for cleaner upstream-friendly review, and lets the slicing reflect what you discover in the code rather than the architecture-time guess. Reference this issue as Part of: #25 on each sub-issue.