Spec questions from messagebus model coverage (PIPELINE-1 / STOP-1)

[JarbasAl]

Raised while adding validated pydantic models for the spec-defined messages (ovos-pydantic-models#6):

1. PIPELINE-1 §8 — the handler-lifecycle messages (ovos.intent.handler.start/complete/error) lack a canonical payload schema (unlike §9.1/§9.2/§9.6). Models currently infer skill_id + intent_name (+ optional pipeline_id) from the §7.1 dispatch shape. Should §8 define the payload normatively?
2. STOP-1 §4.2 — ovos.stop.pong payload: is a skill_id field expected for disambiguation on the shared reply topic, or is session propagation via reply() considered sufficient? (Modeled as Optional pending verification against ovos-stop-pipeline-plugin.)
3. PIPELINE-1 §9.6 — ovos.utterance.speak vs the legacy speak TTS dispatch are distinct layers; consider a spec note clarifying the relationship for consumers.

[JarbasAl]

Additional spec questions from SESSION-1 / SESSION-2 / BRIDGE-1 / AUDIO-IN-1 coverage pass (ovos-pydantic-models#6 continued):

4. SESSION-1 §3 / implementation gap — the in-code Session carries active_skills (list of (skill_id, timestamp) tuples) and utterance_states (dict skill_id → "intent"|"response") which pre-date the spec. SESSION-1 §3 registers active_handlers (array of object {skill_id, activated_at, …}) and CONVERSE-1 §2.2 owns response_mode. Are active_skills / utterance_states deprecated in favour of the spec fields, or are they distinct tracking structures that should both survive on the wire? Models carry both for round-trip fidelity until the spec clarifies.

5. SESSION-2 §2.7 ovos.session.sync — the spec says the updated snapshot travels in Message.data.session. The current ovos-core implementation fires ovos.session.update_default (data is the session object directly, not {session: …}). Is ovos.session.sync a different topic (explicit out-of-utterance push by a component) versus ovos.session.update_default (orchestrator broadcast)? If so, both should be normalised; currently update_default uses the flat-data form and sync uses the spec {session: …} shape.

6. BRIDGE-1 §4.2 layer-2 policy injection — the spec says a Layer-2 system SHOULD inject blacklisted_skills into session at the bridge boundary. SESSION-1 §3 now also registers blacklisted_pipelines and per-transformer blacklists. Should BRIDGE-1 explicitly list which blacklist fields a bridge is normatively permitted to inject, or is any SESSION-1 §3 blacklist field fair game?

7. AUDIO-IN-1 §5.1 stt_lang write obligation — the spec says the audio input service SHOULD write session.stt_lang before STT invocation. Does this mutation happen via a transformer boundary (TRANSFORM-1 §3.1) or is it an in-place pre-transformer mutation outside the §2.6 boundaries? If it is pre-transformer, SESSION-2 §2.6's mutation discipline rule does not apply, but it is also not described as a transformer hook.

[JarbasAl]

🤖 Auto-generated by Claude Fable 5.1 (claude-fable-5-1) via Claude Code — NOT human-reviewed. Verify before acting. Each answer quotes the clause at dev d9169ee; nothing here was run.

Answers against the specs as they stand.

1. PIPELINE-1 §8 payload. Defined since: §8.2 "Payload" fixes skill_id (required), intent_name (required) and exception (error only) for all three lifecycle events. No pipeline_id field; the dispatching pipeline travels in context.pipeline_id per §7.1 stamping.
2. STOP-1 §4.2 pong. skill_id is required: "The pong payload is the PIPELINE-1 §4.5 shape [...] { "skill_id": "example.skill", "can_handle": true }", verified against the round's candidate set. Session propagation is not a substitute.
3. ovos.utterance.speak vs legacy speak. ovos-spec-tools already maps speak → ovos.utterance.speak (messages.py, PIPELINE-1 §9.6). appendix/divergences.md §5.7 has no row for it; PR docs: catalogue the legacy speak topic and session views; stt_lang write is source composition #254 adds one.
4. active_skills / utterance_states. Superseded. SESSION-1 §3 registers active_handlers (PIPELINE-1 §7.1) and response_mode (CONVERSE-1 §2.2) and no other field for either purpose; ovos-bus-client already exposes Session.utterance_states as a deprecated legacy view of response_mode (session.py). Models need not carry them; docs: catalogue the legacy speak topic and session views; stt_lang write is source composition #254 records the pair in the divergences catalogue.
5. ovos.session.sync / update_default. Both retired: SESSION-2 §2.7 is "Convergence without push" and §5.7 lists both topics as "retire — no spec defines a session push topic". Nothing to normalise.
6. BRIDGE-1 injection set. §4.1.1: "A layer-2 system MAY populate any of the blacklisted_* arrays catalogued in OVOS-SESSION-1 §3", then enumerates the three PIPELINE-1 §5 denylists and the six TRANSFORM-1 §5.2 ones. Any registered blacklisted_* field is fair game.
7. stt_lang write. The audio input service is the lifecycle source: it assigns the session (§5.2) and composes the entry Message, so writing session.stt_lang before STT builds the Message rather than mutating a session carried on an inbound one. SESSION-2 §2.6 governs mutation "during an utterance lifecycle" and MSG-1 §4.1 forbids modifying a session "present on the source Message"; neither applies before the lifecycle exists. docs: catalogue the legacy speak topic and session views; stt_lang write is source composition #254 adds that sentence to AUDIO-IN-1 §5.1 so the answer is in the text.