Vision: treat plugin run artifacts and continuations as first-class session objects

[Q00]

Vision

ourocode should treat plugin run outputs as first-class session objects, not as files the user has to discover manually after a plugin finishes.

Issue #2 defines the missing dispatch bridge for installed Ouroboros UserLevel plugins. Once ourocode can safely invoke a trusted plugin, the next product boundary is the lifecycle after invocation: understanding what the plugin produced, showing it in the active TUI session, and guiding the user toward the next safe continuation step.

The user should not need to leave ourocode, inspect stable plugin artifact reference, copy a generated seed.md path, and manually type the next ooo run seed_path=... command.

Product direction

Plugin execution should produce session-visible records that ourocode can render, audit, and continue from:

• the plugin identity and command that ran
• trust and permission state at dispatch time
• the run directory or external artifact location
• generated handoff files, reports, Seeds, or logs
• recommended continuation actions
• whether continuation is read-only, review-required, or blocked by policy

This turns plugin workflows into a coherent in-session experience instead of a shell-oriented handoff.

Target UX

A user runs a plugin workflow inside ourocode:

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

Expected behavior:

• ourocode streams plugin progress in a child pane or status surface.
• When the plugin finishes, generated artifacts are attached to the current session.
• If stable plugin artifact reference.mdexists,ourocode` displays it as a generated Seed artifact.
• The TUI presents the next safe action, such as:

ooo run seed_path=stable plugin artifact reference.md

• Auto-continuation only happens when the user explicitly requested it and policy allows it.

Principles

• Generated artifacts should be visible, attributable, and reviewable.
• ourocode should preserve the provenance chain from user intent to plugin command to generated Seed.
• Continuation should be policy-aware; no generated workflow should run silently across a trust or destructive-action boundary.
• Artifact detection should be generic and plugin-metadata-driven where possible, not hardcoded only for superpowers.
• Missing or malformed artifacts should produce actionable diagnostics rather than silent failure.

Proposed scope

1. Define a normalized internal record for plugin run artifacts.
2. Detect common Ouroboros plugin output locations such as stable plugin artifact reference.
3. Identify generated seed.md, handoff files, reports, and logs when declared by plugin metadata or observed in the run directory.
4. Attach artifact records to the active ourocode session and journal.
5. Render generated artifacts in the TUI with clear provenance and next-step affordances.
6. Add a continuation policy that distinguishes suggest-only, confirm-before-run, auto-run-allowed, and blocked states.
7. Test artifact detection, malformed/missing artifact handling, provenance recording, and continuation policy decisions.

Acceptance criteria

• After a trusted plugin command completes, ourocode records the plugin run directory and generated artifacts in the current session.
• Generated seed.md files are detected and surfaced as Seed-compatible artifacts.
• The TUI can show the next ooo run seed_path=... action without requiring the user to inspect the filesystem manually.
• Continuation into ooo run happens only when explicitly requested by the user and allowed by policy.
• Artifact records include enough provenance to answer which user prompt, plugin, command, and run produced them.
• Missing, malformed, or untrusted artifact states are visible and actionable.
• Tests cover successful Seed detection, no-artifact completion, malformed artifact paths, policy-blocked continuation, and journal/provenance recording.

Non-goals

• Auto-trusting or auto-installing plugins.
• Running generated Seeds without explicit user intent or policy approval.
• Building a full artifact browser or marketplace UI.
• Replacing the Ouroboros plugin firewall.
• Hardcoding the artifact lifecycle only around the superpowers plugin.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• Complements Build a plugin capability index for intent-driven workflows #5 by consuming plugin capability metadata for expected outputs.
• Fits under the broader orchestration vision in Vision: make ourocode the orchestration front door for trusted plugin workflows #6.