Vision: make plugin workflow runs controllable as durable sessions

[Q00]

Context

Issue #2 defines the first product boundary for installed Ouroboros UserLevel plugins inside ourocode: users should be able to invoke trusted plugins through direct ooo <plugin> ... prompts or natural language without leaving the TUI. PR #3 documents that bridge and uses superpowers as the motivating example.

That bridge should not stop at command dispatch. Once plugin workflows become native to ourocode, their runs need to feel like first-class, controllable sessions rather than opaque subprocesses that merely print output.

Vision

ourocode should treat every trusted plugin workflow run as a durable session with explicit lifecycle control, observable progress, recoverable state, and reviewable artifacts.

A user should be able to start a workflow, understand what phase it is in, pause or cancel it when needed, resume it after interruption, inspect the generated artifacts, and continue into the next ooo run step without manually reconstructing what happened.

In practice, plugin workflows should feel less like one-off commands and more like managed Ouroboros work units.

Desired experience

A user can type:

ooo superpowers test-driven-development --goal "Add retry behavior"

Then ourocode should surface the run as an active session:

• current plugin, command, goal, and trust scope
• lifecycle state such as queued, running, awaiting approval, paused, completed, failed, or cancelled
• recent output and structured progress events
• generated artifact paths, especially handoffs and seed.md files
• available next actions such as inspect, resume, cancel, replay, or continue with ooo run seed_path=...

The same model should work when the workflow is started through natural language instead of a direct command.

Product principles

• Plugin runs should be durable enough to survive TUI refreshes, interrupted terminals, and session reloads.
• Lifecycle controls should respect the existing Ouroboros trust and firewall model.
• ourocode should never hide important plugin state behind raw logs only.
• Continuation into generated Seeds or handoffs should be explicit, policy-driven, and inspectable.
• The same session model should support simple read-only commands and long-running workflow commands.

Proposed scope

1. Define a plugin run session model with stable IDs, lifecycle states, timestamps, command metadata, trust metadata, and artifact references.
2. Persist enough run state to recover active/recent plugin workflows after restarting or resuming ourocode.
3. Render active plugin runs in the TUI with clear status and available actions.
4. Add lifecycle commands or palette actions for inspect, pause/resume where supported, cancel, replay output, and continue from generated artifacts.
5. Normalize plugin output into structured progress events where the plugin surface provides enough information, while preserving raw output as a fallback.
6. Connect generated handoff/Seed artifacts to the existing ooo run flow without requiring users to manually search stable plugin artifact reference.

Acceptance criteria

• A plugin workflow started inside ourocode appears as a durable run session with a stable ID and visible lifecycle state.
• Restarting or resuming ourocode can rediscover recent plugin runs and their generated artifacts.
• Users can inspect recent output and artifact paths for a completed or failed plugin run.
• Users can cancel an active plugin run through a safe, explicit control path when the underlying execution supports cancellation.
• When a run produces a seed.md, the TUI presents the exact continuation action and does not require manual filesystem discovery.
• Tests cover lifecycle projection, persistence/recovery, artifact linking, cancellation behavior, and continuation rendering.

Non-goals

• Replacing the Ouroboros plugin trust/firewall system.
• Guaranteeing pause/resume support for plugins that do not expose resumable execution semantics.
• Building a marketplace, plugin catalog, or install flow.
• Auto-running generated handoffs without policy approval.

Relationship to #2

Issue #2 answers: how does ourocode safely dispatch installed plugins from direct commands or natural language?

This issue answers: once dispatched, how does ourocode make plugin workflow execution observable, durable, and controllable as part of the user's working session?