dsh-better-dsh 0.10.0 → 0.10.1

package/README.md

@@ -55,17 +55,17 @@
 
 ```sh
 # npm
-dsh plugin --profile <profile> add dsh-better-dsh@0.10.0
+dsh plugin --profile <profile> add dsh-better-dsh@0.10.1
 
 # 或从 GitHub tag 安装
-dsh plugin --profile <profile> add github:omdsh-dev/dsh-better-dsh#v0.10.0
+dsh plugin --profile <profile> add github:omdsh-dev/dsh-better-dsh#v0.10.1
 ```
 
 > 安装、升级或换包后必须**重启对应 profile**；只刷新网页不够。
 >
 > 不要同时显式添加 Better DSH 和独立插件 bundle：行实例仍只有一个，但 DSH 0.2.2-rc.1 会把同一 id 的配置写入拒绝为只读。只保留一个显式入口。
 
-本轮版本：**Better DSH `0.10.0`**，搭配 goal `0.4.1`、subagent `0.5.0`、compact `0.3.1`、ask-user `0.3.1`、ptc `0.2.0`。
+本轮版本：**Better DSH `0.10.1`**，搭配 goal `0.4.1`、subagent `0.5.0`、compact `0.3.1`、ask-user `0.3.1`、ptc `0.2.0`。
 
 ## 架构
 
@@ -120,7 +120,7 @@ Better DSH 的 bundle patch 直接声明这些行；DSH 不会自动应用传递
 | 技能 | 用途 |
 |---|---|
 | `/brainstorming` | 把大型需求设计为获批的主 Spec 与子 Spec |
-| `/exec` | 按依赖分波：worktree → 并行子代理实现 → 审查 → 验证与合并 |
+| `/exec` | 先选自动 / 仅质量档 / 仅快速档；按依赖分波并行实现，子任务按需 CR，验证与合并后保留最终整体 CR |
 | `/dev` | 实现与审查节点的 prompt、报告结构与失败契约 |
 | `/main-agent-driven-development` | 实现一个边界明确的单个任务 |
 | `/tdd` | 测试先行、红绿循环、测试边界与反模式 |
@@ -128,6 +128,8 @@ Better DSH 的 bundle patch 直接声明这些行；DSH 不会自动应用传递
 | `/code-review` | 并行检查仓库标准与原始需求，并排报告 |
 | `/handoff` | 把当前上下文整理为交接文档；仅由用户手动触发 |
 
+`/exec` 的选档约束实现与修复，所有 CR 始终使用质量档；超时未选默认自动，普通任务用快速档，特别难或实际遇阻时可升质量档。等待子代理每次使用至少 30 分钟的超时窗口，提前完成即返回，不因等待超时催促或换人。所有审查与复审节点仅由顶层主 agent 派发；子 agent（包括 reviewer）直接完成分配的工作并向主 agent 返回结果或审查需求，不再派发审查节点。
+
 技能需要在所选预设中挂载 DSH 的技能工具；两套工程预设已挂载。
 </details>
 
@@ -181,7 +183,7 @@ Better DSH 包详情里的「集成设置」按 Core、Subagents、Compaction、
 # 旧入口
 dsh plugin --profile <profile> remove @menghuan1918/dsh-apollo
 # 新入口
-dsh plugin --profile <profile> add dsh-better-dsh@0.10.0
+dsh plugin --profile <profile> add dsh-better-dsh@0.10.1
 # subagent 独立安装的用户
 dsh plugin --profile <profile> remove @menghuan1918/dsh-better-subagent
 dsh plugin --profile <profile> add @oh-my-dsh/dsh-better-subagent@0.5.0
@@ -247,7 +249,7 @@ dsh plugin --profile <profile> add dsh-better-ask-user@0.3.1 dsh-better-ptc@0.2.
 3. `dsh-better-compact@0.3.1`
 4. `dsh-better-goal@0.4.1`
 5. `@oh-my-dsh/dsh-better-subagent@0.5.0`
-6. `dsh-better-dsh@0.10.0`
+6. `dsh-better-dsh@0.10.1`
 
 各仓库使用 npm trusted publishing（OIDC）；创建对应 GitHub Release 会发布 tag 指向的版本。旧包 `@menghuan1918/dsh-apollo` 与 `@menghuan1918/dsh-better-subagent` 已标记 deprecate，仅作为历史入口保留。
 </details>

package/docs/DEVELOPMENT.md

@@ -2,7 +2,7 @@
 
 面向维护者、集成者和需要排查装配问题的用户。用户安装与配置请看 [README](../README.md)；本文保留 DSH 插件的实现细节、旧配置迁移、组合安装边界与验证方法。
 
-当前实现版本：`0.10.0`；npm 包名是 `dsh-better-dsh`。纯 ESM，无构建步骤；宿主浏览器半边是直接加载的闭包工厂。旧 `Apollo` 名称只保留在迁移、历史兼容和旧包 deprecate 说明里。
+当前实现版本：`0.10.1`；npm 包名是 `dsh-better-dsh`。纯 ESM，无构建步骤；宿主浏览器半边是直接加载的闭包工厂。旧 `Apollo` 名称只保留在迁移、历史兼容和旧包 deprecate 说明里。
 
 ## 目录
 
@@ -319,7 +319,7 @@ DSH_PACKAGE_ROOT="/…/node_modules/@deepseek-ai/dsh" npm run prompts
 ### npm 安装
 
 ```sh
-dsh plugin --profile <profile> add dsh-better-dsh@0.10.0
+dsh plugin --profile <profile> add dsh-better-dsh@0.10.1
 ```
 
 包发布后即可用此命令安装，并带入五个精确依赖、应用三份 bundle patch。安装后需要重启对应 profile 的 DSH 进程。本轮版本与精确依赖见上述包清单；发布后需重新验证 registry 干净安装。
@@ -381,7 +381,7 @@ dsh plugin --profile <profile> remove @menghuan1918/dsh-apollo   # 旧包；新
 
 1. 先发布 `dsh-better-ptc@0.2.0`、`dsh-better-ask-user@0.3.1`、`@oh-my-dsh/dsh-better-subagent@0.5.0`、`dsh-better-goal@0.4.1`、`dsh-better-compact@0.3.1`（各自仓库的 Release）；
 2. 在官方 registry（`https://registry.npmjs.org/`）确认五个版本可取得、可安装；
-3. 再把 Better DSH 的精确依赖指向已发布版本，推已验证的发布提交及 tag 并发布 Better DSH Release（本轮为 `v0.10.0`）；
+3. 再把 Better DSH 的精确依赖指向已发布版本，推已验证的发布提交及 tag 并发布 Better DSH Release（本轮为 `v0.10.1`）；
 4. 子包版本可取得前，不要把指向它们的精确依赖推到 Apollo main，否则 `npm install` / GitHub 源码安装会 404。
 
 ## 测试与冒烟

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-better-dsh",
-  "version": "0.10.0",
+  "version": "0.10.1",
   "description": "Better DSH: a DSH plugin bundle that installs workflow skills, engineering presets, and five independent plugins (goal, subagent, compact, ask-user, ptc). Pure ESM, no build step.",
   "license": "Apache-2.0",
   "repository": {

package/skills/brainstorming/SKILL.md

@@ -9,6 +9,8 @@ Turn a large requirement into one approved master Spec and at least two executab
 
 **The end state is a handoff to `/exec`.** Do not implement features, create worktrees, or invoke development skills. Stop once the user approves the written Specs.
 
+Only the top-level main agent serving the user may dispatch review or re-review nodes. Subagents do their assigned work directly and return drafts, findings, or review requests to the main agent; they never dispatch reviewers, even if another skill calls for it.
+
 ## Process
 
 1. **Explore project context** — inspect files, docs, and current project state. Look up facts yourself; do not ask the user.
@@ -16,7 +18,7 @@ Turn a large requirement into one approved master Spec and at least two executab
 3. **Offer 2-3 options** — with tradeoffs and a recommendation, leading with the recommended option.
 4. **Present the design in sections** — scale each section's length to its complexity, and get the user's confirmation on each. When a split is needed, present it (master Spec + sub-Specs, dependency order, shared contracts, integration acceptance).
 5. **Write all Specs** — self-review after writing (placeholders, contradictions, ambiguity, over-detail) and fix inline. See self-review below.
-6. **Dispatch a spec-reviewer** — per [`spec-document-reviewer-prompt.md`](spec-document-reviewer-prompt.md), dispatch a fresh read-only `subagent` (quality tier) to review the master Spec and all sub-Specs; fix blockers and re-dispatch if needed.
+6. **Main agent dispatches a spec-reviewer** — per [`spec-document-reviewer-prompt.md`](spec-document-reviewer-prompt.md), dispatch a fresh read-only `subagent` (quality tier) to review the master Spec and all sub-Specs; fix blockers and re-dispatch if needed.
 7. **Ask the user to review** — revise per feedback until approved.
 8. **Hand off to `/exec`** — tell the user to invoke `/exec` with the master Spec path.
 

package/skills/brainstorming/spec-document-reviewer-prompt.md

@@ -1,6 +1,6 @@
 # Spec Document Reviewer Prompt Template
 
-Use this template when dispatching a spec document reviewer via the `subagent` tool (fresh read-only child, quality tier).
+Only the top-level main agent serving the user uses this template to dispatch a spec document reviewer via the `subagent` tool (fresh read-only child, quality tier). Subagents return review requests to the main agent instead of dispatching reviewers.
 
 **Purpose:** Verify a master Spec or sub-Spec is complete, consistent, and ready for implementation.
 
@@ -8,7 +8,7 @@ Use this template when dispatching a spec document reviewer via the `subagent` t
 
 ```
 subagent(
-  prompt="You are a spec document reviewer. Verify this spec is complete and ready for implementation.
+  prompt="You are a spec document reviewer. Verify this spec is complete and ready for implementation. Perform the review directly; do not dispatch review nodes, even if another skill calls for it. Return findings and any further review needs to the main agent.
 
     **Spec to review:** [SPEC_FILE_PATH]
     **Spec type:** [master | sub]

package/skills/code-review/SKILL.md

@@ -10,7 +10,7 @@ Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
 - **Standards** — does the code conform to this repo's documented coding standards?
 - **Spec** — does the code faithfully implement the originating issue / PRD / spec?
 
-Both axes run as parallel `subagent` delegations so they don't pollute each other's context, then this skill aggregates their findings.
+Only the top-level main agent serving the user may dispatch review or re-review nodes. It dispatches both axes as parallel `subagent` delegations and aggregates their findings. If you are a subagent, perform only your assigned review directly and return findings or further review needs to the main agent; never dispatch reviewers, even if another skill calls for it.
 
 ## Process
 
@@ -57,7 +57,7 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
 
 ### 4. Spawn both sub-agents in parallel
 
-Send both `subagent` calls in a single message — each a fresh quality-tier child with a fully self-contained prompt; children see none of this conversation.
+The top-level main agent sends both `subagent` calls in a single message — each a fresh quality-tier child with a fully self-contained prompt; children see none of this conversation. Include in both prompts: "Perform this review directly. Do not dispatch review nodes; return findings and any further review needs to the main agent."
 
 **Standards sub-agent prompt** — include:
 

package/skills/dev/SKILL.md

@@ -5,11 +5,13 @@ description: "Node contract for the DSH execution backend: prompt requirements,
 
 # Built-in development backend (node contracts)
 
-This skill defines the execution backend's two node types. Wave orchestration (worktrees, merging, cleanup, review-loop scheduling) belongs to `/exec`; this skill must not create, merge, or delete worktrees. Subagents have no independent working directory and cannot see the orchestration session: every node input must come with the prompt (absolute worktree path, Spec path, shared contracts, verification commands), with bash always using `workdir` and file tools always using absolute paths.
+This skill defines the execution backend's two node types. Wave orchestration (worktrees, merging, cleanup, review-loop scheduling) belongs to `/exec`; this skill must not create, merge, or delete worktrees. Subagents have no independent working directory and cannot see the orchestration session: every node input must come with the prompt (absolute worktree path, Spec path, shared contracts, verification commands; implementation/fix nodes also need the execution mode and assigned tier), with bash always using `workdir` and file tools always using absolute paths.
+
+Only the top-level main agent serving the user may dispatch review or re-review nodes. All subagents, including implementation/fix nodes and reviewers, perform their assigned work directly and return findings or review requests to the main agent. Never dispatch reviewers from a subagent, even when another skill calls for it.
 
 ## Implementation node (develop)
 
-One brand-new subagent (quality tier) handles exactly one sub-Spec, following `main-agent-driven-development` in prebuilt-worktree mode (in an `/exec` wave, skip its internal review step — the review loop is run by `/exec`, and nodes do not dispatch reviewers themselves).
+An implementation subagent handles exactly one sub-Spec at the caller-selected tier, following `main-agent-driven-development` in prebuilt-worktree mode. In `/exec`, skip its internal review step: the top-level main agent decides whether and when to request a sub-Spec review. Carry the execution mode into any further implementation/fix delegations. Fixes normally reuse the active node; `/exec` may hand off a node after it has stopped writing, either to escalate fast to quality in Automatic mode or to honor a later explicit mode change. Never run two implementation nodes writing to the same Spec at once.
 
 Report format (JSON code block at the end of the closing message):
 
@@ -25,7 +27,7 @@ Report format (JSON code block at the end of the closing message):
 
 ## Review node (review-only)
 
-A brand-new read-only subagent (quality tier). The prompt supplies: absolute worktree path, diff range, Spec path, implementation summary, and verification already run. Four-state verdict format (JSON code block at the end of the closing message):
+A brand-new read-only subagent (quality tier), dispatched only by the top-level main agent. The reviewer performs the review directly and never delegates another review. The prompt supplies: absolute worktree path, diff range, Spec path, implementation summary, and verification already run. Four-state verdict format (JSON code block at the end of the closing message):
 
 ```js
 {
@@ -38,4 +40,4 @@ Serious correctness errors, Spec gaps, integration risks, security issues, or mi
 
 ## Failure semantics
 
-A subagent failure (error / empty return) = `node-failed`; `blocked`, timeouts, partial replies, or uncommitted results never count as complete. The caller decides whether to redispatch, or to continue via `send_message` only when unblocking the same sub-Spec. Never reuse a node for another sub-Spec.
+A subagent failure (error / empty return) = `node-failed`; `blocked`, node execution timeouts, partial replies, or uncommitted results never count as complete. A `wait_subagent` timeout while the child is still running is not a node failure: wait again with `timeout_ms: 1800000` or longer, without status nudges or replacement merely because time elapsed. The caller decides whether to redispatch, or to continue via `send_message` only when unblocking the same sub-Spec. Never reuse a node for another sub-Spec.

package/skills/exec/SKILL.md

@@ -11,7 +11,21 @@ Run approved sub-Specs in isolated worktrees under `.worktrees/` in the target r
 
 - The master Spec indexes at least two sub-Specs.
 - Confirm a single target repo; the main workspace is on a named branch and its working tree is clean.
-- `.worktrees/` is covered by the target repo's `.gitignore`; if not, ask the user to add it first.
+- Ensure `.worktrees/` is covered by the target repo's `.gitignore`; if missing, add the rule yourself and commit the setup change before creating wave worktrees.
+
+## Execution mode
+
+Before dispatching the first node, use `ask_user_question` to ask for the execution mode, unless the user already specified it for this run. The choice applies to implementation and fixes; **all code reviews use the quality tier**. Offer:
+
+1. **Automatic (Recommended)** — use the fast tier by default; reserve the quality tier for particularly difficult tasks.
+2. **Quality only** — use the quality tier for every implementation and fix.
+3. **Fast only** — use the fast tier for every implementation and fix, without automatic escalation.
+
+Default to Automatic if the question times out or the user skips the choice; use the host's normal question waiting behavior. A later explicit answer applies to future implementation/fix turns; let running turns finish. If the next fix requires a different tier, use the stopped-node handoff below instead of resuming the old route.
+
+Keep the mode in session context and pass it to implementation/fix nodes and any further implementation delegations. In Automatic, ordinary implementation and routine fixes use fast; use quality only when the task demands unusually difficult reasoning or evidence shows the fast node cannot converge. Implementation work alone is not a reason to choose quality.
+
+Resolve fast/quality from the current system prompt's configured routes and pass their `provider` / `model` / `reasoning_effort` to `subagent`; do not hardcode model IDs or use `subagent_fork` to select a tier. If a tier is unconfigured, follow its documented parent-route inheritance and disclose that distinct tiers are not configured. If a selected route is unavailable, report the blocker rather than silently switching tiers.
 
 ## Execution
 
@@ -21,58 +35,65 @@ Run approved sub-Specs in isolated worktrees under `.worktrees/` in the target r
 
 ## Wave execution: subagent + wait_subagent
 
-The main agent orchestrates each wave; node contracts (prompt elements, report format, failure semantics) are in the `dev` skill.
+The main agent orchestrates each wave; node contracts (prompt elements, report format, failure semantics) are in the `dev` skill. Only the top-level main agent serving the user may dispatch any review or re-review node. All subagents, including reviewers, must do their assigned work directly and return findings or review requests to the main agent; they never dispatch reviewers, even if another skill instructs them to.
 
-1. **Dispatch**: in a single message, call `subagent` once per sub-Spec in this wave (quality tier), and record "Spec → subagent id". Implementation-node prompt template:
+1. **Dispatch**: in a single message, call `subagent` once per sub-Spec in this wave using the execution mode, and record "Spec → active subagent id and tier". Implementation-node prompt template:
 
    ```
    You work in the isolated worktree <worktree absolute path>: always run bash with workdir=<worktree>, and use absolute paths for file tools.
-   Follow the main-agent-driven-development skill in prebuilt-worktree mode (skip its internal review step; the review loop is run by /exec).
+   Execution mode: <Automatic / Quality only / Fast only>; assigned tier: <fast / quality>. Carry the mode into any implementation/fix delegations.
+   Follow the main-agent-driven-development skill in prebuilt-worktree mode (skip its internal review step; the top-level main agent decides whether and when to request a sub-Spec review). Do not dispatch review nodes; report any review needs to the main agent.
    Implement only <sub-Spec path> and obey the shared contracts: <contracts>. Run verification: <verification command>.
    After committing, report in the dev skill's implementation-node format. Do not merge or delete the worktree; if blocked, set status=blocked and fill in blocker.
    ```
 
 2. **Collect**: pass every id in this wave to `wait_subagent` in one call; reports arrive with the settlement notice. A Spec with a missing report, `blocked`, or no commit is recorded as `node-failed` and does not affect the other Specs in the wave.
-3. **Review loop** (each completed Spec advances independently; batches may be dispatched in parallel):
-   - Dispatch a brand-new read-only reviewer (quality tier): `Read-only review of the full diff of worktree <worktree> against the baseline (always run bash with workdir=<worktree>). Spec: <path>. Implementation summary: <summary>. Verification already run: <verification>. List issues by severity, each with file and line number; judge with the dev skill's four-state format. Do not edit, commit, or merge.`
-   - `CHANGES_REQUIRED` → send the findings to the original implementation subagent with `send_message` (preserving its context), and require it to fix each real issue, explain false positives, rerun verification, commit, and report again; then `wait_subagent` and dispatch a brand-new reviewer.
+3. **Choose sub-Spec reviews**: the orchestrator decides whether and when each completed Spec needs an independent code review, based on complexity, shared-contract impact, risk, and verification evidence. Ordinary low-risk changes can rely on the mandatory final integrated review. Briefly record the decision and reason in session context. For a selected review:
+   - Dispatch a brand-new read-only reviewer (quality tier): `Read-only review of the full diff of worktree <worktree> against the baseline (always run bash with workdir=<worktree>). Spec: <path>. Implementation summary: <summary>. Verification already run: <verification>. List issues by severity, each with file and line number; judge with the dev skill's four-state format. Perform the review directly; do not dispatch reviewers. Do not edit, commit, or merge.`
+   - `CHANGES_REQUIRED` → send the findings to the active implementation subagent with `send_message` (preserving its context), and require it to fix each real issue, explain false positives, rerun verification, commit, and report again; then wait and dispatch a brand-new quality reviewer. Apply the execution mode and escalation rules to fixes.
    - At most 5 rounds; if still failing, record `review-exhausted`.
-4. Only Specs judged `APPROVED` / `APPROVED_WITH_NOTES` proceed to merge.
+4. **Merge eligibility**: committed, verified, in-scope Specs may proceed without a separate sub-Spec review when the orchestrator chose to omit it. A selected review must reach `APPROVED` / `APPROVED_WITH_NOTES`; never bypass required findings or a `BLOCKED` / exhausted review by changing the review decision.
 
 Key points:
 
-- Every review round uses a brand-new subagent; fixes reuse the original implementation subagent — never start another implementation node for the same Spec.
+- Every review round uses a brand-new quality subagent; fixes normally reuse the active implementation subagent.
 - Report any node question as blocked for the main agent to handle; do not ask the user within a wave.
 - In PTC mode, a whole wave's dispatch and collection can be done in one `run_code`.
 
+## Waiting and escalation
+
+For every implementation, review, fix, and handoff wait in this workflow, call `wait_subagent` with all needed ids and `timeout_ms: 1800000` (30 minutes) or longer. Early completion returns immediately. Do independent work first; when blocked on results, wait patiently. If a wait expires while a node is still running, wait again with the same long window or continue independent work. A wait timeout is not a node failure or evidence that the task is particularly difficult. Do not send status nudges, repeatedly poll agent lists, or interrupt/replace a normally running node because it is taking time.
+
+In Automatic only, an actual blocker, repeated failed attempts, or evidence of exceptional difficulty can justify a fast-to-quality handoff. A later explicit mode change can also require a handoff for the next implementation/fix turn. Reuse the existing node otherwise. Confirm the old node has stopped writing before dispatching its replacement; if interruption is needed, request it and wait for the node to stop. Inspect the actual worktree state and hand off the Spec, contracts, existing commits, any uncommitted changes, verification results, and unresolved issues to a new implementation node in the same worktree at the required tier (quality for automatic escalation). Update the active-node mapping; only one implementation node may write to a Spec at a time. After escalation, keep that quality node for subsequent fixes unless the user explicitly changes the mode.
+
 ## Merge
 
-For each completed node: confirm it is committed and verification passed → check the changed files for out-of-scope edits → merge into the main workspace → verify after merging → delete the worktree and sub-branch.
+For each eligible node: confirm it is committed and verification passed → check the changed files for out-of-scope edits → merge into the main workspace → verify after merging → delete the worktree and sub-branch.
 
-Small, well-defined conflicts are resolved directly by the main agent. For complex conflicts, use a new fix worktree under `.worktrees/` and a development node. Never merge failed or blocked nodes.
+Resolve conflicts through an implementation/fix node under the execution mode; use a new fix worktree under `.worktrees/` for complex conflicts. Never merge failed or blocked nodes.
 
 ## Final review
 
-Once all sub-Specs are merged, run the full integration verification, then dispatch a brand-new read-only reviewer subagent (quality tier) to review the whole integrated result:
+Once all sub-Specs are merged, run the full integration verification, then always dispatch a brand-new read-only reviewer subagent (quality tier) to review the whole integrated result, even when sub-Spec reviews were omitted:
 
 ```
 subagent(
   prompt="Read-only review of the <base>..HEAD diff in <workspace> (always run bash with workdir=<workspace>).
          Master Spec: <path> | all sub-Specs | shared contracts | changed files | implementation summary | verification results.
          List issues by severity, each with file and line number.
-         Return APPROVED / APPROVED_WITH_NOTES / CHANGES_REQUIRED / BLOCKED. Do not edit, commit, or merge."
+         Return APPROVED / APPROVED_WITH_NOTES / CHANGES_REQUIRED / BLOCKED. Perform the review directly; do not dispatch reviewers. Do not edit, commit, or merge."
 )
 ```
 
-Wait with `wait_subagent`. On `CHANGES_REQUIRED` there is no need to ask the user — the main agent classifies and fixes all real bugs directly, and briefly explains false positives and existing behavior in context; after fixing, verify again and dispatch a brand-new reviewer for re-review. If serious or blocking issues remain after a soft cap of 3 rounds, stop the fix loop and truthfully report the remaining issues to the user.
+Wait using the long window above. On `CHANGES_REQUIRED` there is no need to ask the user — the main agent classifies findings and briefly explains false positives and existing behavior in context. Delegate real fixes to an implementation/fix node in an isolated worktree under the execution mode, integrate the committed fixes, verify again, and dispatch a brand-new quality reviewer for re-review. If serious or blocking issues remain after a soft cap of 3 rounds, stop the fix loop and truthfully report the remaining issues to the user. A blocked review is not approval.
 
 ## Wrap-up
 
-Run the full verification, check the Specs, report branches, commits, verification results, and open issues, and ask the user what to do next. Do not create a PR or delete branches without the user's choice.
+Run the full verification, check the Specs, report the execution mode, actual tier use and escalations, sub-Spec review decisions, branches, commits, verification results, and open issues, and ask the user what to do next. Do not create a PR or delete branches without the user's choice.
 
 ## KISS
 
-- One sub-Spec, one worktree, one development node.
-- The main agent holds repo topology (branches/worktrees/merges/cleanup) and in-wave scheduling; implementation and review go to subagents.
+- One sub-Spec, one worktree, at most one active implementation node.
+- The main agent holds repo topology (branches/worktrees/merges/cleanup) and scheduling; implementation, fixes, and selected reviews go to subagents.
 - State lives only in session context; add no integration branch, scheduler scripts, or state files.
 - Completion notices arrive automatically; wait only when you need results to proceed. Never poll with `sleep`.

package/skills/main-agent-driven-development/SKILL.md

@@ -14,7 +14,7 @@ Choose exactly one:
 - **Prebuilt mode** — when the caller already provided an isolated worktree and owns its lifecycle, use it directly; do not create, merge, or delete worktrees.
 - **Standalone mode** — otherwise, identify the target repo, require the baseline to be on a named branch, record the starting SHA, and create a worktree under the repo's `.worktrees/`.
 
-All operations must happen inside the chosen worktree. After isolation, do not edit the original checkout.
+All operations must happen inside the chosen worktree. After isolation, do not edit the original checkout. When called by `/exec`, follow the assigned execution mode and tier, including in any further implementation/fix delegations; report blockers to the orchestrator rather than changing your own tier.
 
 ## Flow
 
@@ -26,14 +26,16 @@ All operations must happen inside the chosen worktree. After isolation, do not e
 6. After each logical step, run focused verification, self-review the diff, and commit when it is complete. Verification standard: run the command this round and confirm the output; never replace it with "it should pass".
 7. After implementation, run all required verification.
 8. When verification fails or review finds a bug, follow the `diagnosing-bugs` skill (bundled in this package): build a feedback loop to find the root cause first, then fix.
-9. Run the internal review loop (see below). Exception: when acting as an implementation node in an `/exec` wave, **skip this step** — the review loop is run by `/exec`, and the node only implements, verifies, commits, and reports.
+9. Only the top-level main agent serving the user runs the internal review loop (see below). When acting as any implementation/fix subagent, **skip this step** — return the implementation and any review needs to the main agent, which owns all review dispatch.
 10. Commit all approved fixes and report to the caller.
 
 Keep it KISS. Prefer reusing existing patterns, small and complete changes, and only the targeted refactoring the Spec requires.
 
 ## Internal review loop
 
-After full verification, dispatch exactly one brand-new read-only reviewer subagent (quality tier):
+Only the top-level main agent may dispatch review or re-review nodes. Subagents never dispatch reviewers, even if invoked outside `/exec` or another skill calls for review.
+
+After full verification, the main agent dispatches exactly one brand-new read-only reviewer subagent (quality tier):
 
 ```
 subagent(
@@ -41,13 +43,14 @@ subagent(
          Spec: <path>
          Implementation summary: <brief>
          Changed files: <list>
-         Verification already run: <commands and results>"
+         Verification already run: <commands and results>
+         Perform the review directly; do not dispatch review nodes. Return any further review needs to the main agent."
 )
 ```
 
 Require file and line numbers, and one status: `APPROVED` / `APPROVED_WITH_NOTES` / `CHANGES_REQUIRED` / `BLOCKED`.
 
-Wait for the review with `wait_subagent`. Once results arrive, fix all necessary correctness errors, Spec gaps, security issues, integration risks, and verification gaps directly — no need to ask the user. After verifying and committing the fixes, dispatch a brand-new reviewer with `subagent` again. Repeat until `APPROVED` or only non-blocking suggestions remain.
+Wait for the review with `wait_subagent` and `timeout_ms: 1800000` (30 minutes) or longer; early completion returns immediately. If the reviewer is still running after a wait timeout, continue long waits without status nudges or replacing it merely because time elapsed. Once results arrive, fix all necessary correctness errors, Spec gaps, security issues, integration risks, and verification gaps directly — no need to ask the user. After verifying and committing the fixes, dispatch a brand-new reviewer with `subagent` again. Repeat until `APPROVED` or only non-blocking suggestions remain.
 
 Never self-approve, and never reuse an old reviewer.
 
@@ -58,7 +61,7 @@ Before reporting completion, all of the following must hold:
 - All assigned acceptance criteria are implemented
 - Required verification ran and passed this round (backed by command output)
 - No uncommitted implementation changes
-- Internal review passed with no required fixes
+- Internal review passed with no required fixes, except for implementation/fix subagents whose review scheduling belongs to the top-level main agent
 - The final commit SHA is available
 
 Report blockers truthfully. Do not merge on your own; the caller owns integration and cleanup.