@zmice/zc 0.2.7 → 0.3.0

package/vendor/packages/toolkit/src/content/commands/start/body.md

@@ -15,6 +15,7 @@
 - `workflow`：六条固定 workflow 之一
 - `entry`：下一步应该调用的 command / skill，必须是实际可执行入口
 - `agent`：可选协作角色；只有平台支持且用户授权时才建议，不作为默认入口
+- `agent_opportunity`：`standard` / `high-risk` 或命中复杂度信号时必须输出，说明是否需要只读协助、串行子代理、上下文级并行或 `zc team`
 - `reason`：用 1-3 条证据说明为什么这样判型
 - `assumption`：如果有未确认前提，明确写出
 - `question`：只有无法安全推进时才问，最多 1-3 个关键问题
@@ -157,12 +158,50 @@
 
 ## 并行与 agent 判断
 
-`start` 可以评估是否适合并行，但不能把并行当默认：
+`start` 采用 Agent Opportunity First：复杂任务默认评估多 agent 机会，但启动方式受风险边界控制。
 
-- 任务能按文件、模块或证据问题拆开，且没有强依赖：可以建议 `parallel-agent-dispatch` 或 `zc team plan`
-- 无法证明独立、存在同文件冲突、存在依赖链：默认串行或先计划
-- 用户没有明确授权时，不自动启动子代理或 `zc team start`
-- 如果进入 `zc team`，先 dry-run：`zc team plan ... --json`
+必须输出 `agent_opportunity` 的信号：
+
+- 涉及 3 个以上文件或 2 个以上模块。
+- 同时包含方案、实现和验证。
+- 用户使用“深入、整体、优化、审查、排查、对齐、联动”等词。
+- 涉及安全、性能、数据恢复、生产配置或敏感配置。
+- 需要前后端、后端与部署、文档与实现同步。
+- 当前上下文不足，需要并行摸底。
+
+`agent_opportunity` 格式：
+
+```text
+agent_opportunity:
+- mode: none | readonly-consult | serial-subagent | context-fanout | zc-team
+- reason:
+- agents:
+- ownership:
+- fan-in:
+- needs_confirmation:
+```
+
+模式规则：
+
+- `none`：简单任务或无法证明 agent 有收益。
+- `readonly-consult`：架构、审查、测试、安全、性能、产品等只读协助；只有用户已授权本会话或项目默认启用只读 agent 时，才可通知式启动，不改文件。
+- `serial-subagent`：已有任务计划、任务彼此独立，但不需要并行执行。
+- `context-fanout`：多个独立问题或互不重叠文件可以并行处理；写入型 fan-out 必须先确认文件所有权和 fan-in 验证。
+- `zc-team`：需要 tmux + git worktree 或 Codex / Qwen 多 CLI worker 时才建议；必须用户明确要求或确认。
+
+数量上限：
+
+- 普通复杂任务最多 1 个只读 agent。
+- 跨模块或高风险任务最多 2 个只读 agent。
+- 写入型并行默认最多 2 个 worker，超过 2 个必须说明收益和 fan-in 成本。
+- `zc team` 不能因“可能更快”自动启动，必须用户明确。
+
+确认边界：
+
+- 只读 agent：用户已授权时通知式启用，必须说明 agent、目标和“不改文件”；未授权时只输出 `agent_opportunity` 和 `Agent assist` 预告，等待确认。
+- 写入型 agent：确认式启用，必须说明文件所有权、验证命令和 fan-in gate。
+- 无法证明独立、存在同文件冲突、存在依赖链：默认先 `task-plan`，不直接并行。
+- 如果进入 `zc team`，先 dry-run：`zc team plan ... --json`。
 
 ## 上下文与持久化边界
 

package/vendor/packages/toolkit/src/content/skills/documentation-and-adrs/body.md

@@ -19,26 +19,28 @@
 ## 执行步骤
 
 1. 判断是否需要 ADR、README 更新、接口文档或注释
-2. 记录背景、约束、候选方案、决策和后果
-3. 对公共 API 或关键流程补充可消费文档
-4. 对源码中的非显而易见陷阱补充“为什么”类注释
-5. 检查发布或实现是否让以下长期文档产生 drift：
+2. 先选文档类型：教程、操作指南、参考手册、解释说明或 ADR；不要把这些目的混进同一份文档
+3. 记录背景、约束、候选方案、决策和后果
+4. 对公共 API 或关键流程补充可消费文档
+5. 对源码中的非显而易见陷阱补充“为什么”类注释
+6. 检查发布或实现是否让以下长期文档产生 drift：
    - README 和 quick start
    - 架构说明、ADR、迁移或兼容性说明
    - 公共 API、CLI、配置项、安装说明
    - 关键行为变更、默认值变化、已知限制
-6. 满足以下任一触发条件时，把文档同步视为显式收尾项，而不是可选备注：
+7. 满足以下任一触发条件时，把文档同步视为显式收尾项，而不是可选备注：
    - 用户首条成功路径变了
    - 安装、升级、回滚步骤变了
    - 默认行为、配置语义或兼容性边界变了
    - 运维、支持或后续开发会因为旧文档而误判
-7. 把文档与代码一起进入版本控制；如果代码已发布，再补一次发布后同步核对
+8. 把文档与代码一起进入版本控制；如果代码已发布，再补一次发布后同步核对
 
 ## 成功标准
 
 - 重要决策有书面理由，不依赖口头记忆
 - 文档说明的是“为什么”和“怎么验证”，不是重复代码
 - 后续工程师或代理能直接消费这些记录
+- 文档类型清楚，不把教程、参考和 ADR 写成一锅粥
 - 文档与当前实现保持同步
 - 文档 drift 被显式识别，而不是在发布后被动暴露
 

package/vendor/packages/toolkit/src/content/skills/engineering-principles/body.md

@@ -12,25 +12,29 @@
 1. 先澄清假设
    把输入、约束、风险和未知项说清楚，再进入实现。
 
-2. 简单优先
+2. 疑点优先收敛
+   遇到相互矛盾、会改变架构或会影响数据安全的疑点时，先提出具体问题；低风险疑点可以声明假设后继续推进。
+
+3. 简单优先
    先选最直接、最容易验证、最少抽象的方案。
 
-3. 外科式修改
+4. 外科式修改
    只改完成目标所需的最小范围，不顺手扩散、不借题发挥。
 
-4. 目标导向
+5. 目标导向
    每一步都要能回答“这一步为什么必要，它离目标更近了什么”。
 
-5. 证据先于断言
+6. 证据先于断言
    结论必须建立在测试、构建、检查或运行结果上，而不是感觉。
 
-6. 发布后不允许失控漂移
+7. 发布后不允许失控漂移
    已发布行为、文档、门禁和回归基线发生变化时，必须有明确校验与同步动作，不能默认“上线后自然会对齐”。
 
 ## 原则落点
 
 | 原则 | 主要落点 |
 | --- | --- |
+| 疑点优先收敛 | `spec-driven-development`、`planning-and-task-breakdown`、`debugging-and-error-recovery` |
 | 证据先于断言 | `verification-before-completion`、`ci-cd-and-automation`、`browser-qa-testing` |
 | 复杂任务谨慎优先于求快 | `verification-before-completion`、`context-engineering` |
 | 简单优先 | `ci-cd-and-automation`、`browser-qa-testing`、`context-engineering` |
@@ -41,6 +45,7 @@
 ## 执行检查清单
 
 - 我是否明确了当前目标和不做什么
+- 我是否把会改变路线的疑点变成了问题或显式假设
 - 这次改动是否是当前问题的最小可行解
 - 是否引入了与目标无关的抽象、重命名或结构变动
 - 是否保留了足够的验证证据来支撑最终结论

package/vendor/packages/toolkit/src/content/skills/git-workflow-and-versioning/body.md

@@ -140,29 +140,29 @@ refactor/<简短描述>  → refactor/auth-module
 
 ## Git Worktree 并行开发
 
-当多个 AI Agent 需要并行工作时，使用 git worktree 同时运行多个分支：
+当多个 AI Agent 需要并行工作时，使用 git worktree 同时运行多个分支。优先使用已被 `.gitignore` 覆盖的项目内 `.worktrees/`；如果无法证明项目内目录会被忽略，就使用仓库外的兄弟目录。
 
 ```bash
 # 为 feature 分支创建 worktree
-git worktree add ../project-feature-a feature/task-creation
-git worktree add ../project-feature-b feature/user-settings
+git worktree add .worktrees/project-feature-a feature/task-creation
+git worktree add .worktrees/project-feature-b feature/user-settings
 
 # 每个 worktree 是独立目录，各自有自己的分支
 # Agent 可以并行工作互不干扰
-ls ../
-  project/              ← main 分支
+ls .worktrees/
   project-feature-a/    ← task-creation 分支
   project-feature-b/    ← user-settings 分支
 
-# 完成后合并并清理
-git worktree remove ../project-feature-a
+# 完成后先确认状态，再合并或清理
+git -C .worktrees/project-feature-a status --short --branch
+git worktree remove .worktrees/project-feature-a
 ```
 
 优势：
 - 多个 Agent 可以同时工作在不同功能上
 - 无需切换分支（每个目录有自己的分支）
-- 实验失败时直接删除 worktree — 不会丢失任何东西
 - 变更相互隔离，直到显式合并
+- 实验失败时也先记录结论并检查 diff，再决定合入、保留或丢弃
 
 ## 存档点模式
 
@@ -180,7 +180,7 @@ Agent 开始工作
     └── 功能完成 → 所有提交形成干净的历史
 ```
 
-这个模式意味着你永远不会丢失超过一个增量的工作。如果 Agent 走偏了，`git reset --hard HEAD` 就能回到上一个成功状态。
+这个模式意味着你不会把多个未验证增量混成一团。如果 Agent 走偏了，先读 `git status` 和 `git diff`，确认哪些文件属于本次增量，再按团队规则回退或丢弃；不要在未确认范围时使用破坏性回退命令。
 
 ## 变更摘要
 

package/vendor/packages/toolkit/src/content/skills/multi-perspective-review/body.md

@@ -21,7 +21,9 @@
 3. 用 **设计视角** 检查交互、可用性、响应式和无障碍
 4. 用 **DevEx 视角** 检查计划中的集成成本、配置复杂度、文档前提、学习曲线和维护负担
 5. 把四个视角发现的问题改写成可执行的修订项、约束或验收标准
-6. 汇总结论，明确需要修订的点，再决定是否进入实现
+6. 对会改变路线的发现触发 `stop gate`，先收敛决策，不把问题静默写进计划后继续
+7. 输出 `Implementation Tasks`，把需要修订的发现转成可执行任务
+8. 汇总结论，明确需要修订的点，再决定是否进入实现
 
 ## 评审产物
 
@@ -31,6 +33,8 @@
 - 分级发现：`Critical / Warning / Suggestion`
 - 每条发现对应的证据、影响和修订动作
 - 对应的验收标准或验证命令
+- 会改变路线的 stop gate 决策及当前状态
+- `Implementation Tasks`：每条待修问题对应的 P1/P2/P3 任务
 - 如果需要提问，最多 1-3 个会改变方案的关键问题
 
 ## 推荐结论格式
@@ -50,6 +54,49 @@ Recommendation: <GO / REVISE / NO-GO + next action> because <specific cross-pers
 
 如果需要提问，每个问题都要说明它会解锁哪个决策，避免只收集背景信息。
 
+## Stop Gate
+
+以下情况不能直接给 `GO`：
+
+- Critical 发现会改变架构、数据模型、权限、破坏性操作或用户可见承诺
+- 不同视角的结论互相冲突，且会改变任务顺序或验收标准
+- 计划缺少关键验证方式，导致实现完成后无法判定是否通过
+- 发现明显过度设计，但当前计划仍按高复杂度方案推进
+
+Stop gate 输出：
+
+```text
+STOP: <route-changing finding>
+- Perspective:
+- Evidence:
+- Impact:
+- Options:
+- Recommendation:
+- Required decision or assumption:
+```
+
+如果用户已给出偏好，写成 `Assumption` 并继续；否则先提问。不要把 stop gate 伪装成普通 Suggestion。
+
+## Implementation Tasks
+
+评审发现必须能转成 plan 可吸收的任务：
+
+```text
+### Implementation Tasks
+- [ ] T1 (P1) — <component> — <imperative title>
+  - Surfaced by: <perspective> — <specific finding>
+  - Files likely touched:
+  - Acceptance criteria:
+  - Verification:
+```
+
+规则：
+
+- P1 阻塞进入实现或合并
+- P2 应进入当前计划
+- P3 可以作为 follow-up，但要说明不阻塞的理由
+- 没有 actionable task 的发现，要明确写 `_No implementation task; informational only._`
+
 ## 边界说明
 
 - 这里的 DevEx 只评估“实现前是否想清楚”，不替代实现后的真实安装和上手走查
@@ -65,6 +112,7 @@ Recommendation: <GO / REVISE / NO-GO + next action> because <specific cross-pers
 - DevEx 问题被表达为计划假设、约束或验收条件，而不是模糊感受
 - 最终结论可以明确是 `GO / REVISE / NO-GO`
 - 评审输出能直接变成 plan 修订、任务依赖或验证门禁
+- Critical 或 route-changing 发现没有被跳过；要么进入 stop gate，要么转成 P1 任务
 
 ## 相关原则
 

package/vendor/packages/toolkit/src/content/skills/parallel-agent-dispatch/body.md

@@ -2,7 +2,7 @@
 
 ## 角色定位
 
-在用户明确允许多 agent / 并行 / team 模式时，把彼此独立的任务做上下文级 fan-out，并在结束时做 fan-in、冲突检测和集成验证。
+把彼此独立的任务做上下文级 fan-out，并在结束时做 fan-in、冲突检测和集成验证。只读 fan-out 只有在用户已授权本会话或项目默认启用只读 agent 时，才可通知式启动；写入型 fan-out 必须先确认文件所有权、验证命令和 fan-in gate。
 
 这个 skill 不是默认加速器。能并行不等于应该并行；并行会增加 token、延迟、集成和验证成本。
 
@@ -10,11 +10,11 @@
 
 1. 读取计划，列出所有任务、依赖和预计触达文件。
 2. 判断任务是否彼此独立，是否有清晰文件所有权。
-3. 给出并行推荐，但在用户明确确认前不启动子代理。
-4. 为每个 worker 分配唯一责任范围、允许修改文件和验证命令。
-5. fan-out 执行，期间不让多个 worker 修改同一文件。
-6. fan-in 汇总，检查 diff、冲突、接口一致性和测试结果。
-7. 记录验收 transcript：谁做了什么、证据是什么、还有什么风险。
+3. 区分只读通知式 fan-out 和写入确认式 fan-out。
+4. 为每个 worker 分配唯一责任范围、允许读取或修改的边界和验证命令。
+5. fan-out 执行，期间不让多个写入 worker 修改同一文件。
+6. fan-in 汇总，检查 diff、冲突、接口一致性、review finding 和回归结果。
+7. 记录验收 transcript：谁做了什么、谁提出了什么、谁修复了什么、谁回归了什么、证据是什么、还有什么风险。
 
 ## 使用条件
 
@@ -22,7 +22,7 @@
 
 - 多个任务互不依赖。
 - 每个任务能在独立上下文中完成。
-- 文件所有权可以提前划清。
+- 写入任务的文件所有权可以提前划清，或只读任务有明确问题边界。
 - fan-in 后有集成测试或人工审查门禁。
 
 不适用：
@@ -30,12 +30,13 @@
 - 任务依赖同一个未完成设计。
 - 多个任务必须改同一文件。
 - 缺少测试或集成验证方式。
-- 用户没有明确授权并行。
+- 写入型并行没有用户确认。
 
 ## 模式选择
 
 | 模式 | 适用场景 | 代价 |
 |---|---|---|
+| Readonly Consult | 多个只读 agent 分别评估架构、测试、安全、性能、产品或 review 风险 | 需要主线程判断哪些结论成立 |
 | Context Fan-Out | 只需要多个子代理分别分析或修改互不重叠文件 | 共享同一 worktree，fan-in 需谨慎检查 |
 | Worktree Parallel | 任务可能触及相邻区域，或需要独立构建环境 | 需要分支和 worktree 清理 |
 | Cascade | 任务有层级依赖，但每层内可并行 | 每层都要验证后再进下一层 |
@@ -43,9 +44,19 @@
 
 如果需要文件系统级隔离，切到 `team-orchestration`；不要在本 skill 内展开完整 `zc team` 教程。
 
-## 授权提示
+## 通知与授权
 
-启动前必须给用户看到这段信息的等价内容：
+只读 fan-out 在已授权时使用通知式提示：
+
+```text
+Agent assist:
+- <agent>：只读评估 <范围>，不改文件
+fan-in：主线程汇总结论后再决定是否改代码
+```
+
+如果当前会话或项目没有只读 agent 默认授权，只输出上面的 `Agent assist` 预告并等待确认。
+
+写入型 fan-out 启动前必须给用户看到这段信息的等价内容：
 
 ```text
 Recommendation: 开启 <模式> because <并行收益> outweighs <集成代价>。
@@ -57,13 +68,21 @@ Recommendation: 开启 <模式> because <并行收益> outweighs <集成代价>
 确认后我再启动；不确认则按串行推进。
 ```
 
+默认上限：
+
+- 普通复杂任务最多 1 个只读 agent。
+- 跨模块或高风险任务最多 2 个只读 agent。
+- 写入型并行默认最多 2 个 worker。
+- 超过 2 个 worker 必须说明收益和 fan-in 成本。
+- `zc team` 必须用户明确要求或确认。
+
 ## Worker 合约
 
 每个子代理都必须收到：
 
 - 任务目标和验收标准
 - 允许读取的关键上下文
-- 允许修改的文件或模块边界
+- 允许修改的文件或模块边界；只读 worker 必须明确“不改文件”
 - 不得触碰其他 worker 文件的说明
 - 任务内验证命令
 - 返回格式：`DONE / BLOCKED / NEEDS_CONTEXT`
@@ -72,6 +91,7 @@ Recommendation: 开启 <模式> because <并行收益> outweighs <集成代价>
 
 - 修改文件
 - 已运行验证
+- 提出的 findings 或回归结论
 - 未覆盖风险
 - 需要主线程 fan-in 的事项
 
@@ -82,9 +102,16 @@ Recommendation: 开启 <模式> because <并行收益> outweighs <集成代价>
 - 所有子代理结果是否到齐。
 - 是否出现同文件修改、命名冲突或接口冲突。
 - 局部验证是否可信。
+- review finding 是否由提出方完成回归。
 - 主线程是否运行集成测试或目标平台验证。
 - 是否需要清理分支、worktree、临时文件或保留待审查分支。
 
+闭环所有权：
+
+- `producer owns fix`：谁引入问题，谁优先修复。
+- `reviewer owns regression`：谁提出问题，谁负责复验原 finding 是否关闭。
+- `controller owns fan-in`：主线程负责接受、转派、整合和最终验证。
+
 推荐记录格式：
 
 ```text
@@ -92,6 +119,9 @@ Parallel acceptance transcript:
 - Plan:
 - Workers:
 - Files:
+- Findings:
+- Fixes:
+- Regression:
 - Results:
 - Verification:
 - Conflicts:

package/vendor/packages/toolkit/src/content/skills/planning-and-task-breakdown/body.md

@@ -27,6 +27,7 @@
    - Dependencies
    - Files likely touched
 5. 排出顺序，并设置阶段性检查点
+6. 如果发现会改变计划路线的阻塞问题，先进入 `stop gate`，不要把问题静默写进计划后继续推进
 
 ## 提问纪律
 
@@ -42,8 +43,11 @@
 - `decision log`：关键取舍和采用原因
 - `evidence`：读取过的规格、代码、配置、测试或上游证据
 - `open risks`：尚未证明的风险和验证方式
-- `fan-out eligibility`：是否能并行、按哪些文件或模块拆、是否需要 `zc team plan`
-- `fan-in gate`：实现后如何合流、审查、验证和清理
+- `stop gates`：会改变架构、数据模型、破坏性边界、并行边界或验收口径的阻塞决策
+- `agent_opportunity`：本计划是否需要只读协助、串行子代理、上下文级并行或 `zc team`
+- `fan-out eligibility`：是否能并行、按哪些文件或模块拆、是否有确认边界、是否需要 `zc team plan`
+- `fan-in gate`：实现后如何合流、审查、回归、验证和清理
+- `implementation tasks`：从计划或评审发现转化来的可执行任务列表
 
 ## 决策日志格式
 
@@ -60,6 +64,79 @@ Recommendation: <chosen action> because <evidence and trade-off>.
 
 理由必须说明被放弃的替代方案，以及当前选择为什么更适合本任务。不能只写“更稳”“更简单”“更符合最佳实践”。
 
+## Stop Gate
+
+以下发现必须先停下来收敛，不允许直接写进计划然后继续：
+
+- 现有证据推翻了原始目标或核心假设
+- 任务顺序、数据模型、权限边界、破坏性操作或并行边界需要重新选择
+- 评审发现如果不处理会导致后续实现返工
+- 缺少验证方式，导致任务无法判断完成
+
+Stop gate 输出格式：
+
+```text
+STOP: <阻塞发现>
+- Evidence:
+- Impact:
+- Options:
+- Recommendation:
+- Required decision:
+```
+
+只有用户已经给出明确偏好，或仓库证据能支持保守路线时，才把 `Required decision` 写成显式假设并继续；否则先问。
+
+## Implementation Tasks
+
+从计划或评审发现生成任务时，统一使用这个可执行格式：
+
+```text
+- [ ] T1 (P1) — <component> — <imperative title>
+  - Source finding:
+  - Files likely touched:
+  - Acceptance criteria:
+  - Verification:
+  - Dependencies:
+```
+
+规则：
+
+- `P1`：阻塞当前交付，必须本轮处理
+- `P2`：应在同一分支处理，否则会留下明显质量缺口
+- `P3`：可延后的跟进项，必须说明为什么不阻塞当前目标
+- 每个任务必须来自具体发现、需求或证据；不能为了填表新增空任务
+- 任务标题用动作开头，能直接交给实现阶段
+
+## Agent Opportunity
+
+计划阶段必须给出明确的多 agent 结论，而不是只写“可并行”：
+
+```text
+agent_opportunity:
+- mode: none | readonly-consult | serial-subagent | context-fanout | zc-team
+- trigger:
+- recommended agents/workers:
+- ownership:
+- confirmation:
+- fan-in gate:
+```
+
+判断规则：
+
+- `readonly-consult`：适合架构、测试、安全、性能、产品或审查侧评；用户已授权只读 agent 默认启用时通知式启动，否则先预告并等待确认，不能改文件。
+- `serial-subagent`：任务独立但存在依赖顺序，主线程逐个委派并 fan-in。
+- `context-fanout`：任务可按文件、模块或证据问题拆开，写入前必须确认文件所有权。
+- `zc-team`：只有用户明确要求或确认，且 `zc team plan` 返回可启动时才进入。
+- `none`：任务简单、强耦合、同文件冲突或缺少验证方式。
+
+fan-in gate 必须说明：
+
+- 主线程如何整合结果。
+- 谁负责修复问题：`producer owns fix`。
+- 谁负责回归确认：`reviewer owns regression`。
+- 哪些命令或人工检查作为最终验证。
+- 是否需要保留、合并或清理分支 / worktree / 临时文件。
+
 ## 成功标准
 
 - 每个任务都能独立实现、测试和验证
@@ -67,7 +144,9 @@ Recommendation: <chosen action> because <evidence and trade-off>.
 - 依赖顺序和可并行项是显式的
 - 人类看完计划后能明确判断“方案对不对”
 - 计划中的问题和风险都能落到后续验证命令或审查项
+- `agent_opportunity` 已给出 mode、触发原因、确认边界和 fan-in gate
 - 并行任务必须有明确文件所有权或隔离理由
+- 阻塞发现已经进入 stop gate 或被转成 P1 implementation task
 
 ## 相关原则
 

package/vendor/packages/toolkit/src/content/skills/sdd-tdd-workflow/body.md

@@ -38,23 +38,57 @@
 
 ## 构建模式选择
 
-- **Manual（默认）**：你自己按任务串行实现。适合大多数改动。
-- **Subagent-Driven**：任务彼此独立，但用户没有要求并行时，可作为串行委派建议。
-- **Parallel**：用户明确要求多 agent / 并行 / team 模式，且任务有清晰文件所有权时，使用 `parallel-agent-dispatch`。
-- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离或多 CLI worker 时，使用 `team-orchestration`。
+进入 Build 前先选择执行模式，而不是直接默认手动实现：
 
-除非用户已经明确要求并行，否则只给并行建议，不直接启动子代理或 `zc team`。
+- **Manual**：简单任务、小修复或同一文件内紧耦合改动，主线程直接实现。
+- **Readonly Consult**：复杂任务需要架构、测试、安全、性能、产品或审查侧评；只有用户已授权本会话或项目默认启用只读 agent 时，才可通知式启动，不改文件。
+- **Serial Subagent**：已有计划，任务彼此独立但有依赖顺序；使用 `subagent-driven-development` 串行委派。
+- **Context Fan-Out**：任务可以按文件、模块或证据问题并行，且有清晰 fan-in gate；使用 `parallel-agent-dispatch`。
+- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离、长时间多 worker 或 Codex / Qwen 多 CLI 协作；使用 `team-orchestration`，必须用户明确要求或确认。
+
+主线程是 controller / integrator：
+
+- 主线程负责目标、计划、分派、文件所有权、stop gate、fan-in 和最终验证。
+- 只读 agent 只汇报结构化结论，不改文件。
+- 写入 agent 只处理被分配的任务和文件，并返回修改文件、验证结果、风险和待 fan-in 项。
+- 审查 agent 默认只读；提出 finding 后负责回归确认。
+- 主线程可以处理小任务、集成冲突、最终修补和验证失败分析，但在已经选择多 agent 模式后，不抢占已分配给 worker 的任务。
 
 推荐提示格式：
 
 ```text
-Recommendation: 按 Manual / Parallel / Team 模式推进 because <证据与 trade-off>。
-- 并行收益：
-- 并行代价：
-- 文件所有权：
-- fan-in 验证：
+Recommendation: 按 Manual / Readonly Consult / Serial Subagent / Context Fan-Out / Team 模式推进 because <证据与 trade-off>。
+- agent_opportunity:
+- 只读协助:
+- 写入边界:
+- fan-in 验证:
+- 是否需要确认:
 ```
 
+## 审查与回归闭环
+
+多 agent 任务必须遵循闭环所有权：
+
+```text
+producer owns fix
+reviewer owns regression
+controller owns fan-in
+```
+
+- 实现方或产生方负责优先修复自己引入的问题。
+- 审查方或提出方负责给出复现条件、断言、期望行为、风险等级，并在修复后复验原 finding。
+- 主线程负责判断 finding 是否成立、优先级是否阻塞、是否转派、是否接受结果。
+- 实现方两次修不好时，主线程可以缩小问题后转给更合适的 agent 或自己接手。
+- 审查方默认不直接修；机械小修或用户明确要求时，主线程可以把 finding 转成修复任务。
+
+审查等级：
+
+- `light review`：实现方自审 + 主线程检查。
+- `standard review`：实现方自审 + 独立 reviewer + 提出方回归。
+- `strict review`：规格审查 + 代码质量审查 + 测试 / 安全 / 性能按风险加入。
+
+中等以上任务默认 `standard review`，高风险任务默认 `strict review`。
+
 ## 阶段切换纪律
 
 - 进入新阶段前，说明当前阶段已满足的证据。
@@ -72,6 +106,7 @@ Recommendation: 按 Manual / Parallel / Team 模式推进 because <证据与 tra
 - 计划要求修改的文件和实际代码结构明显不一致。
 - 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
 - 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
+- review finding 未闭环，或提出方尚未完成回归确认。
 
 ## 输出契约