Vision: keep plugin capability resolution fresh across session changes

[Q00]

Vision

ourocode should keep installed UserLevel plugin capability resolution fresh as the local Ouroboros plugin environment changes. Issue #2 proposed scope item 2 says ourocode should resolve installed plugins and commands through the Ouroboros plugin registry, lockfile, or a stable CLI/MCP surface. That resolution cannot be a one-time snapshot if users install, update, trust, untrust, or remove plugins while an ourocode session is still running.

The product vision is that ourocode should always make plugin routing decisions from a current, explainable capability view. A prompt like:

ooo superpowers test-driven-development --goal "Add retry behavior"

should not route through stale metadata after the plugin has been updated, revoked, moved, or granted new trust. The TUI should know when capabilities were last resolved, why they changed, and whether the user must refresh, retry, or re-run preflight.

Why this matters

Natural-language plugin dispatch depends on trustworthy plugin resolution. If the capability view goes stale, several failures become hard to diagnose:

• a newly installed plugin is invisible until restart
• a removed plugin still appears in command suggestions
• a trust change is ignored and dispatch behaves inconsistently
• an updated command schema is parsed with old argument metadata
• generated artifact expectations are wrong after plugin upgrades
• tests pass against static fixtures while real sessions drift

Freshness is part of the safety boundary. ourocode should not silently execute from cached plugin metadata when the authoritative Ouroboros source has changed.

Proposed scope

1. Track a freshness marker for the plugin capability source, such as registry revision, lockfile digest, CLI/MCP version stamp, or filesystem mtime where appropriate.
2. Add a refresh path that re-loads installed plugin capabilities without requiring an ourocode restart.
3. Invalidate or re-run plugin preflight results when the underlying capability source changes before dispatch.
4. Surface capability changes in the TUI, including installed, removed, updated, trusted, untrusted, and incompatible plugin states.
5. Keep stale capability behavior conservative: block dispatch or ask for confirmation instead of falling back to shell-shaped execution.
6. Add tests for stale cache detection, refresh after install/update/remove, trust-state changes, and preflight invalidation.

Acceptance criteria

• ourocode can detect when the authoritative plugin capability source has changed during a running session.
• Capability lookup can refresh and return updated plugin command metadata without restarting the TUI.
• A previously accepted plugin preflight result is invalidated if plugin identity, command schema, trust state, or risk class changes before dispatch.
• Removed or untrusted plugins stop being executable through cached metadata.
• New or updated plugin commands can appear in routing and command palette surfaces after refresh.
• The user sees actionable status when capability metadata is stale, refreshed, or incompatible.
• Tests cover stale metadata, refresh success, refresh failure, trust revocation, plugin removal, and preflight invalidation.

Non-goals

• Defining the full capability contract. See Vision: define an authoritative plugin capability contract for ourocode #9.
• Building the capability registry itself. See Establish a plugin capability registry for natural-language dispatch #8.
• Defining the full preflight decision model. See Vision: make plugin resolution an explicit preflight step #16.
• Auto-installing, auto-updating, or auto-trusting plugins.
• Bypassing the Ouroboros plugin firewall.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2, especially proposed scope item 2.
• Complements the capability contract direction in Vision: define an authoritative plugin capability contract for ourocode #9.
• Complements the registry/index direction in Establish a plugin capability registry for natural-language dispatch #8 and Build a plugin capability index for intent-driven workflows #5.
• Complements the explicit preflight boundary in Vision: make plugin resolution an explicit preflight step #16.