Vision: make plugin trust understandable at the moment of use

[Q00]

Context

Issue #2 defines the near-term product gap: ourocode should dispatch installed Ouroboros UserLevel plugins from natural language or direct ooo <plugin> ... prompts without forcing users back into shell commands.

That bridge depends on a deeper product principle: plugin execution should feel powerful, but never mysterious. When a user asks ourocode to run an installed plugin, they should understand what is trusted, what is blocked, what capability is being requested, and what exact action would unblock the workflow.

Vision

Make ourocode the place where plugin trust becomes understandable at the moment of use.

Instead of treating trust failures as low-level CLI errors, ourocode should translate them into clear workflow states:

• this plugin is installed and trusted for the requested command
• this plugin is installed but not trusted for the requested scope
• this plugin is unknown or unavailable in the current environment
• this command would require capabilities that are not currently allowed
• this command is read-only, handoff-producing, or potentially destructive

The goal is not to hide the Ouroboros plugin firewall. The goal is to make the firewall legible inside the TUI so users can make explicit decisions without leaving the product flow.

Product Direction

ourocode should expose trust as an intentional preflight layer before plugin dispatch:

1. Resolve plugin and command intent.
2. Show the trust/capability status in plain language.
3. Execute immediately only when the installed plugin, command, and requested capability are already trusted.
4. For missing trust, show the exact non-destructive command needed to grant trust.
5. Never silently install, trust, or elevate plugin permissions.
6. Keep destructive or high-risk actions blocked unless explicitly declared and trusted.

Why This Matters

Natural-language plugin dispatch is only useful if users can rely on it. If ourocode turns plugin prompts into opaque background execution, it weakens the safety model. If it simply dumps raw CLI errors, it breaks the terminal-native workflow.

The better product stance is: ourocode should make safe plugin execution feel native, inspectable, and reversible.

Acceptance Criteria

• When a plugin command is requested, ourocode can present a preflight trust status before dispatch.
• Trust-blocked plugin commands produce actionable guidance with the exact ouroboros plugin trust ... --scope ... command.
• Read-only plugin commands can run without additional ceremony when already trusted.
• Handoff-producing plugin commands clearly separate plugin execution from follow-up ooo run continuation.
• Potentially destructive plugin commands remain blocked unless the plugin declaration and trust scope explicitly allow them.
• The TUI language distinguishes missing plugin, missing trust, unsupported command, and denied capability states.

Non-goals

• Auto-trusting plugins.
• Replacing the Ouroboros plugin firewall.
• Building a marketplace or plugin catalog UI.
• Designing the full permission schema in this issue.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• Complements the existing plugin orchestration and capability vision issues by focusing specifically on user-visible trust and permission comprehension.