---
name: multi-review
description: Use when Nucleus 工件、计划、代码变更、测试资产或交付证据需要独立领域审查。
---

# 多角色独立评审

## 核心原则

评审报告只能记录审查发现，不能制造人工批准、PMS 状态、PR 审查通过、合入或发布事实。

<HARD-GATE>
未确定评审领域、未读取被评审产物、或评审发现阻塞项未整改复核时，不得把下游 task 标记完成。
</HARD-GATE>

## 评审领域

按产物类型读取对应 reference：

- 需求分析：`references/requirement-analysis-review.md`
- 方案设计：`references/solution-design-review.md`
- 需求分解：`references/requirement-decomposition-review.md`
- 特性设计：`references/feature-design-review.md`
- 实施计划：`references/implementation-plan-review.md`
- 代码：`references/code-review.md`
- 测试资产：`references/test-asset-review.md`
- 交付证据：`references/delivery-evidence-review.md`
- 特性完成：`references/feature-completion-review.md`

无法确定领域时，先读上下文并提出一个明确问题，不得默认用代码评审代替设计评审。

## 客观评审纪律

方案一致性评审不是机械要求实现逐字贴合原方案。评审者必须判断：

- 实现是否满足特性设计和实施计划承诺的能力、边界、接口、数据、权限和验证要求。
- 实现差异是必要改进、等价实现、计划外扩 scope，还是破坏原方案约束。
- 如果实现明显更简单、更稳健或更符合现有架构，且没有越界或遗漏，应保留实现，并记录“实现优于原方案”的证据和后续是否需要同步设计 / 计划。
- 如果实现改变了用户可见能力、数据 / 接口 / 权限边界、外部依赖或风险假设，必须阻塞并要求回到计划或特性设计评审节点，不能由 reviewer 直接批准扩 scope。

## 输出纪律

评审必须区分：

- `blocking`：阻塞下游任务。
- `important`：进入下游前应处理。
- `suggestion`：可记录但不阻塞。
- `unverifiable`：当前证据无法判断，需要人工或外部系统确认。

特性开发完成后的评审必须同时覆盖：

- code-review。
- 方案一致性评审。
- 计划满足度评审。

向用户呈现评审结果时，按 `_shared/references/interaction-format.md` 的确认型格式，第一句先给结论（通过 / 有阻塞 / 需整改），再展开 findings。

## 子代理预审

所有人工审查 / 人工评审 / 人工复核节点在提交给人之前，必须先按 `_shared/references/subagent-precheck-protocol.md` 调度独立 reviewer 子代理完成预审，并取得“材料可提交人工审查”结论；子代理 prompt 基于 `references/subagent-review-prompt.md` 组织。

<HARD-GATE>
人工审查点缺少 `subagentPreReview.required=true` 前置元数据时，不得进入该人工审查点；子代理发现 `blocking` 或 `important` 后，必须先整改并用新的独立 reviewer 复核，未复核前不得把下游 task 标记完成。
</HARD-GATE>

`multi-review` 自身的 review report 仍只记录发现、风险、整改建议和复核证据，不能替代人工审批、PMS 状态、PR 审查通过、合入或发布事实。

## Runtime 边界

`scripts/multi_review.py` 只校验 review report schema 和语义，不创建评审结论、不替人审查、不改代码。