Skip to content

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

Open
JarbasAl wants to merge 1 commit into
devfrom
spec/msg-1-audit
Open

spec: OVOS-MSG-1 — deterministic reply source, unified unknown-key rule, decomposed-topic hygiene#137
JarbasAl wants to merge 1 commit into
devfrom
spec/msg-1-audit

Conversation

@JarbasAl

@JarbasAl JarbasAl commented Aug 4, 2026

Copy link
Copy Markdown
Member

🤖 Auto-generated by Claude Fable 5 (claude-fable-5) via Claude Code — NOT human-reviewed. Verify before acting. Cross-spec citations were model-verified against dev source; behavior-change sections need owner judgment.

Audit fixes for OVOS-MSG-1. Within-class refinement of Version 2 — no version bump. Only msg-1.md and CHANGELOG.md are touched.

Blockers

  • §5.2 reply source is now deterministic. The reply derivation sets source to the identifier of the component producing the reply, whatever shape the source Message's destination had. No assigned identifier means source is omitted, never copied out of context; an absent C.source yields a broadcast reply. Previously a reply copied C.destination forward, so a poll response was addressed to the original utterance emitter instead of the component that asked — on a bridged deployment the bridge relayed the internal poll response out to the satellite. This is the load-bearing change the poll-family specs cite: the converse and fallback ping/pong round-trips, the common-query contest, and the PIPELINE-1 §7.1 dispatch claim (source is the orchestrator) are all unsatisfiable under the old rule.
  • §5.2 array branch deleted. It asserted the producer's own identifier and a RECOMMENDED first element in the same breath, then annulled both as implementation-defined. The single rule above subsumes it.
  • §2.3 vs OVOS-SESSION-1 §2.5 reconciled. Unknown/unowned context keys MUST be ignored and MUST NOT cause rejection; a key's owning specification MAY prescribe rejection for a malformed value of its own key. That is what SESSION-1 §2.5 does for a non-object session carrier.
  • §2 unknown top-level keys unified. §2 said SHOULD-malformed / MAY-ignore while §6 said MUST-malformed. Now: MUST ignore, MUST NOT reject on that ground alone; malformedness is scoped to parse failures and wrong value types on defined keys. §7 resynchronised.
  • §2.1.1 separator hygiene scoped to decomposed shapes. The old blanket rule outlawed deployed dotted identifiers (a skill_id such as wiki.test in wiki.test.converse.ping), and CONVERSE-1 §4.2 cites MSG-1 for the opposite conclusion. Hygiene now binds only shapes a consumer splits back into identifiers; shapes assembled for exact subscription are exempt. A topic-defining spec states which it is; absent a statement, decomposed.

Major

  • §4.1 session propagation raised SHOULD → MUST (every dependent spec already treats it as MUST), with a narrow exception: a component at an OVOS-SESSION-2 §2.6 boundary MAY mutate the session fields it owns; unowned fields are carried unchanged. This unblocks the transformer, pipeline, and handler paths plus the PIPELINE-1 §7.1 active_handlers push, which the old blanket prohibition forbade.
  • §6.1 (new) defines "treat as malformed" once — drop, do not act, do not coerce, do not crash or tear down the transport, SHOULD log, no error reply unless the topic's spec prescribes one. SESSION-1 §2.5 cites this phrase.
  • §3.4 adds the anti-spoofing rules: no claiming an unassigned identifier, trust-domain ingress MUST overwrite source with the identifier it assigned the peer, routing keys are never proof of identity.
  • §3.4 defines "layer-2 system" and "assistant core", both load-bearing and previously undefined.
  • §5.3 response arithmetic scoped to topics that neither end in .response nor contain a :; askers MUST NOT assume <request>.response unless the defining spec says so (siblings hand-name their answering topics).
  • §2.1.1 rule 1 tightened: a dispatch topic contains exactly one : and is definable only by a specification in this family; component-owned contracts are dotted-only, reconciling §1.

Minor and nits

  • Per-member string equality for an array destination (BRIDGE-1's membership test).
  • Empty-string source/destination forbidden on the producer side, treated as absent on the consumer side.
  • §2.1 topic syntax forbids empty segments and leading/trailing separators.
  • "exactly these top-level keys" → "no top-level keys other than these" (data/context are optional).
  • §5.4 correlation guidance now recommends echoing a discriminating field from the request (OVOS-COMMON-QUERY-1 §11) instead of pointing at a topic+session pairing that does not separate parallel requests.
  • §3.1 names the derivations in prose rather than implementation method names, drops the undefined A/B markers, and carries the worked ping/pong trace.
  • §7 duplicate type bullets merged; derivation count corrected to two plus the response shorthand; redundant RFC 8259 restatement dropped; §2 rationale marked informative.

Deliberately not in this PR

The GLOSSARY rows, the GLOSSARY Session attribute repoint, the README version row, the CONVERSE-1 §4.2 citation fix, and the family-wide sweep of implementation method names belong to their own PRs. The layer-2 definition lands here in §3.4 so nothing in this file references an undefined term.

@coderabbitai

coderabbitai Bot commented Aug 4, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@JarbasAl, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 36 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 11da28d4-f220-41b2-bb99-1c55d1671f34

📥 Commits

Reviewing files that changed from the base of the PR and between 1d3622b and b76a5a2.

📒 Files selected for processing (2)
  • CHANGELOG.md
  • msg-1.md

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@JarbasAl
JarbasAl marked this pull request as ready for review August 4, 2026 12:46
…le, decomposed-topic hygiene

Squashed from:
- spec: OVOS-MSG-1 — §5.4 correlation exemplar updated to query_id
- spec: OVOS-MSG-1 — deterministic reply source, unified  unknown-key rule, decomposed-topic hygiene

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant