SESSION-2: handler mutation-propagation discipline

CHANGELOG.md

@@ -89,6 +89,19 @@ tool does not recognize the token and cannot expand the template.
   guarantees, session lifecycle, and the internal shape of `session`
   beyond `session_id` and `lang` are explicitly out of scope.
 
+## OVOS-SESSION-2 — Session Lifecycle and State Ownership
+
+### 1
+
+- The state-ownership model (stateless bus, stateless orchestrator for
+  named sessions, orchestrator-owned default session), the mutation
+  boundaries, `ovos.session.sync` (§2.7), client-side merge rules,
+  resumption semantics, and conformance.
+- §2.4 — a handler that emits no Message cannot propagate in-place
+  session mutations: the orchestrator-emitted handler-lifecycle trio
+  does not reflect handler-side changes, so a handler whose mutations
+  must appear in terminal events emits at least one Message
+  (`ovos.utterance.speak` or `ovos.session.sync`).
 ## OVOS-SESSION-1 — Session Carrier Wire Shape
 
 ### 1

session-2.md

@@ -255,7 +255,16 @@ happen only at these boundaries:
   plugin-bundled handler per PIPELINE-1 §7.0) MAY mutate
   session in-place; its emissions via `forward` / `reply` /
   `response` (OVOS-MSG-1 §5) carry the mutated session
-  forward.
+  forward. **A handler that emits no Message has no
+  bus-visible way to propagate its session mutations.** The
+  handler-lifecycle trio `.complete` (PIPELINE-1 §8) is
+  orchestrator-emitted from the dispatch context the
+  orchestrator holds — it does not reflect handler-side
+  in-place changes, particularly for handlers running
+  out-of-process. A handler that mutates session and needs
+  that state visible in terminal events MUST emit at least
+  one Message (typically `ovos.utterance.speak` or
+  `ovos.session.sync` per §2.7).
 
 **Session mutation discipline.** A handler SHOULD NOT mutate
 session fields unless the mutation is necessary for the