maintain-dynamic-plugins

# Maintain Dynamic Plugins ## Companion Guidance Use `karpathy-guidelines`, `validate-change`, `maintain-packaging`, and `contribute-docs` alongside this skill when implementation, packaging, CI, or documentation changes are involved. Use this skill for `plugin.kind = "rust_dynamic"`, `plugin.kind = "worker"`, `nemo-relay-plugin`, `nemo-relay-worker`, `nemo-relay-worker-proto`, `nemo-relay-types`, and the Python `nemo-relay-plugin` package. ## Rules - Keep the stable boundary explicit: native plugins cross a C ABI; worker plugins cross `grpc-v1`. - Do not pass Rust runtime types, trait objects, futures, or allocator-owned strings across the native dynamic-library boundary. - Keep worker protocol DTOs in `JsonEnvelope`; protobuf owns control flow, not duplicated Relay data models. - Keep `relay-plugin.toml` dynamic records separate from generic runtime components. Enabled dynamic records may synthesize internal component specs; disabled records stay inspectable but unloaded. - Treat plugin Relay compatibility as normal SemVer. Use `>=0.5,<1.0` in examples unless a plugin intentionally declares a narrower range. - Do not add tests under `src`; Rust tests belong in crate `tests/` trees and Python SDK tests belong under `python/tests`. - Native and worker plugins are trusted extensions. Document that native plugins are in-process and unsandboxed; worker plugins provide process isolation but not a security sandbox. ## Checklist - [ ] Manifest validation co...