Vision: make ourocode a policy-driven workflow conductor

[Q00]

Vision

ourocode should become a policy-driven workflow conductor for Ouroboros, not a thin shell proxy for plugin commands.

Issue #2 identifies the immediate missing bridge: users should be able to run installed Ouroboros UserLevel plugins from inside ourocode, either with direct ooo <plugin> ... commands or natural-language prompts. The deeper vision is that every dispatch decision should be understood, constrained, observable, and continuable by ourocode as product state.

A plugin command should not merely be forwarded somewhere and forgotten. It should become a structured workflow step with identity, trust status, declared capability, live output, produced artifacts, and a clear next action.

Product principle

The user should be able to stay inside ourocode and ask for outcomes, while ourocode handles the orchestration discipline:

• resolve intent into a known core workflow, trusted plugin command, MCP tool, or dynamic skill
• explain what will run before crossing a trust or destructive-action boundary
• dispatch through the appropriate Ouroboros safety surface instead of arbitrary shell execution
• stream execution status into the TUI without losing provenance
• capture generated Seeds, handoffs, reports, and run directories as session state
• decide whether the next step should be suggested, confirmed, auto-run, or blocked by policy

Why this matters

The value of ourocode is not only that it can start workflows. Its value is that it can keep the workflow coherent after the first command runs.

Without this product boundary, UserLevel plugins remain external commands that force users to inspect files, copy paths, and manually decide the next ooo run step. With this boundary, plugins become composable capabilities that ourocode can route, observe, audit, and continue safely.

Relationship to #2 and PR #3

• Support natural-language dispatch for installed Ouroboros UserLevel plugins #2 is the first implementation slice: safe natural-language and command-shaped dispatch for installed UserLevel plugins.
• PR docs: rescope userlevel plugin dispatch around SSOT #25 (PR 1/5) #3 documents that missing dispatch bridge and uses superpowers as the concrete example.
• This issue defines the broader conductor model that should guide follow-up work after the first bridge exists.

The bridge should be designed so it can grow into policy-aware orchestration instead of becoming a plugin-specific command passthrough.

Target behavior

Before execution

When a user enters:

Use Superpowers test-driven-development to add retry behavior, then run the generated handoff.

ourocode should resolve the likely plugin and command, check installation and trust state, classify the requested continuation, and make any trust or destructive boundary explicit before execution.

During execution

The plugin run should appear as a structured activity in the TUI, with streamed output, plugin identity, command identity, and enough context to understand what is happening without leaving the session.

After execution

Generated artifacts should be attached to the session:

• run directory
• generated seed.md
• handoff or report files
• logs or diagnostics
• recommended next command
• continuation policy result

If a Seed is produced, the next action should be visible as something like:

ooo run seed_path=stable plugin artifact reference.md

Running that continuation should require explicit user intent or an allow policy. It should never happen as an accidental side effect of plugin dispatch.

Architectural direction

• Represent dispatchable work as capabilities with normalized metadata: name, source, trust state, inputs, outputs, side-effect class, and continuation hints.
• Share the same resolution path for direct ooo ... commands and natural-language plugin intents.
• Keep plugin execution behind the Ouroboros plugin firewall or another stable trusted surface.
• Normalize plugin run events into the same runtime/event model used by the TUI for core workflows.
• Treat generated artifacts as first-class session and journal records, not hidden filesystem side effects.
• Make continuation policy explicit and testable instead of embedding plugin-specific rules inside the terminal event loop.

Acceptance criteria

• Follow-up implementation issues can describe where they fit in the conductor model: intent resolution, policy, dispatch, event streaming, artifact capture, or continuation.
• Plugin dispatch does not depend on arbitrary shell-string execution.
• Trust failures and destructive-action blocks produce precise, non-destructive guidance.
• Generated Seeds and handoffs include provenance linking them back to the user prompt, plugin, command, and run.
• Continuation from generated artifacts is governed by explicit policy and user intent.
• The design remains generic enough to support plugins beyond superpowers.

Non-goals

• Auto-installing or auto-trusting plugins.
• Replacing Ouroboros plugin trust/firewall semantics.
• Building a marketplace UI.
• Treating every natural-language prompt as safe to execute without confirmation.
• Hardcoding the conductor model around one plugin.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• Informed by PR docs: rescope userlevel plugin dispatch around SSOT #25 (PR 1/5) #3.
• Complements the existing vision issues around plugin-native orchestration, artifacts, capability registries, and auditability.