spec: OVOS-INTENT-4 — identity check, entity blacklist, session-scope fixes

[JarbasAl]

🤖 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 pass over intent-4.md. One file, plus its CHANGELOG entry.

Behavior changes

• The payload skill_id MUST now equal context.skill_id on every
  message of §§5–8. Consumers MUST NOT index or act on a mismatch and
  MUST log it at WARN. Before this, nothing tied the payload identity
  to the emitting skill: any skill could register, disable, or
  deregister another skill's intents, and ovos.skill.deregister
  (§8.4) amounted to a remote uninstall. The rule is imported from
  OVOS-FALLBACK-1 §3.1, which already states it for fallback
  registration, and is restated in §12 for plugins and orchestrator.
• The entity payload gains an optional blacklist field (§7.1) —
  slot-free phrases that MUST NOT be bound as values of the entity's
  slot. This closes OVOS-INTENT-2 §4.3's slot-value-exclusion role,
  which had no carrier on the bus. Absent means no exclusion. It is
  distinct from §6.1's intent-suppression blacklist, and §5.4 is
  rewritten so its "no .blacklist" statement is scoped to the
  intent-suppression role only. Per triage D7; INTENT-3 gets the
  matching entity-side sentence in its own PR.
• A session-scoped entry now shadows the "default" entry on
  exact key collision (§11.2), instead of both entering the pool.
  The old text deferred to OVOS-PIPELINE-1 §6 first-match-wins, which
  orders pipeline plugins, not entries within one plugin — the
  collision had no defined outcome.

Key and scoping consistency

• §3.2 states the registration key as the quintuple
  (session_id, skill_id, intent_name, lang, method), matching §8.1,
  §11.1 and §12; the session_id component stays owned by §11.1.
• §11.3: deregistration removes every entry matching
  (session_id, skill_id, intent_name, lang) across both methods,
  reconciling it with §8.2's no-per-method rule.
• §11.3, §8.5, §12: ovos.intent.enable / .disable are scoped to
  context.session.session_id and span both methods.
• §11.1: an absent session, or one with no session_id, is keyed
  under "default". The claim that every Message already carries a
  session is deleted — OVOS-MSG-1 §4 only SHOULDs it.
• §11.2: blacklisted_pipelines dropped from the effective-pool
  formula; it removes pipeline plugins, not pool entries.

Cold start and introspection

• §8.5, §10, §12: enabled/disabled state does not survive an
  orchestrator restart; the disabling party re-asserts after the
  readiness announcement.
• §10: re-emission MUST carry the same session context — a different
  session creates a second entry its owner cannot deregister. The
  satellite case is delegated to OVOS-BRIDGE-1 §4.4.
• §10.2: ovos.intent.describe gains an optional session_id filter,
  and each definitions[] entry carries its session_id.
• §2, §12: the manifest indexes every non-reserved registration
  verbatim without validating it — presence records that the broadcast
  was observed, not that any plugin will match it.

Editorial

• §8.4 reframed as a broadcast, not a message sent to the orchestrator.
• §5.3: two descriptors sharing a name within one role merge into
  one vocabulary whose samples is the union.
• §3.2: lang case-insensitivity cites OVOS-INTENT-2 §2, not
  OVOS-SESSION-1 §3.2.
• §12: §6.2 dropped from the malformed-rule citation list (§6.2
  mandates acceptance).
• RFC 2119 list adds RECOMMENDED; §6.2 and §7 key words bolded.
• See also gains OVOS-BRIDGE-1 and OVOS-FALLBACK-1.

Not in this PR

• OVOS-BRIDGE-1 §4.4's "hub-side session_id in the deregister
  payload" wording (belongs to the bridge PR).
• OVOS-FALLBACK-1 §3.2 session scoping and its §11.1/§11.2 miscite.
• GLOSSARY entries for manifest, registration key, effective intent
  pool, session-scoped registration, vocabulary descriptor.

Version unchanged (still 2).

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 41 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: e0d40639-e70c-4c42-8813-50d1db771122

📥 Commits

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

📒 Files selected for processing (2)

• CHANGELOG.md
• intent-4.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

• X
• Mastodon
• Reddit
• LinkedIn

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