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.