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

package/.pi/extensions/superpowers.ts

@@ -28,11 +28,17 @@ export default function superpowersPiExtension(pi: ExtensionAPI) {
 		injectBootstrap = true;
 	});
 
-	pi.on("agent_end", async () => {
+	pi.on("session_switch", async () => {
+		injectBootstrap = true;
+	});
+
+	pi.on("agent_end", async (event) => {
+		if (event?.willContinue) return;
 		injectBootstrap = false;
 	});
 
-	pi.on("context", async (event) => {
+	pi.on("context", async (event, ctx) => {
+		if (ctx?.agent?.kind === "sub") return;
 		if (!injectBootstrap) return;
 		if (event.messages.some(messageContainsBootstrap)) return;
 
@@ -88,15 +94,21 @@ function stripFrontmatter(content: string): string {
 function piToolMapping(): string {
 	return `## omp tool mapping
 
-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.
+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 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: ONE call carries \`{ context, tasks[] }\` — one subagent per item, run concurrently. 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.
+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.
+
+To resume an idle subagent with new input, message it with \`write agent://<id>\`, using the id its result reports. A result longer than 5,000 characters arrives as a preview; read the rest at \`agent://<id>\`.
+
+The \`task\` tool has NO \`model:\` field — a template's \`model:\` line is inert; the agent TYPE carries the model, thinking level, and tools. For subagent-driven-development use this plugin's own agents: \`sdd-implementer\` (implementation, fix rounds 1-2), \`sdd-escalation-implementer\` (fix round 3, and tasks ruled to need the strongest tier), \`sdd-reviewer\` (task review), \`sdd-rereviewer\` (scoped re-review), \`sdd-final-reviewer\` (whole-branch review). Each agent file sets a default model and thinking level; a host re-points any seat with \`task.agentModelOverrides\`. Never use the bundled \`task\` agent for an SDD seat: it lacks the seat's tools, output contract and no-subagent rule.
+
+omp ships a built-in task-list tool: \`todo\` (\`init\`, \`start\`, \`done\`, \`rm\`, \`drop\`, \`block\`, \`unblock\`, \`append\`, \`view\`). Use it for all task tracking. Do not track work in plan files or a repo-local \`TODO.md\`. Treat older \`TodoWrite\` references as the \`todo\` tool.
 
-The \`task\` tool has NO \`model:\` field — a template's \`model:\` line is inert; the agent TYPE carries the model, thinking level, and tools. For subagent-driven-development use this plugin's own agents: \`sdd-implementer\` (implementation, fix rounds 1-2), \`sdd-escalation-implementer\` (fix round 3, xhigh reasoning), \`sdd-reviewer\` (task review, no file writes, no shell), \`sdd-rereviewer\` (scoped re-review, low reasoning), \`sdd-final-reviewer\` (whole-branch review, xhigh reasoning). The bundled \`task\` agent resolves to \`modelRoles.task\`, whatever that is — never use it for an SDD seat.
+From omp 18.4.12 every subagent is told to leave builds, tests and smoke runs to the main agent unless its assignment explicitly instructs them: name the checks a subagent must run in its dispatch.
 
-omp ships a built-in task-list tool: \`todo\` (\`init\`, \`start\`, \`done\`, \`rm\`, \`drop\`, \`block\`, \`unblock\`, \`append\`, \`view\`). Use it for all task tracking. Do not track work in plan files or a repo-local \`TODO.md\`. Treat older \`TodoWrite\` references as the \`todo\` tool.`;
+If your tools include \`vibe_spawn\` but not \`task\`, omp's vibe mode is on and you are its director: you have none of the \`task\`, \`bash\`, \`edit\` or \`write\` tools named above. Read the "Vibe mode" section of \`skill://using-superpowers/references/pi-tools.md\` before acting on them.`;
 }
 
 function messageContainsBootstrap(message: unknown): boolean {

package/CHANGELOG.md

@@ -6,6 +6,46 @@ A version is `<upstream version>-omp.<n>`: the upstream release this fork is syn
 
 ## [Unreleased]
 
+## [6.4.2-omp.4] - 2026-10-03
+
+### Added
+
+- **omp vibe mode support.** In `/vibe` the session is a director with `read`, `todo`, the `vibe_*` tools and any MCP tools, but no `task`, `bash`, `edit` or `write`, and its `fast` and `good` workers are the bundled `sonic` and `task` agents, not SDD seats. subagent-driven-development and executing-plans now tell a director (tools include `vibe_spawn` but not `task`) to hand the whole run to one `good` worker, which keeps the ledger and dispatches the `sdd-*` seats through its own `task` tool. Each controller brief explicitly instructs the worker to run the tests, builds and scripts the skill calls for. using-git-worktrees says vibe refuses `/move` and `/wt` and leaving vibe kills every worker, so the worktree and `/move` come first. writing-plans' handoff says both approaches run in a worker. `pi-tools.md` gains a *Vibe mode* section: the action-to-`vibe_*` table, what workers have, and the request-budget note. Checked end to end on omp 18.4.12, with the director and worker on sonnet-5-5:low and the seats on haiku-4-5:low: a single `/vibe` prompt to execute a one-task plan led the director to read executing-plans' vibe note and brief one `good` worker with both rules; the worker resolved the scripts with `realpath`, created the workspace and ledger, ran `task-start`, ran `npm test` RED then GREEN, committed, ran `task-done` and `review-package`, and dispatched `sdd-final-reviewer` through its own `task` tool; the reviewer found nothing to fix, and the director reported the branch mergeable.
+- **The injected mapping points a vibe director at that section.** Its last paragraph tells a session whose tools include `vibe_spawn` but not `task` that it is a director without the `task`, `bash`, `edit` or `write` tools the mapping names, and to read the section before acting on them. Live check on omp 18.4.10: a `good` worker ran `read skill://subagent-driven-development`, dispatched `sdd-rereviewer` through its own `task` tool, and the seat ran on its `task.agentModelOverrides` model, returned its structured output to the worker, and was resumed with `write agent://<id>`.
+
+### Fixed
+
+- **Subagents on omp 18.4.12 skip their checks unless told.** From 18.4.12 every subagent's system prompt, plugin agents and vibe workers alike, carries a hand-off rule: the main agent verifies once after all subagents land, and a subagent must not verify its changes (builds, tests, linters, formatters, smoke runs) unless its assignment explicitly instructs it. 18.4.10 allowed scoped proof instead. The rule is prompt text, not a tool block. The injected mapping now tells a dispatching session to name the checks a subagent must run, and `pi-tools.md` gains a *Checks* subsection that quotes the rule and says every dispatch that needs a check names the command and when to run it. Measured on 18.4.12 with haiku-4-5:low, a weak proxy for the real seats: an `sdd-implementer` given the implementer template ran `npm test` before and after its fix and reported RED/GREEN; a vibe `good` worker told to fix `sum.js` and commit ran no test; the same brief plus an explicit instruction to run `npm test` before and after the fix ran both.
+
+## [6.4.2-omp.3] - 2026-10-02
+
+### Fixed
+
+- **The reviewer read-only boundary was overstated.** The text said reviewers could not run a shell, leaning on `hub`, which omp 18.3.0 removed. A `tools:` list limits built-in tools only: extension tools and MCP tools (`xd://` devices through the device-only `write`) still attach, and memory tools attach only when the list names them. A live probe on 18.4.10 had a read/grep/glob reviewer run a shell command through an MCP device. The docs now say read-only is by instruction, and the reviewers forbid such calls.
+- **Subagents start in the session's cwd.** The `task` tool has no `cwd`, so after `omp worktree add` and before `/move`, every SDD subagent worked in the original checkout (measured). using-git-worktrees, SDD Setup and executing-plans' final-review dispatch now require `/move` first, or the worktree's absolute path plus the bash `cwd` parameter in every dispatch.
+- **The bootstrap reaches `/new`, `/resume` and `/fork` sessions.** omp fires `session_start` once per process, so only the first session got the bootstrap. The extension now re-arms on `session_switch`, skips subagent sessions, and ignores an `agent_end` that will auto-continue, so an automatic retry no longer ends injection early.
+- **The scripts directory resolves on omp.** The SDD and executing-plans text assumed a path that does not exist there. They now resolve `skill://subagent-driven-development/scripts` and `skill://executing-plans/scripts` with `realpath`, record them in the ledger, and run scripts from the repo root.
+- **The omp worktree steps match omp 18.4.10.** All re-measured. `omp worktree clear --all` force-removes every worktree under the worktree directory, live and `/wt` ones included, uncommitted work and all; the text had said it "also takes PR checkouts". Clone-first falls back to a plain checkout, without `node_modules`, on filesystems without copy-on-write clones or for in-repo targets. Setup and tests run in the worktree via the bash tool's `cwd` parameter until `/move`. omp's bash rewrites a literal `git worktree add` into `omp worktree add`, but only without shell expansion. The omp-added lines say "your human partner".
+- **Reviewers read the whole package.** Reads came in 300-line pages, and summarization could replace the diff with a digest. Seats set `readSummarize: false`, the text uses `:1-3000` ranges, and the call budgets now leave room for the extra pages and the final `yield` call.
+- **Parallel implementer waves are gone.** Isolated work merges as a patch with no per-task commits, and an isolated agent cannot be resumed for fix rounds. Implementers run one at a time, as upstream does.
+- **The implementer runs the full suite once before committing,** as upstream's template says, not on every iteration.
+- **The escalation seat handles a first implementation** when a task is ruled to need the strongest tier, not only a third fix round.
+- **Templates carry the required `solutionSpace`.** omp's task schema requires it on every spawn, not only in the batch shape.
+- **The tool mapping is complete.** It adds resume via `write agent://<id>`, full results at `agent://<id>`, `task.batch`, `solutionSpace`, and the `superpowers:` skill-name prefix, and drops tier claims that hosts override.
+- **Marketplace and `--plugin-dir` installs keep model pins.** Without `.omp-plugin/plugin.json`, omp treated the repo root as Claude dialect and dropped every agent's `model:` line. The repo now carries that manifest. The discovery check was read from omp's source; a marketplace install has not been exercised.
+
+### Changed
+
+- **New seat defaults, with fallbacks.** Each seat pins `anthropic/claude-sonnet-5-5` (medium, high, low) or `claude-opus-5-5:max`, then falls back to `@task` (implementer, reviewers) or `@slow` (escalation, final review). omp takes the first entry with credentials, and the list is also the retry chain on rate and usage limits (`retry.modelFallback`). An override in `task.agentModelOverrides` replaces the whole list; append `,@task` to keep a fallback.
+- **`sdd-final-reviewer` reads `code-reviewer.md`'s rubric** at run time (What to Check, Calibration, severity definitions, Critical Rules) and reports Strengths first and Mergeable last.
+- **Task review scales with risk** through `effort: "hi"` on high-risk tasks, only when `task.enableEffort` is on. The controller ledgers a `Task <N>: high-risk diff — <class>` line; without `effort`, it names that risk in the final review dispatch.
+- **The controller checks reviewer results** and runs the tests a re-review names, rather than trusting the reviewer's word.
+- **The final dispatch passes the applied-fix and high-risk lines,** so the final reviewer knows where to look hardest.
+- **Fix rounds go to the same implementer.** Fix rounds 1-2 and NEEDS_CONTEXT message the idle implementer with `write agent://<id>`; the id is ledgered at dispatch (a `dispatched` line). A write to an idle agent has two success answers: a live agent answers `Delivered to <id>.`, and a parked one answers `Queued for <id> (was parked; revived).` (an idle agent is parked after `task.agentIdleTtlMs`, 7 minutes by default). Only an error means dispatch fresh, and the fresh dispatch's new id is ledgered as `re-dispatched`. BLOCKED maps onto seats: retry the same seat, or escalate to `sdd-escalation-implementer` as a takeover or a first implementation.
+- **The escalation takeover also covers a BLOCKED implementer.** The dispatch carries the blocker instead of findings.
+- **Ledger lines are found by prefix, never by position.** Lines like `SDD scripts:` are matched by prefix, so SDD and executing-plans can share a ledger.
+- **Agent descriptions name roles only,** never models, since hosts re-point them.
+
 ## [6.4.2-omp.2] - 2026-10-02
 
 ### Fixed
@@ -23,7 +63,7 @@ First release, synced to upstream [v6.4.2](https://github.com/obra/superpowers/b
 - **Five SDD agents** (`agents/sdd-*.md`): implementer, task reviewer, scoped re-reviewer, round-3 escalation implementer, and final whole-branch reviewer, each with its own model, thinking level, and tool set. Re-point any seat per host with `task.agentModelOverrides`.
 - **subagent-driven-development rewritten around them:** *Agent Selection* replaces *Model Selection*; a three-round fix loop whose third round goes to the escalation seat; a proven-trivial-fix route; structured reviewer results with a `package_gap` verdict; parallel implementer waves only when `task.isolation.enabled` is on.
 - **omp worktree steps** in `using-git-worktrees`: `/wt` for the user, `omp worktree add` for the agent.
-- **npm package.** `omp plugin install npm:@loneexile/omp-superpowers`. The package holds only what omp loads (the extension, `skills/`, `agents/`). GitHub Releases publish it through npm Trusted Publishing, with provenance.
+- **npm package.** `omp plugin install npm:@loneexile/omp-superpowers`. The package holds only what omp loads (the extension, `skills/`, `agents/`). This first version was published by hand, without provenance; 6.4.2-omp.2 was the first release published through GitHub Releases and npm Trusted Publishing, with provenance.
 
 ### Changed
 
@@ -31,6 +71,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/v6.4.2-omp.2...HEAD
+[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v6.4.2-omp.4...HEAD
+[6.4.2-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.4
+[6.4.2-omp.3]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.3
 [6.4.2-omp.2]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.2
 [6.4.2-omp.1]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.1

package/README.md

@@ -6,9 +6,9 @@ Upstream superpowers is a set of workflow skills (brainstorm → plan → implem
 
 This fork keeps the skills and fixes the omp side:
 
-- the always-injected tool mapping tells the truth about `task`, `todo`, `read`/`grep`/`glob`
+- 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, waves gated on isolation
+- subagent-driven-development is rewritten around them: three-round fix loop, structured reviewer output, implementers one at a time
 
 ## Install
 
@@ -25,6 +25,8 @@ omp plugin install npm:@loneexile/omp-superpowers@<version>
 
 Unreleased `main` installs from GitHub under the same plugin name, pinned to a commit: `omp plugin install github:LoneExile/omp-superpowers#<sha>`. Installs made before 6.4.2-omp.1 used the plugin name `superpowers`; run `omp plugin uninstall superpowers` before installing this package.
 
+npm and `github:` installs keep each seat's model. For a marketplace or `--plugin-dir` install of the repo root, the repo carries `.omp-plugin/plugin.json`: omp 18.4.10's agent discovery treats a root that has `.claude-plugin/plugin.json` as Claude dialect, and drops every agent's `model:` line, unless that file is present. This was read from omp's source; a marketplace install has not been exercised.
+
 Verify it loaded — the roster of your `task` tool should now include the five `sdd-*` agents:
 
 ```bash
@@ -33,7 +35,7 @@ omp -p --no-session --no-skills --model anthropic/claude-haiku-4-5 \
 # scout, reviewer, security-reviewer, sonic, task, sdd-implementer, sdd-reviewer, sdd-rereviewer, sdd-escalation-implementer, sdd-final-reviewer
 ```
 
-Agent definitions are read **per dispatch**, so a reinstall takes effect on the next `task` call in a running session. The injected tool mapping and the skill catalog are read at process start — restart omp after upgrading to pick those up.
+Agent definitions are read **per dispatch**, so a reinstall takes effect on the next `task` call in a running session. The injected tool mapping and the skill catalog are read at process start — restart omp after upgrading to pick those up. The bootstrap is injected at the start of each session, including `/new`, `/resume` and `/fork`, until that session's first agent run ends, and again after compaction. Main session only; subagents never get it.
 
 ## Using it
 
@@ -46,6 +48,8 @@ The skills drive themselves once loaded. The usual path:
 
 On omp the agent invokes a skill by reading it (`read skill://<name>`); you can also invoke one explicitly with `/skill:<name>`.
 
+**Vibe mode.** After `/vibe` the session is a director of `fast`/`good` workers and has no `task`, `bash` or file-writing tool, so it cannot run subagent-driven-development or executing-plans itself. Both skills tell it to hand the whole run to one `good` worker, which dispatches the `sdd-*` seats through its own `task` tool. Each worker brief names the tests to run, because omp 18.4.12 workers skip them otherwise. Vibe refuses `/move` and `/wt`, so create the worktree and `/move` into it first; for a long plan set `task.softRequestBudget: 0`. Details are in the *Vibe mode* section of [`pi-tools.md`](skills/using-superpowers/references/pi-tools.md).
+
 ### What subagent-driven-development does per task
 
 ```mermaid
@@ -57,7 +61,7 @@ flowchart TD
     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
-    RR -->|"still open, round 3"| E["sdd-escalation-implementer: xhigh reasoning"]
+    RR -->|"still open, round 3"| E["sdd-escalation-implementer: fresh context, strongest tier"]
     E --> RR
     RR -->|"still open after round 3"| A["controller adjudicates and parks with a ruling"]
     A --> D
@@ -74,17 +78,21 @@ Blue nodes are the five omp agents this fork ships. A reviewer that cannot read
 
 ### The SDD seats
 
-| Seat | agent | shipped default · thinking | tools |
-|---|---|---|---|
-| implementer (every task, fix rounds 1–2) | `sdd-implementer` | sonnet-5 · medium | read, write, edit, bash, grep, glob, lsp, ast_grep |
-| task reviewer | `sdd-reviewer` | sonnet-5 · high | read, grep, glob |
-| scoped re-review | `sdd-rereviewer` | sonnet-5 · low | read, grep |
-| fix round 3 / ruled strongest-tier task | `sdd-escalation-implementer` | opus-5 · xhigh | same as implementer |
-| final whole-branch review (subagent-driven or Native) | `sdd-final-reviewer` | opus-5 · xhigh | read, grep, glob, bash, lsp, ast_grep |
+| Seat | agent | shipped default · thinking | falls back to | tools |
+|---|---|---|---|---|
+| implementer (every task, fix rounds 1–2) | `sdd-implementer` | claude-sonnet-5-5 · medium | `@task` | read, write, edit, bash, grep, glob, lsp, ast_grep |
+| task reviewer | `sdd-reviewer` | claude-sonnet-5-5 · high | `@task` | read, grep, glob |
+| scoped re-review | `sdd-rereviewer` | claude-sonnet-5-5 · low | `@task` | read, grep |
+| fix round 3 / ruled strongest-tier task | `sdd-escalation-implementer` | claude-opus-5-5 · max | `@slow` | same as implementer |
+| final whole-branch review (subagent-driven or Native) | `sdd-final-reviewer` | claude-opus-5-5 · max | `@slow` | read, grep, glob, bash, lsp, ast_grep |
+
+`lsp` and `ast_grep` are listed for the seats that benefit, but omp only activates them in subagents when `task.enableLsp` / `astGrep.enabled` are on (both default off).
+
+omp takes the first list entry whose provider has credentials. If the pin has none, the seat runs on your `modelRoles.task` / `modelRoles.slow` model at that role's own level. An unset `@task` drops out, and the seat then silently runs on the controller's model; an unset `@slow` expands to omp's built-in strong-model ranking. The list is also the retry chain on rate-limit and usage-limit errors, gated by `retry.modelFallback` (default on); there is no switch on context overflow. Turn on `task.showResolvedModelBadge`, or read `session_init.resolvedModel` in a subagent transcript, to see what actually ran.
 
-The shipped defaults are Anthropic: sonnet for the seats that run on every task, opus for the two that run once per plan or once per stuck task. The tiers are a **thinking ladder** as much as a model ladder — re-reviews reason at `low`, escalation and the final review at `xhigh`.
+The shipped defaults are Anthropic: sonnet for the seats that run on every task, opus for the two that run once per plan or once per stuck task. The tiers are a **thinking ladder** as much as a model ladder — re-reviews reason at `low`, escalation and the final review at `max`.
 
-The two reviewer seats have no `bash`, `edit`, or filesystem `write`: the review package (`git diff -U10` written to a file) is their whole view of the change, and they return a structured result (`spec_compliance`, `task_quality`, `findings[]`, `cannot_verify[]`; `finding_verdicts[]`, `new_breakage[]`, `round_verdict`) plus `package_gap` when they could not read the package. Note the honest boundary: omp always attaches `hub` to subagents, and `hub start` can launch a process, so "no shell" means *cannot edit the tree and cannot run a shell*, not a sandbox.
+The two reviewer seats have no `bash`, `edit`, or filesystem `write`: the review package (`git diff -U10` written to a file) is their whole view of the change, and they return a structured result (`spec_compliance`, `task_quality`, `findings[]`, `cannot_verify[]`; `finding_verdicts[]`, `new_breakage[]`, `round_verdict`) plus `package_gap` when they could not read the package. Note the honest boundary: an agent's `tools:` list limits built-in tools only. Extension tools and MCP tools (mounted as `xd://` devices and run through a device-only `write`) still attach to every subagent; memory tools attach only when the agent's `tools:` list names them. On omp 18.4.10 a read/grep/glob reviewer ran a shell command through an MCP device. Read-only is by instruction, not a sandbox.
 
 ### Changing models — no file edits
 
@@ -93,7 +101,7 @@ omp resolves each seat's model and thinking level in a fixed order. The override
 ```mermaid
 flowchart LR
     subgraph model["model"]
-        M1["task.agentModelOverrides"] -->|"unset"| M2["agent file model:"]
+        M1["task.agentModelOverrides"] -->|"unset"| M2["agent file model list: pin, then @task or @slow"]
     end
     subgraph level["thinking level"]
         L1["explicit :level on the winning model string"] -->|"none"| L2["agent file thinkingLevel:"]
@@ -107,7 +115,7 @@ flowchart LR
 
 Set the override in `~/.omp/agent/config.yml`, or interactively with `/agents` in any session (it edits the same map). It applies on the next dispatch; delete a line to fall back to the agent file.
 
-This is how the fork's own author runs it — every seat on a flat-rate model, mapped onto that model's own thinking ladder:
+Example — every seat on one flat-rate model, mapped onto that model's own thinking ladder:
 
 ```yaml
 task:
@@ -127,28 +135,33 @@ Rules that are easy to get wrong:
 
 - A **bare model** (`anthropic/claude-haiku-4-5`) keeps the agent file's own `thinkingLevel`. Add `:level` (`…:high`) to change reasoning too.
 - **Delete a line** to fall back to the agent file's default for that seat. Overrides apply on the next dispatch — no restart.
-- The `task` tool has **no `model:` field**. Never dispatch the bundled `task` or `reviewer` agent for an SDD seat — they resolve to `modelRoles.task` / `@slow`, which on many hosts is a cheap model.
-- `effort` on a dispatch (when `task.enableEffort` is on) accepts only `"lo"`, `"med"`, `"hi"`.
+- An override **replaces the whole model list**, fallback included. Append `,@task` (for example `provider/model:high,@task`) to keep one.
+- The `task` tool has **no `model:` field**. Never dispatch the bundled `task` or `reviewer` agent for an SDD seat — they lack the seat's tools, structured output and no-subagent rule, and run whatever `modelRoles.task` / `modelRoles.slow` names.
+- `effort` on a dispatch (when `task.enableEffort` is on) accepts only `"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.
 - Discovery-only model ids (the OpenCode Go catalog, for example) accept `:level` in config and in overrides but not on the `--model` CLI flag.
 
 ### Optional settings that matter
 
 | setting | why |
 |---|---|
-| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default; SDD only runs implementers in **parallel waves** when it is on — otherwise they share one checkout and stay serial. Older omp builds spelled this `task.isolation.mode`; check `omp config get task.isolation.enabled` on your build |
-| `task.enableEffort` | exposes per-dispatch `effort` for the round-3 escalation |
+| `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.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 |
 | `autolearn.autoContinue` | omp's auto-learn mints managed skills every session; the whole catalog is injected into every subagent's prompt. Keep it pruned or off — a 2,500-skill catalog was ~220k tokens per subagent turn |
 
 ## What changed from upstream
 
-- `.pi/extensions/superpowers.ts` — the injected mapping names `task`, `todo`, the `sdd-*` roster, and the no-`model:`-field rule
-- `skills/using-superpowers/references/pi-tools.md` — same, as the reference doc
-- `agents/sdd-*.md` — new. `sdd-final-reviewer` reviews the whole branch for both ways of running a plan, and carries the review rules upstream keeps in `requesting-code-review/code-reviewer.md` (the spec is a vision document; a "Declined to judge" list), because it replaces that template there
-- `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; waves keyed to the plan's pre-flight file/interface table and gated on isolation; templates show omp's real `{ context, tasks: [{ agent, task }] }` wire shape and the reviewers' structured fields
-- `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
-- `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
+- `.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/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
 - `README.md` — this file: rewritten for omp (install, seats, overrides, maintenance); upstream's multi-harness README is gone
-- `tests/pi/test-pi-extension.mjs` — one assertion follows the renamed mapping heading; the package-name assertion is gone (`scripts/check-npm-package.sh` checks the published name)
+- `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
 - `CHANGELOG.md`, `.github/workflows/` (CI, npm release), `scripts/check-npm-package.sh` — new
 
@@ -166,7 +179,7 @@ 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.
 
-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, which here live in `agents/sdd-final-reviewer.md`.
+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.
 
 ### Releasing
 
@@ -181,7 +194,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 the npm source tree. `~/.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 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. 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

@@ -1,18 +1,30 @@
 ---
 name: sdd-escalation-implementer
-description: "Superpowers SDD round-3 escalation: a fresh implementer at xhigh reasoning for a task that survived two fix rounds. Same tools and contract as sdd-implementer."
+description: "Superpowers SDD escalation implementer: a fresh implementer for a task that survived two fix rounds or whose implementer reported BLOCKED, or one the controller ruled needs the strongest seat from the start. Same tools and contract as sdd-implementer."
 tools: read, write, edit, bash, grep, glob, 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.
-model: ["anthropic/claude-opus-5:xhigh"]
-thinkingLevel: xhigh
+# `model` is an ordered list: the first entry whose provider has credentials
+# wins, so `@slow` (the host's strong-model role) only catches a missing pin;
+# the list is also the seat's runtime retry chain (retry.modelFallback).
+model: ["anthropic/claude-opus-5-5:max", "@slow"]
+thinkingLevel: max
+# A plain `read` summarizes code files to declarations; this seat edits what it reads.
+readSummarize: false
 ---
 
-You take over one task from a Superpowers plan after a prior implementer attempted it and could not clear the review findings across two fix rounds. You own it now. Your dispatch names the brief (requirements, exact values verbatim), the report file (read it first — it records what was tried and what the reviewer rejected), and the open findings.
+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:
+
+- **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.
+
+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.
 
 <contract>
-- Start from the report: understand why the previous rounds 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.
-- Fix the open findings; re-run the covering tests (name them); append your fix report to the same report file; commit with Conventional Commits.
+- 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.
+- First implementation: TDD (failing test → minimal code → green → refactor), self-review your diff once, and write the full report to the report path in the dispatch.
+- Commit with Conventional Commits.
 - Return ≤12 lines: status (`DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED`), commits, one-line test summary, concerns.
 - You do NOT dispatch subagents. Review arrives from the controller after your report.
+- Any message after you reported — an answer to your `NEEDS_CONTEXT`, or findings from the next review — is a new turn: do it, then yield again.
 </contract>

package/agents/sdd-final-reviewer.md

@@ -1,23 +1,32 @@
 ---
 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. xhigh reasoning."
+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."
 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.
-model: ["anthropic/claude-opus-5:xhigh"]
-thinkingLevel: xhigh
+# `model` is an ordered list: the first entry whose provider has credentials
+# wins, so `@slow` (the host's strong-model role) only catches a missing pin;
+# the list is also the seat's runtime retry chain (retry.modelFallback).
+model: ["anthropic/claude-opus-5-5:max", "@slow"]
+thinkingLevel: max
+# A plain `read` summarizes code files to declarations; this seat judges whole hunks.
+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 already passed its own task review. Per-task reviews cannot see cross-file seams; you can, so spend your attention there.
+- **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.
 - **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.
 
 <method>
-- Read the package once. 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.
+- 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.
 - 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.
 - 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.
@@ -25,5 +34,5 @@ If the dispatch does not say how the plan ran, review it as an inline run.
 </method>
 
 <output>
-Begin with the verdict. Findings carry file:line, severity (Critical / Important / Minor), trigger, impact, and a concrete fix. Then a `### Ledger triage` section: each ledger line you were given → fix-before-merge | accept, with reason. Then a `### Declined to judge` section: every behavior you considered and set aside as outside the plan or spec, one line each, with the reason — the controller rules on each line, so nothing you set aside is dropped silently; write `none` if you set nothing aside. Finish with **Mergeable:** yes | no.
+Open with a short `### Strengths` list (specific, from code you read). Then the findings, each with file:line, severity (Critical / Important / Minor), trigger, impact, and a concrete fix. Then a `### Ledger triage` section: each ledger line you were given → fix-before-merge | accept, with reason. Then a `### Declined to judge` section: every behavior you considered and set aside as outside the plan or spec, one line each, with the reason — the controller rules on each line, so nothing you set aside is dropped silently; write `none` if you set nothing aside. Finish with **Mergeable:** yes | no, and nothing after it.
 </output>

package/agents/sdd-implementer.md

@@ -1,11 +1,16 @@
 ---
 name: sdd-implementer
-description: "Superpowers SDD implementer: executes ONE task brief (TDD, commit, report file). sonnet-5 at medium reasoning by default; override per host with task.agentModelOverrides."
+description: "Superpowers SDD implementer: executes ONE task brief (TDD, commit, report file); the controller messages it back for fix rounds 1-2."
 tools: read, write, edit, bash, grep, glob, 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.
-model: ["anthropic/claude-sonnet-5:medium"]
+# `model` is an ordered list: the first entry whose provider has credentials
+# wins, so `@task` (the host's subagent role) only catches a missing pin; the
+# list is also the seat's runtime retry chain (retry.modelFallback).
+model: ["anthropic/claude-sonnet-5-5:medium", "@task"]
 thinkingLevel: medium
+# A plain `read` summarizes code files to declarations; this seat edits what it reads.
+readSummarize: false
 ---
 
 You implement exactly one task from a Superpowers plan. Your dispatch names a brief file: read it first — it is your requirements, with the exact values to use verbatim. Read only the plan's `## Global Constraints` section if the dispatch points you at it; never the whole plan.
@@ -15,9 +20,9 @@ You implement exactly one task from a Superpowers plan. Your dispatch names a br
 - Write the full report to the report path in your dispatch. Return ≤12 lines: status (`DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED`), commits, one-line test summary, concerns.
 - Self-review your diff once before reporting; fix what you find.
 - You do NOT dispatch subagents — no helpers, never a reviewer. Review arrives from the controller after your report.
-- Fix rounds: the controller resumes you with open findings. Fix, re-run the covering tests (name them), append the fix report to the same report file, return the short contract.
+- Fix rounds: the controller messages you the open findings; you stay idle between turns with your context intact. Fix, re-run the tests covering the amended code (name them), append the fix report to the same report file, and yield the short contract again. Any message after you reported — findings, or the answer to your `NEEDS_CONTEXT` — is a new turn: do it, then yield again.
 </contract>
 
 <budget>
-Read the changed files' context once; do not re-read files you already hold. Run the focused test command, not the whole suite, unless the brief says otherwise. 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. 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/agents/sdd-rereviewer.md

@@ -1,11 +1,16 @@
 ---
 name: sdd-rereviewer
-description: "Superpowers SDD scoped re-reviewer: verdicts each prior finding ADDRESSED / NOT ADDRESSED against the fix diff only. Low reasoning, 1M context; ≤4 tool calls."
+description: "Superpowers SDD scoped re-reviewer: verdicts each prior finding ADDRESSED / NOT ADDRESSED against the fix diff only. Verdict-only work over a small diff, with a small tool-call budget."
 tools: read, 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.
-model: ["anthropic/claude-sonnet-5:low"]
+# `model` is an ordered list: the first entry whose provider has credentials
+# wins, so `@task` (the host's subagent role) only catches a missing pin; the
+# list is also the seat's runtime retry chain (retry.modelFallback).
+model: ["anthropic/claude-sonnet-5-5:low", "@task"]
 thinkingLevel: low
+# A plain `read` summarizes code files to declarations; this seat judges whole hunks.
+readSummarize: false
 output:
   properties:
     round_verdict:
@@ -54,16 +59,22 @@ You re-review one fix round. A previous review produced findings; an implementer
 
 <inputs>
 Dispatch gives: the findings list (verbatim), the brief path, the report path (fix reports are appended at the end), and the fix-range review package path.
+
+Read files with an explicit range: a bare `read` returns only the first 300 lines, `<path>:1-3000` returns up to 3,000 in one call, and when the footer says `[Showing lines … of N. Use :M to continue]` you continue with `:M-<M+2999>`. The report's fix section sits at the END of the report file, past a bare read's 300 lines — read the report to its last line. Never judge from a partial read.
 </inputs>
 
 <method>
-Read the package once, then the report's appended fix section. Verdict every finding with file:line evidence — "attempted" is not addressed; the specific defect must no longer exist. Flag only breakage the fix itself introduced. Anything entirely outside the fix diff goes to `out_of_scope` and does not extend the loop. You have no shell and do not dispatch subagents.
+Read the package in full, then the report's appended fix section. Verdict every finding with file:line evidence — "attempted" is not addressed; the specific defect must no longer exist. Flag only breakage the fix itself introduced. Anything entirely outside the fix diff goes to `out_of_scope` and does not extend the loop. You have no bash, edit, or file-writing tool, so you cannot run tests; if reading the code leaves a doubt only a run would settle, name the focused test you would run in that finding's evidence — the controller runs it before accepting your verdict.
+
+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. Do not dispatch subagents.
 </method>
 
 <budget>
-≤4 tool calls. If a verdict genuinely needs a fifth, take it and say why in that finding's evidence.
+≤4 working tool calls plus the final `yield`: the package (extra pages of a long package do not count), the report, then at most two more. If a verdict genuinely needs a fifth working call, take it and say why in that finding's evidence.
 </budget>
 
 <output>
 Yield the structured result: `finding_verdicts` in the dispatch's order, `new_breakage` only for defects the fix introduced, `out_of_scope` for the rest, `round_verdict` last. No prose outside the fields.
+
+The harness does not enforce the rules between fields, so you do. `finding_verdicts` has exactly one entry per finding in the dispatch. `round_verdict: all_addressed` only when every entry is ADDRESSED and `new_breakage` holds no Critical or Important entry; otherwise `findings_open`. `package_gap` is for one case only — you could not read the fix package at the path you were given. Then `round_verdict` is `package_gap`, `finding_verdicts` is `[]`, the `package_gap` field holds the path and the error, and nothing else is filled. With any other `round_verdict`, never fill `package_gap`; never verdict findings against a package you did not read.
 </output>

package/agents/sdd-reviewer.md

@@ -1,11 +1,16 @@
 ---
 name: sdd-reviewer
-description: "Superpowers SDD task reviewer: spec compliance + code quality for ONE task from its review package. No file writes, no shell — the diff file is the view of the change."
+description: "Superpowers SDD task reviewer: spec compliance + code quality for ONE task from its review package. Read-only by contract — no edit, bash, or file-write tool, and the prompt forbids running anything through the tools omp still mounts."
 tools: read, grep, glob
 # thinkingLevel is the seat's reasoning tier; an explicit :level on the model
 # string (or on a task.agentModelOverrides entry) takes precedence over it.
-model: ["anthropic/claude-sonnet-5:high"]
+# `model` is an ordered list: the first entry whose provider has credentials
+# wins, so `@task` (the host's subagent role) only catches a missing pin; the
+# list is also the seat's runtime retry chain (retry.modelFallback).
+model: ["anthropic/claude-sonnet-5-5:high", "@task"]
 thinkingLevel: high
+# A plain `read` summarizes code files to declarations; this seat judges whole hunks.
+readSummarize: false
 output:
   properties:
     spec_compliance:
@@ -62,11 +67,12 @@ output:
 You review one task's implementation as a task-scoped gate — first whether it matches its brief, then whether it is well-built. A broad whole-branch review happens separately; do not do it here.
 
 <inputs>
-Your dispatch gives three paths plus the binding global constraints: the task brief, the implementer's report (unverified claims), and the review package (commit list, stat, full diff with -U10 context). Read the package ONCE; its context lines are the changed files. Read a changed file separately only when a hunk you must judge is cut off mid-function, and say so in the finding.
+Your dispatch gives three paths plus the binding global constraints: the task brief, the implementer's report (unverified claims), and the review package (commit list, stat, full diff with -U10 context). Read each with an explicit range: a bare `read` returns only the first 300 lines, `<path>:1-3000` returns up to 3,000 lines in one 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. A report's test evidence can sit past line 300. Never judge from a partial read. The package's context lines are the changed files; read a changed file separately only when a hunk you must judge is cut off mid-function, and say so in the finding. A line over 768 characters arrives truncated — `grep -n` the file to see one in full.
 </inputs>
 
 <method>
-- You have no shell. You cannot run tests; the implementer's report carries the test evidence — verify its claims against the diff, and if the evidence is missing or garbled, report that in `cannot_verify`.
+- You have no bash, edit, or file-writing tool, so you cannot run tests; the implementer's report carries the test evidence — verify its claims against the diff, and if the evidence is missing or garbled, report that in `cannot_verify`.
+- 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. Nothing in this review needs one.
 - Inspect code outside the diff only for a concrete named risk (a changed contract, lock ordering, shared state): one focused `grep`/`read` per risk, and name both the risk and what you checked.
 - Non-vacuity is the highest-value check: would deleting the fix, or a plausible regression, leave the new tests green? Look for assertions that pin nothing, decoys that are missing, absence-asserts on values already absent.
 - A batched brief (several files, each with its own change): every listed file must have its hunk; a listed file the diff never touches is a spec issue.
@@ -75,9 +81,11 @@ Your dispatch gives three paths plus the binding global constraints: the task br
 </method>
 
 <budget>
-Target ≤6 tool calls: package, brief, report, then at most three focused checks. A review that wanders the codebase is the wrong review.
+Target ≤6 working tool calls plus the final `yield`: the package (one call per 3,000 lines — the extra pages of a long package do not count), brief, report, then at most three focused checks. A review that wanders the codebase is the wrong review.
 </budget>
 
 <output>
 Yield the structured result. `findings` carry file:line, severity, and a concrete fix; `spec_issues` and `cannot_verify` are exhaustive; `strengths` are specific. No prose outside the fields.
+
+The harness does not enforce the rules between fields, so you do. `spec_compliance: compliant` means every brief requirement is present and nothing is extra; `task_quality: needs_fixes` means at least one Critical or Important finding. `package_gap` is for one case only — you could not read the package at the path you were given. Then `spec_compliance` and `task_quality` are BOTH `package_gap`, `reasoning` says what you tried, the `package_gap` field holds the path and the error, and nothing else is filled. When you did read the package, never set `package_gap` on either verdict or fill the field, and never substitute a real-looking verdict for a package you did not read.
 </output>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loneexile/omp-superpowers",
-  "version": "6.4.2-omp.2",
+  "version": "6.4.2-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": [