Vision: make ourocode the terminal-native orchestration layer for Ouroboros

[Q00]

Vision

ourocode should become the terminal-native orchestration layer for the whole Ouroboros ecosystem, not just a nicer shell around a few core ooo commands.

Issue #2 highlights the immediate gap: installed Ouroboros UserLevel plugins can already produce valuable workflows and artifacts, but users still have to leave ourocode, run shell commands manually, find generated files, and return with ooo run seed_path=.... That is a symptom of a larger product boundary problem.

The long-term vision is that users should be able to stay inside ourocode and express intent in the way they naturally think:

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

ourocode should resolve that intent into trusted Ouroboros capabilities, execute them through the right safety boundary, show progress in the TUI, capture artifacts, and guide or continue the next step.

Product direction

ourocode should feel like the control room for Ouroboros:

• Core workflows such as interview, seed, run, evolve, ralph, and QA are first-class.
• Installed UserLevel plugins are discoverable and invokable from the same interaction model.
• Natural-language intent and direct command-shaped prompts converge into the same safe dispatch path.
• Generated artifacts become visible, actionable state inside the TUI rather than files users must hunt for.
• Continuations are explicit and policy-aware: inspect commands stop, handoff-producing commands can offer or trigger the next workflow step, and destructive actions remain gated.
• Trust, permissions, and provenance are surfaced clearly instead of hidden behind shell execution.

Why this matters

The value of Ouroboros increases when workflows compose. A plugin should not be an isolated command that drops files somewhere; it should become a capability that ourocode can understand, route, observe, and chain.

This would make ourocode the user-facing layer where:

1. intent is captured,
2. the correct Ouroboros capability is selected,
3. execution happens inside existing trust boundaries,
4. artifacts are tracked, and
5. the next useful action is obvious.

Relationship to #2

Issue #2 can be treated as the first concrete implementation slice of this vision: a safe dispatch bridge for installed UserLevel plugins, starting with command-shaped prompts and natural-language routing for known plugin commands.

This vision issue should guide follow-up work beyond that first slice, including artifact indexing, workflow continuation policy, plugin capability discovery, and richer TUI surfaces for plugin execution.

Possible milestones

1. Implement safe UserLevel plugin dispatch from inside ourocode (Support natural-language dispatch for installed Ouroboros UserLevel plugins #2).
2. Add a unified capability registry that can represent core commands, MCP tools, dynamic skills, and trusted plugins.
3. Track generated artifacts as structured runtime state, not just terminal output.
4. Add continuation policies for handoff-producing workflows.
5. Expose plugin/workflow runs in dedicated child panes with provenance, trust status, logs, and next actions.
6. Support natural-language routing across all registered capabilities with transparent explanations when confidence is low.

Non-goals

• Bypassing Ouroboros plugin trust or firewall semantics.
• Auto-installing or auto-trusting third-party plugins.
• Turning ourocode into a marketplace UI.
• Treating arbitrary shell command execution as equivalent to trusted workflow dispatch.

Acceptance criteria for the vision

• The project has a clear north star for plugin and workflow orchestration work.
• Implementation issues can be linked back to this vision when they improve capability routing, artifact tracking, continuation, or TUI orchestration.
• Security and trust boundaries remain explicit requirements for every slice of the work.