Vision: make ourocode the orchestration front door for trusted plugin workflows

[Q00]

Vision

ourocode should become the terminal-native orchestration front door for trusted Ouroboros plugin workflows.

Issue #2 defines the first missing product boundary: users should be able to invoke installed UserLevel plugins from inside ourocode, either with direct ooo <plugin> ... prompts or natural language, without dropping to the shell and manually chasing generated artifacts.

The broader vision is that ourocode should not treat plugins as disconnected external commands. It should treat them as workflow-capable collaborators that can be discovered, invoked, observed, continued, and audited from one coherent TUI session.

Product direction

A user should be able to start with intent, not plumbing:

Use the Superpowers TDD workflow to implement retry behavior, review the handoff, then continue with the generated Seed.

ourocode should understand the installed plugin surface, route the request through the existing Ouroboros trust and firewall model, show progress in context, capture generated artifacts, and guide the user into the next safe step.

Principles

• Keep Ouroboros trust boundaries intact. ourocode should never silently install, trust, or escalate plugin permissions.
• Prefer intent-driven workflow orchestration over shell-command ceremony.
• Make generated artifacts first-class session objects, not files the user has to hunt for manually.
• Preserve user control at continuation points, especially before running generated Seeds or performing destructive actions.
• Design the bridge generically so superpowers is the first proof point, not a one-off integration.

Target experience

• Installed plugins and commands are discoverable inside the command palette or prompt flow.
• Direct prompts such as ooo superpowers list and natural-language prompts resolve to the same safe dispatch path.
• Plugin execution output streams into an appropriate pane/status surface.
• Generated handoff files, Seeds, reports, and run directories are detected and attached to the active session.
• ourocode can suggest the next safe action, such as ooo run seed_path=..., with policy-aware confirmation.
• Trust failures are actionable: the user sees the exact trust/install command required, but ourocode does not grant trust automatically.

Suggested milestone breakdown

1. Dispatch bridge

   • Implement the safe installed-plugin dispatch path described in Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
   • Cover direct command-shaped prompts and a narrow natural-language routing path.

2. Artifact lifecycle

   • Normalize plugin-generated artifacts into session-visible records.
   • Detect handoff/Seed outputs and expose continuation actions.

3. Plugin-aware session UX

   • Add command palette entries, status indicators, and pane-level rendering for plugin runs.
   • Make plugin state understandable without requiring shell inspection.

4. Policy and auditability

   • Record plugin dispatch decisions, trust blocks, artifacts, and continuation choices in the journal.
   • Keep destructive or elevated actions explicit and reviewable.

Acceptance criteria for this vision track

• A user can complete a plugin-driven workflow from intent to generated Seed continuation without leaving ourocode.
• The implementation works through generic installed-plugin metadata rather than hardcoding superpowers behavior.
• All plugin execution respects existing Ouroboros trust/firewall semantics.
• Artifacts created by plugin runs are visible, attributable, and actionable in the current session.
• Continuation into ooo run is policy-aware and never silently crosses a trust or destructive-action boundary.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• PR docs: rescope userlevel plugin dispatch around SSOT #25 (PR 1/5) #3 documents the initial UserLevel plugin dispatch boundary.