Vision: make plugin capability discovery portable across CLI and MCP surfaces

[Q00]

Vision

ourocode should resolve installed UserLevel plugins through a stable discovery surface that works the same way whether the runtime talks to Ouroboros through CLI, MCP, or future daemon-style APIs.

This builds on proposed scope item 2 in #2: resolving installed plugins and commands through the Ouroboros plugin registry, lockfile, or a stable Ouroboros CLI/MCP surface. The product direction is broader than one registry implementation: plugin capability discovery should be a portable contract between Ouroboros and ourocode, not a behavior that only works in one transport path.

Why this matters

Natural-language plugin dispatch will become fragile if each execution path discovers plugins differently:

• CLI dispatch may read one registry or lockfile shape.
• MCP dispatch may expose a different set of commands or trust states.
• Tests may pass against fixtures while real sessions behave differently.
• The TUI may show plugin commands that the active transport cannot safely execute.
• Trust, permission, and artifact metadata may drift between surfaces.

For users, the expectation is simpler: if ooo superpowers test-driven-development --goal "..." is valid in one supported Ouroboros surface, ourocode should explain and handle it consistently in every supported surface.

Proposed direction

Define a transport-neutral capability discovery layer for installed UserLevel plugins.

1. Specify the minimum plugin capability payload that must be available from both CLI and MCP surfaces.
2. Include plugin identity, command metadata, argument schema, trust state, risk class, and expected artifact declarations.
3. Make the active discovery source visible in diagnostics so users can understand whether ourocode resolved capabilities from CLI, MCP, daemon state, or static fixtures.
4. Add compatibility/version checks so unsupported discovery payloads fail closed with actionable guidance.
5. Keep discovery read-only: it must never install, trust, or execute plugin code.
6. Ensure direct command-shaped prompts and natural-language prompts consume the same normalized capability model regardless of source.

Acceptance criteria

• ourocode has a normalized capability discovery model that can be populated from at least a CLI-backed source and an MCP-backed or fixture-backed source.
• The same installed plugin command resolves to the same normalized capability shape across supported sources.
• Source-specific failures produce structured blocked states rather than falling back to shell execution or prompt guessing.
• The TUI and logs can show which discovery source was used and why another source was unavailable.
• superpowers can be represented through the portable discovery model, including read-only and handoff-producing commands.
• Tests cover source precedence, version mismatch, missing source, trust-blocked capability metadata, and source-to-normalized-model parity.

Non-goals

• Implementing plugin dispatch.
• Auto-installing or auto-trusting plugins.
• Building a plugin marketplace UI.
• Replacing the Ouroboros plugin firewall.
• Designing the full continuation UX after a Seed is generated.

Related

• Support natural-language dispatch for installed Ouroboros UserLevel plugins #2 defines the end-to-end UserLevel plugin dispatch experience.
• Establish a plugin capability registry for natural-language dispatch #8 covers the ourocode-side capability registry.
• Vision: define an authoritative plugin capability contract for ourocode #9 covers the authoritative plugin capability contract.
• Vision: make plugin resolution an explicit preflight step #16 covers the explicit preflight resolution boundary before dispatch.