@loneexile/omp-superpowers 7.0.0-omp.2 → 7.0.0-omp.4

package/CHANGELOG.md

@@ -6,6 +6,32 @@ A version is `<upstream version>-omp.<n>`: the upstream release this fork is syn
 
 ## [Unreleased]
 
+## [7.0.0-omp.4] - 2026-10-16
+
+### Fixed
+
+Found by an independent review of 7.0.0-omp.3; a second review checked these fixes. Checked live on omp 18.11.1 with a three-task Python plan (an editable install in `.venv`). On the default workspace the controller ran `git status`, created the approved branch in place with no `/move`, ran tasks 1 and 2 in parallel worktrees, removed and recreated each cloned `.venv` and checked the import from `/` before dispatching, then merged both. Resumed from a ledger left mid-wave (task 1 merged but not ledgered, task 2 with no commits), it ledgered task 1 merged after the commit-count and ancestor checks, and re-dispatched task 2. The released 7.0.0-omp.3 text happened not to lose work in the same resume: its controller checked task 2's history before acting on the ancestor test.
+
+- **Resuming mid-wave no longer marks unstarted tasks as merged.** subagent-driven-development's resume rule ledgered a wave task `merged` when its branch tip was an ancestor of the plan branch, and a branch with no commits yet passes that test (`git merge-base --is-ancestor` exits 0). After a compaction or restart mid-wave, every unstarted sibling would have been ledgered merged and complete, its branch deleted, and its later work never merged. A wave task now counts as merged only when its branch also has commits past its BASE, and that check runs for every unfinished wave task, whatever its last ledger line. Resume then goes by each task's last line and covers `rebased` and `fix round` lines (read the agent first), review-list lines, `merge stuck`, a merge interrupted before its commit (`MERGE_HEAD`), and a wave whose suite has not passed. executing-plans finishes an open wave task under subagent-driven-development's rules instead of redoing it in place.
+- **The default workspace gets created.** writing-plans' approval names a new branch in this checkout, but both executors' Setup still sent the controller to make a worktree and wait for `/move`, or let it work on `main`, where the final review package comes out empty. Setup now creates the approved branch in place, runs project setup and baseline tests there, and ledgers the branch, so a resumed run only switches back to it. A change to a tracked file or anything staged goes back to the partner to commit or stash first, because a run in place commits from that index and tests that working tree; writing-plans' approval message says so up front, and implementers stage their own files by path. finishing-a-development-branch switches to the base branch before deleting a branch made in this checkout.
+- **Task worktrees test their own code.** A cloned in-project virtualenv keeps absolute paths into the plan checkout, through its scripts' interpreter and any editable install, so a wave task's tests ran the plan checkout's code (reproduced with a `uv` project: the cloned interpreter imported the package from the plan checkout, a recreated one from the worktree). Every task worktree, including one reused on resume, now runs the project's install step with a cloned virtualenv removed first (the venv's own pip, not the one on `PATH`); the controller checks from outside the worktree that the code resolves there, and records what the install wrote so it is not sent back to the implementer.
+- **Wave merges and their failures have a defined path.** A merge that git refuses to start (an untracked file in the way) is the controller's to clear and costs the task no round. In a wave of two or more, implementers run only their covering tests (the template and the `sdd-implementer` seat agree), and the controller runs the full suite once each wave merges, the last one included, and ledgers the result. Round 3 of a merge failure goes to the escalation seat, whose agent file now knows a merge round, with the plan branch and the worktree; a task whose rounds were spent in review still gets that one merge round; a task that still will not merge stops the run instead of being parked, and so does a wave suite still red after its one fix, both now in the skill's list of stops. A `review per-task` task whose rebase changed code gets its full task review again, over a merge-base SHA. A fix on the plan checkout gets its own brief and report file, its seat and its follow-up suite run. The reviewer templates take a wave task's branch-tip SHA as its head and next FIX_BASE, never the branch name. An implementer that had to change a file outside its brief reports DONE_WITH_CONCERNS ("or scope" is back, in the review-list trigger too), and the task merges after its wave's others.
+- **Small changes keep their guard.** A fully specified request on the never-small list is no longer built straight away as a "quick task". The small-change path asks before starting when something is already staged, runs the suite before changing anything so an existing failure is reported instead of mistaken for its own, commits only its own hunks of a file that already had edits, and stops before committing when the change grows into a project.
+- writing-plans no longer calls Native "fastest for a few tightly coupled tasks", a plan executing-plans and subagent-driven-development both turn away. The README's file list and upstream-sync notes now include this fork's executing-plans, requesting-code-review and finishing-a-development-branch edits.
+
+## [7.0.0-omp.3] - 2026-10-16
+
+### Changed
+
+- **A small change no longer goes through the full process.** brainstorming's small-change row said "build it through the normal workflow", which left it to a plan and a subagent run. It now has its own path: after the in-chat approval the session builds it itself, test first, runs the covering tests and the suite once, and commits once, with no design document, plan or subagents. A new behavior such as a `--quiet` flag can be small. Security, auth, concurrency, money, migrations, changes one revert cannot undo, new config files or stored formats, changes to existing behavior (defaults, exit codes, error handling, what happens with no input), new interfaces other code builds on and new dependencies never are: in a live run before that list was written, a request for a `--format` flag and a `~/.wcrc` config file was sized small and committed with no design, and the commit also changed what the tool does with no input. In a measured herdr-tunnel feature (2026-09-21), the brainstorm, plan and finish phases took 1h41m of its 3h52m agent time.
+- **One approval for design, plan and method.** A playback no longer waits for its own answer; it rides along with the next question. For software, the plan is written right after the builder check, and writing-plans asks once for approval of the design, the plan, the execution method and the workspace (a new branch in this checkout by default, so no `/move`), picking the method itself and naming its reason instead of asking the partner to choose. In the same feature, 16h55m of 20h48m wall clock was waiting for the partner's reply across the brainstorm, plan and finish prompts; this removes some of those prompts, not the time a partner takes to answer the rest. The combined plan-review and method prompt alone waited 1h42m.
+- **subagent-driven-development reviews per task only where risk earns it, and runs independent tasks in parallel.** writing-plans marks security, auth, concurrency, migration or persisted-format, money and destructive tasks `**Review:** per-task`, and a plan with such a mark runs subagent-driven unless the partner says otherwise. The controller's pre-flight scan turns the marks into a review list and the scan table into waves: tasks with no shared file or interface (lockfiles, manifests and test-time ports count as shared) run in parallel, up to three, each in its own `omp worktree add` worktree. Every dispatch for a wave task, reviewers included, names its worktree. A wave task's covering tests run on the merged tree before the merge commits (`git merge --no-ff --no-commit`), a failure goes back to its implementer as a counted round, and the full suite runs once after each wave. A task reviewed at final gets the controller's own run of its covering tests instead of a task reviewer, and `sdd-final-reviewer` does the task review's work on it, and on any rebased or wave-fix code, before the seams. 6.4.2-omp.3 removed parallel waves because they rode on `task.isolation`, whose patch merge leaves no commits and whose agents cannot be resumed; these waves use git worktrees and keep both. Across six measured SDD runs, task reviews and re-reviews took 2h28m and final reviews 1h24m, against 7h06m of implementation, and every task ran in sequence.
+- **`sdd-final-reviewer` always reports crashes and lost data.** A crash (an uncaught exception, a traceback) or lost data on input a user can give is a finding, never a "Declined to judge" line, whatever the plan or spec says about that input. In a live SDD run on a three-task plan, the final reviewer listed a traceback on a bad `--larger-than` value under "Declined to judge", and the branch kept it; per-task reviews now cover fewer tasks, so the final review is where such a crash gets caught.
+
+### Fixed
+
+- **The `task.isolation` notes match omp 18.11.0.** They said isolated work always returns as an uncommitted patch and an isolated agent cannot be messaged. Measured in two scratch runs on 18.11.0 (the bundled `task` agent, and an `sdd-implementer` seat on cursor-sdk): `merge: branch` keeps a subagent's commits and cherry-picks them onto the parent branch as it finishes, under new ids, and deletes the task branch; a same-file conflict leaves `omp/task/<id>` behind. A `write agent://<id>` to an isolated agent answers `Delivered` although its result says it "cannot be resumed or messaged", and the fix it then committed never reached the parent branch while the session ran; after the session ended it sat on a leftover `omp/task/<id>` branch that also repeated the already-merged commit. `pi-tools.md` now says never to send an isolated subagent a follow-up, and how to recover one that went out (cherry-pick only its new commits). SDD still uses its own worktrees, because its fix rounds resume the implementer.
+
 ## [7.0.0-omp.2] - 2026-10-11
 
 ### Changed
@@ -90,7 +116,9 @@ 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.0-omp.2...HEAD
+[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.0-omp.4...HEAD
+[7.0.0-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.4
+[7.0.0-omp.3]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.3
 [7.0.0-omp.2]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.2
 [7.0.0-omp.1]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.1
 [6.4.2-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.4

package/README.md

@@ -8,7 +8,8 @@ This fork keeps the skills and fixes the omp side:
 
 - the injected tool mapping tells the truth about `task`, `todo`, `read`/`grep`/`glob`
 - **five omp agents** (`agents/sdd-*.md`) give every subagent-driven-development seat its own model, thinking level, and tool set
-- subagent-driven-development is rewritten around them: three-round fix loop, structured reviewer output, implementers one at a time
+- subagent-driven-development is rewritten around them: three-round fix loop, structured reviewer output, independent tasks in parallel worktrees, a task review only where a task's risk earns it
+- a small change skips the design document, plan and subagents, and a project asks for one approval of design, plan and execution method together
 
 ## Install
 
@@ -41,9 +42,9 @@ Agent definitions are read **per dispatch**, so a reinstall takes effect on the
 
 The skills drive themselves once loaded. The usual path:
 
-1. `read skill://brainstorming` — turn an idea into a design
-2. `read skill://writing-plans` — produce `docs/plans/<date>-<name>.md`
-3. `read skill://subagent-driven-development` — execute the plan task by task via subagents. If you choose Native at the plan handoff, `executing-plans` runs instead: the session does every task itself, and only the final review is a subagent (`sdd-final-reviewer`)
+1. `read skill://brainstorming` — turn an idea into a design. A small change stops here: after you approve it in chat, the session builds it itself, test first, and commits once
+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 / PR / discard
 
 On omp the agent invokes a skill by reading it (`read skill://<name>`); you can also invoke one explicitly with `/skill:<name>`.
@@ -54,10 +55,15 @@ On omp the agent invokes a skill by reading it (`read skill://<name>`); you can
 
 ```mermaid
 flowchart TD
-    B["task-brief: one task's text from the plan"] --> I
-    I["sdd-implementer: TDD, commit, report file"] --> P["review-package: git diff -U10 to a file"]
+    S["pre-flight scan: review list + waves"] --> B
+    B["task-brief: one task's text from the plan; a wave of 2+ gets a worktree per task"] --> I
+    I["sdd-implementer: TDD, commit, report file"] --> L{"on the review list?"}
+    L -->|"no: review at final"| T["controller runs the covering tests"]
+    T -->|"pass"| D
+    T -->|"fail: fix round"| I
+    L -->|"yes: risk class"| P["review-package: git diff -U10 to a file"]
     P --> R["sdd-reviewer: spec + quality, structured result"]
-    R -->|"approved"| D["ledger: Task N complete"]
+    R -->|"approved"| D["merge the task branch; ledger: Task N complete"]
     R -->|"Critical or Important findings"| F
     F["fix round 1 or 2: resume sdd-implementer"] --> RR["sdd-rereviewer: verdict per finding"]
     RR -->|"all addressed"| D
@@ -65,9 +71,9 @@ flowchart TD
     E --> RR
     RR -->|"still open after round 3"| A["controller adjudicates and parks with a ruling"]
     A --> D
-    D --> N{"more tasks?"}
+    D --> N{"more waves?"}
     N -->|"yes"| B
-    N -->|"no"| W["sdd-final-reviewer: whole-branch, once per plan"]
+    N -->|"no"| W["sdd-final-reviewer: whole-branch, once per plan; does the task review's work for review-at-final tasks"]
     W --> X["finishing-a-development-branch"]
 
     classDef seat fill:#1e3a8a,stroke:#3b82f6,color:#dbeafe
@@ -144,7 +150,7 @@ Rules that are easy to get wrong:
 
 | setting | why |
 |---|---|
-| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default. SDD does not use it: implementers run one at a time, because isolated work returns as an applied patch with no per-task commits, and an isolated subagent cannot be messaged for fix rounds. Older omp builds spelled this `task.isolation.mode`; check `omp config get task.isolation.enabled` on your build |
+| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default. 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. Parallel tasks get their own `omp worktree add` worktrees instead. Older omp builds spelled this `task.isolation.mode`; check `omp config get task.isolation.enabled` on your build |
 | `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 |
 | `task.enableLsp`, `astGrep.enabled` (both default off) | omp only activates `lsp` and `ast_grep` in subagents when these are on |
@@ -155,11 +161,14 @@ Rules that are easy to get wrong:
 - `.pi/extensions/superpowers.ts` — the injected mapping names `task`, `todo`, the `sdd-*` roster, and the no-`model:`-field rule; it also re-arms on `session_switch`, skips subagent sessions, and ignores an `agent_end` that will auto-continue; 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
-- `agents/sdd-*.md` — new. Each seat's `model:` is a pin plus a role fallback (`@task` or `@slow`), and all set `readSummarize: false`. `sdd-final-reviewer` reviews the whole branch for both ways of running a plan. It reads `requesting-code-review/code-reviewer.md` at run time and applies its What to Check, Calibration, severity definitions and Critical Rules, while carrying upstream's vision-document and Declined-to-judge rules in its own body. Descriptions name roles, never models
-- `skills/subagent-driven-development/` — *Model Selection* → *Agent Selection*; fix-loop cap 5 → 3 with a round-3 escalation seat; a proven-trivial-fix route that replaces a re-review with a one-command proof; implementers run one at a time; the scripts directory resolves via `realpath skill://subagent-driven-development/scripts`; fix rounds resume the implementer with `write agent://<id>` (id ledgered) and full results are read at `agent://<id>`; task review scales with risk through `effort: "hi"`; the controller checks reviewer results; templates show omp's real `{ context, tasks: [{ agent, task, solutionSpace }] }` wire shape and the reviewers' structured fields; one omp paragraph for vibe mode, where a director (no `task` or `bash`) hands the whole run to one `good` worker that dispatches the seats itself
-- `skills/executing-plans/` — one additive omp paragraph in *Final Review*: the `task` tool has no `model:` field, so the final review goes to `sdd-final-reviewer` (its model is what the host maps that agent to), told that no task was reviewed; it also resolves the scripts directory with `realpath` and reads full results at `agent://<id>`; one more omp paragraph for vibe mode, where a director hands the whole run to one `good` worker
+- `skills/brainstorming/` — 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 (a new behavior such as a `--quiet` flag can be small; 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 never are, and none of them takes the quick-task route however complete the request); a playback rides along with the next question instead of waiting for its own answer; for software, the plan is written right after the builder check so the design and the plan get one approval
+- `agents/sdd-*.md` — new. Each seat's `model:` is a pin plus a role fallback (`@task` or `@slow`), and all set `readSummarize: false`. `sdd-final-reviewer` reviews the whole branch for both ways of running a plan; after subagent-driven-development it does the task review's work on every task left to it (`review at final`) before the seams. It reads `requesting-code-review/code-reviewer.md` at run time and applies its What to Check, Calibration, severity definitions and Critical Rules, while carrying upstream's vision-document and Declined-to-judge rules in its own body; a crash or lost data on user input is always a finding, never a Declined-to-judge line. Descriptions name roles, never models
+- `skills/subagent-driven-development/` — *Model Selection* → *Agent Selection*; fix-loop cap 5 → 3 with a round-3 escalation seat; a proven-trivial-fix route that replaces a re-review with a one-command proof; the pre-flight scan builds a review list (plan-marked or ruled high-risk tasks get a task review, the rest get the controller's own covering-test run and the final review) and waves (tasks with no shared file or interface run in parallel, up to three, each in its own `omp worktree add` worktree with the project's install step re-run there, merged back with `--no-ff` after their covering tests pass on the merged tree; a task that still will not merge after round 3 stops the run); Setup creates the approved branch in this checkout instead of a worktree; resume reads each task's last ledger line, and treats a wave task as merged only when its branch has commits past BASE; the scripts directory resolves via `realpath skill://subagent-driven-development/scripts`; fix rounds resume the implementer with `write agent://<id>` (id ledgered) and full results are read at `agent://<id>`; task review scales with risk through `effort: "hi"`; the controller checks reviewer results; templates show omp's real `{ context, tasks: [{ agent, task, solutionSpace }] }` wire shape and the reviewers' structured fields; one omp paragraph for vibe mode, where a director (no `task` or `bash`) hands the whole run to one `good` worker that dispatches the seats itself
+- `skills/executing-plans/` — the description, *Why inline*, *When to Use* and the "Prefer subagent-driven-development" paragraph say the partner approved inline execution at the handoff and that SDD reviews per task only where a plan marks it; Setup creates the approved branch in this checkout; a ledger with `Wave` lines resumes under SDD. Additive omp paragraphs: in *Final Review*, the `task` tool has no `model:` field, so the final review goes to `sdd-final-reviewer` (its model is what the host maps that agent to), told that no task was reviewed; it also resolves the scripts directory with `realpath` and reads full results at `agent://<id>`; one more for vibe mode, where a director hands the whole run to one `good` worker
+- `skills/requesting-code-review/` — *Mandatory* says a review follows each task on subagent-driven-development's review list, and once on the whole branch at the end, instead of after every task
 - `skills/using-git-worktrees/` — additive omp section: `/wt` is the user's one-line answer to the consent question (moves the session, carries WIP); when the agent creates the worktree itself it uses `omp worktree add` under `~/.omp/wt/` (the only place `omp worktree list`/`clear` manage), knows that command leaves uncommitted changes behind, and asks for `/move <path>` because `cd` never moves the tools' cwd. Also: clone-first falls back to a plain checkout without `node_modules` (no copy-on-write, or in-repo targets); setup and tests use the bash tool's `cwd` parameter until `/move`; `omp worktree clear --all` is warned against, since it force-removes every worktree, uncommitted work included; omp's bash rewrites a literal `git worktree add` into `omp worktree add` only without shell expansion; vibe mode refuses `/move` and `/wt`, so the worktree and `/move` come before `/vibe`, or every worker brief carries the absolute path
-- `skills/writing-plans/` — one added line in *Execution Handoff*: in vibe mode both execution approaches run in one `good` worker the director briefs, not in its own session
+- `skills/writing-plans/` — *Execution Handoff* picks the method itself and asks for one approval of the design, the plan, the method and the workspace (a new branch in this checkout by default, which answers using-git-worktrees' consent question); *Review Marks* (and a self-review check) mark security, auth, concurrency, migration, money and destructive tasks `**Review:** per-task`; tasks that share no file or interface can run in parallel; in vibe mode both execution approaches run in one `good` worker the director briefs, not in its own session
+- `skills/finishing-a-development-branch/` — one line in the discard path: in a normal repo (a branch made in this checkout), switch to the base branch before `git branch -D`, which git refuses on the checked-out branch
 - `README.md` — this file: rewritten for omp (install, seats, overrides, maintenance); upstream's multi-harness README is gone
 - `tests/pi/test-pi-extension.mjs` — covers the extension's lifecycle (bootstrap on start, `session_switch`, compaction; none for subagents or an auto-continuing `agent_end`), the action table in `pi-tools.md`, the seat table against the names in `agents/*.md`, and the `.omp-plugin/plugin.json` manifest; the package-name assertion is gone (`scripts/check-npm-package.sh` checks the published name)
 - `package.json` — the npm identity: `@loneexile/omp-superpowers`, `<upstream version>-omp.<n>` versions, a `files` allowlist (the extension, `skills/`, `agents/`), `publishConfig`, `omp`/`oh-my-pi` keywords; `main` is dropped, since it pointed at the OpenCode plugin this package does not ship
@@ -178,7 +187,7 @@ git rebase upstream/main
 git push --force-with-lease origin main
 ```
 
-Expect conflicts in `skills/subagent-driven-development/`, `pi-tools.md`, `README.md`, and `package.json` whenever upstream touches them — this fork rewrites those files rather than appending to them (README.md is never a partial conflict). In `package.json` keep the fork's identity and set `version` to `<new upstream version>-omp.1`: CI's package check fails until the version's base matches the upstream version in `.claude-plugin/plugin.json`. `agents/`, the extension's mapping paragraph, and the omp blocks in `using-git-worktrees` are additive.
+Expect conflicts in `skills/subagent-driven-development/`, `skills/brainstorming/`, `skills/writing-plans/`, `skills/executing-plans/`, `skills/requesting-code-review/SKILL.md`, `skills/finishing-a-development-branch/SKILL.md`, `pi-tools.md`, `README.md`, and `package.json` whenever upstream touches them — this fork rewrites those files rather than appending to them (README.md is never a partial conflict). A sync that takes upstream's side of executing-plans or requesting-code-review brings back "review after every task" text that contradicts subagent-driven-development's review list: keep the fork's lines. In `package.json` keep the fork's identity and set `version` to `<new upstream version>-omp.1`: CI's package check fails until the version's base matches the upstream version in `.claude-plugin/plugin.json`. `agents/`, the extension's mapping paragraph, and the omp blocks in `using-git-worktrees` are additive.
 
 A clean rebase is not the whole sync. Upstream's edits to text this fork replaced never reach the replacement, so read upstream's diff for those files and port what still applies. The v6.4.x sync needed two: `bash scripts/...` invocations in the SDD text, and `code-reviewer.md`'s new review rules. Upstream edits to `code-reviewer.md`'s What to Check, Calibration, severity definitions and Critical Rules now reach `sdd-final-reviewer` without porting, because it reads the file at run time. Edits to the vision-document or Declined-to-judge sections still need porting into the agent body, which carries them itself.
 
@@ -197,7 +206,7 @@ gh release create "v$v" --target main --title "v$v" --notes-file /tmp/notes.md
 
 ### New omp versions
 
-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 last verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12. 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), 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). The fork was last verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12, and the `task.isolation` notes against 18.11.0. 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), and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
 
 ## License
 

package/agents/sdd-escalation-implementer.md

@@ -13,12 +13,13 @@ thinkingLevel: max
 readSummarize: false
 ---
 
-You own one task from a Superpowers plan. Your dispatch names the brief (requirements, exact values verbatim), the report file, and which of two cases this is:
+You own one task from a Superpowers plan. Your dispatch names the brief (requirements, exact values verbatim), the report file, and which of three cases this is:
 
 - **Takeover:** a prior implementer attempted the task and either could not clear the review findings across two fix rounds, or reported `BLOCKED`. The dispatch lists the open findings, or the blocker that implementer reported. Read the report file first — it records what was tried and, for findings, what the reviewer rejected.
 - **First implementation:** the controller ruled the task needs the strongest seat from the start. No report file exists, no review has happened, and there are no findings: start from the brief and implement it test-first, as `sdd-implementer` would.
+- **Merge round:** the task's branch would not merge into the plan branch, or its covering tests failed on the merged tree, and its earlier rounds did not clear that. The dispatch names the plan branch, the task's worktree, and the conflict or the failing output file. Work in that worktree: rebase the task's branch onto the plan branch, make its covering tests pass on the result, and append what you did to the report file.
 
-If the dispatch does not say which case it is, the report file settles it: it exists for a takeover and not for a first implementation.
+If the dispatch does not say which case it is, the report file settles takeover against first implementation: it exists for a takeover and not for a first implementation. A dispatch that names a plan branch to rebase onto is a merge round.
 
 <contract>
 - Takeover: understand why the previous attempt did not converge before touching code. A loop that survives two resumes usually means the implementer could not see its own problem — look for the framing error, not just the diff; for a blocker, find what actually stopped it. Then fix the open findings, or clear the blocker and finish the task (test-first, as for a first implementation); re-run the covering tests (name them) and append your fix report to the same report file.

package/agents/sdd-final-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: sdd-final-reviewer
-description: "Superpowers final whole-branch reviewer, dispatched once per plan: after subagent-driven-development it checks the seams between reviewed tasks; after an inline executing-plans run it is the only review the branch gets. Triages the ledger lines it is given."
+description: "Superpowers final whole-branch reviewer, dispatched once per plan: after subagent-driven-development it reviews the tasks left to it and the seams between all of them; after an inline executing-plans run it is the only review the branch gets. Triages the ledger lines it is given."
 tools: read, grep, glob, bash, lsp, ast_grep
 # thinkingLevel is the seat's reasoning tier; an explicit :level on the model
 # string (or on a task.agentModelOverrides entry) takes precedence over it.
@@ -15,7 +15,7 @@ readSummarize: false
 
 You review a whole branch once, at the end of a plan. Your dispatch gives the merge-base..HEAD review package, the plan/spec paths, the ledger lines to triage, and how the plan ran:
 
-- **subagent-driven-development:** every task went through its own task review, except the fixes the controller applied itself on the proven-trivial route (ledger lines `Task <N>: applied … proof: …`, passed in the dispatch), which skipped the re-review: check each such fix and its proof as if no one had. Per-task reviews cannot see cross-file seams; you can, so spend your attention there.
+- **subagent-driven-development:** the dispatch names the tasks that had their own task review (`review per-task`, with a risk class) and the tasks that did not (`review at final`). Do the task review's work on every `review at final` task first, as for an inline run below. Then the seams: per-task reviews cannot see cross-file seams, so spend your attention there, deepest around the `review per-task` classes. Fixes the controller applied itself on the proven-trivial route (ledger lines `Task <N>: applied … proof: …`, passed in the dispatch) skipped the re-review: check each such fix and its proof as if no one had.
 - **executing-plans (inline):** no task was reviewed, and you are the only fresh review this branch gets. Do the task reviews' work across the whole branch first — every plan requirement present, nothing extra, the code sound, and tests that can fail (would deleting a fix, or a plausible regression, leave them green?) — then the seams.
 
 If the dispatch does not say how the plan ran, review it as an inline run.
@@ -24,10 +24,11 @@ If the dispatch does not say how the plan ran, review it as an inline run.
 - Read `skill://requesting-code-review/code-reviewer.md` first and apply its **What to Check** (plan alignment, code quality, architecture, testing, production readiness), its **Calibration**, its Critical / Important / Minor definitions (under *Output Format → Issues*), and its **Critical Rules**. Its Output Format layout, Recommendations, Assessment, and Read-Only Review section do not apply: `<output>` below governs the result, and the bash limits below govern the checkout.
 - Read the package in full, from line 1, with an explicit range: a bare `read` returns only the first 300 lines, `<path>:1-3000` returns up to 3,000 per call, and when the footer says `[Showing lines … of N. Use :M to continue]` you continue with `:M-<M+2999>` until you have read all N lines. Never judge from a partial read. A line over 768 characters arrives truncated — `grep -n` the file to see one in full.
 - Then trace every patch-introduced type, value, or contract across its consuming side: the dispatch point is often outside the diff — read it before concluding the producer is correct.
-- If the dispatch names a high-risk change class (concurrency, security, a data migration), start there and go deeper.
+- If the dispatch names a high-risk change class (concurrency, security, a data migration), go deepest there, after any task left to you for its task review. Code the dispatch lists as `rebased` or `Wave <K>: fix` had no task review: check it as if no one had.
 - Bash is read-only: `git log`, `git show`, `git diff`, running a focused test. Never edit, never run the whole suite.
 - Read-only is your rule, not the harness's: omp mounts MCP and extension tools on you as `xd://` devices reached through `write`, and the `tools:` list cannot remove them. Never call an `xd://` device, or any extension or MCP tool, that executes code, writes files, or changes external state — nor a memory tool that writes (`retain`, `memory_edit`) if your tool list shows one.
 - The spec is a vision document: it says what the software must do, not every input, environment, or condition it will meet. Where it is silent, a reasonable person's expectation is the requirement — the spec's silence is not permission. Grade such findings by their effect on that person, not by whether the spec mentions the trigger.
+- A crash (an uncaught exception, a traceback) or lost data on input a user can give is always a finding, never a `Declined to judge` line, whatever the plan or spec says about that input.
 - If the dispatch carries the plan's Review Focus list, check each item deliberately: those are inputs and failure modes the plan's tests do not exercise.
 - Triage the ledger lines you were given: which deferred minors must be fixed before merge, which rulings you overturn — say why in one line each.
 - You do not dispatch subagents.

package/agents/sdd-implementer.md

@@ -24,5 +24,5 @@ You implement exactly one task from a Superpowers plan. Your dispatch names a br
 </contract>
 
 <budget>
-Read the changed files' context once; do not re-read files you already hold. While iterating, run the focused test for what you are changing; run the full suite once before you commit, not after every edit. A fix round re-runs only the tests that cover the amended code. Every extra turn is wall-clock the controller waits on.
+Read the changed files' context once; do not re-read files you already hold. While iterating, run the focused test for what you are changing; run the full suite once before you commit, not after every edit — unless your dispatch says the task runs in a wave with other tasks, in which case run only the covering tests your brief names. A fix round re-runs only the tests that cover the amended code. Every extra turn is wall-clock the controller waits on.
 </budget>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loneexile/omp-superpowers",
-  "version": "7.0.0-omp.2",
+  "version": "7.0.0-omp.4",
   "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/brainstorming/SKILL.md

@@ -20,7 +20,9 @@ Before you reply, ask yourself: what do I know about what they want, and
 why?
 
 - **Everything that matters is in the request** ("make the icon cornflower
-  blue"). This is a quick, clear task. Do it, and say what you did.
+  blue"). This is a quick, clear task. Do it, and say what you did. Nothing
+  on the never-small list (Size the Work) is a quick task, however complete
+  the request.
 - **Something non-trivial is missing.** Start the conversation.
 
 ## Your First Message
@@ -31,7 +33,8 @@ Your first message is two things, in this order:
    have you just start, they can say so. If they take you up on it, this
    skill is done: state any significant how-it-gets-made choice
    (platform, language, medium) in one plain line, then do what they
-   asked through the normal workflow.
+   asked the way its size calls for (Size the Work, below). Their opt-out
+   is the approval a small change needs.
 2. One open question that gets them describing. Ask about a real moment
    or a concrete picture: "What's the moment you find yourself wishing
    this existed?" or "Tell me about the people who'll be in the room."
@@ -113,12 +116,15 @@ conversation.
 
 Play back as you go. As soon as you understand one part well enough to
 describe it (what it's for and who it serves, say, or how one piece
-behaves), describe that part back in about 200-300 words, then return to
-questions about the next part. Playback and questions alternate through
-the whole conversation; the last chunk covers whatever is left.
+behaves), describe that part back in about 200-300 words. A playback
+doesn't wait for its own answer: send it in the same message as your
+next question, with one line saying they can correct anything in it in
+their reply. The last chunk covers whatever is left and goes out with
+the size you pick; for a small change, it ends by asking whether to
+build it.
 
 Mark anything you're guessing as your guess; only what they said goes in
-as theirs. End each chunk by asking what's wrong or missing.
+as theirs.
 
 Before you send a chunk, check it: does it describe something they'll
 look at, like a page, a screen, a schedule, or a printout? If so, and
@@ -134,10 +140,51 @@ words. They can override it.
 | Size | The full description | Then |
 |------|----------------------|------|
 | A quick, clear task | the request itself | do it |
-| A small change | in chat | build it through the normal workflow |
+| A small change | in chat | the small-change path, below |
 | A project with a written design | a written design document | a full plan (for software: superpowers:writing-plans) |
 
-If it grows mid-task, stop, say so, and step up a size.
+**A small change** is one you can describe in a few lines of chat: it
+stays inside one area of the work, adds nothing that other parts will
+build on, and one revert undoes it. Adding a behavior can be small (a new
+`--quiet` flag). These are never small; size them as projects: security,
+authentication, concurrency, money, data migrations, anything one revert
+cannot undo, and in software a new config file or stored format, a change
+to existing behavior (a default, an exit code, error handling, what
+happens with no input), a new interface other code builds on (plugins, a
+public API), or a new dependency.
+
+**The small-change path.** Once they approve the description, build it
+yourself, in this session: no design document, no plan, no subagents.
+For software:
+
+1. Run `git status --short` first and note anything that isn't yours. If
+   anything is staged (`git diff --cached --quiet` exits non-zero), ask
+   before you start: a commit takes the whole index. On the default
+   branch or a detached HEAD, start a branch for the change
+   (`git switch -c <topic>`), unless they told you to work where you are.
+   Run the full suite once before you change anything: a failure there
+   isn't yours. Report it with the rest; don't fix it unasked.
+2. Test first (superpowers:test-driven-development): a failing test,
+   then the code that makes it pass. A change no test can cover
+   (configuration, docs) gets the cheapest check that can fail instead:
+   a build, a lint, a parse. Their approval of the description covers
+   that exception.
+3. Run the tests that cover the change, then the full suite once.
+4. Commit once, staging your own files by path, never with `-a` or `-A`.
+   A file step 1 showed as changed also holds someone else's edits:
+   stage only your hunks (`git apply --cached` with a patch of just them;
+   `git add -p` needs a terminal), or ask.
+5. Before you call it done, follow
+   superpowers:verification-before-completion: name the commit, the
+   command you ran, what it printed, and any changes in the tree that
+   aren't yours.
+
+Your human partner reviews that commit; it is the only review a small
+change gets. Outside software, make the change and show it to them.
+
+If it grows mid-task, stop before committing, say so, and step up a size:
+say what the uncommitted work holds, and ask whether the design should
+keep it or start clean. A plan never starts on top of it uncommitted.
 
 If this is really several independent projects, say so, agree on an
 order, and brainstorm them one at a time.
@@ -159,9 +206,11 @@ Otherwise, ask. Your human partner's preferences override both.
 
 **Builder check:** dispatch a fresh subagent with
 `builder-check-prompt.md` in this directory. When you tell your human
-partner you're writing it up, say a reviewer will read it first and you
-may come back once with a few questions. Don't hand over the document
-until the check is back. Sort what the builder asks into three piles:
+partner you're writing it up, say a reviewer will read it first, that you
+may come back once with a few questions, and, for software, that the
+plan comes with it. Don't hand over the document until the check is
+back. Without a subagent tool, read the document as that builder
+yourself. Sort what the builder asks into three piles:
 
 - **Answered already** by the conversation or the project: put the answer
   in the document.
@@ -170,26 +219,31 @@ until the check is back. Sort what the builder asks into three piles:
 - **Theirs:** only your human partner can answer it, and the answer changes
   what gets built.
 
-Bring the "theirs" pile in one message, most important first. Update the
-document with their answers, then hand it over with a short list of the
-calls you made so they can check those while reading. That's the only
-round of questions the check produces. Without a subagent tool, read the
-document as that builder yourself.
+Bring the "theirs" pile in one message, most important first. That's the
+only round of questions the check produces. Update the document with
+their answers. Then, for software, don't hand the document over on its
+own: invoke superpowers:writing-plans and write the plan now, so your
+human partner approves the design and its plan in one reading. The plan's
+handoff asks for that approval and lists the calls you made. Outside
+software, hand the document over with a short list of the calls you made
+so they can check those while reading.
 
 <HARD-GATE>
 Nothing gets built until your human partner approves the full
-description: in chat for a small change, the document for a project.
-Building includes writing product code, scaffolding, installing
-dependencies, creating projects, and invoking an implementation skill.
-Reading and exploring are fine.
+description: in chat for a small change; for a software project, the
+design document and its plan together, in one approval; otherwise the
+document. Building includes writing product code, scaffolding,
+installing dependencies, creating projects, and invoking an
+implementation skill. Reading, exploring, and writing the plan are fine.
 
 Two exceptions. If they opted out of the questions, the skill is done
 and the gate goes with it. A spike they said yes to may be built; it
 stays labeled throwaway, and keeping what it produced is a new request
 that comes back through this gate.
 
-After a project's document is approved, the next step is the plan. For
-software, invoke superpowers:writing-plans and no other skill.
+The next step after the builder check is the plan. For software, write
+it before the approval: invoke superpowers:writing-plans and no other
+skill. Outside software, the plan follows the document's approval.
 </HARD-GATE>
 
 ## Red Flags
@@ -200,6 +254,7 @@ software, invoke superpowers:writing-plans and no other skill.
 | "I'll fill in sensible defaults" | Good. Say them out loud. A default they never heard is one they couldn't reject. |
 | "I should explain the process first" | Ask your question. The process shows itself. |
 | "They said 'sounds good' to the idea" | Approval covers what you showed them. A description you haven't written isn't approved. |
+| "I'll get the design approved, then write the plan" | For software, write the plan first, so they approve both in one reading. A change to the design updates the plan before you ask again. |
 | "The spike works, I'll keep building on it" | Keeping it is a new request. Back through the gate. |
 
 ## Visual Companion

package/skills/executing-plans/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: executing-plans
-description: Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
+description: Use when executing an implementation plan in the current session as the implementer yourself — your human partner approved inline execution, or no subagent tool is available
 ---
 
 # Executing Plans
@@ -10,7 +10,7 @@ subagent per task, no reviewer per task. One fresh-context review of the
 whole branch at the end.
 
 **Why inline:** Subagent-driven development pays for a fresh implementer
-and a fresh reviewer on every task, each re-reading the codebase from zero.
+on every task and a fresh reviewer on each high-risk one, each re-reading the codebase from zero.
 Inline execution pays for one context (yours) plus one reviewer at the end.
 What it gives up is a fresh context per task and a second pair of eyes per
 task. This skill keeps what those two things bought, by other means: the
@@ -25,7 +25,7 @@ record that survives your own forgetting.
 ledger and the tool results carry the record.
 
 **Continuous execution:** Do not pause to check in with your human partner
-between tasks. They chose inline execution to spend less, not to answer
+between tasks. They approved inline execution to spend less, not to answer
 "should I continue?" after every task. Execute all tasks from the plan
 without stopping.
 
@@ -62,7 +62,7 @@ answers. The worktree and budget limits are in "Vibe mode" in
 ## When to Use
 
 - You have a plan from superpowers:writing-plans and your human partner
-  chose inline execution at the handoff.
+  approved inline (Native) execution at the handoff.
 - Your harness has no subagent tool (see the per-platform references in
   `../using-superpowers/references/`). Never fabricate a dispatch; run
   the plan here.
@@ -74,8 +74,8 @@ it runs well on a mid-tier session model, and the one place the most
 capable model earns its cost is the final review, which this skill
 dispatches separately. Tell your human partner so when they choose inline.
 
-Prefer superpowers:subagent-driven-development when your human partner
-wants a review gate on every task, or when the plan is long enough that
+Prefer superpowers:subagent-driven-development when the plan marks tasks
+`**Review:** per-task`, when your human partner wants a review gate on every task, or when the plan is long enough that
 its later tasks would run on a compacted context. Inline execution over a
 long plan still works — the ledger is what makes it recoverable — but the
 last tasks get the least of you.
@@ -124,10 +124,23 @@ digraph process {
 
 ## Setup
 
-Ensure the work happens in an isolated workspace: use
-superpowers:using-git-worktrees to create one or verify the existing one.
-Never start implementation on a main/master branch without your human
-partner's explicit consent.
+Ensure the work happens in an isolated workspace. If the plan's approval
+named a new branch in this checkout (writing-plans' default), that approval
+was your human partner's answer to superpowers:using-git-worktrees' consent
+question: work in place, with no worktree. With a ledger for this plan
+(below), `git switch` to the branch its `Setup:` line names and resume.
+On a first run, run `git status --porcelain`: a change to a tracked file,
+or anything staged, goes back to your human partner to commit or stash
+first, since your commits and tests would include it; untracked files may
+stay, and stay out of every commit. If a branch with the approved name
+already exists, ask, or name another. Then `git switch -c <branch>`, run
+using-git-worktrees' Step 2 (project setup) and Step 3 (baseline tests)
+here, and, once the ledger exists, ledger `Setup: branch <branch> in this
+checkout; untracked before start: <paths | none>`. Commit your own files
+by path, never with `-a` or `-A`. Otherwise use
+superpowers:using-git-worktrees to create a worktree or verify the
+existing one. Never start implementation on a main/master branch without
+your human partner's explicit consent.
 
 Conversation memory does not survive compaction. An inline executor that
 loses its place re-implements tasks whose commits already exist — the same
@@ -151,7 +164,11 @@ and the new one resumes from the same ledger.
   commits exist in git even when your context no longer remembers making
   them: after compaction, trust the ledger and `git log` over your own
   recollection. A ledger whose first line names a different plan file is
-  another plan's progress: leave it and start your own, fresh.
+  another plan's progress: leave it and start your own, fresh. A wave task
+  (its `dispatched` line names a worktree) with no `merged` or `complete`
+  line after it is still open in its worktree: finish it under
+  subagent-driven-development's resume rules and Complete the task before
+  continuing here. Finished waves need nothing.
 - Create the ledger with its identity as the first line:
   `# SDD ledger — plan: <plan file path>`.
 - `git clean -fdx` will destroy the workspace (it's git-ignored scratch);
@@ -292,7 +309,9 @@ carries the model — so choosing the reviewer's model means choosing its
 agent. Dispatch `sdd-final-reviewer`, the whole-branch reviewer this
 plugin ships, not the bundled `reviewer` or `task` agent. Give it the
 inputs above and say the plan ran inline, with no task reviewed, so it
-checks every change rather than only cross-task seams. Do not paste
+checks every change rather than only cross-task seams. Name every task the
+plan marks `**Review:** per-task`, with its class, so it goes deepest
+there. Do not paste
 code-reviewer.md into the dispatch: the agent reads the review rubric from
 it itself, and its own `<output>` governs. Its model is whatever this host
 maps that agent to: opus-5-5 · max by default (`@slow` when that pin has no
@@ -386,7 +405,7 @@ Use superpowers:finishing-a-development-branch.
 ```
 You: I'm using the executing-plans skill to implement this plan inline.
 
-[Setup: worktree verified]
+[Setup: the approval named a new branch feat/hooks in this checkout — git switch -c feat/hooks, project setup and baseline tests in place]
 [Read plan once: docs/plans/feature-plan.md; spec read]
 [Resolve workspace: sdd-workspace docs/plans/feature-plan.md — no ledger inside, fresh start]
 [Pre-flight scan: 2 shared-interface rows, 4 self-consistency rows, clean; written to ledger]

package/skills/finishing-a-development-branch/SKILL.md

@@ -150,9 +150,13 @@ MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-tople
 cd "$MAIN_ROOT"
 ```
 
-Then clean up the worktree (Step 6) and force-delete the branch:
+Then clean up the worktree (Step 6) and force-delete the branch. In a
+normal repo (`GIT_DIR == GIT_COMMON`, for example a branch made in this
+checkout) the branch is still checked out here, and git refuses to delete
+it, so switch away first:
 
 ```bash
+git switch <base-branch>   # normal repo only
 git branch -D <feature-branch>
 ```
 

package/skills/requesting-code-review/SKILL.md

@@ -12,7 +12,7 @@ Dispatch a code reviewer subagent to catch issues before they cascade. The revie
 ## When to Request Review
 
 **Mandatory:**
-- After each task in subagent-driven development
+- After each task on subagent-driven development's review list, and once on the whole branch at the end
 - After completing major feature
 - Before merge to main