Vision: make plugin workflows completion-aware from intent to verified outcome

[Q00]

Context

Issue #2 defines the first missing bridge: ourocode should let users invoke installed Ouroboros UserLevel plugins from inside the TUI, either through direct ooo <plugin> ... prompts or natural language, without dropping to shell commands.

That bridge is necessary, but it should not be the end of the product experience. A plugin workflow often produces a handoff or seed.md, which then starts another Ouroboros execution step. If ourocode only dispatches the plugin and exposes the next command, the user still has to mentally track whether the original goal was actually completed.

The broader vision is that ourocode should carry the user's intent all the way from plugin dispatch to verified outcome.

Vision

ourocode should make plugin-driven work completion-aware.

When a user asks for a workflow such as:

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

ourocode should preserve the original objective, connect it to the selected plugin command, attach the generated Seed or handoff, follow the subsequent ooo run execution, and summarize whether the resulting work satisfied the expected completion criteria.

The user should be able to answer, inside the TUI:

• What did I ask ourocode to accomplish?
• Which plugin workflow was selected and why?
• What Seed, handoff, or run artifact did it generate?
• Did the follow-up execution complete, fail, or need more input?
• Which acceptance criteria, tests, or verification signals passed or failed?
• What is the next safe action if the goal is not done?

Product direction

Issue #2 should become the first vertical slice of a larger completion loop:

1. Capture the user's original objective as a durable workflow goal.
2. Resolve and dispatch the trusted plugin through the safe plugin bridge.
3. Detect generated artifacts such as seed.md, handoffs, reports, and run manifests.
4. Continue into ooo run only when user intent and policy allow it.
5. Attach execution status, tests, QA verdicts, and acceptance-criteria evidence back to the original objective.
6. Render a concise outcome summary instead of leaving the user with raw logs and scattered files.

This keeps ourocode focused on operator experience while Ouroboros continues to own workflow execution semantics.

Desired UX

After a plugin workflow and generated Seed run complete, ourocode should show a compact completion summary:

Goal: Add retry behavior
Source: superpowers test-driven-development
Generated Seed: stable plugin artifact reference
Execution: completed
Verification: 8 tests passed, 1 acceptance criterion needs review
Next action: inspect failing criterion / continue repair loop / finish

For failed or partial runs, the summary should make the blocking state clear and preserve enough context to resume or repair without re-discovering files manually.

Principles

• The user's original intent is workflow state, not disposable prompt text.
• Generated Seeds and handoffs should inherit goal context from the plugin workflow that produced them.
• Completion should be based on explicit evidence: tests, acceptance criteria, QA verdicts, or declared workflow outputs.
• Partial success should be visible; ourocode should distinguish completed, failed, blocked, needs review, and needs continuation.
• The completion model should work for any trusted plugin workflow, not only the superpowers happy path.
• ourocode should summarize and connect evidence, not invent success when no verification signal exists.

Proposed scope

1. Define a normalized workflow goal record that links original prompt, resolved plugin command, generated artifacts, follow-up runs, and verification evidence.
2. Preserve goal provenance when a plugin-generated seed.md is passed into ooo run.
3. Collect completion signals from execution status, test output, QA/evaluation results, and acceptance-criteria events where available.
4. Render an outcome summary in the TUI for completed, failed, blocked, and needs-review states.
5. Add continuation actions for repair, inspect evidence, rerun verification, or finish.
6. Persist enough state for session replay and recovery to reconstruct the goal-to-outcome chain.
7. Add tests for successful completion, partial verification failure, blocked continuation, missing evidence, and resumed-session summaries.

Acceptance criteria

• A plugin workflow started from direct command or natural language creates a durable workflow goal linked to the original user intent.
• Generated seed.md or handoff artifacts preserve provenance back to the plugin command that created them.
• Follow-up ooo run execution can be associated with the originating plugin workflow goal.
• The TUI can show an outcome summary that includes goal, plugin command, generated artifact, execution state, verification evidence, and next action.
• If no verification evidence exists, ourocode labels the outcome as unverified instead of complete.
• Failed, blocked, and partially verified outcomes are recoverable through explicit next actions.
• Tests cover provenance linking, completion-state projection, missing evidence handling, verification failure, and session recovery.

Non-goals

• Implementing the UserLevel plugin dispatch bridge itself; that belongs to Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• Replacing Ouroboros execution, evaluation, or trust semantics inside ourocode.
• Auto-running generated work without user intent and policy approval.
• Claiming completion based only on plugin process exit code.
• Building a full project-management dashboard.

Related

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2.
• Complements the plugin artifact, planning, audit, trust, and durable-session vision issues by adding an explicit definition of verified completion.