spec: OVOS-MSG-1 — deterministic reply source, unified unknown-key rule, decomposed-topic hygiene

CHANGELOG.md

@@ -220,6 +220,56 @@ version 2: its `{{ … }}` sequences become substitution points, and its
 
 ### 2
 
+- §5.2 — `reply` rewrites `source` to the identifier of the component
+  producing the reply, whatever shape the source Message's
+  `destination` had; a producer with no assigned identifier omits
+  `source` rather than copying one out of `context`, and an absent
+  `C.source` yields a broadcast reply. The array-`destination` branch
+  and its RECOMMENDED first-element choice are removed — a single
+  deterministic rule replaces them, and the addressed round-trips of
+  the converse, fallback, and common-query specifications depend on
+  it. §3.2 restated to match; §3.1 gains a worked ping/pong trace
+  showing why a poll response reaches the asker and not the
+  utterance emitter.
+- §4.1 — session propagation onto derived Messages raised from
+  SHOULD to MUST, matching how the dependent specifications already
+  treat it. The blanket no-mutation rule gains a narrow exception:
+  a component at one of the OVOS-SESSION-2 §2.6 boundaries MAY
+  mutate the session fields it owns; unowned fields are carried
+  through unchanged.
+- §2, §2.3 — one unknown-key rule for the whole envelope: unknown
+  top-level keys and unowned `context` keys MUST be ignored and MUST
+  NOT cause rejection. A `context` key's owning specification MAY
+  still prescribe rejection for a malformed value of its own key
+  (OVOS-SESSION-1 §2.5). Malformedness is scoped to parse failures
+  and wrong value types on defined keys.
+- §6.1 (new) — "treat as malformed" defined once: drop, do not act,
+  do not coerce, do not crash or tear down the transport, SHOULD log,
+  and no error reply unless the topic's specification prescribes one.
+- §2.1.1 — separator hygiene binds only **decomposed** topic shapes,
+  whose components a consumer splits back out. Shapes **assembled**
+  for exact subscription are exempt, so a `skill_id` containing a dot
+  is conformant in `<skill_id>.converse.ping`. A topic-defining
+  specification states which of the two its shape is; absent a
+  statement, decomposed. A dispatch topic MUST contain exactly one
+  `:` and is definable only by a specification in this family;
+  component-owned contracts are dotted-only.
+- §3.4 — routing keys are not credentials: a producer MUST NOT claim
+  an unassigned identifier, a trust-domain ingress MUST overwrite
+  `source` with the identifier it assigned the peer, and no consumer
+  derives an authorization decision from the routing pair. Adds the
+  layer-2 and assistant-core definitions, per-member equality for an
+  array `destination`, and the empty-string rule.
+- §5.3 — the `response` shorthand defined only where the topic
+  arithmetic is unambiguous (`T` neither ending in `.response` nor
+  containing a `:`); askers do not assume `<request>.response` unless
+  the defining specification says so.
+- §5.4 — correlation guidance points at echoing a discriminating
+  field from the request (OVOS-COMMON-QUERY-1 §6.4, the `query_id`);
+  topic plus session does not separate parallel requests.
+- §2.1 — topic syntax forbids empty segments and leading or trailing
+  separators. §3.1 walkthrough names derivations in prose. §7
+  conformance resynchronised throughout.
 - §2.1.1 — the topic convention made the single authoritative rule
   every topic-defining specification inherits: a `:` in a topic marks
   a **dispatch-shaped** topic assembled from identifiers (canonical