You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #2 defines the first product boundary for running installed Ouroboros UserLevel plugins directly inside ourocode: resolve plugin intent, dispatch through the Ouroboros trust/firewall layer, capture generated artifacts, and optionally continue into ooo run.
Once that bridge exists, the next product step should not be only one-off plugin execution. Successful plugin workflows should become repeatable, inspectable recipes that users can run again without reconstructing the same natural-language prompt, command flags, artifact handling, and continuation policy each time.
Vision
ourocode should let trusted plugin workflows graduate into reusable recipes: named, reviewable workflow templates that preserve the user's intent, plugin command, trust assumptions, input shape, generated artifact expectations, and continuation behavior.
A user should be able to run a workflow once, see that it produced the right handoff, and then save that path as something like:
Later, they should be able to invoke it naturally:
Use the saved TDD handoff recipe for retry behavior in the HTTP transport.
Product principles
Recipes are not a bypass around plugin trust. They must still resolve the installed plugin, declared command, and current trust state at execution time.
Recipes should be transparent before execution: show the plugin, command, inputs, expected artifacts, and continuation policy.
Recipes should remain portable enough to share in a repository or team workflow, while keeping local secrets and trust grants out of the recipe itself.
Recipes should make repeated workflows faster without hiding meaningful execution decisions from the user.
Initial scope
Capture a successful plugin invocation as a recipe draft.
Store the recipe in a predictable project-local or user-local location.
Support required and optional inputs instead of saving one frozen command string.
Re-resolve plugin capability and trust before each run.
Display a review step before executing a saved recipe.
Preserve artifact capture and continuation behavior from the original plugin dispatch flow.
Acceptance criteria
After a successful trusted plugin workflow, ourocode can present a recipe draft with plugin, command, inputs, expected artifacts, and continuation policy.
A saved recipe can be invoked by name from inside ourocode.
Context
Issue #2 defines the first product boundary for running installed Ouroboros UserLevel plugins directly inside
ourocode: resolve plugin intent, dispatch through the Ouroboros trust/firewall layer, capture generated artifacts, and optionally continue intoooo run.Once that bridge exists, the next product step should not be only one-off plugin execution. Successful plugin workflows should become repeatable, inspectable recipes that users can run again without reconstructing the same natural-language prompt, command flags, artifact handling, and continuation policy each time.
Vision
ourocodeshould let trusted plugin workflows graduate into reusable recipes: named, reviewable workflow templates that preserve the user's intent, plugin command, trust assumptions, input shape, generated artifact expectations, and continuation behavior.A user should be able to run a workflow once, see that it produced the right handoff, and then save that path as something like:
Later, they should be able to invoke it naturally:
Product principles
Initial scope
Acceptance criteria
ourocodecan present a recipe draft with plugin, command, inputs, expected artifacts, and continuation policy.ourocode.Non-goals
Related: #2