Vision: make plugin handoffs first-class workspace artifacts

[Q00]

Vision

ourocode should treat plugin-generated handoffs as first-class workspace artifacts, not as files users have to discover manually after a plugin command finishes.

Issue #2 focuses on the dispatch bridge: detecting plugin intent, resolving installed UserLevel plugins, invoking them through the Ouroboros trust boundary, streaming output, and detecting generated seeds. This issue captures the broader product direction that should guide that implementation.

The goal is for ourocode to become the place where a user can understand, review, continue, and audit a plugin workflow from intent through handoff and execution.

Why this matters

UserLevel plugins can produce important intermediate artifacts: seed.md, handoff notes, run metadata, logs, suggested next commands, and policy decisions. If those artifacts remain hidden in internal run-storage paths, the user is forced back into shell/file-system navigation at the exact moment the workflow should become clearer.

A plugin-native ourocode experience should make those artifacts visible and actionable in the TUI while preserving trust boundaries.

Product principles

• Artifacts before automation: show generated handoffs clearly before continuing into execution unless policy explicitly allows auto-continuation.
• Continuations are reviewable: when a plugin produces seed.md, show the proposed ooo run seed_path=... continuation with enough context for the user to approve or decline.
• Workspace memory is durable: plugin runs, generated artifacts, decisions, and continuation status should survive pane refreshes, session recovery, and process restarts when possible.
• Trust remains explicit: ourocode should explain missing trust or blocked capabilities without silently granting plugin permissions.
• The user should not need to know internal run-storage paths: paths can be visible for auditability, but the primary interaction should be artifact-centric.

Desired experience

After a command such as:

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

ourocode should render a workflow result that answers:

• What plugin and command ran?
• Was it trusted, blocked, cancelled, or completed?
• What artifacts were produced?
• Which artifact is the recommended handoff?
• What continuation is available?
• Has the continuation already been run?

For natural-language plugin prompts, the same artifact model should be used after intent resolution and dispatch.

Proposed scope

Build a small artifact/workflow model around plugin-generated outputs:

1. Represent plugin run artifacts with stable metadata:
   • plugin name
   • command name
   • run id
   • artifact type (seed, handoff, log, metadata, unknown)
   • path
   • created/updated timestamp when available
   • continuation hint when applicable
2. Surface artifacts in the child pane/status area after plugin completion.
3. Highlight the best next action for generated seeds without hiding the underlying path.
4. Track continuation state:
   • not offered
   • offered
   • accepted
   • running
   • completed
   • failed
   • declined
5. Persist enough metadata for session recovery and audit views.
6. Keep the implementation generic so superpowers is the golden path, not a hard-coded special case.

Acceptance criteria

• A plugin run that produces a seed through the stable artifact contract is shown in ourocode as a generated seed artifact.
• The TUI displays the suggested continuation command, including ooo run seed_path=<generated-seed>.
• The user can distinguish plugin output, generated artifacts, and follow-up workflow execution status.
• Artifact metadata is recoverable after a pane/session refresh when the underlying run directory still exists.
• Missing, malformed, or multiple candidate handoffs are handled explicitly instead of choosing silently.
• Tests cover artifact classification, continuation hint generation, recovery metadata, and ambiguous artifact handling.

Non-goals

• Auto-trusting plugins.
• Creating a full plugin marketplace UI.
• Replacing the Ouroboros plugin firewall.
• Hard-coding behavior only for superpowers.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• Complements the plugin dispatch bridge by defining the post-dispatch artifact and continuation experience.