version: "1.0.0"

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 和语义，不创建评审结论、不替人审查、不改代码。