recipe-front-review

用户明确指示：用户明确指示并授权本流程中提及的每次子 Agent 调用。满足前置条件时，执行每次适用的调用。

在编写 Agent 提示词、交接内容或生成的产物之前，执行 Skill：llm-friendly-context。 在制定工作流决策、调用 Agent 或处理审查发现之前，执行 Skill：subagents-orchestration-guide。

上下文：React/TypeScript 前端实现后的质量保证

编排器定义

核心身份：「我是编排器。」（参见 subagents-orchestration-guide skill）

本地权限关卡：制定本流程的工作流决策，并直接验证每项返回结果；将语义交付物的产出委派给指定的专业人员。

审查处理关卡 [MANDATORY]：在修正或继续之前，必须通过 subagents-orchestration-guide 的 Review Resolution 处理每项可执行的交付物审查发现。 处理首项发现之前，先读取已加载的 subagents-orchestration-guide skill 中的 references/review-resolution.md。

执行关卡：按顺序完成步骤 1-10，仅遵循由各步骤所述条件触发的分支。仅在达到声明的收敛条件时，才推进各项审查、修正和重新验证环节。所有适用发现和保留的质量限制都达到所需处理状态或重试结果后，方可提交最终报告。

执行方式

• 实现审查 → 由 code-reviewer 执行
• 安全验证 → 由 security-reviewer 执行
• 代码侧修复路径：修复实现 → task-executor-frontend；质量检查 → quality-fixer-frontend；重新验证 → code-reviewer / security-reviewer
• 设计侧更新路径：修订 DD → technical-designer-frontend（更新模式）；DD 审查 → document-reviewer；DD 间一致性检查 → design-sync（存在多个 DD 时）；重新验证 → code-reviewer

当 Design Doc 对所需结果已过时、过于冗长或不正确时，适用设计侧路径。两种路径都不会默认将现有实现或先前的设计视为权威依据。

在下方每次调用 Agent 时，按机械式提取方式构建提示词：将指定源值复制到对应字段，仅应用声明的序列化方式，然后立即调用。

Design Doc：$ARGUMENTS

执行流程

步骤 1：前置条件检查

根据当前分支与仓库默认分支的合并基点到当前仓库状态之间的路径差异，推导 implementationFiles，包括已提交的更改、工作树中的更改和未跟踪文件。implementationFiles 包含内容用于实现或验证被审查行为，或控制其架构、构建、部署或运行时行为的每个变更路径，包括源文件、测试、迁移、可执行脚本以及会影响行为的配置。治理文档和 Work Plan 保留其在文档选择和治理文档输入中的专属角色；任务文件和仅文档类路径不属于本流程的代码审查和安全审查输入。

使用 $ARGUMENTS 中明确提供的 Design Doc。如果未提供，首先使用其声明的目标文件或职责与 implementationFiles 有交集的 Work Plan，并采用其中记录的 Design Doc 路径。如果这样未能确定唯一候选项，则使用 docs/design/ 下唯一的 Design Doc。仅当仍有多个治理 Design Doc 时，才列出候选项；如果没有，则报告缺少前置条件。

步骤 2：执行 code-reviewer

使用 Agent 工具调用 code-reviewer：

• subagent_type：「dev-workflows-frontend:code-reviewer」
• description：「已完成的前端实现审查」
• prompt：「审查已完成的前端实现。governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]。返回初始审查 JSON。」

将输出存储为：$STEP_2_OUTPUT

步骤 3：执行 security-reviewer

使用 Agent 工具调用 security-reviewer：

• subagent_type：「dev-workflows-frontend:security-reviewer」
• description：「安全审查」
• prompt：「governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. Review security compliance.」

将输出存储为：$STEP_3_OUTPUT

步骤 4：裁定与响应

当任一审查者返回受阻或其他不可用结果时，根据其语义原因应用 subagents-orchestration-guide Specialist Result Acceptance。报告中仅保留尚未解决的验证限制。

在报告或转交前，对两个输出应用 Review Resolution Gate。由发现项的处理决定转交方向。

对于每个 apply 发现项，按照以下规则计算建议的转交方向。每个发现项选择一个方向；如果所选的删减同时移除一项设计陈述及其授权的实现，则同时选择 d 和 c：

发现项模式	建议的转交方向
解决方案保留当前实现，因为它符合原始要求，并更正了过时的 Design Doc	d（设计侧更新）
解决方案要求更改实现以达到认可状态	c（代码侧修正）
解决方案移除 Design Doc 选定、但实现所需结果并不需要的机制	d 和 c（先处理设计陈述）

随后向用户呈现裁定结果。按建议的转交方向对 apply 发现项分组，并列出已拒绝的 ID 及其原因：

Implementation Review: [verdict from code-reviewer]
  Acceptance Criteria:
  - [fulfilled] [item]: [evidence]
  - [unfulfilled] [item] -> [corresponding finding ID under Required Corrections]
  Required Corrections:
  - [id] [category] [location]: [description] — [basis and effect] [recommended: c | d | d and c]
  Limitations:
  - [unverified judgment and effect]

Security Review: [status from security-reviewer]
  Findings by category:
  - [confirmed_risk] [location]: [description] — [rationale] [recommended: c]
  - [defense_gap] [location]: [description] — [rationale] [recommended: c]

Approve the proposed changes:
  c) Code-side correction — change implementation to reach the accepted state
  d) Design-side update   — correct a stale, excessive, or incorrect Design Doc
  d and c) Reduction     — delete the selecting design statement, then remove the implementation it authorized
  s) Decline              — record the governing reason and accept current state

此审查命令仅授权分析；使用 AskUserQuestion 获取单独的实现授权。批量选项为 “批准所有建议的 apply 转交方向”，其范围仅包括这些转交方向。当批准的变更集为空时，直接进入步骤 10。

将已批准的发现项、转交方向、涵盖的文件／章节以及任何声明的总规模预算传递给更新或修复 Agent。重新验证前，将每个差异区块对应到已批准的发现项或必要的一致性更新。移除意外且无法对应的变更；如果必要变更会改变已确认的值边界或明确的规模限制，则返回 Requirement Change Detection。

步骤 5：设计侧更新

仅当用户将至少一项发现路由到 d 时才运行此步骤。没有 d 路由时，跳过此步骤；仅当仍有已批准的 c 路由时，才继续执行步骤 6。

1. 使用 Agent 工具，以更新模式调用 technical-designer-frontend：

   • subagent_type："dev-workflows-frontend:technical-designer-frontend"
   • description："根据评审发现更新设计文档"
   • prompt："以更新模式更新位于 [path] 的设计文档。将以下发现应用于设计：[来自 $STEP_2_OUTPUT 的完整 d 路由发现对象，除已批准的路由外保持不变]。对于接受当前代码的发现，在相关章节中反映该行为；对于删除不必要机制的发现，删除选择该机制的相关陈述。添加一条历史记录。"

2. 调用 document-reviewer 验证更新后的设计文档：

   • subagent_type："dev-workflows-frontend:document-reviewer"
   • description："评审更新后的设计文档"
   • prompt："检查位于 [path] 的更新后设计文档，确认其一致性和完整性。doc_type: DesignDoc. review_context: update."
   • 通过其修正复审和收敛转换运行 Review Resolution Gate。对于重新路由的修正，使用 technical-designer-frontend。只有满足其收敛条件后才能继续。

3. 当 docs/design/ 下存在多个设计文档时，调用 design-sync：

   • subagent_type："dev-workflows-frontend:design-sync"
   • description："跨设计文档一致性检查"
   • prompt："source_design: [更新后的设计文档路径]"
   • 当 sync_status: CONFLICTS_FOUND 时，应用 Review Resolution Gate，并遵循其有界验证器交接和收敛规则。

4. 步骤 5 完成后：

   • 如果用户对所有发现都选择了 d（没有 c 路由）→ 跳过步骤 6-7，继续执行步骤 8 进行重新验证
   • 如果用户同时选择了 d 和 c → 根据更新后的设计文档重新评估 c 路由的发现，并剔除已由设计文档修订解决的发现；仅更新设计文档并不能满足要求移除代码的发现。然后，携剩余的 c 发现继续执行步骤 6

步骤 6：执行修复

使用 Agent 工具调用 task-executor-frontend：

• subagent_type："dev-workflows-frontend:task-executor-frontend"
• description："执行评审修复"
• direct_scope：在已确认的评审范围和规定的总量预算内应用已批准的前端修正
• governing_sources：经评审的设计文档、适用的 UI Spec，以及已接受的需求或 ADR 路径
• target_paths：已确认为获批代码侧路由所涉及的实现和测试路径
• observable_verification：发现和规范中指定的针对性 UI 行为测试或可观察契约检查均通过
• correction_findings：完整的评审发现对象，逐字保留，仅添加编排器处置结果

步骤 7：质量检查

使用 Agent 工具调用 quality-fixer-frontend：

• subagent_type："dev-workflows-frontend:quality-fixer-frontend"
• description："质量门禁检查"
• 原样复制步骤 6 中的 direct_scope、governing_sources、observable_verification 和 correction_findings 输入。
• 传入步骤 6 的 mutationEvidence。

处理 quality-fixer-frontend 的结果：

• pass → 继续执行步骤 8
• stub_detected → 携 incompleteImplementations 原样返回步骤 6，然后重复步骤 7
• verification_incomplete → 保留完整结果并继续执行步骤 8
• blocked → 应用 Specialist Result Acceptance

步骤 8：重新验证 code-reviewer

在调用之前，立即根据步骤 1 的纳入规则重新推导 implementationFiles，确保其中包含经批准的修正所添加或更改的实现工件。

使用 Agent 工具调用 code-reviewer：

• subagent_type："dev-workflows-frontend:code-reviewer"
• description："重新验证前端实现审查"
• prompt："在经批准的修正后，重新审查已完成的前端实现。governingDocuments：["[path]"]. implementationFiles：[implementationFiles]. prior_feedback：[{id, disposition, reason?, evidence}]。逐项协调所有收到的反馈。"

步骤 9：重新验证 security-reviewer

在调用之前，立即根据步骤 1 的纳入规则重新推导 implementationFiles，确保其中包含经批准的修正所添加或更改的实现工件。

当 subagents-orchestration-guide 的实施后重新运行规则要求获取最新安全结果时，使用 Agent 工具调用 security-reviewer：

• subagent_type："dev-workflows-frontend:security-reviewer"
• description："重新验证安全性"
• prompt："修复后重新验证安全性。governingDocuments：["[path]"]. implementationFiles：[implementationFiles]. prior_feedback：[{id, disposition, reason?, evidence}]。根据审查者的重新审查范围，逐项协调所有先前事项。"

在进入步骤 10 之前，对步骤 8 和步骤 9 的每项结果应用 Review Resolution Gate。遵循其 maintained 转换；修正被重新路由后，重复受影响的验证；当 Review Resolution 退出并转至上级要求或权威门槛时，应用该要求或门槛；在达到其收敛条件时继续。

步骤 10 之前，使用相同的步骤 7 输入和受影响的检查，对每项保留的 quality-fixer-frontend 限制再重试一次。重试返回 pass 时，从保留状态中移除该限制。通过步骤 6-9 处理新发现的未完成实现，并报告重复出现的 verification_incomplete 结果。如果重试更改了代码库，则在报告之前，对更改后的代码重复步骤 8-9。

步骤 10：最终报告

提交最终报告：

Implementation Review:
  Initial: [verdict from code-reviewer]
  Correction review: [verdict for the re-review scope] (if fixes executed)
  Reconciliation: [resolved / withdrawn / maintained by finding ID]

Security Review:
  Initial: [status]
  Correction review: [status for the re-review scope] (if fixes executed)
  Reconciliation: [resolved / withdrawn / maintained by finding ID]

Quality Check:
  Final: [pass / verification_incomplete / not_run when no code-side fixes were selected]

Remaining proof limitations:
- [reason — affected check and evidence] (only when repeated after retry)

Declined actionable findings:
- [ID: governing reason — evidence] (only when any were declined)

Remaining issues:
- [items requiring manual intervention]

范围：已完成前端实现审查、安全审查，以及经用户批准的修正路由。