docs: mark mycroft.skill.handler.* as internal workshop->core sync (not spec)#436
Conversation
These are NOT spec topics — they are an internal ovos-workshop -> ovos-core synchronization signal (workshop reporting 'I started/ended/errored' running a handler). They exist only because skills run out-of-process from the orchestrator; if core manipulated skill objects directly this bus round-trip would not be needed. ovos-core consumes them as a private done-signal to emit the authoritative PIPELINE-1 §8 spec trio (ovos.intent.handler.*); the legacy names are permanently ovos-workshop event-wrapper signals and do not bridge to the spec namespace (spec-tools MIGRATION_MAP excludes the trio). Doc-only.
|
Warning Review limit reached
More reviews will be available in 18 minutes and 49 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the 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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Processing sequence 0x4F564F53 complete! 🦾I've aggregated the results of the automated checks for this PR below. 📋 Repo HealthI've checked the repo's flexibility (aka refactorability). 🧘♂️ ✅ All required files present. Latest Version: ✅ 🔍 LintEnsuring we're following our development process. 📏 ❌ ruff: issues found — see job log 🔒 Security (pip-audit)Patrolling the perimeter for any security threats! 🚓 ✅ No known vulnerabilities found (72 packages scanned). ⚖️ License CheckI've audited the copyright holders list. 👥 ✅ No license violations found. Policy: Apache 2.0 (universal donor). StrongCopyleft / NetworkCopyleft / WeakCopyleft / Other / Error categories fail. MPL allowed. 🔨 Build TestsConstruction of your features is officially finished. 🏠
❌ 3.10: Install OK, tests failed Signed, sealed, and delivered by the OVOS bot. 📧 |
1 participant
Documents the
_on_event_{start,end,error}emissions ofmycroft.skill.handler.{start,complete,error}as what they are: an internal ovos-workshop → ovos-core synchronization signal, explicitly not part of any OVOS spec.They are an implementation detail that exists only because skills (ovos-workshop) run in a separate process from the orchestrator (ovos-core) — workshop's way to confirm "I started / ended / errored" running a handler. If core manipulated skill objects directly, in-process, the bus round-trip wouldn't be needed.
ovos-core consumes them as a private done-signal to emit the authoritative PIPELINE-1 §8 spec trio (
ovos.intent.handler.*, core #788); the legacy names are permanently ovos-workshop event-wrapper signals and do not bridge to the spec namespace (spec-tools #63 excludes the trio from MIGRATION_MAP). Doc/comment-only — no behaviour change.