ovos.intent.disable/enable are instance-wide, not session-scoped (OVOS-INTENT-4 §8.5)

Start in padacioso/opm.py with PadaciosoPipeline.handle_disable_intent and handle_enable_intent, then read calc_intent and the SessionManager.get(message) path for existing blacklist handling. Use the reproduction described in knowledge/wiki/audits/spec-adoption-2026-09/gate-intent4-8.5-scope-current.md and probe_padacioso.py. Done means disabling or enabling through one session no longer changes matching for another session.

🤖 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 probe against origin/dev@e063f0c: PadaciosoPipeline.handle_disable_intent and .handle_enable_intent (padacioso/opm.py) mutate self.containers[lang] directly, keyed only by (lang, name) — no session key anywhere. Two independently constructed Sessions both match skillX:off before disable. Disabling via session-one removes the intent from the shared container: both session-one and the untouched session-two stop matching. Enabling restores it for both.

A genuinely session-scoped mechanism already exists in the codebase — sess.blacklisted_intents/sess.blacklisted_skills, read in calc_intent — but the spec ovos.intent.enable/ovos.intent.disable handlers never touch it; they mutate the shared regex container instead.

Reproduction script and executed output: see knowledge/wiki/audits/spec-adoption-2026-09/gate-intent4-8.5-scope-current.md in the TigreGoticoLda knowledge workspace, and ~/tmp/gate-padacioso-hknn-001809/probe_padacioso.py.

For comparison, ovos-adapt-pipeline-plugin and ovos-padatious-pipeline-plugin both conform: they key disable state per-session (adapt via Session.blacklisted_intents, padatious via (session_id, full_name)).

Suggested fix shape (not prescriptive)

Route handle_disable_intent/handle_enable_intent through the session obtained from SessionManager.get(message) (the same object calc_intent already reads blacklisted_intents/blacklisted_skills from) instead of mutating the shared container, so a disable on one session's blacklist does not remove the intent from every other session's candidate pool.