@loneexile/omp-superpowers 7.0.2-omp.2 → 7.0.2-omp.3

package/.pi/extensions/superpowers.ts

@@ -86,6 +86,8 @@ function piToolMapping(): string {
 
 This harness is omp (Oh My Pi). It has native skills but does not expose Claude Code's \`Skill\` tool. When a Superpowers instruction says to invoke a skill, read it with \`read skill://<name>\` when the skill applies, or let a human invoke \`/skill:name\` explicitly. Superpowers text names skills \`superpowers:<name>\`; read them as \`skill://<name>\`, without the prefix. \`read skill://superpowers:brainstorming\` returns "Unknown skill".
 
+omp's own instructions to act without asking for confirmation and to keep turns short do not cover a Superpowers approval step. A request that touches security, auth, concurrency, money or a data migration, or changes existing behavior (a default, an exit code, error handling, what happens with no input), or adds a config file, a stored format, an interface other code builds on or a dependency, goes through superpowers:brainstorming before any edit, however completely it is specified: read \`skill://brainstorming\` first. For a complete spec, brainstorming sends a short design and asks whether to go ahead.
+
 omp's built-in coding tools are lowercase: \`read\`, \`write\`, \`edit\`, \`bash\`, \`grep\`, \`glob\`. Use \`read\` for a file OR a directory listing, \`grep\` for file contents, and \`glob\` for finding paths by name. omp's own system prompt directs you to prefer these over shell \`ls\`, \`find\`, \`grep\`, and \`rg\`; follow that preference.
 
 omp ships a built-in subagent tool: \`task\`. Use it for all Superpowers subagent workflows. Batch shape (the \`task.batch\` setting, on by default): ONE call carries \`{ context, tasks[] }\` — one subagent per item, run concurrently. Every item also needs \`solutionSpace\`, one line on how open the problem is. Dispatch N parallel subagents as N entries in a single \`task\` call, never N sequential calls. Pick the most specific agent type per item from the roster in the \`task\` tool's own description (typically \`scout\` for read-only research, \`reviewer\`, \`security-reviewer\`, \`sonic\` for strictly mechanical work, and \`task\` for general-purpose). The tool is lowercase \`task\`; \`Task\` does not exist here. Never conclude that subagent capability is missing.

package/CHANGELOG.md

@@ -6,6 +6,24 @@ A version is `<upstream version>-omp.<n>`: the upstream release this fork is syn
 
 ## [Unreleased]
 
+## [7.0.2-omp.3] - 2026-11-09
+
+### Fixed
+
+- **On omp 18.18.3, a fully specified behavior change waits for your approval again.** omp 18.18.3's system prompt gained speed rules ("Every turn costs seconds… Once the change is verified, stop and report"; "Verify proportionally"), and with them a request like "Make `todo add` reject empty or whitespace-only text … exit with code 2" skipped brainstorming and was built straight away: 12 of 12 runs in a normal omp setup with 7.0.2-omp.2, and 46 of 48 skipped on an API key with either 7.0.2-omp.1 or 7.0.2-omp.2, all built before approval. On omp 18.18.1 the same request had read brainstorming in 10 of 12 runs and built nothing. The agents' reason was that the spec was complete. The extension's injected omp tool mapping now says that omp's act-without-asking and short-turn rules don't cover a Superpowers approval step, and that a request on brainstorming's never-small list (security, auth, concurrency, money, data migrations, changes to existing behavior, new config files, stored formats, interfaces or dependencies) goes through brainstorming before any edit, however completely it is specified. The pass rule was fixed before the runs. On omp 18.18.3, claude-opus-5-5 on an API key, both profiles given the same cached skill descriptions:
+  - That request, 12 runs per release: 7.0.2-omp.2 built it before approval 12 of 12; this release read brainstorming first and sent a short design with a go-ahead question 12 of 12, building nothing.
+  - Requests that leave something open (a spec with a shortcut conflict, "a way to share my todo list", "Let's make a react todo list"), 4 runs each: brainstorming first and nothing built, 12 of 12.
+  - A typo fix ("Todo Lisst" → "Todo List" in the README heading), 4 runs per release: fixed directly, without brainstorming, 4 of 4 in both.
+
+### Changed
+
+- **The `task.isolation` notes are re-measured on omp 18.18.3 with ovnfs.** With `isolation.backend: auto` and ovnfs on `PATH`, isolated subagents run in ovnfs checkouts, which last until omp exits. With a stub model in both merge modes: `merge: patch` still applies an uncommitted patch; `merge: branch` still lands the work on your branch (same message and author, a new commit id only when the commit time differs) and deletes the task branch; a conflict still leaves `omp/task/<id>`; and a follow-up message to an isolated subagent is still delivered without its work ever reaching your branch, ending on a leftover `omp/task/<id>` branch after exit. `pi-tools.md` and the README now say so instead of citing omp's documentation as unmeasured.
+- **The README's A/B testing note** passes an API key to test runs as `ANTHROPIC_API_KEY` and keeps OAuth logins out of test profiles, since a token refresh there can sign your main profile out. It also says to fix the pass/fail rule before the runs, to give both arms the same cached skill descriptions (omp rewrites them per profile, so they differ), and never to reuse a scratch path with ovnfs.
+
+### Correction
+
+- **7.0.2-omp.2's skip counts were confounded.** omp turns each skill description into a short routing hint with a model and caches it per profile, so that release's test profiles showed brainstorming under different wording even though the packages' descriptions are identical. Its "5 of 36 against 0 of 12" skip comparison is therefore not a comparison of the two releases; its counts among runs that loaded the skill are unaffected.
+
 ## [7.0.2-omp.2] - 2026-11-08
 
 Measured on omp 18.18.1 with ovnfs installed, so every system prompt carried omp's *Separate checkouts* section; claude-opus-5-5 as the controller, each arm linked into its own isolated profile, arms interleaved, results graded blind and then read by hand.
@@ -189,7 +207,8 @@ First release, synced to upstream [v6.4.2](https://github.com/obra/superpowers/b
 - The fork's rewritten subagent-driven-development text invokes its helper scripts through `bash` as well, so a package extractor that drops exec bits cannot break them.
 - `sdd-final-reviewer` carries upstream's new review rules from `code-reviewer.md`, the template it replaces in SDD's final review: the spec is a vision document (behavior it is silent on is graded by what a reasonable person expects), and a "Declined to judge" section that the controller rules on and ledgers like a plan conflict.
 
-[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.2-omp.2...HEAD
+[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.2-omp.3...HEAD
+[7.0.2-omp.3]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.2-omp.3
 [7.0.2-omp.2]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.2-omp.2
 [7.0.2-omp.1]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.2-omp.1
 [7.0.1-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.1-omp.4

package/README.md

@@ -78,7 +78,7 @@ flowchart TD
 
 The usual path, skill by skill:
 
-1. `read skill://brainstorming` — turn an idea into a design. It reads the project first, asks what you want something for when you haven't said, asks only questions whose answers change what gets built, and lays out nameable choices with a recommendation. When nothing is open, its first message is a short design for you to approve. A small change stops here: after you approve it in chat, the session builds it itself, test first, and commits once
+1. `read skill://brainstorming` — turn an idea into a design. It reads the project first, asks what you want something for when you haven't said, asks only questions whose answers change what gets built, and lays out nameable choices with a recommendation. When nothing is open, its first message is a short design for you to approve. A small change stops here: after you approve it in chat, the session builds it itself, test first, and commits once. A change to existing behavior (an exit code, error handling, a default) or anything else on its never-small list waits for your approval however completely you specified it; the extension tells the agent that omp's act-without-asking rules don't override that, which omp 18.18.3 otherwise does
 2. `read skill://writing-plans` — produce `docs/plans/<date>-<name>.md`, pick the execution method, and ask once for approval of the design, the plan and the method together
 3. `read skill://subagent-driven-development` — execute the plan via subagents, independent tasks in parallel. If you swap to Native in that approval, `executing-plans` runs instead: the session does every task itself, and only the final review is a subagent (`sdd-final-reviewer`)
 4. `read skill://finishing-a-development-branch` — merge, open a PR, or keep the branch
@@ -179,7 +179,7 @@ Two ovnfs facts the skills work around, measured on ovnfs with omp 18.18.1:
 - `ovnfs apply <checkout> --branch main`, while your folder has `main` checked out, moves `main` and the index but not the files, so the folder then shows the merge as uncommitted changes that undo it. Plain `ovnfs apply <checkout>` brings changes back as uncommitted edits, without the commits.
 - `.superpowers/` (the SDD workspace and ledger) is ignored, so it never comes back with `ovnfs apply`; it is scratch either way.
 
-According to omp's documentation, omp also runs `task.isolation` subagents in ovnfs checkouts when its `isolation.backend` is `auto`; that was not measured here. subagent-driven-development does not use that switch (see *Settings worth knowing*).
+omp also runs `task.isolation` subagents in ovnfs checkouts when its `isolation.backend` is `auto` (measured on omp 18.18.3); each checkout lasts until omp exits. subagent-driven-development does not use that switch (see *Settings worth knowing*).
 
 ## Changing models (no file edits)
 
@@ -239,7 +239,7 @@ Measured on a real fix-round re-review with identical inputs: a grok-4.6 seat to
 
 | setting | why |
 |---|---|
-| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default, and SDD does not use it. Under the default `merge: patch` isolated work returns as an uncommitted patch; `merge: branch` keeps commits but applies them as each task ends, before review, under new ids. Either way, an isolated subagent cannot take a fix round: on omp 18.11.0 a message to one is delivered, but its fix never reaches your branch while the session runs. With `auto` and ovnfs on `PATH`, omp 18.18.1 runs isolated subagents in ovnfs checkouts (from omp's documentation; not measured here). Parallel tasks get their own `omp worktree add` worktrees instead |
+| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default, and SDD does not use it. Under the default `merge: patch` isolated work returns as an uncommitted patch; `merge: branch` keeps commits but applies them as each task ends, before review. Either way, an isolated subagent cannot take a fix round: a message to one is delivered, but its fix never reaches your branch while the session runs, and after the session it sits on a leftover `omp/task/<id>` branch (measured on omp 18.11.0, and on 18.18.3 with ovnfs in both merge modes). With `auto` and ovnfs on `PATH`, isolated subagents run in ovnfs checkouts. Parallel tasks get their own `omp worktree add` worktrees instead |
 | `ovnfs.path` | where omp finds the ovnfs binary (default: `ovnfs` on `PATH`). Found means the *Separate checkouts* section is in every system prompt; see [Separate copies](#separate-copies-worktrees-and-ovnfs) |
 | `task.enableEffort` | exposes per-dispatch `effort` (`"lo"`, `"med"`, `"hi"`); `"hi"` maps to the model's top supported level, capped by `task.maxEffort`. SDD uses `effort: "hi"` for high-risk task reviews, and for escalation only when a host override lowers that seat |
 | `task.showResolvedModelBadge` (default off) | shows the model each subagent actually ran. A seat whose pinned provider has no credentials silently runs on another model |
@@ -253,7 +253,7 @@ In short: the omp extension and `pi-tools.md` describe omp's real tools; five `s
 <details>
 <summary><b>File by file</b></summary>
 
-- `.pi/extensions/superpowers.ts` — the injected mapping names `task`, `todo`, the `sdd-*` roster, and the no-`model:`-field rule; it also skips subagent sessions; it tells a dispatching session to name the checks each subagent must run, since omp 18.4.12 tells subagents to leave builds, tests and smoke runs to the main agent unless their assignment explicitly instructs them; its last paragraph points a vibe-mode director (tools include `vibe_spawn` but not `task`) at the *Vibe mode* section of `pi-tools.md`
+- `.pi/extensions/superpowers.ts` — the injected mapping names `task`, `todo`, the `sdd-*` roster, and the no-`model:`-field rule; it says omp's act-without-asking and short-turn rules don't cover a Superpowers approval step, so a never-small request goes through brainstorming however completely it is specified; it also skips subagent sessions; it tells a dispatching session to name the checks each subagent must run, since omp 18.4.12 tells subagents to leave builds, tests and smoke runs to the main agent unless their assignment explicitly instructs them; its last paragraph points a vibe-mode director (tools include `vibe_spawn` but not `task`) at the *Vibe mode* section of `pi-tools.md`
 - `.omp-plugin/plugin.json` — new. Marks the repo root as an omp-native plugin so a marketplace or `--plugin-dir` install keeps each agent's `model:` line
 - `skills/using-superpowers/references/pi-tools.md` — same, as the reference doc; it also gains a *Checks* subsection (the 18.4.12 subagent hand-off rule, and why every dispatch names its checks) and a *Vibe mode* section: what a director keeps and lacks, how skill actions map onto `vibe_*` and workers, and the worktree and request-budget limits
 - `skills/brainstorming/` — upstream v7.0.2's questions (ask why first; ask only when the answer changes what gets built, otherwise state the call as a proposal; process steps are the agent's calls; nameable choices sketched with a pick; technical appetite read from how they talk; recon done, not offered; text sketches, the visual companion only when the look is theirs to decide), on top of the fork's own flow: a defined small-change path (after the in-chat approval the session builds it itself on a branch: the full suite before changing anything, test first, the covering tests and the suite again, then one commit of only its own files and hunks, with no design document, plan or subagents; security, auth, concurrency, money, migrations, changes one revert cannot undo, new config files or stored formats, changes to existing behavior, new interfaces other code builds on and new dependencies are never small, and none of them takes the quick-task route however complete the request); a request is a quick task only if doing it leaves no choice the person would see; each question asks one thing, with any reason before it; a playback rides along with the next question; the approaches ride with the last playback chunk instead of a message of their own; when nothing is open, the first message's short design asks whether to go ahead, and for a project that means writing it up with its plan; for software, the plan is written right after the builder check so the design and the plan get one approval. Upstream's short design doc and plan for every small change are not taken
@@ -298,7 +298,7 @@ The fork changes upstream's `docs/superpowers/specs` and `docs/superpowers/plans
 <details>
 <summary><b>Testing a skill change</b></summary>
 
-A change to a skill's text changes agent behavior, so it ships after a live A/B on omp: the released package against the candidate, each linked into its own isolated profile (`omp --profile <p> plugin link <unpacked package>`; `omp plugin install <file>.tgz` fails with `ENOTDIR` on 18.18.1), with credentials piped in (`omp auth export | omp --profile <p> auth import -`), the user's `config.yml` copied in, and memory, the advisor and auto-learn off. Profile names are lowercase. Run the arms interleaved in fresh scratch repos, grade the results blind, and delete the profiles afterwards. The CHANGELOG entry for each behavior change gives its scenario and counts.
+A change to a skill's text changes agent behavior, so it ships after a live A/B on omp: the released package against the candidate, each linked into its own isolated profile (`omp --profile <p> plugin link <unpacked package>`; `omp plugin install <file>.tgz` fails with `ENOTDIR` on 18.18.1), the user's `config.yml` copied in, and memory, the advisor and auto-learn off. Profile names are lowercase. For credentials, pass an API key to each test process as `ANTHROPIC_API_KEY` (for example read from a pay-as-you-go key kept in `~/.omp/.env`) and leave the test profile's auth store empty. Don't copy OAuth logins into test profiles with `omp auth import`: a token refresh in a test profile can rotate the refresh token and sign your main profile out. omp turns each skill description into a short routing hint with a model and caches it per profile (`skill-descriptions.db`), and the wording differs between profiles; seed both profiles with the same cache, for example a copy of `~/.omp/agent/skill-descriptions.db`, so the arms see the same hints when the result depends on which skill gets picked. Decide the pass/fail rule before the runs, run the arms interleaved in fresh scratch repos (ovnfs keeps state per source path, so never reuse one), grade the results blind, and delete the profiles afterwards. The CHANGELOG entry for each behavior change gives its scenario and counts.
 
 </details>
 
@@ -319,7 +319,7 @@ gh release create "v$v" --target main --title "v$v" --notes-file /tmp/notes.md
 <details>
 <summary><b>Checking a new omp version</b></summary>
 
-Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). The fork was first verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12, the `task.isolation` notes against 18.11.0 and, live, on 18.12.6, and the extension's per-prompt bootstrap, the helper scripts and the ovnfs paths live on 18.18.1. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), the docs at `omp read omp://`, and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
+Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). omp's own system prompt changes too: 18.18.3's speed rules made agents build fully specified behavior changes without brainstorming until the extension said those rules don't cover an approval step, so re-run a fully specified never-small request after each omp update. The fork was first verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12; the `task.isolation` notes against 18.11.0, live on 18.12.6, and again on 18.18.3 with ovnfs; the extension's per-prompt bootstrap, the helper scripts and the ovnfs paths live on 18.18.1; and the approval rule live on 18.18.3. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), the docs at `omp read omp://`, and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
 
 </details>
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loneexile/omp-superpowers",
-  "version": "7.0.2-omp.2",
+  "version": "7.0.2-omp.3",
   "description": "obra/superpowers adapted for Oh My Pi (omp): a truthful task/todo tool mapping and five subagent-driven-development agents, each with its own model, thinking level, and tools.",
   "type": "module",
   "keywords": [

package/skills/using-superpowers/references/pi-tools.md

@@ -18,7 +18,7 @@ Batch shape (the `task.batch` setting, on by default): one call carries `{ conte
 
 Agent types: pick the most specific one per item from the roster in the `task` tool's own description. Commonly available: `scout` (read-only research — use for investigation), `reviewer`, `security-reviewer`, `sonic` (strictly mechanical work), `task` (general-purpose, full capabilities). The exact roster depends on installed and configured agents, so read the tool description rather than assuming.
 
-The tool is lowercase `task`; `Task` does not exist. `task.isolation.enabled` (default off) only lets a dispatch mark items `isolated: true`. Under the default `task.isolation.merge: patch`, isolated work comes back as an applied, uncommitted patch. Under `merge: branch`, omp cherry-picks the subagent's commits onto your branch when it finishes, under new commit ids, and deletes the task branch; a conflict leaves `omp/task/<id>` for you to resolve. Never send an isolated subagent a follow-up. Measured on omp 18.11.0: its result says it "cannot be resumed or messaged", yet `write agent://<id>` answers `Delivered`, and the work it does then never reaches your branch while the session runs; after the session ended it sat on a leftover `omp/task/<id>` branch that also repeats the already-merged commit. Dispatch a fresh subagent instead. If a follow-up already went out, cherry-pick only its new commits from that branch, never merge the branch. Superpowers SDD does not use isolation.
+The tool is lowercase `task`; `Task` does not exist. `task.isolation.enabled` (default off) only lets a dispatch mark items `isolated: true`. With `isolation.backend: auto` and ovnfs on `PATH`, each isolated subagent works in its own ovnfs checkout; without ovnfs, in a native copy-on-write clone. Under the default `task.isolation.merge: patch`, isolated work comes back as an applied, uncommitted patch when the subagent finishes. Under `merge: branch`, omp commits the subagent's work onto your branch when it finishes (same message and author, a new commit id whenever the commit time differs) and deletes the task branch; a conflict leaves `omp/task/<id>` for you to resolve. Never send an isolated subagent a follow-up. Measured on omp 18.11.0, and again on 18.18.3 with ovnfs in both merge modes: its result says it "cannot be resumed or messaged", yet `write agent://<id>` answers `Delivered`, and the work it does then never reaches your branch while the session runs; after the session ended it sat on a leftover `omp/task/<id>` branch that also repeats the already-merged commit. Dispatch a fresh subagent instead. If a follow-up already went out, cherry-pick only its new commits from that branch, never merge the branch. Superpowers SDD does not use isolation.
 
 ### Model selection on omp