🤖 Auto-generated by Claude Sonnet 5 (claude-sonnet-5) via Claude Code — NOT human-reviewed. Verify before acting.
Governing clause
OVOS-INTENT-4 §8.5 (architecture repo, intent-4.md, origin/dev):
Enable and disable are session-scoped like every other message here (§11.3): they affect only registrations under the session_id read from context.session.session_id.
What was found
Live-gated against a merged worktree of #122 (b72acf5 onto dev c9aba2d): ovos.intent.disable removes the label from self.intents for every session, not just the session carrying the disable message. A second, untouched session stops matching the same intent after another session's disable. ovos.intent.enable does not restore matches in prototype mode at all — the plugin's own docstring says prototypes are dropped on disable and only re-registration restores them, and this is already xfail-covered in the plugin's own suite as test_spec_enable_rearms_intent.
Executed evidence, side-by-side against padatious and adapt (both of which conform — a second session is unaffected by another session's disable, and enable fully re-arms): knowledge/wiki/audits/spec-adoption-2026-09/gate-intent4-attribution-122-146.md in the TigreGoticoLda knowledge workspace, abuse #3 and the adapt three-way comparison table.
This predates and is unrelated to #122's attribution changes (#122 only wraps existing skill_id resolution; it does not touch the disable/enable label-tracking code path).
Why it matters
OpenVoiceOS/architecture#246 (open) tightens §8.5 into an explicit MUST, written directly off this same divergence between conformant implementations. Once merged, this becomes a spec violation with no ambiguity.
Suggested fix shape (not prescriptive)
Disable/enable need per-session state instead of a single instance-wide self.intents label removal — mirroring the session-scoped blacklist approach in ovos-bus-client's Session.blacklisted_intents that adapt and padatious both key off. Enable needs to actually re-register/restore the prototype for the target session rather than only clearing bookkeeping.
Governing clause
OVOS-INTENT-4 §8.5 (architecture repo,
intent-4.md,origin/dev):What was found
Live-gated against a merged worktree of
#122(b72acf5 onto dev c9aba2d):ovos.intent.disableremoves the label fromself.intentsfor every session, not just the session carrying the disable message. A second, untouched session stops matching the same intent after another session's disable.ovos.intent.enabledoes not restore matches in prototype mode at all — the plugin's own docstring says prototypes are dropped on disable and only re-registration restores them, and this is alreadyxfail-covered in the plugin's own suite astest_spec_enable_rearms_intent.Executed evidence, side-by-side against padatious and adapt (both of which conform — a second session is unaffected by another session's disable, and enable fully re-arms):
knowledge/wiki/audits/spec-adoption-2026-09/gate-intent4-attribution-122-146.mdin the TigreGoticoLda knowledge workspace, abuse #3 and the adapt three-way comparison table.This predates and is unrelated to
#122's attribution changes (#122only wraps existing skill_id resolution; it does not touch the disable/enable label-tracking code path).Why it matters
OpenVoiceOS/architecture#246(open) tightens §8.5 into an explicit MUST, written directly off this same divergence between conformant implementations. Once merged, this becomes a spec violation with no ambiguity.Suggested fix shape (not prescriptive)
Disable/enable need per-session state instead of a single instance-wide
self.intentslabel removal — mirroring the session-scoped blacklist approach inovos-bus-client'sSession.blacklisted_intentsthat adapt and padatious both key off. Enable needs to actually re-register/restore the prototype for the target session rather than only clearing bookkeeping.