Typed Plugins and External Wrappers

The plugin ecosystem around the kernel

MRP-VM delegates most behavior to typed plugins. Built-in plugins live in-process, while external wrappers can expose the same typed contracts through the manifest-driven wrapper convention. See DS003, DS016, and DS027.

Plugin families

• sd-plugin — emits Intent/Seed control plus current-turn KU shells
• kb-plugin — retrieves and fuses evidence, strategy units, and phase-scoped guidance
• gs-plugin — produces answers, no-context, or needs-decomposition
• mrp-plan-plugin — selects plugin order and child-frame strategy
• val-plugin — checks grounding and answer acceptability

Key concepts

• Typed contracts — plugins exchange structured inputs and outputs rather than ad-hoc prompt snippets.
• SOP on control boundaries — when control payloads are serialized, they use SOP Lang Control rather than legacy heading blocks.
• Branch-local execution — goal solvers operate over resolved intents within a branch attempt, not over raw user text.
• Planner-driven routing — plugin order is chosen per request and may change after retrieval guidance arrives.

Wrapper convention

wrappers/z3-solver/
├── manifest.json    # protocolVersion, command, plugin type, metadata
├── wrapper.js       # adapter process
└── README.md

External wrappers are useful when a capability already exists outside Node.js. The wrapper speaks the protocol expected by the kernel and advertises its metadata in the manifest.

How plugins fit into explainability

Plugin attempts appear in the canonical execution graph as typed plugin nodes connected to frames, seeds, branches, results, and failures. This is why plugin IDs, statuses, and selected routes are visible in the Explainability panel per chat turn.

Learn more

• Plugin Development Guide — repository layout, descriptor rules, and examples
• Planner concepts — how route selection works
• Agentic Plugin Loops — future multi-step continuation ideas