Vision: make plugin workflow decisions observable and auditable

[Q00]

Vision

ourocode should make every trusted plugin workflow explainable after the fact.

Issue #2 defines the missing execution bridge for installed Ouroboros UserLevel plugins. Once ourocode can resolve and dispatch plugin commands from direct prompts or natural language, the next product requirement is observability: users should be able to see why a plugin was selected, what trust state applied, what was dispatched, what artifacts were produced, and which continuation decision was made.

The goal is not just to run plugins inside the TUI. The goal is to make plugin-driven work feel native, reviewable, and safe enough to trust for real development workflows.

Product direction

A plugin workflow should leave a clear decision trail in the active session and journal:

• the original user prompt
• whether the prompt was direct command-shaped or natural language
• the resolved plugin, command, and arguments
• the capability metadata used for routing
• the trust and permission state at dispatch time
• whether execution was allowed, blocked, or required clarification
• the dispatched payload or stable execution reference
• streamed output and terminal status
• generated artifacts such as Seeds, handoff files, reports, and logs
• continuation suggestions, confirmations, or policy blocks

This turns plugin dispatch from an opaque side effect into a product surface that users and maintainers can inspect.

Why this matters

Natural-language plugin routing introduces real ambiguity. If ourocode quietly chooses the wrong plugin, silently crosses a trust boundary, or loses the provenance of a generated seed.md, the workflow becomes hard to debug and hard to trust.

An observable decision trail gives us:

• safer natural-language routing, because uncertain decisions can be explained or blocked
• better support diagnostics, because users can share what ourocode resolved and why
• stronger tests, because routing and continuation decisions can be asserted as records
• a foundation for future UI, such as session replay, plugin run summaries, and policy review

Relationship to existing issues

• Support natural-language dispatch for installed Ouroboros UserLevel plugins #2 covers the first end-to-end UserLevel plugin dispatch experience.
• Vision: make ourocode the orchestration front door for trusted plugin workflows #6 frames ourocode as the orchestration front door for trusted plugin workflows.
• Vision: treat plugin run artifacts and continuations as first-class session objects #7 covers generated artifacts and continuation as first-class session objects.
• Vision: define an authoritative plugin capability contract for ourocode #9 covers the authoritative plugin capability contract that should feed routing decisions.

This issue focuses on the audit and observability layer across those features.

Proposed scope

1. Define normalized journal events for plugin intent detection, capability resolution, trust evaluation, dispatch, artifact detection, and continuation decisions.
2. Record both successful and blocked paths, including missing plugin, untrusted plugin, ambiguous intent, unsupported capability schema, and policy-blocked continuation.
3. Preserve enough provenance to connect a generated artifact back to the prompt, plugin command, dispatch record, and run directory that produced it.
4. Render concise plugin run summaries in the TUI without requiring users to inspect raw journal files.
5. Add fixtures and tests that assert the decision trail for direct command prompts and natural-language prompts.
6. Keep sensitive values redacted where plugin arguments or environment-derived metadata may contain secrets.

Acceptance criteria

• Direct prompts such as ooo superpowers list produce journal records for intent detection, capability resolution, trust evaluation, and dispatch outcome.
• Natural-language plugin prompts record the matched plugin/command candidates, selected route, and confidence or clarification reason.
• Trust-blocked and policy-blocked states are recorded as first-class outcomes, not only rendered as text.
• Generated artifacts include provenance linking them to the plugin run and original user prompt.
• Continuation decisions record whether ourocode suggested, confirmed, auto-ran, or blocked the next step.
• The TUI can show a compact plugin workflow summary from the recorded state.
• Tests cover success, ambiguity, missing trust, missing plugin, artifact detection, and continuation policy records.

Non-goals

• Implementing the plugin dispatch bridge itself.
• Designing a full analytics dashboard.
• Storing secrets or raw sensitive environment values in the journal.
• Auto-trusting, auto-installing, or escalating plugin permissions.
• Replacing the Ouroboros plugin firewall.