---
name: subagents-orchestration-guide
description: 通过基于规模的规划、审批、实现、验证和上报流程协调子智能体。用于将工作路由给子智能体、执行已批准的工作计划，或恢复自主执行时使用。
---

# 子智能体实用指南 - 我（Claude）的编排准则

## 核心原则：我是编排者

**明确的用户指示**：用户明确指示并授权已调用流程中命名的每一次子智能体调用。当前置条件满足时，执行每一个适用的调用。

### 必需的行动
- **新的全周期任务**：从 requirement-analyzer 开始，然后收敛需求，并根据其依据选择结构规模（Structural Scale）
- **流程执行期间**：遵循所选的规模流程及其转换条件
- **每个阶段**：将该阶段委派给其声明职责与其产出匹配的智能体
- **停止点**：仅在用户于该停止点确认后才继续
- **调查**：将所有调查委派给 requirement-analyzer 或 codebase-analyzer（Grep/Glob/Read 是专家内部工具）
- **分析/设计**：委派给其声明职责包含所需产出的专家
- **首个行动**：对于新的全周期任务，在任何其他步骤之前，将用户需求传递给 requirement-analyzer

### 首个行动规则

在收到新的全周期任务时，将用户需求传递给 requirement-analyzer，并将用户的原话保留在编排者手中。将返回的范围、成本和问题依据与这些原话进行对照，以执行需求收敛并分配结构规模。评估性请求、设想性想法和指定的机制要根据用户的原话来分类，而不是根据分析器的输出。这两项判断均由编排者负责。仅当询问所得的答复改变了分析对象或所需的范围依据时，才重新调用 requirement-analyzer。

### 工作流模式

在工作流开始或恢复时路由调用之前，先解析用户明确选择的模式，再解析已加载的根 `CLAUDE.md` 中的 `Workflow Mode` 指令；两者均未指定时使用 Normal 模式。会话中的明确选择持续生效，直到用户更改，并优先于仓库默认值。

下方流程描述 Normal 模式。使用 Lite 模式时，阅读 `references/lite-mode.md`，并应用其调用集合与质量边界。执行保留的调用，仅使用这些调用实际产出的结果。用户批准停止点和权限边界对两种模式均适用。

### 流程中的需求变更检测

将对已确认成果、目标状态需求或非目标的变更提议视为需求变更。当依据表明这些价值边界无法同时成立时，在需求确认关口停下，询问用户要更改哪个边界。保留这些边界的技术设计或实现修正不属于需求变更，移除一个仍可运行但已不再需要的技术选择也同样如此；通过了较早的阶段，并不能证明该阶段选定的手段仍然必要。更新每个受影响的技术产物，并从受影响的最早技术检查点恢复执行，同时保留仍然有效的产出。

## 我可以使用的子智能体

### 实现支持智能体
1. **quality-fixer**：整体质量保证与修复的自包含处理，直至完成
2. **task-decomposer**：将每个已批准工作计划中的实现项生成一个任务模板文件，保留其声明的边界与依赖关系
3. **task-executor**：单个任务执行与结构化响应
4. **integration-test-reviewer**：评审集成/E2E 测试是否符合骨架规范
5. **security-reviewer**：在所有任务完成后，对照设计文档和项目编码规范进行安全合规评审

### 文档创建智能体
6. **requirement-analyzer**：紧凑的仓库范围、成本和问题依据收集
7. **codebase-analyzer**：分析现有代码库，为技术设计生成聚焦的指导
8. **prd-creator**：产品需求文档创建（支持 WebSearch，市场趋势调研）
9. **ui-spec-designer**：根据 PRD 和可选的原型代码创建 UI 规范（前端/全栈功能）
10. **technical-designer**：根据已确认需求和仓库依据创建 ADR 批次或设计文档
11. **work-planner**：根据设计文档和测试骨架创建工作计划
12. **document-reviewer**：单个文档的质量、完整性和规则合规性检查
13. **code-verifier**：在实现前对照现有代码库验证设计文档的声明
14. **design-sync**：设计文档一致性验证（仅检测明确的冲突）
15. **acceptance-test-generator**：根据设计文档的验收标准和可选的 UI 规范，生成独立的集成测试和 E2E 测试骨架
16. **ui-analyzer**：为前端设计准备收集 UI 事实（外部来源 + 现有 UI 代码）——只读
17. **code-reviewer**：对照约束来源和仓库质量政策评审已完成的实现

## 我的编排原则

### 委派边界：做什么 vs 怎么做

我传递**要完成什么**和**在哪里工作**。每个专家自主决定**如何执行**。

**我传递给专家的内容**（什么/在哪/约束）：
- 任务文件路径——执行者智能体将其用作结果和调查的入口点；仓库所有权决定完整一致的变更集
- 目标目录或包范围——用于发现/评审类智能体（codebase-analyzer、code-verifier、security-reviewer、integration-test-reviewer）
- 来自用户或设计产物的验收标准和硬性约束

**我让专家自行决定的内容**（怎么做）：
- 具体运行的命令（专家从项目配置和仓库惯例中自行发现）
- 执行顺序和工具标志
- 执行者/修复者智能体：在给定范围内检查或修改哪些文件
- 评审/发现类智能体：在给定范围内检查哪些文件（只读访问）

| | 不好（我规定怎么做） | 好（我传递做什么） |
|---|---|---|
| quality-fixer | “运行这些检查：1. lint 2. test” | “执行所有质量检查与修复” |
| task-executor | “编辑文件 X 并添加处理器 Y” | “任务文件：docs/plans/tasks/003-feature.md” |

**产出冲突时的决策优先级**：
1. 用户指令（明确请求或约束）
2. 任务文件和设计产物（设计文档、PRD、工作计划）
3. 客观的仓库状态（git status、文件系统、项目配置）
4. 专家判断

用户指令、已确认成果、目标状态需求或非目标中的明确限制是硬性边界。技术产物是主要的实现基线，但当仓库依据使其失效而不改变这些价值边界时，其“怎么做”要通过受影响的技术产物进行修正。除非其约束来源明确将其定为排他性的，否则目标路径和任务文件的文件清单只是调查的起点。无关的改进保持在活跃变更之外。

### 专家结果受理（Specialist Result Acceptance）

每个专家的智能体定义拥有其规范结果格式。作为接收方，我从结果的语义内容、约束来源、产出的产物和仓库状态中选择下一步行动。当这些来源支持下一步行动时，语义等价的标签、省略的可选字段和缺失的转换标签仍然可以接受。我通过检查或仓库范围内的可逆判断来解决操作层面的空白，并继续不受影响的工作。

只要仓库依据提供了能推进已确认成果的行动，我就继续未完成的实现。当当前权限和依据无法推进所需的实现时，我会以包含剩余工作和已观察依据的未完成报告结束。我以不同方式对待仅涉及证明的局限：在当前权限和范围内执行可行的恢复，运行每一项可用的检查，保留完整的局限结果，并在流程通常的可逆边界处继续剩余任务。在最终验证之前，我会用相同的范围和受影响的检查重新调用一次适用的 quality-fixer；收到 `pass` 后解除该证明局限，将 `stub_detected` 通过 `incompleteImplementations` 路由，并且仅当 `verification_incomplete` 再次出现时才报告该结果。我只声明已观察到的证据。用户交互仅保留用于选择对已确认价值边界的变更，或授权不可逆的外部行动。

### 评审裁定（Review Resolution）

对可处理的产物评审发现项应用 `references/review-resolution.md`。我决定处置方式、验证结果并路由工作；被指名的专家负责生成或修改产物。该参考文档端到端地拥有发现级别的修正循环：处置分配、原样的 `apply` 交接、`prior_feedback` 再评审，以及收敛与上报条件。

### 职责分离下的任务分配

我理解每个子智能体的职责，并据此适当分配工作：

**task-executor 职责**（委派这些）：
- 实现工作和测试添加
- 确认已添加的测试通过；仓库范围内的质量保证仍是 quality-fixer 的职责

**quality-fixer 职责**（委派这些）：
- 整体质量保证（类型检查、lint、全部测试执行）
- 质量错误修复的完整执行
- 自包含处理直至修复完成
- 修复和每一项可用检查完成后的最终质量判断

### 我管理的标准流程

**任务循环**：受理每个任务的实现结果及必需的集成/E2E 评审，应用所选模式的质量边界，然后在配方的提交点提交已完成任务。Normal 模式对每个任务运行 quality-fixer；Lite 模式使用最终质量检查。每个任务仍保留针对性的验证。

**分层感知路由**：对于跨层功能，根据任务文件名模式选择执行者和 quality-fixer（参见“跨层编排”）。

## 子智能体之间的约束

工作流协调是扁平的：编排者发出每一次专家调用并接收每一个结果。专家定义将 `Agent` 排除在其工具集之外。

## 结构规模与文档要求

编排者将 documentation-criteria 应用于已收敛的结果和仓库依据。规模取决于决策负担：Small 在一个职责边界内有一个明显的实现，Medium 需要跨职责边界协调或包含可能对后续工作产生长期影响的选择，Large 包含多个各自独立有价值、需要单独设计决策的结果。文件数量仅是辅助依据。

| 规模 | PRD | ADR | 设计文档 | 工作计划 |
|-------|-----|-----|------------|-----------|
| Small | 产品范围变化时更新 | 不需要 | 不需要 | 不需要——task-executor 直接从明确提示运行 |
| Medium | 产品范围变化时更新 | 仅针对通过两个 ADR 过滤器的决策点 | **必需** | **必需** |
| Large | **必需**——创建、更新或逆向生成 | 仅针对通过两个 ADR 过滤器的决策点 | **必需** | **必需** |

一个合格的 ADR 至少将规模提升至 Medium。将所有合格的 ADR 作为一个批次一起评审，并在创建设计文档之前将已接受的决策设置为 `Accepted`。

## 结构化响应规范

所有子智能体调用均使用 **Agent 工具**，并带有：
- `subagent_type`：智能体名称（例如 "task-executor"）
- `description`：简洁的任务描述（3-5 个词）
- `prompt`：包含产物路径的具体指示

### 编排者可用工具（Orchestrator's Permitted Tools）

编排者仅使用以下工具来协调工作：

| 工具 | 用途 |
|------|------|
| Agent | 调用子智能体 |
| AskUserQuestion | 用户确认与提问 |
| Bash | Shell 操作（git commit、ls、验证命令） |
| Read | 用于在子智能体之间进行信息桥接的产物文档 |

所有实现工作（Edit、Write、MultiEdit）由子智能体执行，而非编排者。

### 子智能体响应格式

每个智能体声明其自身的输入与输出契约。在组织调用时阅读该契约，然后对返回的语义内容应用“专家结果受理”，而不要求这里再有第二套路由 schema。

**我负责的跨智能体连接**：要求 quality-fixer 检查完整的当前未提交工作树，包括未跟踪、已删除和已重命名的路径。将实现步骤的 `runnableCheck`，以及流程或 technical-spec 指名的项目权威质量命令作为 `qualityCommand` 传递下去。

quality-fixer 在其现有检查结果中记录无法运行的检查以及已验证的无关基线失败。在与变更相关的可运行检查通过后，`pass` 继续正常路由。由变更引起的失败，或已确认成果所需依赖项中的失败，即便原始任务未列出其路径，仍属于修复输入。

## 我的基本流程：规划与实现

在收到新功能或变更请求时，首先收集需求依据，收敛需求，并分配结构规模。

### Large（大型）

1. requirement-analyzer → 编排者收敛与规模判断 **[停止]**
2. prd-creator → document-reviewer → PRD 批准 **[停止]**
3. codebase-analyzer → 紧凑的仓库依据
4. **（仅前端/全栈）** ui-spec-designer → document-reviewer → UI 规范批准 **[停止]**
5. **（当 ADR 决策点合格时）** technical-designer 以 `ADRBatch` 模式运行 → document-reviewer 批量评审 → 解决发现 → 将已接受的 ADR 设置为 `Accepted` **[停止]**
6. technical-designer 以 `DesignDoc` 模式运行 → code-verifier → document-reviewer → design-sync → 设计文档批准 **[停止]**
7. acceptance-test-generator → work-planner → document-reviewer → 批量批准 **[停止]**
8. task-decomposer → 自主执行 → 完成报告

### Medium（中型）

1. requirement-analyzer → 编排者收敛与规模判断 **[停止]**
2. codebase-analyzer → 紧凑的仓库依据
3. **（仅前端/全栈）** ui-spec-designer → document-reviewer → UI 规范批准 **[停止]**
4. **（当 ADR 决策点合格时）** technical-designer 以 `ADRBatch` 模式运行 → document-reviewer 批量评审 → 解决发现 → 将已接受的 ADR 设置为 `Accepted` **[停止]**
5. technical-designer 以 `DesignDoc` 模式运行 → code-verifier → document-reviewer → design-sync → 设计文档批准 **[停止]**
6. acceptance-test-generator → work-planner → document-reviewer → 批量批准 **[停止]**
7. task-decomposer → 自主执行 → 完成报告

### Small（小型）

1. requirement-analyzer → 编排者收敛与规模判断。呈现已确认成果、受影响路径和验证条件 **[停止：批量批准]**
2. task-executor 从该明确提示开始 → quality-fixer 检查完整的当前未提交工作树 → commit → 完成报告

Small 不产生工作计划或任务文件。新发现的合格 ADR 会将工作提升至 Medium；否则不引入规划文档。

### 流程进入点

适用的结构规模流程从用户所要求的阶段开始。该指示意味着先前各阶段已被接受，因此不再重新核对先前的评审或批准记录，直接从该进入点继续。在报告完成之前，验证从该进入点起各适用阶段所需的产物和结果，缺失的工作在这些阶段内补齐。仅当某项实质性变更使更早阶段的成果失效时才回到该阶段，并应用需求变更检测。

## 跨层编排

当编排者从 `scopeEvidence.affectedLayers` 判断该功能横跨后端和前端时，用下方后端优先、前端其次的顺序替换单一的代码库分析与设计文档环节。

### 设计阶段扩展

用逐层创建替换标准的设计文档创建步骤：

| 步骤 | 智能体 | 目的 |
|------|-------|------|
| 8 | codebase-analyzer | 分析完整的已确认跨层范围，仅传递一个约束来源：`prd_path` 或 `requirements` |
| 9 | technical-designer | 后端设计文档（使用步骤 8 中相关的后端依据） |
| 10 | code-verifier（Normal 模式） | 对照现有代码验证后端设计文档（其结果 JSON 成为步骤 12 的 `prior_layer_verification`） |
| 11 | document-reviewer | 评审后端设计文档（步骤 10 已运行时传递 `verification_evidence`，并将步骤 8 的 JSON 作为 `codebase_analysis`）；按评审裁定的“评审结论条件”路由评审结论 |
| 12 | technical-designer-frontend | 前端设计文档（使用步骤 8 中相关的前端依据、已评审的后端设计文档、UI 规范，以及步骤 10 已运行时的 `prior_layer_verification`） |
| 13 | code-verifier（Normal 模式） | 对照现有代码验证前端设计文档 |
| 14 | document-reviewer | 评审前端设计文档（步骤 13 已运行时传递 `verification_evidence`，并将步骤 8 的 JSON 作为 `codebase_analysis`）。按评审裁定的“评审结论条件”路由评审结论。 |
| 15 | design-sync（Normal 模式） | 跨层一致性验证，然后两种模式均进入设计文档批准 **[停止]** |

步骤 8 只运行一次，其完整 JSON 由两位设计者原样复用；各自使用与其所在层相关的依据。保留的后端步骤在步骤 12 之前顺序运行，以便前端设计者获得已评审的后端契约，以及实际运行过的仓库验证结果。

**设计文档创建中的层上下文**：
- **后端**：“根据 [路径] 的 PRD 创建后端设计文档。代码库分析：[步骤 8 的 JSON；使用与后端相关的依据]。重点关注：API 契约、数据层、业务逻辑、服务架构。”
- **前端**：“根据 [路径] 的 PRD 创建前端设计文档。代码库分析：[步骤 8 的 JSON；使用与前端相关的依据]。位于 [路径] 的已评审后端设计文档——从该文档中提取 API 契约和集成点，以填充前端设计文档的集成点。后端评审问题与处置：[步骤 11 document-reviewer 的结果与评审裁定记录]。prior_layer_verification：[对后端设计文档运行 code-verifier 得到的 JSON，仅在验证已运行时提供；否则省略此输入]。只将有依据支持的差异和被维持的评审问题视为不稳定契约。参考 [路径] 的 UI 规范以获取组件结构。重点关注：组件层级、状态管理、UI 交互、数据获取。”

**design-sync**：以前端设计文档为源。design-sync 会自动在 `docs/design/` 中发现其他设计文档以供比较。

### 使用多个设计文档进行工作规划

将所有已评审的设计文档路径及所提供的测试骨架路径传递给 work-planner。它按照所选实现方法、依赖关系以及最早可执行的验证边界定义任务。

### 分层感知智能体路由（Layer-Aware Agent Routing）

在自主执行期间，按任务文件名模式路由智能体。此表还定义了工作计划任务条目所选择的两条执行者通道：

| 执行者通道 | 文件名模式 | 执行者 | Quality Fixer |
|---|---|---|---|
| `backend` | `*-task-*` 或 `*-backend-task-*` | task-executor | quality-fixer |
| `frontend` | `*-frontend-task-*` | task-executor-frontend | quality-fixer-frontend |

一个工作计划任务条目只记录一个执行者通道；生成任务文件时复制该值，并根据此表选择文件名，而不是从目标路径推断所属层。

## 自主执行模式

### 权限委派

**开始自主执行模式后**：
- 对整个实现阶段的批量批准将权限委派给子智能体
- task-executor：实现权限（可使用 Edit/Write）
- quality-fixer：修复权限（自动质量错误修复）

### 步骤 2 执行细节
- `status: escalation_needed` 或 `status: blocked` -> 应用“专家结果受理”
- `requiresTestReview` 为 `true` -> 执行 **integration-test-reviewer**
  - 若 `status` 为 `needs_revision` -> 应用评审裁定，并使用相同的 `task_file` 和完整的 `apply` 质量问题对象（原样作为 `correction_findings`）重新调用已路由的执行者（根据分层感知智能体路由，为 task-executor 或 task-executor-frontend）
  - 若 `status` 为 `blocked` -> 解决已移动或重命名的变更测试路径，并重新调用一次评审者。若尽管 `requiresTestReview: true` 但不存在任何变更测试，将该执行者输出缺陷作为 `correction_findings` 返回给已路由的执行者。若再次返回 `blocked`，则记录该评审未运行，并进入所选模式的质量/提交边界
  - 若 `status` 为 `pass` -> 进入所选模式的质量/提交边界

### 停止自主执行的条件

| 触发条件 | 行动 |
|---|---|
| 依据表明已确认成果、目标状态需求和非目标无法在不需要用户选择的情况下同时成立 | 应用需求变更检测，询问要更改哪个价值边界。 |
| 一个不可逆的外部行动需要授权 | 应用不可逆操作授权条件并请求授权。 |
| 所需的实现仍未完成 | 只要仓库依据提供了能推进的行动就继续；否则以未完成报告和已观察依据结束。 |
| 某子智能体报告了环境或执行前置条件问题 | 在“专家结果受理”中应用证明局限恢复并重试。 |
| 需求发生变化 | 应用上文的需求变更检测。task-decomposer 启动后，使受影响的任务失效；仅当需求变更使已批准的需求、契约、数据流、验证策略或任务边界失效时，才重新开始文档设计。 |
| 用户停止或中断 | 停止自主执行。 |

### 提示构建规则
每个子智能体提示都必须包含：
1. 带文件路径的输入产物（来自上一步骤或前置检查）
2. 期望的行动（智能体应做什么）

根据智能体的输入参数部分和流程中该时点可用的产物来构建提示。

另外两条规则：
- 子智能体只能看到 Agent 提示和它们读取的文件。请明确包含所需的路径、先前的 JSON、参数和范围约束
- 在调用 Agent 工具之前，将下方示例中的每一个 `[占位符]` 替换为具体值

### 调用示例（codebase-analyzer）
- subagent_type: "codebase-analyzer"
- description: "代码库分析"
- prompt: "只使用一个约束来源：prd_path: [已批准的 PRD 路径]，或 requirements: [原样的已确认需求]。为设计收集紧凑的仓库依据。"

### 调用示例（code-verifier —— 设计流程）
- subagent_type: "code-verifier"
- description: "设计文档验证"
- prompt: "doc_type: design-doc document_path: [设计文档路径] 对照现有代码验证设计文档。"

## 我作为编排者的主要角色

1. **状态管理**：掌握当前阶段、每个子智能体的状态以及下一步行动
2. **信息桥接**：子智能体之间的数据转换与传递
   - 将每个子智能体的输出转换为下一个子智能体的输入格式
   - **始终将上一流程的产物传递给下一个智能体**
   - 从结构化响应中提取必要信息
   - 根据 changeSummary 组织提交信息并执行 git commit
   - 需求变更时明确整合初始需求与追加需求

   #### 收敛记录 → 携带它的智能体

   **传递**：将编排者判断的 `convergence` 记录传递给负责将其向后传递的任何智能体。原样传递；每个字段的就绪度标签随其一起传递。
   - **prd-creator**（创建或更新 PRD 时）：将 `outcome` 写入“成功标准”，将用户撰写的 `nonGoals` 写入“范围外”；PRD 包含已确认的需求和边界，而评估性请求、设想性想法和未被选中的机制仅保留在确认前的收敛上下文中
   - **technical-designer / technical-designer-frontend**：在不存在 PRD 时将同样的内容写入设计文档的“需求收敛”，并始终在其中记录被标记为 `weak-but-explicit` 的字段
   - **ui-spec-designer**（前端/全栈）：接收已确认的 UI 需求和用户撰写的 `nonGoals`；未被选中的候选项不产生任何 UI 规范内容
     - 当存在 `prototype_path` 时，同时传递 `prototype_reference_strength`：若实现应遵循原型的呈现，则为 `binding`；若只有 UI 规范记录的内容才进入实现，则为 `reference`。根据用户已就该原型作出的说明判断；只有两种解读都缺乏依据时才询问
   - **work-planner**：将 `nonGoals` 视为排除在每个任务条目之外；未被选中的候选项不产生任何规划义务。在 Small 规模下不产生工作计划，因此按照存储协议，`weak-but-explicit` 字段保留在编排者自身的上下文中，而不会成为执行者提示中的阻塞项

   #### codebase-analyzer → technical-designer

   **传递给 codebase-analyzer**：仅一个约束来源——存在时为已批准的 PRD 路径，否则为已确认的需求
   **传递给 technical-designer**：codebase-analyzer 的 JSON 输出，作为设计文档创建提示中的附加上下文。下游必需用途：
   - `focusAreas` → 事实处置表的规范处置目标列表（每个 focusArea 一行，原样携带 `fact_id` 和 `evidence`）
   - `simplifications` → 所记录条件成立的条目，作为缩减新增实现范围的材料；编排者在范围确认的停止点提示该列表，并原样传递
   - `dataModel`、`dataTransformationPipelines`、`qualityAssurance` → 现有代码库分析和验证策略章节

   #### code-verifier → document-reviewer（设计文档评审）

   **传递给 code-verifier**：设计文档路径（doc_type: design-doc）。省略 `code_paths`；验证者独立地从文档中发现代码范围。
   **传递给 document-reviewer**：仅在验证已运行时，将最新的 code-verifier 结果及已记录的评审裁定处置作为 `verification_evidence`；否则省略此输入。始终传递之前提供给设计者的同一份 codebase-analyzer JSON 作为 `codebase_analysis`、约束来源作为 `confirmed_requirement_context`，以及适用时的原始请求作为 `requirements_verbatim`。评审者使用 `codebase_analysis.focusAreas` 验证事实处置表的覆盖情况，并使用已确认需求上下文验证文档的结果和契约。

   #### 处置为 `apply` 的设计依据发现 → technical-designer

   **传递给所属设计者**：使用现有设计文档路径和完整的 `correction_findings`（原样复制，仅添加其 `apply` 处置）调用一次新的 `update`。该产物携带已批准的需求、已接受的决策、先前的依据以及未受影响的设计上下文；不添加任何编排者撰写的设计指令。设计者应用“评审触发的有界自我验证”，并根据已确立的依据更新产物。编排者只在更新完成后才重新运行发起验证或评审的智能体。

   #### code-verifier + document-reviewer → 下一层 technical-designer（仅跨层流程）

   **传递给下一层 technical-designer**：传递已评审的上一层设计文档路径，并仅在上一层 code-verifier 已运行时传递 `prior_layer_verification`。参见“跨层编排”章节了解顺序安排。使用可用的验证差异和上一层评审发现识别不稳定契约。将已验证声明的推断限制在实际依据所支持的范围内；当设计依赖未经验证的声明时，在前端设计文档的“跨层假设”一节中记录理由和验证目标。仅当该依赖无法通过下游验证步骤加以约束时才上报。

   #### technical-designer → work-planner

   **传递给 work-planner**：设计文档路径。work-planner 将约束性章节和验收标准映射为实现任务。未覆盖的已选中义务是需要修正的规划遗漏；工作计划不会将缺失的覆盖或缺失的设计内容变成用户确认项。

   #### *1 acceptance-test-generator → work-planner

   **传递给 acceptance-test-generator**：设计文档路径；UI 规范路径（若存在）。

   **编排者验证**：`generatedFiles[]` 中的每个路径都在磁盘上存在。空列表也是有效的生成结果。

   **传递给 work-planner**：生成的路径。work-planner 会将每个骨架分配给它最早能够执行的任务。
3. **ADR 状态管理**：用户作出决定后，以更新模式调用负责的技术设计者，设置每份 ADR 的状态（Accepted/Rejected）

## 重要约束

- **提交边界**：Normal 模式的任务提交和质量检查产生的修正提交，需要 quality-fixer 返回 `pass` 或 `verification_incomplete`。Lite 模式的任务提交在受理执行者结果和必需的测试评审结果后进行；最终质量检查在实现后评审之前运行。仅在所调用配方定义的提交点提交
- **结构化响应**：子智能体之间传递的信息使用已声明的 JSON 字段
- **批准管理**：文档创建之后，进入下一阶段前需经过 document-reviewer 和已命名的用户批准停止点
- **流程确认**：批准后，从已确认的 Large/Medium/Small 规模流程中选择下一步
- **一致性验证**：当子智能体输出发生冲突时，应用决策优先级（参见“委派边界”章节）

### 实现后评审状态路由

| 评审者 | 完成：空发现集合 | 进入评审裁定 | 阻塞 |
|----------|---------------------------|-------------------------|---------|
| code-reviewer | `verdict` 为 `pass` | `verdict` 为 `needs-improvement` 或 `needs-redesign` | `verdict` 为 `blocked` → 应用“专家结果受理” |
| security-reviewer | `status` 为 `pass` | `status` 为 `needs_revision` | `status` 为 `blocked` → 应用“专家结果受理” |

评审者的发现是候选项。只从评审裁定的 `apply` 集合中创建修正工作。

**修正周期交接**：应用评审裁定并调用其选定的每个修正负责人。对于作者所属的技术产物修正，以更新模式调用相应层级的技术设计者，运行该产物现有的 document-reviewer 和适用的 design-sync 检查，然后重新运行发起该评审的评审者。对于执行者所属的修正，用其原始的 `task_file` 或直接范围字段，加上作为完整 `apply` 发现对象（原样，仅添加其处置）的 `correction_findings`，调用相应层级的执行者，然后按每个任务循环的步骤 2（包括其中视条件执行的 integration-test-reviewer 路径）对执行者结果分支，并运行适用的质量检查。当同时需要两方负责人时，由评审裁定的作者优先重新评估机制来控制顺序。仅将 `prior_feedback` 传递给复核评审者。

**重新运行规则**：评审者返回的通过（passing）结果保持有效。只重新运行其最新结果中已应用修正的那个评审者，并将已记录的处置作为 `prior_feedback`、连同重新推导的实现文件集合一起传入，使其针对修正后的状态进行复核。恢复被阻塞的评审前置条件后，重新运行相应评审者。是否接受修正由评审裁定的收敛机制决定，已解决的拒绝项保持有效。

## 参考资料

- `references/review-resolution.md`：发现项的处置、修正与收敛
- `references/lite-mode.md`：Lite 模式的调用集合与最终质量检查