Vision: make ourocode the plugin-native orchestration surface for Ouroboros

[Q00]

Vision

ourocode should become the terminal-native orchestration surface where Ouroboros core workflows, trusted UserLevel plugins, generated Seeds, and follow-up execution all feel like one coherent product.

Issue #2 covers the first concrete bridge for dispatching installed Ouroboros UserLevel plugins from inside ourocode. This vision issue defines the broader direction that bridge should serve: users should not have to understand where core commands end, where plugin commands begin, where artifacts are written, or which shell command should be run next.

Product direction

The target experience is an intent-driven workflow console:

• Users express intent in natural language or direct ooo ... command syntax.
• ourocode resolves whether the intent belongs to a core workflow, installed plugin, dynamic skill, or generated artifact.
• Execution stays inside the TUI, with clear status, streamed output, and child-pane isolation when work is long-running.
• Generated handoffs, Seeds, reports, and run directories are detected automatically and shown as first-class next steps.
• Trust and permission boundaries remain visible and explicit; ourocode guides users to grant trust, but never grants it silently.

Design principles

1. One front door
   ourocode should be the place users start and continue Ouroboros work, even when the implementation lives in a plugin or external workflow engine.

2. Intent before command shape
   Direct commands like ooo superpowers list must work, but natural-language prompts should route to the same safe dispatch path when the target plugin and command can be resolved confidently.

3. Artifacts are workflow state
   Files such as seed.md, handoff documents, run manifests, and generated reports should not be treated as hidden filesystem side effects. They should be detected, summarized, and made actionable inside the session.

4. Trust is a product surface
   Plugin trust, missing permissions, and blocked destructive actions should produce precise, non-destructive guidance. Users should understand what is blocked and exactly how to authorize it outside the implicit execution path.

5. Composable orchestration over special cases
   Superpowers is the reference plugin, not the only target. The dispatch bridge should be generic enough to support any installed trusted UserLevel plugin that declares commands and artifacts through stable Ouroboros surfaces.

Target user journeys

Plugin discovery and inspection

A user types:

ooo superpowers list

ourocode resolves the installed plugin, dispatches through the Ouroboros plugin firewall, streams output in the TUI, and keeps the session ready for the next action.

Handoff-producing workflow

A user types:

Use Superpowers test-driven-development for adding retry behavior.

ourocode resolves the installed plugin and command, runs it safely, detects the generated seed.md, then presents the next step as an actionable continuation such as:

ooo run seed_path=stable plugin artifact reference.md

Automatic continuation should happen only when the current policy allows it.

Trust-blocked plugin

A user asks for a plugin command before trusting the plugin.

ourocode should not execute it. It should explain that the plugin is installed but untrusted, show the exact trust command needed, and preserve the original user intent so the action can be retried after trust is granted.

Architectural implications

• Introduce a stable plugin-intent resolution layer shared by direct command parsing and natural-language routing.
• Keep shell execution out of the dispatch path; use the Ouroboros plugin firewall, CLI/MCP surface, or another explicit trusted interface.
• Normalize plugin command results into a common runtime event shape so the TUI can render output, status, errors, and artifacts consistently.
• Add artifact detectors for plugin run directories, Seed files, handoff manifests, and future workflow outputs.
• Keep continuation decisions policy-driven instead of embedding plugin-specific behavior in the terminal event loop.
• Preserve existing core workflow routing while making plugin routing feel native rather than bolted on.

Milestones

1. Generic plugin command bridge
   Complete the scope in Support natural-language dispatch for installed Ouroboros UserLevel plugins #2 for direct ooo <plugin> ... dispatch, trust-blocked guidance, output rendering, and Seed detection.

2. Natural-language plugin intent routing
   Route confident mentions of installed plugin names and command names to the same dispatch bridge, with ambiguity handled through user confirmation instead of guessing.

3. Artifact-aware continuation
   Promote generated Seeds and handoffs into visible next steps, with policy-controlled execution of follow-up ooo run flows.

4. Unified workflow activity model
   Represent core workflows, plugin runs, generated artifacts, and continuation actions through one status/event model in the TUI.

5. Plugin-agnostic ecosystem readiness
   Validate the bridge against at least one additional UserLevel plugin beyond Superpowers to ensure the design is generic.

Acceptance criteria

• The implementation direction for Support natural-language dispatch for installed Ouroboros UserLevel plugins #2 is aligned with this broader vision instead of hard-coding only the Superpowers happy path.
• Direct plugin commands, natural-language plugin intents, generated artifacts, and continuation prompts share a common routing and event model.
• Trust failures, missing plugins, missing commands, and destructive-action blocks produce actionable guidance without implicit permission changes.
• Generated Seeds and handoff artifacts are surfaced as first-class workflow state in ourocode.
• The architecture remains plugin-agnostic and can support additional installed UserLevel plugins without terminal-event-loop rewrites.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.