Establish a plugin capability registry for natural-language dispatch

[Q00]

Vision

ourocode should treat installed Ouroboros UserLevel plugins as first-class capabilities, not as opaque shell commands. Before it can safely route natural-language prompts such as "use Superpowers TDD for this change", the runtime needs a trusted way to discover which plugins are installed, which commands they expose, what arguments they accept, and what artifacts they may produce.

This is the product foundation for the broader UserLevel plugin dispatch experience described in #2.

Why this matters

The current bridge idea in #2 depends on resolving installed plugins and commands through the Ouroboros plugin registry, lockfile, or another stable CLI/MCP surface. Without that capability layer, ourocode has to guess from raw prompt text or fall back to shell-shaped command metadata. That is brittle, hard to test, and weakens the trust boundary that plugins are supposed to preserve.

A capability registry gives ourocode a clear internal model:

• what plugin names are available
• which command names and aliases each plugin declares
• which commands are read-only, handoff-producing, or potentially destructive
• which arguments are required or optional
• which trust state blocks execution
• which output artifacts should be watched, such as stable plugin artifact reference.md`

Proposed scope

Build a generic plugin capability discovery layer that can be used by router, command palette, natural-language intent detection, and continuation policy code.

1. Load installed UserLevel plugin metadata from the canonical Ouroboros source, such as the plugin registry, lockfile, or a stable Ouroboros CLI/MCP API.
2. Normalize plugin commands into an internal capability struct with name, aliases, argument schema, safety/trust metadata, and expected artifact patterns.
3. Expose lookup APIs for:
   • exact command-shaped prompts like ooo superpowers list
   • natural-language matching against installed plugin and command names
   • command palette or dynamic skill rendering
4. Represent blocked states explicitly, including missing plugin, untrusted plugin, missing command, and unsupported metadata version.
5. Keep dispatch separate from discovery so the registry can be tested without executing plugin code.

Acceptance criteria

• ourocode can list installed UserLevel plugin capabilities through a deterministic internal API.
• superpowers commands such as list, inspect, test-driven-development, and systematic-debugging resolve from installed plugin metadata rather than hardcoded names.
• Unknown plugin names and unknown command names return structured errors that the UI can render as actionable guidance.
• Untrusted plugins are discovered but marked as blocked, and ourocode does not grant trust implicitly.
• Natural-language routing can ask the capability registry for candidate plugin commands without executing anything.
• Tests cover installed plugin discovery, command normalization, exact lookup, fuzzy/natural-language candidate lookup, trust-blocked state, and metadata-version failure.

Non-goals

• Executing plugin commands. Dispatch should be implemented in a separate follow-up.
• Installing plugins automatically.
• Granting plugin trust automatically.
• Building a marketplace UI.

Related

• Support natural-language dispatch for installed Ouroboros UserLevel plugins #2
• docs: rescope userlevel plugin dispatch around SSOT #25 (PR 1/5) #3