feat: emit INTENT-4 template registrations in the intent runner

[JarbasAl]

🤖 Auto-generated by Claude Sonnet 5 (claude-sonnet-5) and Claude Fable 5.1 (claude-fable-5-1) via Claude Code — NOT human-reviewed. Verify before acting.

The runner's _register_templates() only ever emitted the legacy padatious:register_intent bus topic. kw-template-matcher's dev head (merge commit 5640d79, "fix: register templates from ovos.intent.register.template and key by skill_id:intent_name") now also binds the OVOS-INTENT-4 §6 spec topic, ovos.intent.register.template, and keys templates learned from it as "skill_id:intent_name" — the same skill-prefixed form m2v-style fighters return in IntentHandlerMatch.match_type. Since the runner never emitted that topic, and its own transformer slot lookup was always keyed by the bare, normalised intent id, m2v-form fighter labels never scored any slots through a configured intent transformer.

I traced both the producer and consumer side before making this change. ovos-workshop's PadatiousIntentContainer.register_template() (ovos_workshop/intents.py) dual-emits the legacy padatious:register_intent topic and the spec topic via SpecMessage.INTENT_REGISTER_TEMPLATE (ovos_spec_tools.messages.SpecMessage, value "ovos.intent.register.template"), with payload fields skill_id, intent_name, samples, lang, blacklist, slot_blacklist. kw-template-matcher's KeywordTemplateMatcher.handle_register_template (kw_template_matcher/opm.py) reads exactly those fields and registers the resulting templates under f"{skill_id}:{intent_name}", distinct from handle_register_intent's bare-name key for the legacy topic. This change makes the runner emit the same spec-topic message ovos-workshop emits, mirrored onto the transformer bus alongside the legacy one, and makes _transform_slots try both the bare intent id and the "arena:<intent_id>" skill-prefixed form so a transformer that only recognised the spec-form key still fills slots.

Two new tests cover this: one asserts the runner actually emits ovos.intent.register.template with the expected payload shape, the other registers a template only via the spec topic (bypassing the legacy emission) and confirms _transform_slots still finds it through the skill-prefixed fallback key. Reverting only the source change (keeping the tests) makes both fail — zero messages captured on the first, and empty slots instead of {"song": "africa"} on the second — and re-applying the fix makes both pass. The full targeted suite (test_intent_pipeline, test_intent_bench, test_runner, test_registry, test_registry_validation) passes at 136/136 against the fix.

I added a floor pin, keyword-template-matcher>=0.1.6a1, to the test optional-dependency group so CI installs the plugin once that release reaches PyPI. kw-template-matcher's 0.1.5a1 PyPI publish shipped a broken sdist (its setup.py reads a requirements.txt the sdist doesn't include) and is not installable; the first installable release with this spec-topic support will be 0.1.6a1, expected on the plugin's next merge. Until then, keyword-template-matcher>=0.1.6a1 will fail to resolve in CI and the existing skipif guard on TestIntentTransformers (checking whether kw_template_matcher is importable) will keep those tests skipping rather than failing the build. My local verification installed the plugin from a clone of its dev head directly into a throwaway venv — a test-only workaround, not something declared as a dependency anywhere in this repo.

Both registration messages, the legacy padatious:register_intent and the spec ovos.intent.register.template, carry context={"skill_id": "arena"}. OVOS-INTENT-4 §3.1 has engines key a registration on message.context['skill_id'], not on the data payload, and ovos-padatious from 2.1.2a2 rejects a registration that carries the id only in data. test_register_templates_emits_spec_topic asserts the context key; with the context argument removed it fails with KeyError: 'skill_id'.

The test extra pins keyword-template-matcher>=0.1.6a1, the floor that binds the spec topic; 0.1.7a2 is on PyPI, so CI resolves it. The 22 other failures in the full local suite fail identically on origin/dev in the same venv (missing datasets), unchanged by this branch.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}

[github-actions]

Checking back in with the latest test results. 📡

I've aggregated the results of the automated checks for this PR below.

🔍 Lint

The latest check cycle has concluded. 🔄

❌ ruff: issues found — see job log

🔎 Type Check

Analysis complete! Check out the details below. 📊

✅ mypy: no type errors found

🔨 Build Tests

The build process has successfully terminated. 🏁

✅ All versions pass

Python	Build	Install	Tests
3.10	✅	✅	✅
3.11	✅	✅	✅
3.12	✅	✅	✅
3.13	✅	✅	✅
3.14	✅	✅	✅

---

Making code review just a little bit easier. 💆‍♂️