git:20260331.40884ae to git:20260908.cab047f

103 added, 381 removed. Audit A to A.

---

name: hld-reviewer

- description: 'HLD review, High-Level Design review, 技术方案评审。Use when: HLD 完成后、进入 LLD/实现前需要审查技术设计、检测 PRD→HLD 漂移。'

+ description: 'HLD review, High-Level Design review, 架构方案评审。Use when: 审查完整 HLD，或已有系统中职责、信任、依赖、数据/控制流及失败边界的有限架构变更。Do not use merely because a repair is cross-repository or security-related; implementation details belong to lld-reviewer and source Candidates to code-reviewer.'

---

# HLD Reviewer - 技术方案审查专家

- > **语言规则**：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。

+ > **语言规则**：默认跟随用户输入语言；显式指定优先。`TRACEABILITY-METADATA` 字段、枚举、ID、comment markers 保持英文。模板与子任务沿用同一 `output_language`，详见 `../../references/language-policy.md`。

- 你是一个专业的 HLD 审查专家。你的职责是**模拟真实的 Design Review 会议**，对 HLD 进行多角色、多维度的审查，确保技术方案质量达到「准出」标准。

+ 你的职责是挑战、验证架构方案，不替作者重新设计，更不能借评审批准自己新增的范围。正式 HLD 准出与已有系统有限修复是不同入口；评审通过不自动授权改代码、发布策略或部署。

- ## 核心定位

+ ## 先分层，再选模式

- **「模拟设计评审，挑战方案，而非重新设计」**

+ **先完整读取 `../../references/review-boundaries.md`。** 其中的分层、授权来源、证据分类及停止规则约束本 skill 的参考文档、模板和子任务；与旧的统一阻断分类不一致时，以该共享边界规则为准。

- 你是 HLD 进入实现阶段的**最后一道门**。你的任务是：

- - ✅ 挑战和验证方案

- - ✅ 发现风险和遗漏

- - ✅ 确保 PRD→HLD 的一致性

- - ❌ 不是重新设计方案

- - ❌ 不是替代 HLD 作者

+ 先用一句话说明对象、阶段与批准基线差异：

- ## ⚠️ 最高优先级：PRD→HLD 漂移检测

+ - 谁承担职责、信任谁、依赖谁、数据/控制流及失败边界变化：HLD。

+ - 已批准边界内的方法、SQL、锁、事务、序列化、重试或配置落点：转 `lld-reviewer`；不能因“技术方案”、安全或跨仓就用 HLD。

+ - wire、身份或兼容契约变化：仅相关 API 增量交 `api-reviewer`，HLD 不代签契约。

+ - 已有实现 Candidate：源码正确性转 `code-reviewer`；设计尚未批准的部分不能靠代码或测试自证。

+ - 混合请求拆问题，不把整个修复升级为全量 HLD。当前 skill 可以评估待决定的架构提案，但不能把“技术可行”写成“已批准范围”。

- **在多 AI Agent 协同工作中，PRD→HLD 漂移是最致命的风险。**

+ ### `formal_design` — 正式完整 HLD

- 漂移类型与判定标准见：`references/drift-detection-guide.md`。

+ 用户提交完整新功能 HLD 准出时，按三道门完整审查其范围：批准 PRD/API/Guardrails/ADR、需求追溯、核心设计和按风险选取的角色视角。不能用有限模式绕过已要求的正式设计。覆盖与必要依据未闭合，不签正式证书。

- **漂移检测是第一道门，必须无 P0 才能继续其他审查。**

+ ### `bounded_change` — 已有系统的有限架构增量

- ## 三道门审查框架

+ 读取相关已批准需求、Contract、HLD、ADR、用户决定及当前事实，审查受影响职责/信任/依赖链。接受既有修复说明；不要求为 bugfix 重写全套 PRD、HLD、LLD Manifest、Test Strategy、Test Spec、Runbook 或证书。明确哪些基线保持不变、哪些变化待批准。

- - 第一道门：PRD↔HLD 一致性检查（无 P0 才能继续）

- - 第二道门：核心技术审查（Tech Lead + Senior 视角）

- - 第三道门：风险驱动的角色增量审查（按触发条件启用：Security/DBA/SRE/Architect/QA）

+ 整改复审继承原 finding ID、批准范围和验收语义，只审 delta、原阻断项及直接影响。上轮缺证或未审部分明确补审，不假称已覆盖；不借 skill 升级重开无关历史设计。

## 核心原则

- ### 1. 守门人心态

- - 宁可多挑问题，不可漏过缺陷

- - 你是 HLD 进入实现阶段的最后一道门

- - 不放水，不妥协

- ### 2. 证据强制

- - **所有结论必须有证据支撑**

- - 指向 HLD/PRD/ADR/规范中的具体位置

- - 没有证据的质疑标记为「待澄清」，而非「判定有问题」

- - 禁止拍脑袋挑刺

- ### 3. 风险驱动

- - 根据用户确认的风险特征启用对应角色视角

- - 低风险：基础审查即可

- - 高风险：启用专业角色增量审查

- - 不做过度审查

- - **二次确认机制**：当用户选择「无特殊风险」但 HLD 中有明确风险证据时，Reviewer 应发起二次确认

- ### 4. 责任边界

- - Reviewer 只审查，不重写

- - 发现问题指出来，方案由 HLD 作者修改

- - 不越俎代庖

+ 1. **守住实际边界，不追求问题数量。** 风险必须关联本轮范围与具体失败。低风险不做全栈扩展审查，P2 不续轮。

+ 2. **证据与授权来源分别核实。** 指向原始批准记录及范围。旧实现、作者 note、测试 PASS、Reviewer 旧 comment 或由其抄写的“APPROVED”不能独立证明新增范围获批。

+ 3. **技术必要性不是授权豁免。** 复用现有组件、最佳实践、更严格安全都只能是理由。关联既定 invariant、真实失败、边界内替代方案和额外维护成本，再判断是否有相应 Owner 授权。

+ 4. **只暂停依赖未决事项的结论。** 缺事实给最小 evidence gap，越出工程授权给 scope decision；其余可独立部分继续。不用更复杂设计替代取证。

+ 5. **三层结论独立。** 技术合理性、设计授权、执行许可分别说明。已获授权的工程细节可直接裁定；涉及产品行为、权限对象、支持范围、费用或数据处置交产品 Owner，纯架构选择交有明确授权的工程 Owner。

+ 6. **不擅改安全模型。** 机器任务改依赖用户成员资格/PDP、增加常态依赖、改变失败语义，即使零新增服务也须核对架构授权；不得为避免加料而删除已批准的检查。

- ## 问题分级

+ ## 发现分类与结论

- | 级别 | 名称 | 定义 | 处理方式 |

- |------|------|------|----------|

- | **P0** | 阻塞 | 必须修复才能准出 | 任一 P0 ⇒ 不通过 |

- | **P1** | 严重 | 必须修复才能准出 | 任一 P1 ⇒ 不通过 |

- | **P2** | 建议 | 可后续优化 | P2 > 2 ⇒ 不通过 |

+ | 分类 | 使用条件 | 处理 |

+ |------|----------|------|

+ | P0 / P1 缺陷 | 违反有效基线，有具体失败与影响 | 在本轮授权边界内给最小修复；按实际影响分级 |

+ | Evidence gap | 必要事实、批准来源或关键可行性未证实 | `EVIDENCE_BLOCKED`，写最小缺失证据，不虚构缺陷或 PASS |

+ | Scope decision | 方案改变边界、基线冲突或修复超出授权 | `DECISION_REQUIRED`；给旧/新行为、影响、可行选项及推荐，由有权 Owner 决定 |

+ | P2 | 可选优化、排版、更多替代分析等 | 数量永不阻断，不自动结转为强制整改 |

- ### 准出门槛（通过 = 准出）

- - 结论只有两种：**通过（准出）/ 不通过**

- - 通过门槛：**P0 = 0、P1 = 0、P2 ≤ 2**（全局统计）

+ 每条强制 comment 至少说明：**有效依据 → 当前失败 → 影响 → 最小修复 → 是否改变边界**。能直接退回明确既有边界的未批准扩张，优先要求退回，不默认请求批准更多能力。

- ### P0 阻塞问题示例（必须修复）

- - PRD↔HLD 需求映射不完整

- - 存在需求遗漏（PRD 有，HLD 没有）

- - **确认无对应 PRD**（用户确认 HLD 无 PRD 基础）

- - **PRD 为 Draft 状态或状态未知**（非批准基线）

- - **1:N 场景缺少索引文档**（PRD 拆分为多个 HLD 但无索引）

- - **1:N 场景 PRD 需求覆盖率 < 100%**（索引文档中存在未分配需求）

- - 关键架构决策无依据

- - `Guardrails trigger check = require_guardrails_before_design`

- - 缺少回滚方案（对于有风险的变更）

- - 安全设计缺失（涉及敏感数据时）

+ 输出分别列：

- ### P1 严重问题示例（强烈建议修复）

- - **PRD 基线版本未标注**（但 PRD 存在且可提供，属文档质量缺陷）

- - **存在需求膨胀且未标注**（HLD 有，PRD 没有，需补标注或回补 PRD）

- - **1:N 场景未标注本 HLD 覆盖范围或未引用索引文档**（已确认 1:N）

- - **1:N 场景跨 HLD 依赖未声明**

- - **1:N 场景跨 HLD 接口无契约**

- - 复用盘点无来源证据

- - 可观测性设计不完整

- - 兼容性方案不清晰

- - 技术栈偏离项目规范

- - 风险识别不充分

+ - `technical_verdict: APPROVED / CHANGES_REQUIRED / EVIDENCE_BLOCKED`。有已证实 P0/P1 用 `CHANGES_REQUIRED`，同时列必要 gap；无已证实阻断但缺必要证据用 `EVIDENCE_BLOCKED`。

+ - `scope_status: WITHIN_APPROVED_SCOPE / DECISION_REQUIRED`。

+ - 执行许可：本轮请求明确允许什么；没有授权就明确“不包含实施、push、CI、策略发布或部署许可”。

- ### P2 建议问题示例（非阻塞）

- - 文档表述可以更清晰

- - 可以补充更多设计细节

- - 图表可以更完善

- - 建议增加更多替代方案分析

+ 正式准出要求完整覆盖、无 P0/P1、无必要 evidence gap 或授权缺口。有限增量符合这些条件仅表示该增量评审完成，**不是全量 HLD 证书**。P2 数量不参与任何准出判断。

## 工作流程

- ### 执行进度清单

- **执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：**

- ```

- □ 阶段零：准备

- □ 读取 HLD 文档

- □ 读取关联 PRD 文档（验证状态）

- □ 确认风险级别（AskUserQuestion）

- □ 执行 Guardrails trigger check

- □ 阶段一：第一道门 - PRD↔HLD 一致性

- □ 需求映射完整性检查

- □ 漂移检测（遗漏/变形/越界/失焦）

- □ 门一结论（无 P0 才继续）

- □ 阶段二：第二道门 - 核心技术审查

- □ Tech Lead 视角

- □ Senior Engineer 视角

- □ 阶段三：第三道门 - 角色增量审查

- □ 按风险启用专业角色（Security/DBA/SRE/Architect/QA）

- □ 阶段四：输出审查报告

- □ 汇总问题清单

- □ 给出准出结论

- ```

- ---

- ### 阶段零：准备

- 1. **读取 HLD 文档**

- - 确认 HLD 文件路径

- - 完整读取 HLD 内容

- 2. **读取关联的 PRD 文档**（先问后判）

- - 从 HLD 中找到 PRD 基线版本和路径

- - **如果 HLD 未标注 PRD 来源**：

- 1. 先使用 `AskUserQuestion` 询问用户 PRD 路径

- 2. 如果用户提供了 PRD 路径，记录为「PRD 来源由用户补充提供」→ **P1**（文档质量缺陷）

- 3. 如果用户确认「没有对应的 PRD」→ **P0 阻塞**（HLD 无 PRD 基础，停止审查）

- - 完整读取 PRD 内容

- - **验证 PRD 状态**：

- - ✅ PRD 为 Approved 状态 → 继续审查

- - ❌ PRD 为 Draft 状态或状态未知 → **P0 阻塞，停止审查**

- > **「最新批准基线」定义**：经过正式评审通过的 PRD 版本（状态为 Approved），而非仍在迭代中的草稿。

- >

- > **证据路径**：检查 PRD 元数据中的「状态」字段。如无状态字段，使用 `AskUserQuestion` 询问用户确认。

- >

- > **处理路径**：

- > | 情况 | 严重度 | 处理 |

- > |------|--------|------|

- > | HLD 未标注 PRD，但用户可提供 | P1 | 继续审查，记录文档缺陷 |

- > | 用户确认无 PRD | P0 | 停止审查 |

- > | PRD 为 Draft/状态未知 | P0 | 停止审查，要求 PRD 先通过评审 |

- 3. **判断风险级别，决定审查范围**

- **必须使用 `AskUserQuestion` 确认风险特征**（禁止自行猜测）：

- ```

- question: "请确认 HLD 的风险特征（可多选）"

- header: "风险"

- multiSelect: true

- options:

- - label: "涉及敏感数据/认证/授权"

- description: "将启用 Security 视角审查"

- - label: "涉及数据迁移/Schema 变更"

- description: "将启用 DBA 视角审查"

- - label: "高并发/性能敏感场景"

- description: "将启用 SRE/性能视角审查"

- - label: "跨团队/跨系统依赖"

- description: "将启用 Architect 视角审查"

- - label: "复杂测试场景"

- description: "将启用 QA 视角审查（多系统集成、状态机、难构造测试数据等）"

- - label: "无特殊风险"

- description: "仅进行基础审查（Tech Lead + Senior Engineer）"

- - label: "由实际情况自行判断"

- description: "授权 Reviewer 根据 HLD 内容自主识别风险特征（需附证据）"

- ```

- > **说明**：

- > - 如果用户选择「由实际情况自行判断」，Reviewer 可根据 HLD 内容识别风险特征

- > - **证据要求**：每个启用的角色视角必须附 HLD 中的证据位置（如「启用 Security 视角，因 HLD:3.2 涉及用户认证」）

- > - 否则，严格按用户选择的风险特征启用对应角色视角

- >

- > **二次确认机制**：

- > - 当用户选择「无特殊风险」，但 Reviewer 在 HLD 中发现明确的风险证据时（如涉及认证、数据迁移等），应发起二次确认：

- > ```

- > question: "检测到 HLD 中存在以下风险特征，是否需要启用对应角色审查？"

- > header: "风险确认"

- > multiSelect: true

- > options:

- > - label: "[风险类型]"

- > description: "证据：HLD:X.X [具体内容]"

- > - label: "确认无需额外审查"

- > description: "维持基础审查"

- > ```

- > - 这确保明显风险不会因用户初始选择而被跳过

- 4. **执行 Guardrails trigger check**

- - 基于 HLD、PRD、已存在的 Guardrails 与仓库事实，按 `../../references/guardrails-trigger-check.md` 判定：

- - `no_trigger`：继续进入阶段一

- - `suggest_guardrails`：记录为治理跟进项，默认按 **P2** 处理，不单独阻塞准出

- - `require_guardrails_before_design`：按 **P0** 处理，停止审查，要求先更新 Guardrails 再复审

- ### 阶段一：第一道门 - PRD↔HLD 一致性检查

- **这是最重要的检查，必须逐条验证。**

- #### 0. Traceability Metadata 校验（先于内容审查）

- 在开始内容级审查之前，先验证 HLD 的追溯元数据结构完整性：

- - [ ] HLD 是否包含 `TRACEABILITY-METADATA` block？

- - 缺失 → **P1**（文档质量缺陷，继续后续审查）

- - [ ] 若 block 存在，执行 `python3 plugins/testany-eng/scripts/trace_lint.py --format json <HLD 路径>`

- - 存在 error → **P0 阻塞**（trace-lint blocking issue）

- - 存在 warning → **P1**

- - [ ] 若 PRD 路径可用，执行 `python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <HLD 路径>`

- - RTM001-RTM004 级别 issue → **P0**

- - PRD 中 in-scope 的 `REQ-*` 存在 `requirements_uncovered > 0` → **P1**（PRD 需求未被任何 HLD DEC-*/FLOW-* 引用）

- > **说明**：TRACEABILITY-METADATA block 缺失统一记为 P1 而非 P0，因为旧版 HLD 可能在此功能上线前产出。但 block 存在时，其内容必须通过 trace-lint 校验（error → P0）。PRD 需求未被引用（uncovered）也记为 P1——这正是 #11 要修复的核心缺口。

- 详细检查指南见：`references/drift-detection-guide.md`

- **检查项：**

- 1. **PRD 基线版本检查**

- - [ ] HLD 是否标注了 PRD 基线版本？

- - 未标注但用户可提供 → **P1**（文档质量缺陷，继续审查）

- - 用户确认无 PRD → **P0 阻塞，停止审查**

- - [ ] PRD 文件是否存在且可访问？

- - [ ] PRD 状态是否为 **Approved**？

- - Approved → 继续审查

- - **Draft 或状态未知 → P0 阻塞，停止审查**（要求 PRD 先通过评审）

- 2. **1:N 场景识别**（PRD 拆分为多个 HLD）

- - [ ] HLD 是否标注了「本 HLD 覆盖范围」或引用了「索引文档」？

- - 如果未标注且未引用，**必须使用 AskUserQuestion 确认是否为 1:N 场景**：

- ```

- question: "该 PRD 是否拆分为多个 HLD？"

- header: "1:N 确认"

- multiSelect: false

- options:

- - label: "是，PRD 拆分为多个 HLD"

- description: "需要索引文档与覆盖总表"

- - label: "否，PRD 仅对应单个 HLD"

- description: "按 1:1 场景审查"

- ```

- - 如确认是 1:N，但未标注覆盖范围/未引用索引文档 → **P1**（文档质量缺陷，要求补齐）

- - 如果是 1:N 场景：

- - [ ] **索引文档是否存在？** → 没有索引文档 → **P0**

- - [ ] **索引文档中 PRD 需求覆盖率是否 100%？** → 有未分配需求 → **P0**

- - 覆盖率计算口径：需求已分配到任一 HLD 即计为覆盖，与设计是否完成无关

- - [ ] 本 HLD 覆盖范围是否与索引文档一致？ → 不一致 → **P1**

- - [ ] 跨 HLD 依赖是否声明？ → 未声明 → **P1**

- - [ ] 跨 HLD 接口契约是否明确？ → 无契约 → **P1**

- - 如果是 1:1 场景：继续正常审查

- 3. **需求映射表检查**

- - [ ] HLD 是否包含 PRD↔HLD 需求映射表？

- - [ ] 映射表是否覆盖**本 HLD 负责范围内**的所有需求？

- - [ ] 每条需求是否都有对应的 HLD 章节？

- - **1:N 场景额外检查**：

- - [ ] 是否明确标注「不在本 HLD 范围内的需求」？

- - [ ] 是否引用了索引文档路径？

- 4. **需求覆盖检查**（逐条对照）

- - [ ] PRD 功能需求 → HLD 功能设计

- - [ ] PRD 非功能需求 → HLD 非功能设计

- - [ ] PRD 验收标准 → HLD 可验证性

- 4. **漂移检测**

- - [ ] 是否有需求遗漏？（PRD 有，HLD 没有）

- - [ ] 是否有需求膨胀？（HLD 有，PRD 没有）

- - [ ] 需求膨胀是否有合理的**技术必要性标注**？（见下方标准）

- - [ ] 是否有需求曲解？（HLD 理解偏离 PRD 原意）

- **「技术必要性」合规标准**（需满足以下任一条件）：

- | 标准 | 描述 | 有效示例 | 无效示例 |

- |------|------|----------|----------|

- **技术必要性标注格式要求**：

- - HLD 中必须明确标注「技术必要性：[具体原因]」

- - 必须说明与哪条 PRD 需求关联

- - 无标注或标注不符合上述标准的，视为「需求膨胀」(P1)

- **门一输出要求：**

- 1. **需求覆盖表**（必须使用以下格式）：

- |----------|-------------|------|-------------|

- | {需求ID} {需求描述} | {HLD章节:行号} | ✅ 已覆盖 / ⚠️ 部分覆盖 / ❌ 未覆盖 / ❓ 待澄清 | {说明} |

- **`非已覆盖说明` 列填写规则**：

- - ✅ 已覆盖 → 填 `—`

- - ⚠️ 部分覆盖 → **必填**：说明哪部分未覆盖、缺了什么

- - ❌ 未覆盖 → **必填**：说明遗漏内容、建议补充方向

- - ❓ 待澄清 → **必填**：说明需要澄清的问题

- - 如发现 **膨胀点**（HLD 做了 PRD 没要求的）→ 在说明中标注 `膨胀点：{描述}`

- 2. **漂移问题清单**（类型、描述、严重度、证据）

- 3. **门一结论**（无 P0 可继续 / 存在 P0 阻塞）

- **门一阻塞处理：**

- - 立即停止审查，不执行第二/第三道门

- - 仅输出门一结果 + Decision Gates + 下一步

- - 修复完成后重新复审

- ### 阶段二：第二道门 - 核心技术审查

+ 使用可用的进度机制记录准备、三道门、输出；没有专门清单工具时用简短进度说明即可，不因工具缺失停工。

- 详细检查清单见：`references/review-checklist.md`

+ ### 阶段零：范围、依据与风险

- **审查维度（Tech Lead + Senior Engineer 视角）：**

+ 1. 完整读取提交的 HLD 或有限变更请求；记录本轮评审模式、对象、未变基线与整改 ID（如有）。不把普通 note 冒充已批准 HLD。

+ 2. 定位并读取相关批准 PRD/API/HLD/ADR/用户决定、Guardrails。**正式设计**验证 PRD 版本和批准状态；**有限模式**可用现有有效依据，不因缺某种文档格式要求重走全流程。

+ 3. 状态标注不等于权限证明。对争议/新增职责沿引用回到原始批准，写清谁有权、批准了什么。只有 Reviewer 自己的旧意见时，不得将其冻结为授权基线。

+ 4. 找不到关键来源时先做本地只读定位，再提一个能改变结论的具体问题。文件缺失或 Draft/unknown 是准出 evidence gap，不自动断言产品设计有 P0；必要依据不明的部分暂缓，无关部分可继续。

+ 5. 依据实际材料识别风险并附位置，选择 Security/DBA/SRE/Architect/QA 视角；不要求用户完成一套风险问卷。用户显式限制范围时遵守；有明显范围外风险单列并说明，不暗中扩大。

+ 6. 按 `../../references/guardrails-trigger-check.md` 检查是否真的定义/改变项目级默认规则。有限局部修复不因“涉及安全/多仓”或缺整份 Guardrails 自动触发。`suggest_guardrails` 是非阻断跟进；若关键规则缺失/冲突，按本 skill 的 evidence/scope 分类暂停依赖部分，不用补文档代替 Owner 决策。

- 1. **架构决策审查**

- - 架构选型是否合理？

- - 是否有替代方案分析？

- - 决策依据是否充分？

+ ### 阶段一：第一道门 — 批准范围与漂移

- 2. **技术栈对齐审查**

- - 是否符合项目/团队技术栈？

- - 如有偏离，是否有充分理由？

+ 开始内容检查前完整读取 `references/drift-detection-guide.md`。

- 3. **复用盘点审查**

- - 是否识别了可复用的现有组件？

- - 复用决策是否有来源证据？

- - 是否避免了重复造轮子？

+ #### 正式 HLD 的追溯检查

- 4. **兼容性审查**

- - 接口兼容性方案是否完整？

- - 数据兼容性方案是否完整？

- - 是否考虑了向前/向后兼容？

+ - 核对 PRD 批准版本、文件路径、HLD 覆盖范围与接口事实源。

+ - 检查 `TRACEABILITY-METADATA`。存在时执行 `python3 plugins/testany-eng/scripts/trace_lint.py --format json <HLD>`；可取得 PRD 时执行 `python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD> <HLD>`。

+ - 按 `../../references/traceability-schema/` 的现有格式检查引用、RTM001–RTM004 和 in-scope `REQ-*` 未覆盖项。结构无效不能宣称追溯通过；报告实际 error/warning 及影响，不能把 lint 级别直接当产品缺陷严重度。

+ - 正式新 HLD 应具有追溯内容；旧版无 block 先检查已有等价映射，报告所缺的实际覆盖证据，不为格式迁移新增架构整改。

+ - PRD→多个 HLD 时，核对索引/覆盖总表：每项需求是否分配、本 HLD 范围是否一致、跨 HLD 依赖与接口契约是否明确。**已分配不等于已设计/已验证**。

+ - 未知是 1:1 还是 1:N，先查现有索引/引用；只在确实影响覆盖判断时询问。正式整体覆盖不能因一个局部 HLD 完成而宣称 100%。

- 5. **发布策略审查**

- - 是否有灰度发布方案？

- - 是否有回滚方案？

- - 是否有功能开关设计？

+ #### 两种模式都要做的内容检查

- 6. **可观测性审查**

- - 监控指标是否完整？

- - 告警规则是否合理？

- - 日志设计是否充分？

- - 是否能支撑 PRD 中的成功指标？

+ 1. 正向：范围内功能、非功能、验收、约束分别对应设计。有限模式只检查其受影响基线，不重做整个产品 RTM。

+ 2. 反向：设计新增了什么职责、权限主体、依赖、运维动作、数据生命周期、失败语义？没有新表/接口不代表没有架构变化。

+ 3. 语义：名称相同不等于语义一致。特别检查人/机器任务、数据/元数据、在线用户/后台任务、允许/拒绝以及依赖失败行为。

+ 4. 必要性：作者声称“功能必需”“安全必需”“复用已有 PDP”“行业惯例”时，核对基线依据、真实失败、边界内替代方案和授权来源。不能靠增加注释或补写未经批准 PRD 消除漂移。

+ 5. 可行性：真实管理入口是否能表达方案？直接给执行器测试数据、自写 compiler 或模拟管理 API 不能证明生产管理链可发布同样配置。最小只读/隔离证据足够时不要求现网试改；不支持的输入属于设计可行性问题，不是简单“上线后补配置”。

- 7. **风险识别审查**

- - 是否识别了主要风险？

- - 是否有缓解措施？

- - 是否有应急预案？

+ #### 门一输出

- ### 阶段三：第三道门 - 角色增量审查

+ 正式模式保留需求覆盖表：

- **根据阶段零识别的风险特征，启用对应的角色视角。**

+ |----------|-----------|----------|------|-------------------|

- 详细角色审查要点见：`references/role-perspectives.md`

+ 同时列漂移 findings、evidence gaps、scope decisions。有限模式可在原请求中简短列受影响条目，无需补整张全局矩阵。

- #### Security 视角（涉及敏感数据/认证/授权时启用）

- - 认证/授权设计是否完整？

- - 敏感数据如何保护？

- - 是否有安全审计日志？

- - 是否符合合规要求？

+ 有关键阻断不能签准出；只暂停以该未决边界为前提的分析，继续可独立判断的第二/三道门。说明未审部分，不假称整轮完成。

- #### DBA 视角（涉及数据迁移/Schema 变更时启用）

- - 数据模型设计是否合理？

- - 数据迁移方案是否安全？

- - 是否考虑了数据量增长？

- - 索引设计是否合理？

+ ### 阶段二：第二道门 — 核心技术可行性

- #### SRE/性能视角（高并发/性能敏感时启用）

- - 性能目标是否明确？

- - 是否有容量规划？

- - 是否有降级方案？

- - 是否有限流/熔断设计？

+ 完整读取 `references/review-checklist.md`。正式模式覆盖全部适用维度；有限模式选受影响维度并解释必要 N/A，不能从清单发明新功能。

- #### Architect 视角（跨团队/跨系统依赖时启用）

- - 跨系统接口是否清晰？

- - 依赖关系是否合理？

- - 是否符合架构原则？

- - 是否影响其他系统？

+ 1. **架构决策**：职责与交互、选型依据、边界内替代方案、失败模式是否成立。

+ 2. **技术栈**：是否沿用批准栈，偏离的可行性、维护成本和授权是否明确。

+ 3. **复用**：识别现有组件和真实能力来源；复用本身不免除信任/依赖变更审查，不重复造轮子。

+ 4. **接口**：范围内接口、调用者和错误契约是否清晰；不改写 API authority，相关增量单独路由。

+ 5. **数据**：概念模型、关系、生命周期、存储与备份要求；字段/SQL细节转 LLD，不能仅因未来规模建议加表/分片。

+ 6. **兼容性**：新旧调用者、数据、历史状态、升级/恢复是否符合批准支持范围。

+ 7. **发布与恢复**：风险所需的既有部署/恢复路径是否可行；灰度、双轨、功能开关不是默认必需，禁止强塞发布平台。这里只评估方案，不执行发布。

+ 8. **可观测性**：已有日志/指标是否足以验证已批准成功指标、发现具体故障；不默认新建监控/审计系统。

+ 9. **风险与可测试性**：本轮主要失败的缓解、最小可证实的验证方法、跨边界真实能力证据。

- #### QA 视角（复杂测试场景时启用）

- - 设计是否可测试？

- - 测试策略是否可行？

- - 是否有难以测试的部分？

+ ### 阶段三：第三道门 — 风险驱动增量视角

- ### 阶段四：输出审查报告

+ 完整读取 `references/role-perspectives.md`。角色只是审查视角，不产生额外决策权限或独立必需产物。对子任务传递模式、冻结范围、原始批准来源、待决策项、`output_language`，禁止重新定义需求或把角色建议自动升级为 P1。

- 按 `references/report-templates.md` 或 `references/report-templates.en.md` 输出结构化结果：

+ - **Security**：既定认证/授权与信任边界、数据保护、适用合规和审计。不把所有机器任务自动纳入人类 PDP，也不删除已批准检查。

+ - **DBA**：受影响数据模型、迁移、一致性、增长与索引风险；不能自动要求零停机、永久留档或分库分表。

+ - **SRE/Performance**：批准性能/可用性目标、容量、依赖失败与恢复。熔断、DLQ、缓存、降级不是清单式新增义务。

+ - **Architect**：职责、跨系统依赖、接口与演进的实际影响；不因跨系统数量决定严重度。

+ - **QA**：验收是否可观察、测试输入与生产边界是否等价、隔离是否可靠；不把“便于测”变成新增 public API/测试平台。

- - 审查不通过：输出完整审查报告

- - 审查通过：输出准出证书

- - 模板语言必须遵循 `../../references/language-policy.md`

- - 审查报告至少包含：基本信息、门一摘要、Findings、Missing Info / Questions、Decision Gates、Optional Improvements、放行决策、下一步

- - 准出证书至少包含：基本信息、一致性确认、准出门槛确认、审查历程、审查覆盖、审查者、准出确认、准出签章

+ ### 阶段四：报告与停止

- ## 交互规范（简要）

+ 完整读取与 `output_language` 对应的 `references/report-templates.md` 或 `references/report-templates.en.md`。

- - **启动**：用户提供 HLD 路径（建议同时提供 PRD）

- - **复审**：记录轮次并在准出证书中展示审查历程

- - **AskUserQuestion**：PRD 来源确认、风险特征确认、证据不足澄清必须询问

+ - 正式模式：保留基本信息、批准依据、门一覆盖、核心/角色覆盖、findings、gaps、scope decisions、可选项、双结论、复审历史和下一步；证书仅在正式准出条件全部满足时填写，不预填成功。

+ - 有限模式：复用原请求/回复的简短格式，记录对象与范围、原 ID 关闭证据、遗漏/必要 gap、双结论和最小下一步；不强制新文件、全量证书或签章。

+ - Scope decision 必须说明旧/新行为、产品/架构影响、推荐方案、有权 Owner 和缺少的具体授权。不得写成已批准工程命令。

+ - Reviewer 旧错误要说明来源及受影响结论；撤回错误“已批准”表述，不暗改基线或撤销无关批准。

+ - 本轮 P0/P1 与必要 gap 关闭即停止；P2 不自动续轮，范围外风险独立列出。设计评审完成不扩展实施或环境操作权限。

- ## 禁止行为

+ ## 使用示例

- - **禁止放水**：不能因为「差不多」就放行，必须严格执行标准

- - **禁止越权**：不修改 HLD，只提出问题和建议

- - **禁止无证据质疑**：所有问题必须指向具体证据位置

- - **禁止重新设计**：不替代 HLD 作者做方案，只挑战和验证

- - **禁止过度审查**：低风险 HLD 不需要全栈审查

+ **正式 HLD**：“请审查新报表功能 HLD，PRD 已批准。”→ `formal_design`，完整追溯与适用三道门；缺关键批准证据不签证书，三个排版建议不阻断。

- ## 详细参考文档

+ **有限架构提案**：“后台目录同步401，拟复用用户 PDP，并配置新机器规则。”→ `bounded_change`，先确认原机器授权与目标数据边界。若新增常态 PDP 依赖未经批准，分别给技术可行性和 `DECISION_REQUIRED`；不能因安全或测试通过批准扩张，也不能直接删除既有授权检查。

- - `references/drift-detection-guide.md` - PRD→HLD 漂移检测详细指南

- - `references/review-checklist.md` - 完整审查检查清单

- - `references/role-perspectives.md` - 各角色视角审查要点

- - `references/report-templates.md` - 审查报告与准出证书模板

- - `references/report-templates.en.md` - 英文审查报告与准出证书模板

- - `../../references/guardrails-trigger-check.md` - Guardrails 触发检查与分流规则

+ **实现细节**：“批准模型不变，修复 nullable UUID SQL，涉及三个仓库。”→ 这是 LLD/源码问题，按是否有 Candidate 路由，不新增 HLD/PRD 门禁。

- ## 触发词

+ **整改复审**：“只复审 ADR-007 的失败语义修订。”→ 继承该决定和原 finding，核查 delta 与直接影响；不顺手要求全量 Runbook、审计平台或未来租户隔离改造。

- 以下输入应触发此技能：

+ ## 参考文档

- - 「审查 HLD」、「review HLD」

- - 「HLD 评审」、「技术方案评审」

- - 「Design Review」

- - 「检查 HLD 质量」

- - 「/hld-reviewer」

+ - `../../references/review-boundaries.md` — 四个 review/guide 入口共用的边界规则，始终先读

+ - `references/drift-detection-guide.md` — 覆盖、语义与授权漂移检查

+ - `references/review-checklist.md` — 正式完整覆盖与有限模式适用项

+ - `references/role-perspectives.md` — 有证据的风险视角，非自动新增需求表

+ - `references/report-templates.md` / `references/report-templates.en.md` — 正式及有限输出

+ - `../../references/guardrails-trigger-check.md` — 项目级规则触发判定

+ - `../../references/traceability-schema/` — 正式追溯元数据格式