ocmm 0.5.3 → 0.6.0

package/plugins/deepwork/package.json

@@ -1,6 +1,6 @@
 {
   "name": "deepwork-codex-plugin-runtime",
-  "version": "0.5.3",
+  "version": "0.6.0",
   "private": true,
   "type": "module"
 }

package/plugins/deepwork/skills/deepwork/SKILL.md

@@ -30,7 +30,7 @@ When a Deepwork role maps to a generated agent, use the exact Codex agent type w
 
 - Plan review: `[@dw-plan-critic](subagent://dw-plan-critic)` or `multi_agent_v1.spawn_agent(agent_type="dw-plan-critic", fork_context=false, message="Review the plan at <path>.")`
 - Code/work review: `[@dw-reviewer](subagent://dw-reviewer)` or `multi_agent_v1.spawn_agent(agent_type="dw-reviewer", fork_context=false, message="<bounded review task>")`
-- Self-supervision: `[@dw-oracle](subagent://dw-oracle)` or `multi_agent_v1.spawn_agent(agent_type="dw-oracle", fork_context=false, message="<specific verification task>")`
+- Ordered Oracle review: `[@dw-oracle](subagent://dw-oracle)` first, then `[@dw-oracle-2nd](subagent://dw-oracle-2nd)` through configured later slots only when additional independent evidence is explicitly needed.
 
 When Codex exposes MultiAgentV2 flat tools, map Deepwork delegation to the available flat tool names instead of forcing V1 syntax: use `spawn_agent` to create a bounded agent, `wait_agent` to wait for completion, `followup_task` to continue an existing agent, `interrupt_agent` to stop a runaway agent, and `fork_turns` only for explicit branch-style exploration. If those names are not callable in the current thread, fall back to the route order below.
 
@@ -62,85 +62,101 @@ If an exact `dw-*` invocation returns `unknown agent_type`, continue at route 2
 
 ## Generated Agents
 
-| Codex agent | Model | Effort | Deepwork source |
-|---|---|---|---|
-| dw-builder | gpt-5.5 | high | builder |
-| dw-clarifier | gpt-5.5 | high | clarifier |
-| dw-code-search | gpt-5.4-mini-fast | high | code-search |
-| dw-coding | gpt-5.5 | high | coding |
-| dw-complex | gpt-5.5 | high | complex |
-| dw-creative | gpt-5.5 | high | creative |
-| dw-deep | gpt-5.5 | high | deep |
-| dw-doc-search | gpt-5.4-mini-fast | high | doc-search |
-| dw-documenting | gpt-5.5 | high | documenting |
-| dw-explore | gpt-5.4-mini-fast | high | explore |
-| dw-frontend | gpt-5.5 | high | frontend |
-| dw-hard-reasoning | gpt-5.5 | xhigh | hard-reasoning |
-| dw-media-reader | gpt-5.5 | high | media-reader |
-| dw-normal-task | gpt-5.5 | high | normal-task |
-| dw-oracle | gpt-5.4 | xhigh | oracle |
-| dw-orchestrator | gpt-5.5 | high | orchestrator |
-| dw-plan-critic | gpt-5.5 | xhigh | plan-critic |
-| dw-planner | gpt-5.5 | high | planner |
-| dw-quick | gpt-5.4-mini | high | quick |
-| dw-research | gpt-5.5 | high | research |
-| dw-reviewer | gpt-5.5 | xhigh | reviewer |
+| Codex agent | Profile effort | Deepwork source |
+|---|---|---|
+| dw-builder | high | builder |
+| dw-clarifier | high | clarifier |
+| dw-code-search | high | code-search |
+| dw-coding | high | coding |
+| dw-complex | high | complex |
+| dw-creative | high | creative |
+| dw-deep | xhigh | deep |
+| dw-doc-search | high | doc-search |
+| dw-documenting | high | documenting |
+| dw-explore | high | explore |
+| dw-frontend | high | frontend |
+| dw-hard-reasoning | xhigh | hard-reasoning |
+| dw-media-reader | high | media-reader |
+| dw-normal-task | high | normal-task |
+| dw-oracle | xhigh | oracle |
+| dw-oracle-2nd | xhigh | oracle-2nd |
+| dw-orchestrator | high | orchestrator |
+| dw-plan-critic | xhigh | plan-critic |
+| dw-planner | xhigh | planner |
+| dw-quick | high | quick |
+| dw-research | high | research |
+| dw-reviewer | xhigh | reviewer |
+
+Generated profile defaults are installation metadata, not mandatory choices. Actual delegation must preserve explicit user configuration and select overrides only from the currently available model catalog.
 
 ## Runtime Model Selection
 
 For an exact profile, omit `model` and `reasoning_effort` by default so Codex can apply the selected `dw-*` profile. For direct composition, select the tier model below only when the current tool exposes `model`, preserve the profile's existing reasoning effort as the baseline, and load the selected role's developer instructions and required skills. For generic/flat dispatch with no model field, do not invent an override: the child inherits its native/default model while the role and skills are carried in `message`. An explicit user-selected model always wins.
 
-### GPT runtime upgrades (only when directly selectable)
+### Runtime model upgrades (only when directly selectable)
 
-Apply this section only when the current dispatch surface exposes a `model` field or an exact profile route that also accepts a model override. An explicit user-selected model always wins. Determine availability from the current callable surface or active model catalog; do not assume a model exists from its name. When no GPT-5.6 model is available, omit the override and preserve the generated profile's existing model and reasoning behavior unchanged.
+Apply this section only when the current dispatch surface exposes a `model` field or an exact profile route that also accepts a model override. An explicit user-selected model always wins. Determine availability from the current callable surface or active model catalog; model names in examples are references only and never prove availability. When no suitable model in a lane is available, omit the override and preserve the generated profile's existing model and reasoning behavior unchanged.
 
-| Role lane | Preferred GPT-5.6 model | Reasoning effort | Roles |
+| Role lane | Selection principle | Reasoning effort | Roles |
 |---|---|---|---|
-| Flagship | `gpt-5.6-sol` | `high` by default; `xhigh` for deep, architecture, algorithmic, security, or high-risk reasoning | dw-orchestrator, dw-planner, dw-builder, dw-clarifier, dw-deep, dw-hard-reasoning |
-| External review | `gpt-5.6-sol` | `xhigh` minimum; local `max` for complex, cross-module, security, performance, high-risk, or final-gate review (mapped to the target maximum) | dw-reviewer |
-| Plan review | `gpt-5.6-sol` | fixed `xhigh` | dw-plan-critic |
-| Cross-check | `gpt-5.4`, then `gpt-5.5`, then `gpt-5.6-terra` | `xhigh` minimum; local `max` for complex or high-risk verification (mapped to the target maximum) | dw-oracle |
-| Mid | `gpt-5.6-terra` | Preserve the profile baseline unless task complexity requires more | dw-complex, dw-normal-task, dw-coding, dw-research, dw-frontend, dw-creative, dw-documenting, dw-media-reader, dw-doc-search |
-| Mini | `gpt-5.6-luna` | `high` | dw-quick, dw-code-search, dw-explore |
+| Flagship | Best available primary reasoning model in the user's catalog | `xhigh` minimum for planning, deep implementation, hard reasoning, architecture, algorithmic, security, or high-risk work; use native `max` on GPT-5.6 when maximum reasoning is requested, and use the family-supported maximum elsewhere. `high` remains acceptable for coordination, implementation, or clarification roles below that threshold. | dw-orchestrator, dw-planner, dw-builder, dw-clarifier, dw-deep, dw-hard-reasoning |
+| External review | Same primary reasoning lane as flagship work, selected from available models; Reviewer has logical tiers only and no ordinal slots | `xhigh` minimum; use native `max` on GPT-5.6 for complex, cross-module, security, performance, high-risk, or final-gate review | dw-reviewer |
+| Ordered Oracle review | Oracle slots are model priority, not capability ranking (`dw-oracle`, then `dw-oracle-2nd` through configured later slots) | `xhigh` minimum for GPT/Codex review routes; preserve native `max` when explicitly selected and supported | dw-oracle*, dw-oracle-2nd*, dw-oracle-3rd*... |
+| Plan review | Same primary reasoning lane when directly configurable | `xhigh` minimum; local `max` only by explicit local configuration | dw-plan-critic |
+| Mid | Best available mid-tier model; if none exists, use the primary reasoning model at a lower effort | Preserve the profile baseline unless task complexity requires more | dw-complex, dw-normal-task, dw-coding, dw-research, dw-frontend, dw-creative, dw-documenting, dw-media-reader, dw-doc-search |
+| Mini | Best available lightweight model for mechanical, search, or fast lookup work | `high` for accuracy unless the user explicitly configures otherwise | dw-quick, dw-code-search, dw-explore |
+
+When a newer family is explicitly available, select a demonstrably better model in the same capability lane instead of pinning an example name. Keep the role's high/xhigh/max complexity rule, never override an explicit user model, and fall back to the generated profile default when availability or capability evidence is absent.
+
+Reviewer and Oracle routes use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise they use the highest supported review effort for that family. GPT-5.6 supports native `max`, so complex or high-risk review/verification on a GPT-5.6 selected model may request `max` directly. Other families use `max` only when their cataloged controls support it.
 
-When a newer GPT family is explicitly available, select a demonstrably better model in the same capability lane instead of pinning the 5.6 name for Flagship and External review. For Cross-check while a GPT-5.6 primary model is in use, prefer a cross-generation GPT-5.4 xhigh oracle first, then GPT-5.5 xhigh, before same-generation GPT-5.6 Terra/Terra successors. Keep the role's high/xhigh complexity rule, never override an explicit user model, and fall back to the generated profile default when availability or capability evidence is absent.
+The plan-critic profile uses `xhigh` minimum; raise it only through explicit local configuration.
 
-For reviewer and oracle GPT/Codex routes, `xhigh` is the minimum reasoning effort. For complex or high-risk review or verification, request local `max`; the adapter maps it to the target's maximum supported effort (currently `xhigh` for GPT/Codex).
+### Ordered Oracle profiles in this bundle
 
-The plan-critic profile remains fixed `xhigh`; its receipt-focused plan review does not use the reviewer/oracle local-effort escalation policy.
+- Slot 1: `dw-oracle` (logical tiers: `normal`)
+- Slot 2: `dw-oracle-2nd` (logical tiers: `normal`)
+
+Slot ordering is always by Oracle ordinal (`oracle`, `oracle-2nd`, `oracle-3rd`, ...). Logical tier choice never reorders slots.
+
+### Ordered Oracle review
+
+- Oracle priority is ordered by slot: `dw-oracle`, then `dw-oracle-2nd` through later configured slots.
+- Oracle slots are model priority, not capability ranking.
+- The unsuffixed profile is logical `normal`; configured `-low`, `-high`, and `-max` profiles select task rigor independently of slot priority.
+- Simple final acceptance selects the first available Oracle normal profile.
+- Complex cross-module final acceptance selects the first available Oracle plus Reviewer; for each role choose configured `high`, falling back to unsuffixed `normal` when `high` is absent.
+- Security, performance, data-loss, release, or runtime-safety review selects configured `max`, otherwise configured `high`, otherwise unsuffixed `normal`.
+- Logical `low` is selected only by an explicit user/workflow cost-or-latency request and still receives the review-effort floor.
+- Additional Oracle passes select later configured slots in order only when additional independent evidence is explicitly needed.
+- Configuring multiple Oracle profiles does not fan-out automatically.
+- Reviewer has logical tier variants only and has no ordinal profiles.
 
 ### Tier assignments
 
 | Tier | Agents | Model | Effort |
 |---|---|---|---|
-| Flagship | dw-orchestrator, dw-planner, dw-builder, dw-clarifier, dw-deep, dw-hard-reasoning | Latest-gen flagship | high or xhigh by complexity |
-| External review | dw-reviewer | Latest-gen flagship | xhigh minimum; local max for complex or high-risk review |
-| Plan review | dw-plan-critic | Latest-gen flagship | fixed xhigh |
-| Cross-check | dw-oracle | GPT-5.4 xhigh first when available, then GPT-5.5 xhigh, then same-generation GPT-5.6 Terra/Terra successor; otherwise a strong non-identical capable model | xhigh minimum; local max for complex or high-risk verification |
-| Mid | dw-complex, dw-normal-task, dw-coding, dw-research, dw-frontend, dw-creative, dw-documenting, dw-media-reader, dw-doc-search | Latest-gen mid-tier at max, else flagship at high | max or high |
-| Mini | dw-quick, dw-code-search, dw-explore | Latest-gen mini | high |
+| Flagship | dw-orchestrator, dw-planner, dw-builder, dw-clarifier, dw-deep, dw-hard-reasoning | Primary reasoning model from the user's available catalog | xhigh minimum for planner/deep/hard-reasoning; native max for GPT-5.6 maximum-reasoning work. high only for coordination, implementation, or clarification roles below that threshold |
+| External review | dw-reviewer | Primary reasoning lane | xhigh-equivalent minimum when supported; native max for GPT-5.6 complex or high-risk review |
+| Ordered Oracle review | dw-oracle, dw-oracle-2nd, later configured Oracle slots | Ordered by Oracle slot ordinal; tier choice does not reorder slots | xhigh-equivalent minimum when supported; native max for GPT-5.6 complex or high-risk verification |
+| Plan review | dw-plan-critic | Primary reasoning lane | xhigh minimum unless local config raises it |
+| Mid | dw-complex, dw-normal-task, dw-coding, dw-research, dw-frontend, dw-creative, dw-documenting, dw-media-reader, dw-doc-search | Available mid-tier model, else primary reasoning model at lower effort | max or high by task shape |
+| Mini | dw-quick, dw-code-search, dw-explore | Available lightweight model | high |
 
 ### Model tier definitions
 
-- **Flagship**: the most capable model of the latest generation (e.g., gpt-5.5 in the 5.x gen).
-- **Mid-tier**: a lighter-but-capable model within the latest generation. If the latest gen has no mid-tier, use the flagship at `high` effort instead.
-- **Mini**: the smallest/cheapest model of the latest generation (e.g., `-mini` variants).
-- **Strong non-identical cross-check**: a capable available model that differs from the primary lane when possible; model diversity is useful, but not a reason to bypass the newer-model policy.
+- **Flagship**: the most capable primary reasoning model available to the user.
+- **Mid-tier**: a lighter-but-capable configured model. If no mid-tier lane is available, use the primary reasoning lane at `high` effort instead.
+- **Mini**: the smallest/cheapest model available for fast mechanical or lookup tasks.
 
-### Independent review rule
+### Review dispatch guardrail
 
-dw-oracle provides self-supervision through the Cross-check lane, while dw-reviewer provides external review through the External review lane. When GPT-5.6 Sol is the primary review model, prefer GPT-5.4 xhigh for oracle diversity, then GPT-5.5 xhigh, before same-generation GPT-5.6 Terra. For complex multi-module work where GPT-5.4, GPT-5.5, and GPT-5.6 are all directly available, you may run three-way cross-validation: dw-reviewer on GPT-5.6 xhigh/local max plus oracle/cross-check passes on GPT-5.4 xhigh and GPT-5.5 xhigh. Do not force this for ordinary work.
+Oracle and Reviewer profiles are selectable options, not automatic fan-out. Choose exactly the profiles required by risk/complexity and dispatch only those selections.
 
-dw-plan-critic provides receipt-focused plan review through the Plan review lane at fixed `xhigh`.
+dw-plan-critic provides receipt-focused plan review through the Plan review lane at `xhigh` minimum.
 
-If only one capable model is available, keep the reviewer/oracle GPT/Codex `xhigh` floor and use local `max` for complex or high-risk review or verification.
+Reviewer and Oracle routes use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise they use the highest supported review effort for that family. GPT-5.6 supports native `max`; for other families, request `max` only when the selected model and catalog expose a maximum-effort control.
 
-### Example (GPT-5.6 generation — verify against your available models)
+### Example names
 
-| Tier | Example model | Effort |
-|---|---|---|
-| Flagship | gpt-5.6-sol | high or xhigh |
-| External review | gpt-5.6-sol | xhigh minimum; local max for complex/high-risk work |
-| Cross-check | gpt-5.4, then gpt-5.5, then gpt-5.6-terra | xhigh minimum; local max for complex/high-risk work |
-| Mid | gpt-5.6-terra | high or max |
-| Mini | gpt-5.6-luna | high |
+Concrete model names in docs, tests, or generated profile comments are examples and compatibility references only. Select from the user's currently available model catalog and explicit local configuration; never require a specific example name or provider channel.

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

@@ -7,9 +7,10 @@ description: Use after all implementation tasks complete, after major features a
      Upstream: obra/superpowers v6.0.3.
      Adjustments: removed executing-plans and subagent-driven-development
      cross-references (v1 uses subagent-driven as the only path); added
-     Reviewer Selection section for oracle/reviewer duality (oracle =
-     self-supervision, reviewer = external review). See docs/v1-maintenance.md
-     for sync rules. -->
+     Reviewer Selection section for ordered Oracle slot semantics and logical
+     tiers (oracle slots = model-priority ordering, reviewer = external review
+     lane, tiers = low/normal/high/max). See docs/v1-maintenance.md for sync
+     rules. -->
 
 # Requesting Code Review
 
@@ -31,12 +32,28 @@ Dispatch a code reviewer subagent to catch issues before they cascade. The revie
 
 ## How to Request
 
-**1. Get git SHAs:**
+**1. Choose the review input:**
+
+Use a committed range only when an orchestrator-owned, user-authorized commit already exists:
+
 ```bash
 BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
 HEAD_SHA=$(git rev-parse HEAD)
+git diff --stat $BASE_SHA..$HEAD_SHA
+git diff $BASE_SHA..$HEAD_SHA
 ```
 
+Working-tree diff review (use this when implementation subagents returned uncommitted changes):
+
+```bash
+git diff --stat
+git diff
+git diff --cached --stat
+git diff --cached
+```
+
+Do not require implementation subagents to commit, stage, or push merely to create a review range. The orchestrator owns any Git write and performs it only after explicit user authorization.
+
 **2. Dispatch code reviewer subagent:**
 
 Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
@@ -44,8 +61,7 @@ Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
 **Placeholders:**
 - `{DESCRIPTION}` - Brief summary of what you built
 - `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
+- `{REVIEW_INPUT}` - Commit range plus commands, or working-tree/staged diff commands and output
 
 **3. Act on feedback:**
 - Fix Critical issues immediately
@@ -57,31 +73,39 @@ Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
 
 ## Reviewer Selection
 
-Two reviewer agents are available, with distinct semantics:
+Review selection has two independent axes: role/model priority and logical rigor.
 
-| Agent | Role | Model default |
-|---|---|---|
-| `oracle` | Self-supervision — review work the current agent itself produced | Cross-gen (different generation from main, to avoid self-confirmation bias) |
-| `reviewer` | External review — review code not produced by the current agent | Flagship (same family as main) |
+### Axis 1 — Role/Model Priority
 
-**Selection by task complexity:**
+- Oracle slots are ordered as `oracle`, `oracle-2nd`, then configured `oracle-3rd` through `oracle-9th`.
+- `oracle-2nd` and every later slot have lower selection priority, never greater capability.
+- The external review lane is `reviewer`; `reviewer-2nd` does not exist.
 
-| Task shape | Reviewer(s) | Rationale |
-|---|---|---|
-| Simple / single-stage (1-2 tasks, one module, no architectural change) | `oracle` (default) | plan-critic already reviewed the plan; self-supervision suffices |
-| Complex / large (3+ tasks, cross-module, architectural change, security/performance sensitive) | `oracle` + `reviewer` (both, in parallel) | cross-gen self-supervision AND external review catch orthogonal issues |
-| User habit override | user-specified | user may prefer reviewer for all cases, or oracle for all cases |
+### Axis 2 — Logical Rigor Tiers
+
+- Logical tiers are `low`, `normal`, `high`, `max`.
+- `normal` is the unsuffixed profile (`oracle`, `reviewer`).
+- Tier-suffixed profiles are used only when configured and available.
 
-**How to dispatch:**
+**Selection by work shape:**
 
-- Single reviewer: dispatch one subagent with the chosen reviewer agent type (`oracle` or `reviewer`), passing the work SHAs and context via the `code-reviewer.md` template.
-- Both reviewers: dispatch two subagents in parallel (one `oracle`, one `reviewer`), each with the same SHAs and context. Collect both feedback sets before acting.
+| Work shape | Reviewer(s) | Tier choice |
+|---|---|---|
+| Simple / single-stage (1-2 tasks, one module, no architectural change) | first available Oracle | `normal` |
+| Complex / cross-module / large integration | first available Oracle + `reviewer` (parallel) | configured `high`, otherwise `normal` |
+| Security / performance / data-loss / release / runtime-safety work | first available Oracle + `reviewer` (parallel) | configured `max`, otherwise `high`, otherwise `normal` |
+| Additional evidence requested | additional Oracle slots in order (`oracle-2nd`, then later configured slots) | keep the intentionally selected tier; user override is still subject to availability/disabled profiles/floors |
+
+**Dispatch semantics:**
 
-**Default:** `oracle` for simple tasks. Upgrade to both when the orchestrator judges the task complex or large.
+- Configuring several slots or tiers never triggers automatic fan-out by itself.
+- A higher logical tier can be selected without adding more reviewers.
+- A later Oracle slot is another configured model perspective, not a stronger reviewer.
+- User overrides are allowed, but availability, disabled profiles, and floor constraints still apply.
 
-`oracle` can also be an optional independent consultation for a high-risk implementation plan. It does not replace the `plan-critic` receipt, does not make dual plan review mandatory, and a timeout or partial response is not a conclusion.
+`oracle` can also be an optional independent consultation for a high-risk implementation plan. It does not replace the current `plan-critic` receipt, does not make dual plan review mandatory, and a timeout or partial response is not a conclusion.
 
-**GPT/Codex reasoning policy:** `reviewer` and `oracle` use `xhigh` minimum. For complex or high-risk review or verification, request local `max`; the adapter maps it to the target's maximum supported effort (currently `xhigh` for GPT/Codex). `plan-critic` remains `xhigh`.
+**Reasoning policy:** Every parsed Oracle/Reviewer profile retains an `xhigh` minimum floor when the selected model family exposes that control; otherwise use the highest supported review effort for that family. This floor remains in effect while logical tier selection still includes `low`/`normal`/`high`/`max` semantics. GPT-5.6 supports native `max`, so complex or high-risk review/verification on GPT-5.6 can request local `max` directly; other model families use local `max` only when their cataloged controls expose a maximum-effort level. `plan-critic` uses `xhigh` minimum and may be raised by explicit local configuration. Example model names are references only; explicit user configuration and currently available models decide the actual selection.
 
 ## Example
 
@@ -90,14 +114,16 @@ Two reviewer agents are available, with distinct semantics:
 
 You: Let me request final acceptance review before declaring this done.
 
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
+[Implementation subagents returned uncommitted changes, so review the working tree:]
+git diff --stat
+git diff
+git diff --cached --stat
+git diff --cached
 
 [Dispatch code reviewer subagent]
   DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
   PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
+  REVIEW_INPUT: working-tree diff commands and output above
 
 [Subagent returns]:
   Strengths: Clean architecture, real tests

package/plugins/deepwork/skills/deepwork-requesting-code-review/code-reviewer.md

@@ -20,16 +20,21 @@ Task tool (general-purpose):
 
     {PLAN_OR_REQUIREMENTS}
 
-    ## Git Range to Review
+    ## Git Range or Working-Tree Diff to Review
 
-    **Base:** {BASE_SHA}
-    **Head:** {HEAD_SHA}
+    {REVIEW_INPUT}
+
+    If this is a committed range, inspect it with the provided `git diff <base>..<head>` commands. If this is uncommitted work, inspect the supplied working-tree/staged diff commands:
 
     ```bash
-    git diff --stat {BASE_SHA}..{HEAD_SHA}
-    git diff {BASE_SHA}..{HEAD_SHA}
+    git diff --stat
+    git diff
+    git diff --cached --stat
+    git diff --cached
     ```
 
+    Do not request that an implementation subagent create a commit; ask the orchestrator for missing diff evidence instead.
+
     ## What to Check
 
     **Plan alignment:**
@@ -124,8 +129,7 @@ Task tool (general-purpose):
 **Placeholders:**
 - `{DESCRIPTION}` — brief summary of what was built
 - `{PLAN_OR_REQUIREMENTS}` — what it should do (plan file path, task text, or requirements)
-- `{BASE_SHA}` — starting commit
-- `{HEAD_SHA}` — ending commit
+- `{REVIEW_INPUT}` — commit range plus commands, or working-tree/staged diff commands and output
 
 **Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
 

package/plugins/deepwork/skills/deepwork-subagent-driven-development/SKILL.md

@@ -11,12 +11,13 @@ description: Use when executing implementation plans with independent tasks in t
      inline in v1); final code review uses requesting-code-review skill only.
      Synced v6.1.1+: Model Selection rewrite (explicit model dispatch, turn-count
      beats token price, tiered guidance); Constructing Reviewer Prompts section
-     (no pre-judging, no open-ended directives, verbatim global constraints, no
-     history pasting, findings handling by severity); Narration discipline rule;
-     task-type analysis hint (prefer dispatching-parallel-agents for independent
-     tasks). v1 intentionally replaces per-task reviewer loops with
-     completion/integration checks plus one final acceptance review; ⚠️ Items
-     section (reviewer "Cannot verify from diff" items). Did NOT sync:
+      (no pre-judging, no open-ended directives, verbatim global constraints, no
+      history pasting, findings handling by severity); Narration discipline rule;
+      task-type analysis hint (prefer dispatching-parallel-agents for independent
+      tasks); Final Acceptance Review stage updated with ordered Oracle slot
+      priority and logical tiers. v1 intentionally replaces per-task reviewer loops with
+      completion/integration checks plus one final acceptance review; ⚠️ Items
+      section (reviewer "Cannot verify from diff" items). Did NOT sync:
      review-package/task-brief bash scripts (Windows incompatible); progress
      ledger (v1 uses TodoWrite); File Handoffs/Durable Progress sections
      (depend on scripts).
@@ -48,12 +49,14 @@ Execute plan by dispatching a fresh subagent per task, running a completion/inte
 2. **Per task:**
    a. Dispatch implementer subagent (use implementer-prompt.md template)
    b. If implementer asks questions, answer and re-dispatch
-   c. Implementer implements, tests, commits, self-reviews
+   c. Implementer implements, tests, self-reviews, and reports changed files plus a suggested commit message. Subagents do not commit, stage, push, or run any Git write command.
    d. **Completion/Integration check (not a full review):** Read the agent's summary, inspect touched files/diff, run targeted tests or record implementer evidence, verify the task is complete, and check whether the change conflicts with earlier tasks or needs follow-up by the same implementer
    e. If the completion check finds gaps, re-dispatch the same implementer to fix them
    f. Mark task complete in TodoWrite
 3. **After all tasks:** Dispatch final code reviewer subagent for the entire implementation (use requesting-code-review skill)
 
+**Git ownership:** Subagents do not commit, stage, push, or run any Git write command. They return changed files and a suggested commit message to the orchestrator, along with verification evidence. The orchestrator performs any Git write only after explicit user authorization.
+
 ## Model Selection
 
 Use the least powerful model that can handle each role — but **always specify the model explicitly** when dispatching a subagent. Omitting it inherits the session model, which is usually the most expensive.
@@ -76,7 +79,7 @@ Use the least powerful model that can handle each role — but **always specify
 
 Implementer subagents report one of four statuses. Handle each appropriately:
 
-**DONE:** Run the completion/integration check, then continue to the next task. Do not dispatch spec-reviewer or code-quality-reviewer for a clean DONE result.
+**DONE:** Run the completion/integration check, then continue to the next task. Do not dispatch spec-reviewer or code-quality-reviewer for a clean DONE result. If the work needs a commit, the implementer reports the intended files and message; the orchestrator handles any Git write only after explicit user authorization.
 
 **DONE_WITH_CONCERNS:** The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, resolve them before continuing. If the concerns indicate high risk or cross-task conflict, consult a reviewer early; otherwise note them and continue after the completion check.
 
@@ -151,7 +154,7 @@ Each implementation task follows TDD:
 - Repeat only until that blocker is resolved
 
 **If subagent fails task:**
-- Dispatch fix subagent with specific instructions
+- Dispatch a fix subagent with specific instructions; the fix subagent also reports changes instead of committing.
 - Don't try to fix manually (context pollution)
 
 ## Completion / Integration Check
@@ -195,7 +198,7 @@ The reviewer must evaluate the diff on its merits. If you have context the revie
 
 **Do not paste accumulated history into dispatch prompts.** Each dispatch gets exactly the context it needs — the task text, the diff, the constraints. A real session once dispatched 42k characters where 99% was pasted conversation history. The reviewer cannot use that; it dilutes focus.
 
-**Dispatch the diff, not a summary.** When early consultation or final acceptance review is needed, the reviewer needs the actual diff with context, not your description of it. Structure the dispatch with the commit range, the diff, and the task description. The final acceptance review uses `code-reviewer.md` via the requesting-code-review skill; `spec-reviewer-prompt.md` and `code-quality-reviewer-prompt.md` are optional narrow-consult tools only, not routine per-task gates.
+**Dispatch the diff, not a summary.** When early consultation or final acceptance review is needed, the reviewer needs the actual diff with context, not your description of it. Structure the dispatch with the review input, the diff, and the task description; the review input may be a committed range or a working-tree/staged diff. The final acceptance review uses `code-reviewer.md` via the requesting-code-review skill; `spec-reviewer-prompt.md` and `code-quality-reviewer-prompt.md` are optional narrow-consult tools only, not routine per-task gates.
 
 **Handling findings:**
 - **Critical + Important** → dispatch a fix subagent. Each fix dispatch must include: the test name that covers the fix, the command to run it, and the expected output.
@@ -209,24 +212,34 @@ The reviewer must evaluate the diff on its merits. If you have context the revie
 
 After all plan tasks are marked complete, before declaring the work done, run a final acceptance review over the full change set. This is distinct from completion/integration checks — it evaluates the work as a whole.
 
-**1. Assess complexity:**
+**1. Assess complexity and choose reviewers deliberately:**
+
+Review selection has two independent axes: role/model priority and logical rigor.
+
+- Oracle slots are ordered by selection priority as `oracle`, `oracle-2nd`, then configured `oracle-3rd` through `oracle-9th`.
+- `oracle-2nd` and later slots mean lower selection priority, never stronger capability.
+- Logical rigor tiers are `low`, `normal`, `high`, `max` (`normal` is the unsuffixed profile; other tiers are used only when configured and available).
 
-| Complexity | Signal | Reviewer(s) |
+| Complexity / evidence shape | Reviewer(s) | Tier choice |
 |---|---|---|
-| Simple | 1-2 tasks, single module, no architectural change | `oracle` (self-supervision) |
-| Complex | 3+ tasks, cross-module, architectural change, security/performance sensitive, migration | `oracle` + `reviewer` (both, in parallel) |
+| Simple | 1-2 tasks, single module, no architectural change | first available Oracle at `normal` |
+| Complex / cross-module | 3+ tasks, cross-module integration, architectural change, migration | first available Oracle + `reviewer` in parallel; configured `high`, otherwise `normal` |
+| Security / performance / data-loss / release / runtime-safety | high-impact risk profile regardless of file count | first available Oracle + `reviewer` in parallel; configured `max`, otherwise `high`, otherwise `normal` |
+| Additional evidence requested | user/orchestrator asks for more independent model evidence | additional Oracle slots in order (start with `oracle-2nd`, then later configured/available slots in ordinal order) while keeping the intentionally selected tier |
 
-The orchestrator judges complexity from the plan scope and actual changes. When unsure, upgrade to both.
+The orchestrator performs this selection after all tasks complete. Do not fan out reviews merely because several Oracle slots or tiers are registered. Collect only intentionally requested reviews. A later Oracle slot is another configured model perspective, not a stronger reviewer.
 
 **2. Dispatch the acceptance review:**
 
-Use the `requesting-code-review` skill. Pass the full change range:
-- `BASE_SHA` = commit before the first task of the plan
-- `HEAD_SHA` = current HEAD (after all tasks)
-- `DESCRIPTION` = summary of the complete feature/work
-- `PLAN_OR_REQUIREMENTS` = the plan file path
+Use the `requesting-code-review` skill. Pass either a committed range or an uncommitted working-tree/staged diff:
+- committed range: `BASE_SHA`, `HEAD_SHA`, `DESCRIPTION`, and `PLAN_OR_REQUIREMENTS` when the orchestrator has already created a user-authorized commit;
+- working-tree/staged diff: `git diff --stat`, `git diff`, `git diff --cached --stat`, `git diff --cached`, `DESCRIPTION`, and `PLAN_OR_REQUIREMENTS` when implementation subagents returned uncommitted changes.
+
+Do not require implementation subagents to commit, stage, or push merely to create review SHAs. The orchestrator owns any Git write and performs it only after explicit user authorization.
+
+For baseline dispatch: use the selected first available Oracle, and add `reviewer` only when the complexity table says so.
 
-For both-reviewer dispatch: spawn two subagents in parallel (one `oracle`, one `reviewer`), each with the same SHAs and context. Collect both feedback sets before proceeding.
+For additional evidence: add the next configured/available Oracle slot(s) in ordinal order, each with the same review input and context. Do not add slots automatically without an intentional evidence need.
 
 **3. Process feedback:**
 

package/plugins/deepwork/skills/deepwork-subagent-driven-development/implementer-prompt.md

@@ -32,9 +32,16 @@ Task tool (general-purpose):
     1. Implement exactly what the task specifies
     2. Write tests (following TDD if task says to)
     3. Verify implementation works
-    4. Commit your work
-    5. Self-review (see below)
-    6. Report back
+    4. Self-review (see below)
+    5. Report back with changed files, verification evidence, and a suggested commit message if a commit is needed
+
+    ## Delegation Boundary
+
+    Use direct tools first. If direct tools are insufficient and a separate bounded utility result materially improves this task, you may call only utility leaves permitted by your effective Task tool: `quick`, `code-search`, `explore`, `doc-search`, `research`, and `media-reader`. If the Task tool exposes fewer targets, use only the exposed subset.
+
+    Do not launch `planner`, `plan-critic`, any Reviewer profile (`reviewer`, `reviewer-low`, `reviewer-high`, `reviewer-max`), or any Oracle profile (`oracle`, `oracle-2nd`, configured `oracle-3rd`…`oracle-9th`, and their `low`/`high`/`max` tier variants). Do not launch another implementation or coordination workflow agent. If a skill requests a disallowed review or handoff, report that need to the orchestrator instead of dispatching it.
+
+    After local verification, return status, changed files, commands, and evidence to the orchestrator. The orchestrator owns formal plan review and final acceptance review. It also owns planner, plan-critic, and review dispatch.
 
     Work from: [directory]
 

package/prompts/codex/agents/clarifier.md

@@ -81,6 +81,10 @@ Mission: avoid shotgun fixes.
 
 Require reproduction or a failing test when feasible. Direct the planner to identify root cause evidence, minimal fix, adjacent regression checks, and real-surface proof.
 
+## Nested Delegation Boundary
+
+Use direct evidence first. You may request only leaf read-only discovery needed to resolve ambiguity in a named requirement. Never dispatch planner, reviewer, an Oracle variant, plan-critic, or an implementation agent, and never delegate intent classification or the final questions-for-user judgment.
+
 ## Output Contract
 
 Return this structure:

package/prompts/codex/agents/orchestrator.md

@@ -64,7 +64,7 @@ Use the smallest agent/category that fits:
 | Structured implementation plan | `planner` |
 | Plan executability review | `plan-critic` |
 | Architecture/debugging/security/performance judgment (external review) | `reviewer` |
-| Self-supervision review (work the agent itself produced) | `oracle` |
+| Self-supervision review (work the agent itself produced) | ordered Oracle slot/profile |
 | External docs or OSS examples | `dw-doc-search` |
 | Internal codebase structure/patterns | `dw-code-search` |
 | Visual/media extraction | `media-reader` |
@@ -80,6 +80,16 @@ Use the smallest agent/category that fits:
 | Standalone documentation/prose/release-note/copy work | `documenting` |
 | Focused single task (implementation) | `coding` / `quick` / `normal-task` / `deep` (subagent) — `builder` is primary-only |
 
+## Workflow-Agent Composition Ownership
+
+You are the exclusive owner of workflow-agent composition. Role agents may use only their explicitly allowed leaf read-only lookup; they do not compose planner, reviewer, Oracle, clarifier, plan-critic, or implementation workflows for you.
+
+Oracle selection is ordered by configured model priority: `oracle`, `oracle-2nd`, then configured later slots. Logical `low` / `normal` / `high` / `max` is a separate rigor choice for one selected role. Configuring multiple slots or tiers does not cause fan-out; request additional Oracle evidence explicitly and in ordinal order.
+
+Tier selection is deterministic: simple work uses unsuffixed `normal`; complex cross-module work uses configured `high`, otherwise `normal`; security, performance, data-loss, release, or runtime-safety work uses configured `max`, otherwise configured `high`, otherwise `normal`. Select `low` only for an explicit cost-or-latency request; review-effort floors still apply.
+
+Deterministic shorthand: complex cross-module work uses configured high otherwise normal; runtime-safety work uses configured max otherwise configured high otherwise normal.
+
 ### Subagent Git Limitations
 
 Subagent sessions (category agents dispatched via `multi_agent_v1.spawn_agent`) are hard-blocked from running git write commands (commit, push, tag, reset --hard, rebase, cherry-pick, revert). The `subagent-git-guard` hook enforces this at the `tool.execute.before` level.
@@ -101,7 +111,7 @@ Five superpowers skills are embedded in your agent profile. They are not optiona
 | `brainstorming` | User requests any new feature, component, or behavior change, AND no approved design exists yet | Present a design and obtain approval BEFORE any code — approval may be explicit user approval, self-review pass with no ambiguity, or explicit user delegation ("你自己决定" / "无需批准自行继续" / "review N 次就下一步"). When ambiguous, consult `clarifier`. This is a HARD-GATE. |
 | `writing-plans` | A spec/design has been approved, or a multi-step task needs decomposition | Produce a plan at `docs/superpowers/plans/YYYY-MM-DD-<feature>.md` before implementation. Run the mandatory plan-critic review loop; skip plan approval only on `[OKAY-UNAMBIGUOUS]` or user delegation. |
 | `subagent-driven-development` | You have an implementation plan with independent tasks | Dispatch a fresh subagent per task, run a completion/integration check after each returned agent, then run a final acceptance review after all tasks. Do not run full spec/code-quality review after every subtask. |
-| `requesting-code-review` | All implementation tasks complete, a major feature completes, or before merge to main; for final acceptance: oracle (self-supervision) by default for simple tasks, both oracle and reviewer for complex/large tasks | Dispatch a code reviewer subagent with the work SHAs. Do not declare done without review. |
+| `requesting-code-review` | All implementation tasks complete, a major feature completes, or before merge to main; for final acceptance: oracle (self-supervision) by default for simple tasks, both oracle and reviewer for complex/large tasks | Dispatch a code reviewer subagent with the committed range or working-tree/staged diff review input. Do not declare done without review. |
 | `receiving-code-review` | You receive reviewer feedback | Verify each item against the codebase before implementing. No performative agreement. |
 
 Every routing decision must first check: "Does a skill trigger here?" If yes, the skill dictates the next step, not your default instinct.

package/prompts/codex/agents/plan-critic.md

@@ -47,6 +47,10 @@ Approval bias: approve when in doubt. The 80% clarity threshold applies to the `
 
 Semantic ambiguity that could cause divergent implementations IS checked (item 5 above). Stylistic ambiguity that does not affect implementation is not.
 
+## Nested Delegation Boundary
+
+Use direct file/search tools first. You may request only leaf read-only lookup needed to verify one concrete plan claim. Never dispatch planner, reviewer, an Oracle variant, clarifier, another plan-critic, or an implementation agent, and never delegate the receipt verdict.
+
 ## Decision Framework
 
 **[REJECT]** when true blockers exist. List at most 3 blocking issues. Each issue must be specific, actionable, and blocking.