Vision: make installed plugin identity stable across local workspaces

[Q00]

Vision

Ourocode should treat installed Ouroboros UserLevel plugins as stable, explainable workspace capabilities rather than transient shell commands discovered at the moment of execution.

Issue #2 calls out the need to resolve installed plugins and commands through the Ouroboros plugin registry, lockfile, or a stable CLI/MCP surface. That resolution layer should become a first-class product primitive: when a user asks for ooo superpowers test-driven-development or describes the same workflow in natural language, ourocode should know which installed plugin is being referenced, where it came from, which version is trusted, and which command contract will run.

Why this matters

Natural-language plugin dispatch only feels reliable if the identity behind the command is stable. Users should not have to wonder whether superpowers means a local checkout, a marketplace package, a globally installed adapter, or a stale lockfile entry. Ourocode should make that answer deterministic before dispatching anything.

This also protects the trust model. A plugin command can only be safely routed through the Ouroboros firewall if ourocode can explain the plugin identity, source, version, declared capabilities, and trust state it is about to use.

Product direction

• Build a workspace-level installed plugin identity model that records plugin name, canonical id, source, version or revision, install scope, trust scope, and command manifest digest.
• Resolve command-shaped prompts and natural-language plugin mentions against that identity model before dispatch.
• Prefer exact, deterministic matches; when multiple installed plugins could match, present an explicit ambiguity state instead of guessing.
• Show users the resolved plugin identity in preflight output, child pane headers, run metadata, and generated artifact provenance.
• Detect stale or changed plugin manifests and require a fresh resolution/trust check before execution.
• Expose generated handoffs through a stable artifact contract from Ouroboros/plugin runtime metadata.
• Keep this layer independent from any single plugin such as Superpowers, while using Superpowers as the golden-path fixture for early validation.

Success criteria

• ooo superpowers list resolves to one installed plugin identity with a visible source/version/trust summary before execution.
• A natural-language request such as "Use the Superpowers TDD workflow" resolves through the same identity path as the direct command.
• If two installed plugins expose the same display name or command alias, ourocode asks for disambiguation and does not execute either one by default.
• If the installed plugin manifest changes after trust was granted, ourocode surfaces the stale identity state and blocks execution until the trust boundary is refreshed.
• Generated handoffs and seed artifacts include provenance that points back to the resolved plugin identity and command manifest digest through a stable artifact contract.

Relationship to #2

This issue expands proposed scope item 2 from #2 into a product vision for stable installed-plugin identity and command resolution. It should inform the implementation of plugin dispatch, natural-language routing, artifact provenance, and trust-boundary UX.