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
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
session.converse_handlers(recency-ordered list of active handler{skill_id, activated_at}) andsession.response_mode(single{skill_id, expires_at}entry when a handler holds the next utterance)response_modefirst, then pollsconverse_handlersvia unicast ping/pong (<skill_id>.converse.ping/<skill_id>.converse.pong)<skill_id>:responsedispatch (reserved intent name)<skill_id>:converseand<skill_id>:responseare standard dispatches on reserved intent names — no special routingPR
PR #25