技术评审 Checklist

本 skill 用于架构设计阶段的技术评审，确保设计方案在提交 Gate 前经过系统化的质量检查。可独立使用。

循环角色

版本背景：本循环语义于 0.65.0 引入；本标题是稳定规范，不随版本号变更。

角色映射： 在目标 Loop 模型中，本审查对应技术深度子迭代 Middle loop 的 loop-entry-gate。0.66.1 的当前运行能力仍是 experimental scaffolding；该映射不表示持久化 Loop runtime 已激活。

当前可执行行为仅为 Coordinator M7.4 的 NEEDS_CHANGE -> 返工 -> 复审，以及 Check 30 对复审链终态、轮次连续性和熔断结果的校验。

持久化 back-edge、flow-unit loop_count、Middle fuse、PARO transition 与自动升级属于 0.68.0 规划，当前不生效。

Reviewer 只审查并输出结论，不修改产品代码。Reviewer 必须输出 APPROVED、APPROVED_WITH_NOTES、NEEDS_CHANGE 或 BLOCKED；APPROVED_WITH_NOTES 是保留备注的通过终态，只能用于没有未解决 BLOCKING finding 的审查，不得包含未解决的 BLOCKING finding。APPROVED_WITH_NOTES 的审查输出与 REVIEW 证据 MUST 包含独立结构字段 unresolved_blockers=0；字段缺失、非零、非法或重复矛盾时不得通过，自然语言中偶然出现的 blocking 不构成该事实。NEEDS_CHANGE（及兼容输入 NEEDS_CHANGES）不是终态，Coordinator 必须在返工后发起下一轮复审。终态证据由 Check 30 的复审链消费：APPROVED 与 APPROVED_WITH_NOTES 可以通过并结束复审链；BLOCKED 结束链路但不是通过，必须 escalation；NEEDS_CHANGE(S)、未知或格式错误结论必须 fail-closed。超过复审 fuse 的 NEEDS_CHANGE 必须升级为 BLOCKED。

依据 ADR §3.5（loop-engineering-architecture-0.65.0）。完整映射见 共享循环角色映射。

触发条件

• 架构设计文档已完成，需要提交评审
• 概要设计或详细设计完成一个重要模块
• 用户要求对当前设计进行审核

输入

执行步骤

第一步：结构完整性检查

参考 Google Design Doc：设计文档必须包含目标、方案、替代方案、风险四个核心部分。

第二步：架构质量检查

严重级别说明：

• 阻塞：必须修改才能通过评审
• 关键：强烈建议修改，可在评审中标记为"有条件通过"
• 一般：建议修改，不阻塞通过

第三步：非功能需求映射检查

输出：非功能需求映射表

第四步：蓝军挑战（华为蓝军机制）

参考华为蓝军机制，从反对者视角挑战设计。

单 agent 蓝军协议（结构化视角切换——agent 同时担任红军和蓝军）：

蓝军执行前 MUST 执行以下视角切换序列：

Step 1: 框架切换
  从 "这个设计为什么是对的" → "这个设计最可能在哪里失败"
  列出设计中隐含的 3 个核心假设

Step 2: 角色扮演
  依次用以下 3 个角色的视角审查设计：
  (a) 攻击者视角："如果我想让这个系统瘫痪，我会攻击哪里？"
  (b) 最愤怒的用户视角："什么会让我卸载这个产品？"
  (c) 维护者视角："接手这个系统一年后，什么会让我想重写？"

Step 3: 场景推演
  对每个角色，追问 "如果 X 发生，后续 3 步是什么？"
  不只问"会不会出问题"——推演"出问题之后的第一块多米诺骨牌是什么"

蓝军挑战问题（≥3 个必答）：

蓝军输出标准格式（每个挑战问题必须按此格式记录）：

strict profile 要求：蓝军 MUST 完成完整视角切换序列 + ≥3 个挑战问题（含标准格式输出）+ 设计方的逐条回应记录。

第五步：独立评审人（Bar Raiser）— 强制

参考 Amazon Bar Raiser 机制，技术评审必须引入至少 1 位项目外部的独立评审人。

独立评审人资格要求：

• 非当前项目组成员（不在 plan-tracker 的 DRI 列表中）
• 具备对应领域知识（能理解架构决策的技术含义）
• 无项目进度压力（不因"赶时间"降低标准）

独立评审人职责：

• 独立审查设计文档，不受项目组内部意见影响
• 有权对评审结论行使否决权——如果标准不达标，可以单方面阻止 Gate 通过
• 否决必须附带具体的否决理由和解除条件（什么情况下可以撤销否决）

单 agent 场景下的最低标准：

• Agent 必须从"对立面分析框架"重新审查设计（切换视角：从"为什么这样设计是对的"→"这个设计最可能在哪里失败"）
• 至少挑战 3 个核心假设（如"假设 X 服务永远可用""假设数据量不超过 Y"）
• 独立评审结论必须在切换分析框架后得出——不得复用同一分析框架

第六步：评审结论

输出

质量标准

• 结构完整性 4 项检查全部通过
• 无阻塞级别的架构质量问题
• 非功能需求映射表完整（每条需求有对应措施）
• 独立评审人已指定且满足资格要求（非作者、非同一 agent、具备领域知识）
• 评审结论有明确理由；如有否决，否决理由和解除条件已记录

独立使用说明

本 skill 可脱离完整生命周期独立使用。

如果项目已初始化 governance（.governance/ 存在）

1. 先执行目标锚定检查（读 plan-tracker → 确认成功标准 → 偏离检查）
2. 不需要先通过任何 Gate
3. 可用于任何设计文档的评审（不限于架构设计阶段）
4. 如果后续接入完整工作流，本 skill 的产出自动成为 G5（设计完成）的证据

如果项目未初始化 governance（.governance/ 不存在）

1. 跳过所有治理前置检查
2. 直接执行本 skill 的核心流程（设计文档审查 + 蓝军挑战 + 评审结论）
3. 执行完毕后提醒用户："当前项目未初始化 governance。如需自动证据记录、Gate 检查、风险跟踪，运行 /governance-init。"

子工作流映射