Spec proposal: OVOS-INTENT-4 §11 — session-scoped intent registration

Proposal for session-scoped intent registration as an extension to OVOS-INTENT-4.

Problem

All intent registrations are currently global — every session sees the same skill set. This prevents satellite deployments from running their own skills and blocks distributed topologies where different sessions need different intent pools.

Proposal

Key every registration by context.session.session_id from the registration Message — no wire-shape change needed. "default" session is the global/inherited scope; all sessions inherit it automatically. A satellite's skills extend the pool for that session only.

Effective pool for session X: default intents ∪ session-X intents − blacklisted entries

Dispatch routing is transparent: session-scoped intent dispatch uses .reply() which sets context.destination to the satellite's source; existing BRIDGE-1 §3.2 destination-based routing handles delivery with no new protocol.

Changes to INTENT-4

• Registration key extended to quintuple (session_id, skill_id, intent_name, lang, method)
• ovos.skill.deregister gains optional session_id for bulk satellite cleanup on disconnect
• ovos.intent.list gains optional session_id filter returning the effective pool
• New §11 defining indexing model, inheritance rule, plugin visibility, dispatch routing

PR

PR #45

Read the existing OVOS-INTENT-4 specification and the BRIDGE-1 §3.2 routing section first, then review PR #45 for the current proposal context. Done means the registration, deregistration, listing, indexing, inheritance, visibility, and dispatch-routing rules are consistently documented in the new §11 and related specification text.