Skip to content

Keep Superpowers artifacts outside trusted plugin homes#128

Open
shaun0927 wants to merge 1 commit into
mainfrom
fix/superpowers-dispatch-artifacts
Open

Keep Superpowers artifacts outside trusted plugin homes#128
shaun0927 wants to merge 1 commit into
mainfrom
fix/superpowers-dispatch-artifacts

Conversation

@shaun0927
Copy link
Copy Markdown
Collaborator

Summary

Fixes the Superpowers adapter for manifest-facing dispatcher invocation (ouroboros superpowers ...) by keeping runtime artifacts out of the installed plugin home and accepting dispatcher-style --output-dir placement.

Problem

ouroboros superpowers test-driven-development ... launches the plugin entrypoint from the installed plugin home. Before this change, the adapter defaulted artifacts to ./.omx/superpowers, which mutates the plugin install directory. Because plugin homes are trust subjects, later invocations can be blocked by digest drift.

The dispatcher also passes user argv after the command name, so ouroboros superpowers test-driven-development --output-dir <path> reaches the plugin as:

python -m superpowers_ouroboros test-driven-development --output-dir <path>

The previous parser only accepted --output-dir before the subcommand.

Changes

  • Resolve output roots in this order:
    1. explicit --output-dir
    2. OUROBOROS_PLUGIN_OUTPUT_DIR
    3. OUROBOROS_PLUGIN_WORKDIR/.omx/superpowers
    4. current workspace .omx/superpowers
    5. safe user artifact root when invoked from the plugin tree
  • Allow --output-dir before or after the subcommand.
  • Add regression tests for dispatcher-style argv and avoiding plugin-home writes.

Validation

python3 -m compileall -q plugins/superpowers/superpowers_ouroboros
python3 scripts/validate_contract.py
python3 -m unittest tests.test_superpowers_plugin tests.test_validator

Also validated with the companion core branch that repeated dispatcher invocations work without trust-subject drift.

Dispatcher-based plugin invocation runs from the installed plugin home, so the Superpowers adapter must not default runtime artifacts into that immutable trust subject. Resolve output roots from explicit flags or dispatcher-provided environment first, then fall back to a user artifact area when running from the plugin tree.

Constraint: Ouroboros firewall refuses subsequent invocations when plugin_home bytes drift after install.
Rejected: Require users to always pass --output-dir | breaks manifest-facing dispatcher UX and still leaves future commands footgun-prone.
Confidence: high
Scope-risk: narrow
Directive: Do not write runtime .omx artifacts into installed plugin homes; they are code trust subjects.
Tested: python3 -m compileall -q plugins/superpowers/superpowers_ouroboros; python3 scripts/validate_contract.py; python3 -m unittest tests.test_superpowers_plugin tests.test_validator
Not-tested: Full production dispatcher after the companion Ouroboros core PR lands
@shaun0927 shaun0927 requested a review from Q00 as a code owner May 22, 2026 16:17
@shaun0927
Copy link
Copy Markdown
Collaborator Author

Path-contract review note:

A valid concern came up that .omx/superpowers is OMX-flavored and should not be imposed by Ouroboros core on users who do not run OMX. I re-checked the split:

  • This plugin PR keeps Superpowers' plugin-specific historical/default artifact layout compatible with Issue Epic: Expose every Superpowers skill as an Ouroboros-native agentOS command #28 (.omx/superpowers) for direct entrypoint usage.
  • It also honors OUROBOROS_PLUGIN_OUTPUT_DIR first, so manifest-facing ouroboros superpowers ... dispatch can place artifacts in the core-provided Ouroboros-native root.
  • The companion core PR has been amended to set OUROBOROS_PLUGIN_OUTPUT_DIR=<caller cwd>/.ouroboros/plugin-artifacts/<plugin-name> instead of .omx/<plugin>.

So non-OMX Ouroboros users on the dispatcher path get .ouroboros/plugin-artifacts/superpowers, while direct plugin users remain backward-compatible with the Issue #28 artifact examples unless they pass --output-dir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant