dsh-tower 2.0.2 → 2.0.4

package/docs/reference/tools.md

@@ -1,10 +1,10 @@
 # Tools reference
 
 All tools take `repoRoot` (an absolute path inside the target Git repository) and return JSON.
-The build exposes up to 28 tools: 19 core repository tools below (including `tower_interrupt`),
-`tower_mode`, `tower_control` when `mode.allowAgentControl` is enabled (the bundled patch enables it),
+The build exposes up to 29 tools: 19 core repository tools below (including `tower_interrupt`),
+`tower_mode`, `tower_control` (registered by default; set `mode.allowAgentControl:false` to disable),
 `tower_reload` while `dev.hotReload` is on, and the 2.1 verification/ops tools `tower_doctor`,
-`tower_test`, `tower_batch`, `tower_resource`, `tower_import_legacy`, `tower_legacy_map`.
+`tower_recover`, `tower_test`, `tower_batch`, `tower_resource`, `tower_import_legacy`, `tower_legacy_map`.
 
 `tower_mission` uses `id` (alias `missionId`); every other mission-scoped tool uses `missionId`
 (alias `id`). Other input aliases: `task_done`/`taskDone`, `task_drop`/`taskDrop`,
@@ -31,7 +31,7 @@ findings but not mutate them. Violations throw `[tower:not-authorized]` or
 | Tool | Parameters | Purpose / notes |
 |---|---|---|
 | `tower_init` | `base?`, `autoGitInit?`, `snapshotDirty?`, `reanchor?` | Create `<git-common-dir>/dsh-tower/state.json`. `autoGitInit` runs `git init` + empty initial commit; `snapshotDirty` records a dangling snapshot commit of uncommitted tracked changes used as the mission baseline; `reanchor` changes base only when no non-terminal mission exists. Returns `dirty`, `snapshotCommit`, `reanchored`. |
-| `tower_plan` | `missions[]` (`title`, `scope[]`, `tasks[]?`, `deps[]?`, `kind?`, `context?`, `references[]?` ≤20, `reviewPolicy?`, `reviewExemptionReason?`) | Create missions `M1..`; overlapping build scopes auto-add a dependency; rejects unknown deps and cycles. `reviewPolicy:"none"` requires a reason and `gates.allowReviewExemption`. |
+| `tower_plan` | `missions[]` (`title`, `scope[]`, `tasks[]?`, `deps[]?`, `kind?`, `context?`, `references[]?` ≤20, `reviewPolicy?`, `reviewExemptionReason?`) | Create missions `M1..`; overlapping build scopes auto-add a dependency; rejects unknown deps and cycles. `reviewPolicy:"none"` requires a non-empty reason; when the review gate is on, preflight also requires `gates.allowReviewExemption`. |
 | `tower_mission` | `id` (alias `missionId`), `status?`, `task_done?`, `task_drop?`+`task_drop_reason?`, `blocker?`, `clear_blockers?`, `note?`, `scope?`, `pause_cause?`, `authorization?` | Update one mission. Worker-safe fields are task/blocker/note; `merged` cannot be set here. Paused missions record `pause_cause` (user/failure/resource/dependency); resuming a user-paused mission honors `mode.requireResumeAuthorization`. |
 | `tower_status` | `missionId?`, `offset?`, `limit?`, `includeGate?`, `format?` | Dashboard by default. `missionId` returns full detail (tasks/notes/reviews/findings/completionReport). `offset`/`limit` page missions (default 20, max 100), `includeGate` adds gate digests, `format:"markdown"` returns the board. |
 | `tower_spawn` | `missionId` (alias `id`), `role` (`worker`/`reviewer`), `name?`, `instructions?`, `worktreeRoot?`, `wait?`, `waitMs?`, `takeover?`, `includeDirtyBase?` | Provision/reuse the worktree and start a subagent. Worker uses `tower-worker`; reviewer requires a `completed` mission and uses the read-only `tower-reviewer`. `takeover:true` replaces a live worker entry that is no longer running (increments ownerGeneration). Only one live worker per mission; `spawn.maxLiveWorkers` caps the repository. |
@@ -40,7 +40,7 @@ findings but not mutate them. Violations throw `[tower:not-authorized]` or
 | `tower_diff` | `missionId` (alias `id`), `maxBytes?` | Read-only merge-base diff: files, commits, capped patch. Safe for reviewers. |
 | `tower_send` | `to`, `subject`, `body`, `scope?`, `interrupt?`, `consentRef?` | Durable message to a roster name, `tower`, or `all`; delivers live to a running agent. `interrupt:true` interrupts the running turn first (Kimi-style), then delivers; `consentRef` is recorded for audit. Rate-limited by `send.maxPerMinute`. |
 | `tower_inbox` | `limit?`, `include_read?` | Read/ack messages addressed to the caller; unread messages block `tower_complete`. |
-| `tower_complete` | `missionId` (alias `id`), `report`, `checks?` | Worker reports completion (mission becomes `completed`, awaiting review). Requires current owner, no open tasks/blockers, ≥1 commit, no unread inbox. `checks` records `{name, command?, exitCode?, evidence?}` evidence; `gates.requireChecks` can demand it. When configured, test discovery runs automatically and adds a `tests` check; failure throws `[tower:tests-failed]`. |
+| `tower_complete` | `missionId` (alias `id`), `report`, `checks?` | Worker reports completion (mission becomes `completed`, ready for preflight and optional review). Requires current owner, no open tasks/blockers, ≥1 commit, no unread inbox. `checks` records `{name, command?, exitCode?, evidence?}` evidence; `gates.requireChecks` can demand it. When configured, test discovery runs automatically and adds a `tests` check; failure throws `[tower:tests-failed]`. |
 | `tower_interrupt` | `to?` (roster name), `agentId?`, `reason?` | Interrupt one running roster agent via `subagents.interrupt`, record `state:"interrupted"`. Idempotent (not running → `interrupted:false`). |
 | `tower_finding` | `type`, `title`, `summary`, `details`, `suggested_fix`, `severity?`, `missionId?`, `location?` | Record an out-of-scope issue; reviewers use this instead of editing. Finds start as `open`. |
 | `tower_findings` | `id?`, `status?`, `note?`, filters (`type?`, `severity?`, `missionId?`, `open?`, `limit?`) | Lifecycle tool: list/read/transition. Statuses `open → triaged → fixed`/`wontfix`, reopen allowed. Only the tower or a worker may mutate; a reviewer can list/read. |
@@ -50,9 +50,10 @@ findings but not mutate them. Violations throw `[tower:not-authorized]` or
 | `tower_rebase` | `missionId` (alias `id`) | Rebase the branch onto the base in its worktree. Refuses while the worker runs or the worktree is dirty. Already-contained branches return `alreadyMerged` untouched. |
 | `tower_teardown` | `force?`, `exclude?`, `dry_run?` (alias `dryRun`) | Remove eligible merged/abandoned worktrees and branches; running agents are always kept. |
 | `tower_mode` | — | Report mode, last change, paused goal, denied tools, store path, plugin version, HMR availability, workspace-lock holder. |
-| `tower_control` | `action` (`enter`/`exit`), `reason` | Model-initiated mode change; only when `mode.allowAgentControl` is true; reason is mandatory. |
+| `tower_control` | `action` (`enter`/`exit`), `reason` | Model-initiated mode change; registered by default; disable with `mode.allowAgentControl:false`; reason is mandatory. |
 | `tower_reload` | `repoRoot?` | Dev-only: ask DSH HMR to reconcile the profile and reload the Host plugin from disk. Registered while `dev.hotReload` is on; scheduled after the result (default 50 ms); fails with `reload-unavailable` without HMR. When `repoRoot` is supplied the caller must be the tower. |
 | `tower_doctor` | — (takes `repoRoot`) | Read-only health contract: git, state schema, config, presets/subagents/HMR, workspace lock, roster, worktree realpath/ownership, test config, leases. Returns `{ok, checks[{id,status,detail}], environmentContract}`. Never writes. |
+| `tower_recover` | `action` (`status`/`clear-stale-lock`), `confirm?` | Recovery diagnostics plus an explicit stale state-lock repair. `clear-stale-lock` requires `confirm:"CLEAR_STALE_LOCK"` and only moves a lock whose PID is provably dead to a backup; it never resets state/worktrees. |
 | `tower_test` | `missionId` (alias `id`) | Run the worktree's `package.json` `tower.testDiscovery` and record a receipt; `ok:false` on failure. Use `tower_complete` for automatic admission checks. |
 | `tower_batch` | `action` (`create`/`status`/`close`/`abandon`), `missionIds?`, `exclusions?`, `requiredChecks?`, `receiptPaths?`, `batchId?`, `checks?`, `treeTip?`, `receiptHashes?`, `reason?` | Finite evidence batch. Create freezes members/checks/receipts; close verifies every required check and receipt hash; merged members are eligible; abandon retires a stale open batch without deleting missions. Membership is immutable. |
 | `tower_resource` | `action` (`acquire`/`release`/`status`), `name?`, `holder?`, `token?`, `ttlMs?`, `force?` | Advisory per-repository lease in `<common>/dsh-tower/leases.json`. No OS CPU/memory hard cap; expired leases require explicit `force` and the correct token. |

package/docs/zh/README.md

@@ -11,7 +11,7 @@
   workspace 锁、roster、worktree 归属、测试策略与租约，不写任何状态。
 - **测试发现与完成证据**：[测试、发现与证据](reference/testing.md)。仓库可在
   `package.json.tower.testDiscovery` 声明发现命令；回执可自动附加到 `tower_complete`，
-  `gates.requireTests` 可要求针对被审查 tip 的通过回执。
+  `gates.requireTests` 可要求针对当前 mission 分支 tip 的通过回执（与审查门禁独立）。
 - **证据批次、咨询式租约、旧版导入**：[批次、租约与旧版导入](reference/operations.md)
   （`tower_batch`、`tower_resource`、`tower_import_legacy`、`tower_legacy_map`）。
 - **workspace 锁与计划模式**：`mode.workspaceLock` 限制每个仓库同时只有一个 Tower 会话，

package/docs/zh/faq.md

@@ -3,22 +3,25 @@
 [English](../faq.md) | **简体中文**
 
 **什么时候该用 Tower，而不是 Agent Teams、Ralph、Workflow 或普通子代理？**
-当输出是单个 Git 仓库中需要审查并合入的变更时，用 Tower。只读探索或快速独立子任务用普通子代理；
+当输出是单个 Git 仓库中需要集成的变更时，用 Tower（需要独立结论时再开启审查）。只读探索或快速独立子任务用普通子代理；
 横切的人类协作/设计决策用 Agent Teams；对同一目标反复新鲜尝试用 Ralph；程序化高扇出分析用 Workflow。
 完整选择路径、场景与对比表见[什么时候用 Tower](guide/scenarios-and-philosophy.md)。
 
 **可以同时把 Tower 和 Team/Workflow/Ralph 组合使用吗？**
 同一会话中不能并发：Tower 模式会拒绝这些工具并清除 plan mode。请按阶段组合——先用 Workflow/Team
-分析与决策，再启动 Tower 执行并审查仓库变更。详见[完整指南](guide/scenarios-and-philosophy.md#4-tower-与其他-dsh-工作流模式的区别)。
+分析与决策，再启动 Tower 执行（可选审查）仓库变更。详见[完整指南](guide/scenarios-and-philosophy.md#4-tower-与其他-dsh-工作流模式的区别)。
 
 **为什么 worker 刚完成，`tower_preflight` 就因 `no-review` 失败？**
-这是预期行为：`completed` 的 mission 正在等待审查。spawn 一个 reviewer；干净审查后门禁就会变绿。
+只有在 `review.requireReview:true` 开启时才会如此：已完成的 mission 在等待独立审查。spawn 一个
+reviewer；干净审查后门禁就会变绿。默认 `review.requireReview:false` 时审查可选，不会产生
+`no-review` blocker。
 
 **需要轮询 worker 吗？**
 不需要。worker 的最终报告会送回本会话；`tower_roster` 显示实时活动。轮询只会浪费回合。
 
 **`/tower` 显示模式已开启，但没有 `tower_control`。**
-`mode.allowAgentControl` 关闭了。在 profile patch 中把它设为 `true` 并重启 DSH。
+`mode.allowAgentControl` 被关闭了。它默认为 `true`；如果被显式设为 `false`，在 profile patch 中改回
+`true` 并重启 DSH。
 
 **合并钩子要跑几分钟，`tower_merge` 失败了。**
 用更大的 `timeoutMs` 重试：`tower_merge({ missionId, timeoutMs: 1800000 })`。默认超时是 15 分钟，
@@ -31,6 +34,11 @@
 **`tower_rebase` 返回 `alreadyMerged` 且什么都没改。**
 正确：分支已经包含在基线中。此时调用 `tower_merge` 记录已落地的合并，而不是 rebase。
 
+**可以要求强制独立审查吗？**
+可以。在 profile 或仓库配置中设 `review.requireReview:true` 可开启全局审查门禁（默认 `false`，
+即审查可选）。开启后可用 mission 级 `reviewPolicy:"none"` + 理由 + `gates.allowReviewExemption:true`
+做更窄的豁免。`tower_review` 始终可用并记录结论。
+
 **reviewer 能修改文件吗？**
 不能。reviewer 使用只读的 `tower-reviewer` preset（没有 write/edit/pwsh）；reviewer spawn 之后分支
 被改动，审查会被拒绝。mission 之外的问题用 `tower_finding` 记录，不要直接改文件。

package/docs/zh/guide/install-upgrade-migration.md

@@ -31,12 +31,19 @@ Host 插件在 DSH 启动时加载：**安装或更新后需要重启 DSH**。
 
 ## 迁移说明
 
-- **1.x → 2.0（未发布）**：不需要迁移状态（`schemaVersion` 保持 1；新字段都是可选的）。需要留意的
+- **2.0.3 → 2.0.4**：不需要迁移 state/config。本版本是安全加固与完整性修复（授权、merge SHA 绑定、
+  dirty worktree 完成拒绝、stale lock 恢复、限制 test/git 进程环境、`tower_recover`、UI 0.2.2）。
+  升级后请按威胁模型重新检查 `review.requireReview`、`tests.admission` 与 worker 工具权限。
+- **2.0.1 → 2.0.3**：不需要迁移状态。2.0.3 起独立审查**默认可选**（`review.requireReview:false`）；
+  若要保留旧的审查门禁行为，请显式设为 `true`。2.0.1 为 `tower_batch` 增加 `abandon`、允许 merged
+  成员 close、让 doctor 跳过已 teardown 的 worktree，并修复终态 mission spawn/preflight 边界。
+  可选 `ui-bundle` 0.2.1 增加常驻 Tower 模式 chip 与模式感知的 disabled 工具行。
+- **1.x → 2.0（已发布）**：不需要迁移状态（`schemaVersion` 保持 1；新字段都是可选的）。需要留意的
   行为变化：Tower 模式激活期间，`mode.denyTools` 现在还会拒绝 `workflow`、`ralph`、`subagent`、
   `subagent_fork`、`wait_agent` 与 `team_task_list`（可用显式列表覆盖）；`spawn.maxLiveWorkers`
-  默认为 4；`mode.workspaceLock` 默认关闭。worker 不能再直接完成/放弃/扩大 mission 的 scope——
-  请使用 `tower_complete`。新工具：`tower_interrupt`，以及 HMR 可用时的 `tower_reload`。升级后重启
-  一次 DSH；见[热重载](hot-reload.md)。
+  默认为 4；`mode.workspaceLock` 代码默认关闭、随包 patch 开启。worker 不能再直接完成/放弃/扩大
+  mission 的 scope——请使用 `tower_complete`。新工具：`tower_interrupt`，以及 HMR 可用时的
+  `tower_reload`。升级后重启一次 DSH；见[热重载](hot-reload.md)。
 - **1.3 → 1.4**：不需要迁移状态。新增：仓库级配置（`<git-common-dir>/dsh-tower/config.json`）、
   稳定的 `[tower:<code>]` 工具错误、`tower_findings`，以及 `id`/`missionId` 与 snake/camel 输入
   别名。既有调用保持可用；重启 DSH 以加载新工具面（`tower_findings` 与更新的 output schema）。

package/docs/zh/guide/quickstart.md

@@ -32,14 +32,17 @@ tower_spawn repoRoot=D:\work\repo missionId=M1 role=worker
 调用立即返回子代理 id。worker 在 mission worktree 内工作、提交、把任务标记完成，并调用
 `tower_complete`；它的最终报告会送回本会话。用 `tower_roster` 观察活动，不要循环轮询。
 
-## 4. 审查
+## 4. 可选：审查
+
+独立审查默认可选。若要采用严格流程，先在 profile 或仓库配置中开启
+`review.requireReview:true`，然后：
 
 ```
 tower_spawn repoRoot=D:\work\repo missionId=M1 role=reviewer
 ```
 
-reviewer 使用只读的 `tower-reviewer` preset。它查看 `tower_diff` 并提交 `tower_review`。只有
-`clean` + `merge` 的结论才允许合并。
+reviewer 使用只读的 `tower-reviewer` preset，查看 `tower_diff` 并提交 `tower_review`。开启
+`review.requireReview:true` 后，只有 `clean` + `merge` 的结论才允许合并。
 
 ## 5. 门禁、合并与清理
 
@@ -49,8 +52,9 @@ tower_merge     repoRoot=D:\work\repo missionId=M1
 tower_teardown  repoRoot=D:\work\repo
 ```
 
-审查前运行 `tower_preflight` 预期报告 `no-review`；干净审查之后应为 `ok:true`。存在 blocker 时
-`tower_merge` 拒绝合并。`tower_teardown` 移除已 merged/abandoned 的 worktree 与分支。
+开启审查门禁时，审查前运行 `tower_preflight` 会报告 `no-review`；干净审查之后应为 `ok:true`。
+默认 `review.requireReview:false` 时没有审查 blocker。存在其他 blocker 时 `tower_merge` 拒绝合并。
+`tower_teardown` 移除已 merged/abandoned 的 worktree 与分支。
 
 ```
 /tower off
@@ -59,8 +63,9 @@ tower_teardown  repoRoot=D:\work\repo
 ## 如果失败
 
 阅读 blocker code 并查阅 [blocker 参考](../reference/blockers.md)。最常见的情况：`stale-base`
-（执行 `tower_rebase`）、`no-review`（spawn reviewer）、`merge-hook-failed`（重试，或调大
-`timeoutMs`）、`tip-moved`（审查后分支已变化，需要重新审查）。
+（执行 `tower_rebase`）、`no-review`（仅在 `review.requireReview:true` 时；spawn reviewer）、
+`merge-hook-failed`（重试，或调大 `timeoutMs`）、`tip-moved`（仅在审查门禁开启时；审查后分支
+已变化，需要重新审查）。
 
 工具抛出的错误带 `[tower:<code>]` 前缀；见[错误码](../reference/errors.md)（例如
 `preset-missing` 表示安装 bundle 后需要重启 DSH，`not-initialized` 表示先运行 `tower_init`）。
@@ -72,7 +77,7 @@ tower_teardown  repoRoot=D:\work\repo
 
 ```json
 {
-  "review": { "maxRoundsPerReviewer": 3 },
+  "review": { "requireReview": true, "maxRoundsPerReviewer": 3 },
   "merge": { "timeoutMs": 1800000 },
   "worktrees": { "root": "D:/tower-worktrees" }
 }

package/docs/zh/guide/scenarios-and-philosophy.md

@@ -2,9 +2,9 @@
 
 [English](../guide/scenarios-and-philosophy.md)
 
-Tower 不是所有多代理模式的替代品。它是**面向 Git 仓库变更的交付协议**：少量边界清晰的 mission、隔离的写入者、独立审查、证据与合并门禁。本页解释这些设计取舍、适用场景，以及什么时候 Agent Teams、Ralph 循环、Workflow 编排或普通并行子代理更合适。
+Tower 不是所有多代理模式的替代品。它是**面向 Git 仓库变更的交付协议**：少量边界清晰的 mission、隔离的写入者、可选独立审查、证据与合并门禁。本页解释这些设计取舍、适用场景，以及什么时候 Agent Teams、Ralph 循环、Workflow 编排或普通并行子代理更合适。
 
-如果只记一句话：**输出是需要审查并合入仓库的变更时用 Tower；输出是探索、重复尝试或程序化扇出时用其他模式。**
+如果只记一句话：**输出是需要经过受控合并落地的仓库变更时用 Tower；输出是探索、重复尝试或程序化扇出时用其他模式。**如果还需要独立审查，开启 `review.requireReview`。
 
 ## 1. 设计哲学
 
@@ -12,7 +12,7 @@ Tower 做了一组刻意的取舍，这解释了它的优势和成本。
 
 ### 1.1 仓库是责任单位
 
-mission 不是聊天线程或任务卡，而是绑定到分支与 worktree 的契约：有声明式写范围、依赖、完成证据和审查记录。"改了什么、谁改的、凭什么说改对了"有持久答案，位于 `<git-common-dir>/dsh-tower/state.json` 与 Git 历史，而不只在对话里。
+mission 不是聊天线程或任务卡，而是绑定到分支与 worktree 的契约：有声明式写范围、依赖、完成证据和可选审查记录。"改了什么、谁改的、凭什么说改对了"有持久答案，位于 `<git-common-dir>/dsh-tower/state.json` 与 Git 历史，而不只在对话里。
 
 ### 1.2 一个 mission 一个写入者
 
@@ -24,19 +24,25 @@ mission 不是聊天线程或任务卡，而是绑定到分支与 worktree 的
 
 ### 1.4 集成是独立的特权步骤
 
-worker 永远不合并。reviewer 审查特定分支 tip；控制塔运行 preflight；只有之后 `tower_merge` 才执行 `--no-ff` 合并。门禁重新检查 scope、base 新鲜度、任务、审查绑定、worktree 归属、worker 状态、测试与证据。职责分离是重点：写代码的 agent 不批准，批准的 agent 也不合并。
+worker 永远不合并。控制塔运行 preflight；只有之后 `tower_merge` 才执行 `--no-ff` 合并。门禁重新检查 scope、base 新鲜度、任务、worktree 归属、worker 状态、测试与证据。开启审查时，reviewer 还会审查特定分支 tip，门禁检查审查绑定；职责分离（写代码者不批准、批准者不合并）在审查开启时生效。
+
+独立审查默认可选：设 `review.requireReview:true` 才会强制（此时已完成 mission 必须带有绑定 tip 的 clean/merge 审查）。对敏感仓库建议开启；全局开启时仍可用 `reviewPolicy:"none"` + 理由 + `gates.allowReviewExemption:true` 做单个 mission 豁免。无论开关如何，都可以提交并记录 review。
 
 ### 1.5 证据优先于断言
 
-"完成了"是声明；commit、diff、通过的测试回执、独立审查才是证据。Tower 全部记录：`tower_doctor` 检查环境，`tower_test` 记录发现，`tower_complete` 记录 checks，`tower_review` 把结论绑定到提交，`tower_batch` 只有在有限 mission 集合的必需证据齐全时才允许收口。
+"完成了"是声明；commit、diff、通过的测试回执、审查结论都是证据。Tower 全部记录：`tower_doctor` 检查环境，`tower_test` 记录发现，`tower_complete` 记录 checks，`tower_review` 把结论绑定到提交（开启审查时），`tower_batch` 只有在有限 mission 集合的必需证据齐全时才允许收口。
 
 ### 1.6 失败关闭，显式恢复
 
-Tower 宁可显示 blocker，也不静默修复。stale worker 被标记而不是假设已死；脏 base 阻止合并；审查后 tip 变化阻止合并；merge 期间崩溃会留下持久 intent，由下一次 `tower_merge` 对账。代价是偶尔需要人工清理，收益是状态不会谎报已集成的内容。
+Tower 宁可显示 blocker，也不静默修复。stale worker 被标记而不是假设已死；脏 base 阻止合并；开启审查时，审查后 tip 变化阻止合并；merge 期间崩溃会留下持久 intent，由下一次 `tower_merge` 对账。代价是偶尔需要人工清理，收益是状态不会谎报已集成的内容。
 
-### 1.7 人类拥有模式
+### 1.7 模式切换显式且可归因
 
-Tower 模式改变会话姿态：收窄工具面并注入 mission 协议。随包 patch 允许模型给出理由后切换，但该模式存在的前提是人类需要交付纪律。进入会暂停活跃 goal 并清除 plan mode；退出不会静默恢复。Tower 激活期间刻意拒绝 `goal`、`todo`、Team 任务板、Workflow、Ralph 与普通 subagent 工具，避免两套编排协议争夺同一会话。
+Tower 模式改变会话姿态：收窄工具面并注入 mission 协议。人类始终可以用 `/tower` 切换；默认情况下
+模型也可以带具体理由用 `tower_control` 进出，每次变更记录操作者与理由。设计重点不是某一方拥有
+开关，而是切换必须显式、可见；若部署需要仅人类控制，设 `mode.allowAgentControl:false`。进入会
+暂停活跃 goal 并清除 plan mode；退出不会静默恢复。Tower 激活期间刻意拒绝 `goal`、`todo`、
+Team 任务板、Workflow、Ralph 与普通 subagent 工具，避免两套编排协议争夺同一会话。
 
 ### 1.8 本地优先，无隐藏服务
 
@@ -44,11 +50,23 @@ Tower 是 Host 插件，只使用本地 Git、本地文件和 DSH subagent 服
 
 ## 2. Tower 适合的场景
 
+先看速查表；下文逐项解释。
+
+| 场景 | 具体例子 | 为什么用 Tower |
+|---|---|---|
+| 可拆成独立切片的特性 | 加 OAuth：`token 模型` → `callback 路由` → `UI 按钮` + 迁移，四个 scope 基本独立的 mission | 写入隔离、scope 预留、最终统一合并（可选审查） |
+| 有顺序的迁移/重构 | monorepo 重命名 `oldApi`：codemod → import 清理 → 快照 → 文档，每步依赖前一步合并 | `deps`、分支新鲜度、合并串行 |
+| 先调查再修改 | survey mission 映射已弃用 crypto API 的所有调用者；两个 build mission 迁移与补测试 | survey 不能改文件；findings 喂给 build |
+| 敏感或发布绑定变更 | 支付服务改动或公共库发布，需要测试证据与可审计合并（需要独立结论时开启审查） | checks/testRuns、可选审查绑定、人类可审计 |
+| 长期工作 | 多日依赖升级，期间重启、换会话、上下文重置 | mission/roster/review/worktree 持久 |
+| 硬集成边界 | monorepo 四个服务各有 owner，最后统一发布合并 | 多 mission 并行，单一合并门禁 |
+| 可检查的完成定义 | 任务清单 + 必需测试 + 可选独立审查结论 | 另一个 agent 能检查证据 |
+
 ### 2.1 能自然拆成独立切片的特性
 
-例：OAuth 登录拆成"token 模型"、"callback 路由"、"UI 按钮"、"迁移 + 测试"。切片大多改不同文件，可以并行，最后需要集成审查。Tower 的 scope 预留与重叠自动依赖可以避免碰撞。
+例：OAuth 登录拆成"token 模型"、"callback 路由"、"UI 按钮"、"迁移 + 测试"。切片大多改不同文件，可以并行，最后统一合并（需要时再加审查）。Tower 的 scope 预留与重叠自动依赖可以避免碰撞。
 
-**为什么用 Tower：** 并行写入被隔离；每个切片有 owner 与审查；合并在最后统一门禁，而不是逐段即兴处理。
+**为什么用 Tower：** 并行写入被隔离；每个切片有 owner，需要时再审查；合并在最后统一门禁，而不是逐段即兴处理。
 
 ### 2.2 有顺序约束的迁移或重构
 
@@ -64,9 +82,9 @@ Tower 是 Host 插件，只使用本地 Git、本地文件和 DSH subagent 服
 
 ### 2.4 敏感仓库或与发布绑定的变更
 
-例：支付服务、有外部用户的库、release 分支。你需要独立 reviewer、特定被审查 commit、测试证据和人类可审计记录。
+例：支付服务、有外部用户的库、release 分支。你需要测试证据和人类可审计记录；开启审查时，还会得到独立 reviewer、特定被审查 commit 与绑定 tip 的结论。
 
-**为什么用 Tower：** 审查绑定、证据门禁、`MISSIONS.md`、活动日志和可选测试发现提供了可辩护的记录；reviewer 是独立的只读 agent，不是作者。
+**为什么用 Tower：** 证据门禁、`MISSIONS.md`、活动日志和可选测试发现提供了可辩护的记录；开启审查时，reviewer 是独立的只读 agent，不是作者，结论绑定 tip。
 
 ### 2.5 跨上下文压缩或重启的长期工作
 
@@ -76,23 +94,23 @@ Tower 是 Host 插件，只使用本地 Git、本地文件和 DSH subagent 服
 
 ### 2.6 有硬集成边界的并行工作
 
-例：monorepo 中四个独立服务，各有 owner，最后统一发布审查。Tower 给每个 mission 分支/worktree 并预留写范围；控制塔可用 `tower_batch` 审计有限的发布证据。
+例：monorepo 中四个独立服务，各有 owner，最后统一发布合并。Tower 给每个 mission 分支/worktree 并预留写范围；控制塔可用 `tower_batch` 审计有限的发布证据。
 
 **为什么用 Tower：** 并行是真的，但集成仍然是一个统一的、带门禁的步骤。
 
 ### 2.7 需要另一个 agent 能检查的"完成定义"
 
-例：任务清单 + 测试 + 必需审查结论。Tower 的 mission 契约与 completion/review 工具让"完成"可观察。如果你的完成定义只是"用户在聊天里满意"，Tower 是过度设计。
+例：任务清单 + 测试 + 可选审查结论。Tower 的 mission 契约与 completion/review 工具让"完成"可观察。如果你的完成定义只是"用户在聊天里满意"，Tower 是过度设计。
 
 ## 3. Tower 不适合的场景
 
 | 场景 | 更合适的模式 | 原因 |
 |---|---|---|
-| 单文件修改、typo、小 hotfix | 普通会话中的单个 agent | worktree、审查与合并开销大于收益。 |
+| 单文件修改、typo、小 hotfix | 普通会话中的单个 agent | worktree 与合并开销（开启审查时再加审查）大于收益。 |
 | 需求仍在发现阶段 | 普通 agent、Plan mode 或 Agent Teams | Tower 要求先给 scope/tasks；错误契约会导致重新规划。 |
 | 开放式研究或头脑风暴 | Agent Teams、Workflow 或普通子代理 | 没有要隔离和合并的仓库变更。 |
-| 很多极小的独立任务 | Workflow 或普通并行子代理 | 每个 mission 的审查/合并成本太高。 |
-| 交互式 UI 配对或探索式调试 | 普通 agent（或单个 worker） | 需要紧密反馈与频繁人工引导，审查门禁增加延迟。 |
+| 很多极小的独立任务 | Workflow 或普通并行子代理 | 每个 mission 的合并成本（开启审查时再加审查）太高。 |
+| 交互式 UI 配对或探索式调试 | 普通 agent（或单个 worker） | 需要紧密反馈与频繁人工引导，开启审查时门禁增加延迟。 |
 | 一次性生成、没有集成 | 普通子代理/Workflow | 不需要分支、审查、合并决策。 |
 | 跨仓库产品工作 | Agent Teams + 普通工具 | Tower 只作用于单个 Git 仓库。 |
 
@@ -104,12 +122,12 @@ Tower 是 Host 插件，只使用本地 Git、本地文件和 DSH subagent 服
 
 | 维度 | Tower | Agent Teams | Ralph 循环 | Workflow 编排 | 普通并行子代理 |
 |---|---|---|---|---|---|
-| 主要目标 | 交付经审查的仓库变更 | 围绕共享目标协作 | 对同一目标用新鲜 agent 反复尝试 | 程序化扇出/流水线 | 并行探索或实现 |
-| 工作单位 | mission（分支 + worktree + scope + 任务 + 审查） | 共享任务板上的任务/teammate | 轮次/尝试 | 脚本步骤/阶段 | 每个子代理一个 prompt/任务 |
+| 主要目标 | 交付经门禁集成的仓库变更（可选独立审查） | 围绕共享目标协作 | 对同一目标用新鲜 agent 反复尝试 | 程序化扇出/流水线 | 并行探索或实现 |
+| 工作单位 | mission（分支 + worktree + scope + 任务 + 可选审查） | 共享任务板上的任务/teammate | 轮次/尝试 | 脚本步骤/阶段 | 每个子代理一个 prompt/任务 |
 | 隔离 | 每 mission 独立 worktree/分支；单写入者 | 共享工作区；靠任务归属协调 | 每轮新 child；无内置分支/合并契约 | 每步 child；无 Git 隔离 | 子会话；可能共享工作区 |
 | 持久状态 | Git 元数据 + JSON state + 活动日志 + 看板 | Team 任务板 + 会话 | 很少；每轮从零开始 | 运行记录/结果；不是合并账本 | 会话/子代理记录 |
-| 集成权限 | 仅控制塔，且需审查 + 门禁 | 人类/teammate 手动合并或编辑 | 通常由父 agent/worker 应用结果 | 脚本应用结果 | 父 agent 应用结果 |
-| 审查/门禁 | 强制独立审查 + preflight/merge 门禁 | 审查是协作约定，不是硬门禁 | 无内置审查门禁 | 无内置审查门禁 | 无内置审查门禁 |
+| 集成权限 | 仅控制塔，经 preflight/merge 门禁（可选再加审查） | 人类/teammate 手动合并或编辑 | 通常由父 agent/worker 应用结果 | 脚本应用结果 | 父 agent 应用结果 |
+| 审查/门禁 | 可选独立审查（`review.requireReview` 开启）+ preflight/merge 门禁 | 审查是协作约定，不是硬门禁 | 无内置审查门禁 | 无内置审查门禁 | 无内置审查门禁 |
 | 并行度 | 多 mission、互斥 scope、合并串行 | 多 teammate、共享任务板 | 顺序轮次（或外部扇出） | 高扇出，由脚本控制 | 高扇出 |
 | 人的角色 | 拥有模式；可检查证据与发布 | 协作者/协调者 | 重复目标的作者 | 编排脚本作者 | 委派者 |
 | 最适合 | 特性交付、迁移、发布绑定变更 | 设计、研究、横切协作 | 迭代搜索/修复，需要新鲜上下文 | 大规模审计、批量分析、确定性流水线 | 快速探索或独立子任务 |
@@ -119,30 +137,83 @@ Tower 是 Host 插件，只使用本地 Git、本地文件和 DSH subagent 服
 
 普通 `subagent`/`subagent_fork` 便宜灵活，适合"并行读五个文件"或"试三种方案"。它们不提供写范围、专用 worktree、持久 mission、独立审查或合并门禁。Tower 用这些契约包装同一个子代理原语，因此每个 child 更贵。
 
-只读、短生命周期、或你准备自己集成结果时，用普通子代理；结果必须落到分支并经过审查时，用 Tower。
+只读、短生命周期、或你准备自己集成结果时，用普通子代理；结果必须落到分支并经受控合并时，用 Tower；需要独立审查时再开启 `review.requireReview`。
 
 ### 4.2 Tower vs Agent Teams
 
 Agent Teams 是**协作**模式：共享任务板、持久 teammate、消息、wait/interrupt，以及人类/Lead 协调。它适合横切、探索性或需要多视角的工作，且集成决定通常由人类做。
 
-Tower 是**交付**模式：mission 契约、Git 隔离、审查与硬合并门禁。它的点对点协作更少、结构更多。Agent Teams 可以决定"做什么、是否继续"；Tower 可以把决定执行成 mission。二者应顺序或互补，而非并发：Tower 模式会拒绝 Team 任务板工具，避免两套协议争抢同一会话。
+Tower 是**交付**模式：mission 契约、Git 隔离、可选审查门禁与硬合并门禁。它的点对点协作更少、结构更多。Agent Teams 可以决定"做什么、是否继续"；Tower 可以把决定执行成 mission。二者应顺序或互补，而非并发：Tower 模式会拒绝 Team 任务板工具，避免两套协议争抢同一会话。
 
 ### 4.3 Tower vs Ralph 循环
 
 Ralph 用新鲜 agent 一轮轮执行**同一目标**，以工作区为长期记忆。它适合迭代搜索、修复 flaky、以及"换上下文再试一次"。它没有 mission 契约、独立审查或合并门禁。
 
-Tower 是增量的：每个 mission 有边界清晰的交付物，并经审查落地。如果问题是"我不知道能不能做成，反复新鲜尝试也许能找到路"，Ralph 往往更合适；如果问题是"我知道切片，需要安全地构建并集成"，Tower 更合适。可以在 Tower 模式之外先用 Ralph 找到方案，再把结果编码成 Tower mission。
+Tower 是增量的：每个 mission 有边界清晰的交付物，并经合并门禁落地（开启审查时再经审查）。如果问题是"我不知道能不能做成，反复新鲜尝试也许能找到路"，Ralph 往往更合适；如果问题是"我知道切片，需要安全地构建并集成"，Tower 更合适。可以在 Tower 模式之外先用 Ralph 找到方案，再把结果编码成 Tower mission。
 
 ### 4.4 Tower vs Workflow 编排
 
 Workflow 是**程序化编排**：JS 脚本把工作扇出到许多 subagent，带阶段、pipeline 与结构化结果。它适合审计、批量迁移、多角度研究与对抗性验证。它不为每一步提供 Git worktree、审查结论或合并门禁。
 
-Tower 是**仓库交付协议**，mission 数量少，不是高扇出数据平面。用 Workflow "并行分析 200 个文件"；用 Tower "把分析证明需要的 6 个修改，经审查与门禁合入"。Tower 模式会拒绝 Workflow，避免脚本在 Tower 契约下制造竞争写入。
+Tower 是**仓库交付协议**，mission 数量少，不是高扇出数据平面。用 Workflow "并行分析 200 个文件"；用 Tower "把分析证明需要的 6 个修改，经可选审查与合并门禁落地"。Tower 模式会拒绝 Workflow，避免脚本在 Tower 契约下制造竞争写入。
 
 ### 4.5 Tower vs Plan mode
 
 Plan mode 决定做什么；Tower 把已决定的计划执行到仓库。进入 Tower 会清除活跃 plan（`mode.planModePolicy:"refuse"` 时拒绝进入），且 Tower 会话不能使用 goal/todo/team/workflow 工具。先规划，再执行；不要指望 Tower 替你发现计划。
 
+### 4.6 审查默认可选
+
+`review.requireReview:false` 是默认值，因此低风险仓库、临时工作或人类逐轮监督的会话可以在没有
+reviewer 时合并已完成 mission。设为 `true` 才启用强制独立审查门禁；此时检查 `no-review`、
+`not-clean`、`review-hold`、`review-not-approved`、`tip-moved`、`review-mission-mismatch`。
+`tower_review` 始终可用并记录结论。只豁免单个 mission 时，在全局开启的前提下用
+`reviewPolicy:"none"` + 理由 + `gates.allowReviewExemption:true`。
+
+### 4.7 各工作流的具体例子
+
+**Tower** —— 输出是必须经过隔离与合并门禁落地的仓库变更（可选独立审查）：
+
+- **OAuth 登录**：四个 mission（`token 模型`、`callback 路由`、`接受/拒绝 API`、`UI`）；API 依赖 token 与邮件。
+- **Node 18 → 22 升级**：先 survey 破坏性 API，再拆 codemod、测试更新、CI 配置、release notes 为独立 mission。
+- **废弃 crypto 迁移**：只读 survey 映射调用点；build mission 按包替换。
+- **发布硬化**：变更、迁移指南、release notes 三个 mission；打 tag 前用 `tower_batch` 收口必需测试。
+- **monorepo 服务拆分**：每个包一个 scope 不重叠的 mission；最后一个审查 mission 检查集成。
+
+**Agent Teams** —— 输出是决策、设计或横切协作，而不是单个可合并分支：
+
+- 后端、前端、安全三个 teammate 做架构评审，把发现汇总到共享任务板。
+- 事故复盘：一人重建时间线，一人查日志，一人起草行动项。
+- 产品需求发现：多视角收敛成规格，由人类决定做什么。
+- 没有单一仓库可隔离/合并的跨仓库调查。
+
+**Ralph 循环** —— 输出是对*同一目标*的新鲜尝试：
+
+- flaky 测试需要多轮独立复现与修复。
+- 性能优化每轮换一个假设，对 eval 反复尝试。
+- 父 agent 不知道路径的"找到任意可行方案"探索。
+- 反复调 prompt/skill 直到 eval 阈值达标。
+
+**Workflow 编排** —— 输出是大规模程序化扇出或流水线：
+
+- 审计 200 个文件的不安全 API 用法并生成结构化报告。
+- 对多包/多版本并行跑依赖升级矩阵。
+- 多角度研究或对提案做对抗性验证。
+- 批量生成/翻译/测试独立产物并聚合结果。
+
+**普通并行子代理** —— 输出是快速的只读并行或独立探索：
+
+- 并行读五个候选文件并分别总结。
+- 同一函数写三种实现并比较。
+- 扫描仓库中的风险模式但不修改。
+- 父 agent 写答案前做独立的文档查找。
+
+**混合阶段（推荐）** —— 用 Workflow/Teams 分析，用 Tower 交付：
+
+1. Workflow 审计 200 个文件 → 结构化 findings。
+2. Agent Teams 评审 findings，决定前六个改动。
+3. Tower mission 实现这六个改动，经可选审查与合并门禁落地。
+4. 合并后仍有一个顽固 flaky 测试、且不需要新 mission 契约时，再用 Ralph。
+
 ## 5. 具体场景示例
 
 ### 场景 A：四切片特性
@@ -152,24 +223,24 @@ Plan mode 决定做什么；Tower 把已决定的计划执行到仓库。进入
 1. 规划四个 build mission，scope 分别 `src/tokens/**`、`src/email/**`、`src/api/invites/**`、`src/ui/invites/**`；让 API 依赖 token 与 email。
 2. 对独立 mission 启动 worker；API 等依赖完成。
 3. 每个 worker 在自己分支提交，带 checks 完成。
-4. 启动 reviewer；要求 clean + merge。
+4. 若开启 `review.requireReview:true`，启动 reviewer 并要求 clean + merge；否则审查可选。
 5. 逐 mission `tower_preflight` + `tower_merge`，处理 scope/base/review blocker。
 6. `tower_teardown`；`MISSIONS.md` 是人类可读记录。
 
-**为什么不用 Team/Workflow？** 这是已知的仓库变更集合，需要按顺序落地并独立审查。Team 任务板不隔离写入；Workflow 会分析但不会门禁合并。
+**为什么不用 Team/Workflow？** 这是已知的仓库变更集合，需要按顺序经受控合并落地（可选独立审查）。Team 任务板不隔离写入；Workflow 会分析但不会门禁合并。
 
 ### 场景 B：带 survey 的迁移
 
 1. Survey mission："映射 `oldApi` 的所有调用者"，scope 为空，只读。
 2. Build mission：codemod、测试更新、文档；依赖 survey 结果。
-3. Reviewer 对照 survey 检查 diff；被审查 tip 的测试必须通过。
+3. 开启审查时，Reviewer 对照 survey 检查 diff；测试门禁仍校验当前分支 tip。默认审查可选时，可跳过 reviewer，仍受门禁/测试约束。
 4. 按依赖顺序合并。
 
-**为什么不用普通子代理？** survey 不能误改；codemod 不能越界；审查必须绑定精确提交。
+**为什么不用普通子代理？** survey 不能误改；codemod 不能越界；开启审查时，审查必须绑定精确提交。
 
 ### 场景 C：事故 hotfix
 
-生产一行修复。用普通 agent，按你正常的提交/推送流程处理。Tower 会额外增加 worktree、reviewer、门禁与合并步骤；对一行紧急修复主要是延迟。如果"hotfix"实际是多个协调变更，Tower 才合理。
+生产一行修复。用普通 agent，按你正常的提交/推送流程处理。Tower 会额外增加 worktree、合并门禁与（开启时）reviewer；对一行紧急修复主要是延迟。如果"hotfix"实际是多个协调变更，Tower 才合理。
 
 ### 场景 D：大范围代码审计
 
@@ -177,22 +248,22 @@ Plan mode 决定做什么；Tower 把已决定的计划执行到仓库。进入
 
 ### 场景 E：敏感发布
 
-有外部用户的库发布。为变更、迁移指南、release notes 规划 mission；要求测试与审查；用 `tower_batch` 只有在所有必需检查齐全时才收口发布证据；按你的发布流程在 Tower 之外合并/打 tag。
+有外部用户的库发布。为变更、迁移指南、release notes 规划 mission；如发布需要独立审查，开启 `review.requireReview:true`；要求测试，并用 `tower_batch` 只有在所有必需检查齐全时才收口发布证据；按你的发布流程在 Tower 之外合并/打 tag。
 
 ## 6. 实践中的选择路径
 
 1. **输出是 Git 变更吗？** 否 → 普通 agent、Agent Teams、Workflow 或 Ralph。
 2. **你会为它开 PR 吗？** 否 → Tower 太重，用普通 agent。
 3. **切片有稳定 scope 和已知完成定义吗？** 否 → 先规划/探索，再回到 Tower。
-4. **需要独立审查与合并门禁吗？** 是 → Tower；否，普通子代理可能足够。
+4. **需要合并门禁吗？** 有集成风险的仓库变更 → Tower；如果还需要独立审查，开启 `review.requireReview:true`。两者都不需要时，普通子代理可能足够。
 5. **需要大量并行分析或重复新鲜尝试吗？** 那个阶段用 Workflow/Ralph；把结果编码成 Tower mission。
 6. **需要横切的人类协作吗？** 用 Agent Teams 决定；用 Tower 执行决定的仓库工作。
 
 ## 7. 成本、限制与反模式
 
-- **每个 mission 有真实开销**：worktree、spawn、完成检查、审查轮次、门禁、合并。mission 应有意义（大致 PR 大小），不要一个函数一个 mission。
+- **每个 mission 有真实开销**：worktree、spawn、完成检查、可选审查轮次、门禁、合并。mission 应有意义（大致 PR 大小），不要一个函数一个 mission。
 - **合并会串行**：重叠 scope 自动加依赖；独立 mission 仍然逐个合入 base。合并密集的工作不要期待线性加速。
-- **审查不是免费**：每个 mission 需要 reviewer 与 clean 结论；豁免是显式开启且需要理由，不是默认。
+- **审查不是免费的（开启时）**：每个 mission 需要 reviewer 与 clean 结论；`review.requireReview:false`（默认）让审查可选；开启后豁免是显式且需要理由。
 - **过细的 mission** 增加协调与合并成本；**过粗的 mission** 失去并行审查收益，scope 冲突概率高。
 - **Tower 不是沙箱**：它是协调协议；Host 权限、仓库 hooks、测试命令仍以 DSH 用户的 OS 权限执行。
 - **不要同时跑两套编排协议**：Tower 模式会拒绝 Team/Workflow/Ralph/subagent 工具并清除 plan mode；请顺序分阶段。
@@ -202,9 +273,10 @@ Plan mode 决定做什么；Tower 把已决定的计划执行到仓库。进入
 
 - [ ] 工作会产生值得 PR 式审查的仓库变更。
 - [ ] 我能列出 2–8 个 scope 不重叠、依赖顺序大致的 mission。
-- [ ] 每个 mission 有可测试的完成定义（任务、checks/测试、审查）。
+- [ ] 每个 mission 有可测试的完成定义（任务、checks/测试、可选审查）。
+- [ ] 如果这次变更需要独立审查，已开启 `review.requireReview`（默认关闭）。
 - [ ] 我知道哪些 mission 可并行、哪些必须等待。
-- [ ] 我接受审查/合并开销，并会检查 `MISSIONS.md`/分支。
+- [ ] 我接受合并门禁开销（以及开启审查时的审查开销），并会检查 `MISSIONS.md`/分支。
 - [ ] 当前没有在同一会话依赖 Team 任务板、Workflow 脚本、Ralph 循环或 plan mode。
 - [ ] 如果 worker 卡住（interrupt/adopt）或合并冲突，我有恢复路径。
 

package/docs/zh/operations/security.md

@@ -6,9 +6,12 @@ Tower 提供的是**协作层面的保证**，不是沙箱。需要理解哪些
 
 ## 由插件强制执行的约束
 
-- **审查绑定。** `tower_review` 会记录它检查的分支 tip；tip 变化后门禁会拒绝（`tip-moved`），除非
-  一次干净且无冲突的 rebase 给予了豁免。reviewer 在 spawn 之后修改分支会被拒绝
-  （`reviewer must not modify the mission branch`）。
+- **审查绑定（开启审查时）。** `tower_review` 会记录它检查的分支 tip；开启 `review.requireReview` 后
+  tip 变化会被门禁拒绝（`tip-moved`），除非一次干净且无冲突的 rebase 给予了豁免。reviewer 在 spawn
+  之后修改分支会被拒绝（`reviewer must not modify the mission branch`）。
+- **审查默认可选，可配置强制。** `review.requireReview:false` 是默认值；设为 `true` 才启用独立审查
+  门禁。全局开启时，mission 级 `reviewPolicy:"none"` + 理由是更窄的豁免。关闭门禁时插件不强制职责
+  分离；只应用于可信仓库或有人类监督的会话。
 - **角色强制。** 调用方会根据 roster 解析。worker 的 mission 更新仅限于 task/blocker/note；
   `completed`、`abandoned`、扩大 scope 与清除 blocker 仅限控制塔，完成（连同未读消息/提交门禁）必须
   走 `tower_complete`。仅限控制塔的工具会以 `[tower:not-authorized]` 拒绝 roster 中的 worker。
@@ -16,21 +19,28 @@ Tower 提供的是**协作层面的保证**，不是沙箱。需要理解哪些
 - **只读 reviewer preset。** `tower-reviewer` preset 从工具面移除 `write`、`edit`、`pwsh`、
   `tower_mission` 与 `tower_complete`；reviewer 只能读、看 diff、发消息、记录 finding 和提交审查。
 - **Scope 门禁。** mission 只能修改其声明 scope glob 匹配的文件；越界改动会阻止合并。
-- **Worktree 隔离。** worker 在独立 worktree 与分支上工作；主检出只会被 merge/teardown 触及。
-- **人类掌握模式。** `/tower` 归用户所有。开启 `mode.allowAgentControl` 后模型可以切换，但必须
-  给出理由；随包 patch 默认开启——设为 `false` 可让模式只由人类控制。
+- **模式控制显式且可配置。** `/tower` 始终可用。`mode.allowAgentControl:true`（默认）时，模型也可以
+  带必填理由用 `tower_control` 进出；每次变更记录操作者与理由。设为 `false` 则仅人类可控制模式。
+  重点是变更可归因，而不是固定由某一方拥有。
 - **不自动恢复 goal。** 进入模式会暂停活跃 goal；退出时不会恢复它。
 - **建议性 workspace 锁。** `mode.workspaceLock` 防止两个 Tower 会话意外驱动同一个仓库；它是同用户
   之间的协调锁，不是用户间的认证机制。
 
 ## 不由插件强制执行的约束（部署关注点）
 
+- **Worktree 隔离是协议约定，不是 OS 沙箱。** worker 会被分配独立 worktree/分支并被要求留在其中，但
+  `tower-worker` preset 仍包含 `pwsh`、`write`、`edit`；这些工具可写绝对路径或在主检出执行 Git。
+  scope 门禁检查的是提交后的分支 diff，不是文件系统访问。硬隔离需要容器、独立 OS 用户或受限的 host
+  工具策略。
 - **沙箱。** Host 插件运行在文件系统沙箱之外；reviewer 的 shell 能力是在工具面层面移除的，但底层
   进程仍拥有 DSH 的 OS 权限。需要硬隔离的部署必须自行限制进程/用户。
 - **reviewer 信任。** 审查是 reviewer agent/模型给出的背书；插件能把它绑定到提交，但无法证明
   reviewer 真的推理正确。高价值分支建议使用独立模型/角色。
 - **仓库钩子。** `git merge` 会运行目标仓库的钩子（`pre-merge-commit` 等）。Tower 无法让这些钩子
   变安全；在不受信任的仓库上运行 Tower 前请先审查钩子。
+- **测试发现是仓库代码。** `tests.admission` 默认 `off`，只有显式 `tower_test` 才会执行仓库
+  `package.json` 的 `tower.testDiscovery` 命令；该命令以 DSH 的 OS 权限运行，不是沙箱。不可信仓库应
+  设 `tests.allowPackageDiscovery:false`。
 - **HMR 重载。** 开启 `dev.hotReload` 时，`/tower reload`/`tower_reload` 会让 DSH 从磁盘重新导入
   插件。只为你信任的检出配置 HMR 监视 root；重载会执行这些文件当前的代码。
 - **提示注入。** reviewer 会读取不受信任的分支内容（diff/评论）。只读 preset 限制了影响面，但模型侧

package/docs/zh/reference/blockers.md

@@ -3,14 +3,14 @@
 [English](../../reference/blockers.md) | **简体中文**
 
 `tower_preflight` 返回 `{ok:false, blockers:[{code, detail}]}`。`tower_merge` 与 `tower_rebase`
-在操作失败时返回相同结构。code 稳定；detail 面向人。
+在操作失败时返回相同结构。code 稳定；detail 面向人。下表共定义 32 个稳定 blocker/failure code。
 
 ## 门禁 blocker（26 个）
 
 | Code | 含义 / 下一步 |
 |---|---|
 | `mission-missing` | 未知 mission id。用 `tower_status` 查看。 |
-| `mission-not-completed` | mission 不是 `completed`；只有 `completed`（等待审查）的 mission 才能合并。 |
+| `mission-not-completed` | mission 不是 `completed`；只有 `completed`（可进入 preflight/合并）的 mission 才能合并。 |
 | `tasks-open` | 仍有未完成任务；worker 必须先完成，或带理由 `task_drop`。 |
 | `blockers-present` | mission 仍有 blocker；解决后清除。 |
 | `no-check-evidence` | 启用了 `gates.requireChecks` 且完成报告没有 `checks`。把 completed mission 退回 `active`，带 checks 重新调用 `tower_complete`，然后重新审查。 |
@@ -20,20 +20,20 @@
 | `out-of-scope` | 改动文件超出 mission scope；有意为之就扩大 scope，否则回退。 |
 | `base-dirty` | 主检出存在未提交改动，合并会覆盖它们。 |
 | `deps-unmerged` | 依赖 mission 尚未 merged/abandoned。 |
-| `no-review` | 分支上没有审查：spawn reviewer。 |
-| `review-mission-mismatch` | 最新审查属于另一个 mission。 |
-| `not-clean` | 最新审查是 `p1-Nitems`/`p2-Nitems`；需要再来一轮。 |
-| `review-hold` | 最新审查建议 hold；必须由后续的干净审查取代。 |
-| `review-not-approved` | 最新干净审查给出的是 `fix-then-merge` 或 `hold`；只有 `merge` 才算批准。 |
-| `tip-moved` | 审查之后分支发生变化；重新审查（或使用干净 rebase 的免审豁免）。 |
+| `no-review` | `review.requireReview:true` 且分支上没有审查：spawn reviewer（或关闭审查门禁）。 |
+| `review-mission-mismatch` | `review.requireReview:true` 且最新审查属于另一个 mission。 |
+| `not-clean` | `review.requireReview:true` 且最新审查是 `p1-Nitems`/`p2-Nitems`；需要再来一轮。 |
+| `review-hold` | `review.requireReview:true` 且最新审查建议 hold；必须由后续的干净审查取代。 |
+| `review-not-approved` | `review.requireReview:true` 且最新干净审查给出的是 `fix-then-merge` 或 `hold`；只有 `merge` 才算批准。 |
+| `tip-moved` | `review.requireReview:true` 且审查之后分支发生变化；重新审查（或使用干净 rebase 的免审豁免）。 |
 | `worker-busy` | 该 mission 的 roster agent 正在运行；等待或让其退役。 |
 | `worker-status-unknown` | 父目录不可用，无法证明 live roster agent 已停止；等目录恢复后重试，或先 adopt。 |
 | `base-wrong-branch` | 主检出不在记录的基线分支上。 |
 | `branch-owned-by-closed-missions` | mission 已 merged/abandoned；用新标题重新 plan。 |
 | `worker-stale` | 该 mission 的 roster worker 超过 `spawn.staleMs` 没有目录活动；合并前 adopt（只有确实还在运行时才 interrupt）。 |
-| `tests-missing` | 启用了 `gates.requireTests` 且没有针对被审查 tip 的通过测试回执；运行 `tower_test` 或 `tower_complete`。 |
+| `tests-missing` | 启用了 `gates.requireTests` 且没有针对当前分支 tip 的通过测试回执；运行 `tower_test` 或 `tower_complete`。 |
 | `tests-failed` | 最新测试发现回执失败，或不满足 minCount/required 检查。修复测试并重跑。 |
-| `review-exemption-invalid` | mission 请求 `reviewPolicy:"none"`，但 `gates.allowReviewExemption` 关闭（或缺少理由）。 |
+| `review-exemption-invalid` | `review.requireReview:true` 且 mission 请求 `reviewPolicy:"none"`，但 `gates.allowReviewExemption` 关闭（或缺少理由）。 |
 | `merge-intent-pending` | 崩溃/失败前记录了合并意图；先运行 `tower_merge` 对账，再进行其他门禁。 |
 
 ## 合并失败（4 个）