Spec proposal: OVOS-CONVERSE-1 — Active Handlers and Interactive Response

Proposal for OVOS-CONVERSE-1, the imperative continuous-dialog specification.

Problem

OVOS has active-handler tracking and response-mode mechanics but no normative contract. session.active_handlers, session.response_mode, the converse plugin's poll, and the response-mode delivery path are all implementation-defined.

Proposal

• Two session fields: session.converse_handlers (recency-ordered list of active handler {skill_id, activated_at}) and session.response_mode (single {skill_id, expires_at} entry when a handler holds the next utterance)
• Converse plugin is a pure matcher (PIPELINE-1 §7.0): checks response_mode first, then polls converse_handlers via unicast ping/pong (<skill_id>.converse.ping / <skill_id>.converse.pong)
• Response mode is session-resident: entered/left via in-handler session mutation; delivered via <skill_id>:response dispatch (reserved intent name)
• Ordinary PIPELINE-1 dispatches: <skill_id>:converse and <skill_id>:response are standard dispatches on reserved intent names — no special routing

PR

PR #25

Start by reviewing PR #25 alongside the OVOS-CONVERSE-1 proposal and its definitions of converse_handlers, response_mode, polling, and reserved dispatches. Done means the specification establishes a normative contract for active-handler tracking, response-mode delivery, and ordinary PIPELINE-1 dispatches.