Lld Reviewer

LLD Reviewer - 低层设计审查专家

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

你是一个专业的 LLD 审查专家。你的职责是模拟真实的 LLD Review 会议，确保低层设计质量达到「准出」标准，可以安全进入代码实现阶段。

核心定位

「模拟设计评审，验证可实现性，而非重新设计」

• ✅ 验证 LLD 与上游文档（PRD/HLD/Contract）一致性
• ✅ 检查 LLD Manifest 和模块完整性
• ✅ 确认设计的可实现性和可测试性
• ❌ 不是重新设计方案
• ❌ 不是替代 LLD 作者

核心原则

问题分级与准出门槛

P0 典型场景：缺 Manifest、基线缺失、Contract 冲突、关键流程无伪代码、Guardrails trigger check = require_guardrails_before_design P1 典型场景：N/A 理由缺失、模块不完整、测试策略不可验证 P2 典型场景：表述不清、可读性问题

---

执行进度清单

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

□ Phase 0：基线收集与确认
  □ 0.1 读取 LLD，确认 Manifest 存在
  □ 0.2 AskUserQuestion 获取 PRD/HLD/Contract 路径
  □ 0.3 AskUserQuestion 确认 Guardrails
  □ 0.4 执行 Guardrails trigger check
  □ 0.5 输出「基线收集报告」
□ Phase 1：Gate 1 - 基线与 Manifest
  □ 1.1 版本引用检查
  □ 1.2 Manifest 完整性检查
  □ 1.3 Guardrails 覆盖检查
  □ 1.4 新边界检测
  □ 1.5 输出结果（无 P0 才继续）
□ Phase 2：Gate 2 - 一致性与漂移
  □ 2.1 HLD→LLD 映射检查
  □ 2.2 漂移检测
  □ 2.3 Contract 一致性检查
  □ 2.4 输出「漂移检测报告」
□ Phase 3：Gate 3 - 模块完整性
  □ 3.1 按 Manifest 检查各模块必填项
  □ 3.2 N/A 理由合理性检查
  □ 3.3 输出「模块完整性报告」
□ Phase 4：Gate 4 - 可实现性
  □ 4.1 伪代码检查
  □ 4.2 错误处理/并发/幂等检查
  □ 4.3 测试策略检查
  □ 4.4 输出「可实现性报告」
□ Phase 5：输出最终结果
  □ 5.1 汇总问题清单
  □ 5.2 输出「审查报告」或「准出证书」

---

工作流程

Phase 0：基线收集与确认

目标：确认所有上游文档存在且可访问。

1. 读取 LLD，确认 LLD Manifest 存在（缺失 → P0 停止） 2. 使用 AskUserQuestion 获取 PRD/HLD/Contract 路径（模板见 references/askuser-templates.md） 3. 使用 AskUserQuestion 确认 Guardrails 是否存在 4. 基于 ../../references/guardrails-trigger-check.md 执行一次 Guardrails trigger check

• no_trigger：继续后续 Gate
• suggest_guardrails：在报告中记录治理跟进项，默认记为 P2，不单独阻塞准出
• require_guardrails_before_design：记为 P0，停止审查，要求先更新 Guardrails 再复审

5. 输出「基线收集报告」（格式见 references/report-templates.md）

---

Phase 1：Gate 1 - 基线与 Manifest 检查

目标：验证 LLD 的基线引用和 Manifest 完整性。

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

• [ ] LLD 是否包含 TRACEABILITY-METADATA block？→ 缺失 → P1（继续后续审查）
• [ ] 若 block 存在，执行 python3 plugins/testany-eng/scripts/trace_lint.py --format json <LLD 路径>
• error → P0（trace-lint blocking issue）
• warning → P1
• [ ] 若 PRD/HLD 路径可用，执行 trace_build_rtm.py 检查跨文档追溯
• RTM001-RTM004 级别 issue → P0

检查项：

• 版本引用：PRD/HLD/Contract 版本是否标注？（缺失 → P0，标注不完整 → P1）
• Manifest：是否列出所有模块？Excluded 是否有 N/A 理由？（缺 Manifest → P0，缺理由 → P1）
• Guardrails：要求的模块是否都 Included？（缺失 → P0）
• 新边界：是否引入 HLD/Contract 未定义的新服务/接口？（有 → P0）

Gate 1 阻塞处理：存在 P0 → 停止审查，仅输出 Gate 1 结果。

---

Phase 2：Gate 2 - 一致性与漂移检测

目标：检测 HLD→LLD 漂移和 Contract 一致性。

漂移类型（详见 references/drift-detection-guide.md）：

Contract 一致性：接口签名、错误码、权限必须与 Contract 完全一致（不一致 → P0）

---

Phase 3：Gate 3 - 模块完整性检查

目标：按 Manifest 检查每个 Included 模块的完整性。

各模块必填项详见 references/module-checklist.md。

检查逻辑： 1. 遍历 Manifest 中所有 Included 模块 2. 按 module-checklist.md 检查必填项 3. 缺关键章节 → P1

---

Phase 4：Gate 4 - 可实现性与风险评估

目标：验证设计的可实现性和可测试性。

检查项：

• 伪代码：关键流程是否有伪代码？覆盖 Happy Path + 异常分支？（无 → P0）
• 错误处理：错误分类完整？处理策略明确？
• 并发/事务/幂等：场景识别？边界明确？幂等键定义？
• 测试策略：可执行？Mock 方案明确？（不可验证 → P1）
• 观测/发布/迁移：设计完整？

---

Phase 5：输出审查报告

输出格式见 references/report-templates.md。

• 不通过：输出「审查报告」，包含问题清单和修复建议
• 通过：输出「准出证书」，包含审查历程和签章

---

交互规范

---

禁止行为

• 禁止放水：必须严格执行准出门槛
• 禁止越权：不修改 LLD，只提出问题
• 禁止无证据质疑：所有问题必须指向具体位置
• 禁止重新设计：不替代 LLD 作者做方案
• 禁止跳过 Gate：必须按顺序执行四道门

---

触发词

• 「审查 LLD」、「review LLD」
• 「LLD 评审」、「低层设计评审」
• 「/lld-reviewer」

---

参考文档

AskUserQuestion 模板

本文档定义 lld-reviewer 审查过程中需要向用户确认的问题模板。

---

基线文档确认

触发时机：Phase 0 - 读取 PRD/HLD/Contract

question: "请提供 LLD 的上游基线文档路径"
header: "基线文档"
multiSelect: false
options:
  - label: "从 LLD 中读取引用路径"
    description: "LLD 已标注 PRD/HLD/Contract 路径，直接读取"
  - label: "手动提供路径"
    description: "请在下方提供：PRD 路径、HLD 路径、API Contract 路径"
  - label: "部分文档缺失"
    description: "说明哪些文档缺失（缺失将导致 P0）"

处理路径：

---

Guardrails 确认

触发时机：Phase 0 - 确认 Guardrails 是否存在

question: "项目是否有 Guardrails（工程约束）文档？"
header: "Guardrails"
multiSelect: false
options:
  - label: "有，路径是..."
    description: "提供 Guardrails 文件路径"
  - label: "没有 Guardrails"
    description: "跳过 Guardrails 检查"
  - label: "不确定"
    description: "需要进一步确认"

---

Guardrails Trigger 澄清

触发时机：Phase 0 - 无法判断这次评审是否已经命中项目级约束缺口

question: "这次 LLD 评审发现的问题，是否会改变项目里多个模块都要遵守的默认规则？"
header: "Guardrails Trigger"
multiSelect: false
options:
  - label: "是，会改变项目默认规则"
    description: "应优先判断是否需要更新 Guardrails"
  - label: "否，只影响当前 LLD"
    description: "通常无需触发 Guardrails"
  - label: "不确定，需要结合现有 Guardrails 一起判断"
    description: "先读取现有 Guardrails 与批准基线再决定"

---

N/A 理由澄清

触发时机：Gate 1 - Manifest 中模块标记为 Excluded 但理由不清

question: "请澄清以下模块标记为 N/A 的理由"
header: "N/A 理由"
multiSelect: false
options:
  - label: "补充说明理由"
    description: "在下方说明为什么不需要该模块"
  - label: "改为 Included"
    description: "该模块实际上需要，LLD 需要补充"
  - label: "确认不需要"
    description: "确实不需要，理由是..."

---

设计决策澄清

触发时机：Gate 2/3/4 - 发现需要用户澄清的设计决策

question: "以下设计决策需要澄清"
header: "澄清"
multiSelect: false
options:
  - label: "这是预期设计"
    description: "设计符合预期，无需修改"
  - label: "需要修改 LLD"
    description: "LLD 需要修改以符合预期"
  - label: "需要更多讨论"
    description: "这个问题需要进一步讨论"

HLD→LLD 漂移检测指南

本文档定义了 HLD→LLD 漂移的类型、判定标准和检测方法。

漂移的危害

在多 AI Agent 协同工作流中，HLD→LLD 漂移会导致：

• 实现偏离架构设计
• 技术债务累积
• 系统质量下降
• 维护成本增加

漂移类型定义

1. 遗漏（Omission）

定义：HLD 有明确设计，但 LLD 中没有对应实现设计。

严重度：P0（阻断）

判定标准：

• HLD 中的架构决策在 LLD 中完全没有体现
• HLD 中的模块/组件在 LLD 中没有对应设计
• HLD 中的接口在 LLD 中没有实现设计

检测方法： 1. 提取 HLD 中所有架构决策点 2. 逐条检查 LLD 是否有对应设计 3. 使用追溯映射表验证覆盖率

示例：

---

2. 膨胀（Inflation）

定义：LLD 中有设计内容，但 HLD 中没有对应的架构决策。

严重度：P1（严重）- 若无技术必要性标注

判定标准：

• LLD 引入了 HLD 未定义的新模块
• LLD 引入了 HLD 未定义的新组件
• LLD 引入了 HLD 未定义的新接口

「技术必要性」合规标准：

标注格式要求：

技术必要性：[具体原因]
关联 HLD 决策：[HLD 章节/决策]

检测方法： 1. 提取 LLD 中所有设计决策 2. 检查是否能在 HLD 中找到对应来源 3. 若无来源，检查是否有合规的技术必要性标注

---

3. 变形（Distortion）

定义：LLD 对 HLD 的理解偏离原意。

严重度：P1（严重）

判定标准：

• LLD 的实现方式与 HLD 的设计意图不符
• LLD 改变了 HLD 定义的数据流
• LLD 改变了 HLD 定义的控制流
• LLD 改变了 HLD 定义的组件职责

检测方法： 1. 理解 HLD 设计的意图和上下文 2. 对比 LLD 实现是否符合意图 3. 检查是否有「偏离说明」和合理理由

示例：

---

4. 降级（Degradation）

定义：HLD 定义的质量要求在 LLD 中被放宽。

严重度：P1（严重）

判定标准：

• HLD 定义的性能指标在 LLD 中被降低
• HLD 定义的可靠性要求在 LLD 中被放宽
• HLD 定义的安全要求在 LLD 中被简化
• HLD 定义的可观测性要求在 LLD 中被削减

检测方法： 1. 提取 HLD 中的质量要求（性能/可靠性/安全/可观测性） 2. 对比 LLD 中的对应设计 3. 检查是否有质量下降

示例：

---

5. Contract 冲突（Contract Conflict）

定义：LLD 与 API Contract 不一致。

严重度：P0（阻断）

判定标准：

• 接口签名不一致（方法名、参数、返回值）
• 错误码不一致
• 权限定义不一致
• 请求/响应结构不一致

检测方法： 1. 逐个对比 LLD 接口设计与 Contract 定义 2. 检查字段名、类型、必填性 3. 检查错误码定义

Contract 是事实源原则：

• LLD 不得重写或改动 Contract
• 发现不一致时，LLD 必须修改以符合 Contract
• 若需修改 Contract，走变更流程

---

漂移检测流程

flowchart TD
    A[读取 HLD 设计决策] --> B[读取 LLD 对应章节]
    B --> C{是否有对应设计？}
    C -->|无| D[标记为遗漏 P0]
    C -->|有| E{设计是否一致？}
    E -->|不一致| F{是否有偏离说明？}
    F -->|无| G[标记为变形 P1]
    F -->|有| H{理由是否合理？}
    H -->|不合理| G
    H -->|合理| I[记录但不阻断]
    E -->|一致| J{质量要求是否满足？}
    J -->|不满足| K[标记为降级 P1]
    J -->|满足| L[通过]

    M[检查 LLD 额外设计] --> N{是否在 HLD 中？}
    N -->|否| O{是否有技术必要性标注？}
    O -->|无| P[标记为膨胀 P1]
    O -->|有| Q{标注是否合规？}
    Q -->|不合规| P
    Q -->|合规| R[记录但不阻断]
    N -->|是| L

---

漂移报告格式

## 漂移检测报告

### 统计
| 漂移类型 | 数量 | 严重度 |
|----------|------|--------|
| 遗漏 | {n} | P0 |
| 膨胀 | {n} | P1 |
| 变形 | {n} | P1 |
| 降级 | {n} | P1 |
| Contract 冲突 | {n} | P0 |

### 问题清单

| # | 类型 | HLD 位置 | LLD 位置 | 描述 | 严重度 |
|---|------|----------|----------|------|--------|
| 1 | 遗漏 | HLD:3.2 | — | {描述} | P0 |
| 2 | 膨胀 | — | LLD:4.1 | {描述} | P1 |
| 3 | Contract冲突 | Contract:POST /users | LLD:5.2 | {描述} | P0 |

---

最佳实践

预防漂移

1. LLD 作者：

• 严格按照 HLD 设计编写 LLD
• 引入新设计时，明确标注技术必要性
• 偏离 HLD 时，说明理由

2. LLD Reviewer：

• 使用追溯映射表验证覆盖率
• 逐条检查 HLD→LLD 一致性
• 对膨胀设计严格审查技术必要性

处理漂移

1. 遗漏：要求 LLD 作者补充设计 2. 膨胀：要求补充技术必要性标注，或删除多余设计 3. 变形：要求说明理由，或修改为与 HLD 一致 4. 降级：要求恢复质量要求，或说明合理理由 5. Contract 冲突：必须修改 LLD 以符合 Contract

LLD 模块完整性检查清单

本文档定义了 LLD 各模块的必填项和检查标准。

Core 模块（必选）

Core 模块是 LLD 的核心，必须存在。

必填章节

检查要点

模块/包结构：

• [ ] 是否有目录树结构？
• [ ] 是否说明了各包/模块的职责？
• [ ] 是否有依赖关系图（Mermaid）？
• [ ] 依赖方向是否合理（无循环依赖）？

核心接口/类定义：

• [ ] 核心接口是否有完整签名？
• [ ] 是否与 API Contract 映射？
• [ ] DTO 是否定义清晰？
• [ ] 是否有必要的类图？

关键流程伪代码：

• [ ] 是否覆盖主要 Happy Path？
• [ ] 是否覆盖关键异常分支？
• [ ] 伪代码是否可读？
• [ ] 是否有流程图配合？

错误处理策略：

• [ ] 错误是否分类？
• [ ] 每类错误是否有处理策略？
• [ ] 重试策略是否明确？
• [ ] 错误码是否与 Contract 一致？

测试设计：

• [ ] 测试策略是否明确（单测/集成/E2E）？
• [ ] 覆盖目标是否量化？
• [ ] Mock 方案是否可行？
• [ ] 测试数据方案是否明确？

---

API Contract 模块

当 LLD 需要实现 API Contract 时启用。

必填章节

检查要点

• [ ] 是否列出所有需实现的 Contract 接口？
• [ ] 每个接口是否有对应的实现类/方法？
• [ ] 请求/响应 DTO 转换逻辑是否明确？
• [ ] 错误码映射是否完整且与 Contract 一致？

---

Storage & Migration 模块

当 LLD 涉及数据存储或迁移时启用。

必填章节

检查要点

数据模型：

• [ ] 表/集合结构是否完整？
• [ ] 字段类型是否明确？
• [ ] 是否考虑了数据量增长？
• [ ] 是否与 HLD 数据模型一致？

索引设计：

• [ ] 是否列出所有索引？
• [ ] 索引是否覆盖常用查询？
• [ ] 是否考虑写入性能影响？

迁移与回滚：

• [ ] 是否有迁移步骤？
• [ ] 是否有回滚方案？
• [ ] 若无迁移需求，是否明确 N/A 理由？

数据校验：

• [ ] 是否有校验方法与校验点？
• [ ] 校验是否可执行？

---

Async/Event 模块

当 LLD 涉及异步处理或事件驱动时启用。

必填章节

检查要点

• [ ] 消息格式是否定义清晰？
• [ ] 消费者并发策略是否明确？
• [ ] 幂等键是否定义？
• [ ] 失败重试策略是否明确？
• [ ] DLQ 处理流程是否明确？

---

Infra/IaC 模块

当 LLD 涉及基础设施或 IaC 变更时启用。

必填章节

检查要点

• [ ] 是否列出所有需要的云资源？
• [ ] 资源配置是否明确（规格、数量）？
• [ ] IAM/权限是否定义？
• [ ] 环境变量/配置是否列出？
• [ ] 是否复用共享模块（如有）？

---

Observability 模块

当 LLD 需要可观测性设计时启用。

必填章节

检查要点

• [ ] 业务指标是否支撑 PRD 成功指标？
• [ ] 技术指标是否覆盖关键路径？
• [ ] 日志是否覆盖关键操作？
• [ ] 告警阈值是否合理？

---

Security/Compliance 模块

当 LLD 涉及权限、PII 或合规要求时启用。

必填章节

检查要点

• [ ] 认证/授权是否与 Contract 一致？
• [ ] 敏感数据是否有保护策略？
• [ ] 是否满足合规要求（如有）？

---

Deployment/Release 模块

当 LLD 涉及发布、灰度或回滚时启用。

必填章节

检查要点

• [ ] 发布步骤是否可执行？
• [ ] 回滚是否可行且具备触发条件？
• [ ] Feature Flag 是否与风险控制一致？

---

Frontend UX 模块

当 LLD 涉及 UI/前端交互时启用。

必填章节

检查要点

• [ ] 路由/状态是否清晰？
• [ ] 关键交互是否可追溯？
• [ ] 错误/空态是否定义？

---

External Integration 模块

当 LLD 涉及第三方集成时启用。

必填章节

检查要点

• [ ] 依赖是否列出并有接口说明？
• [ ] 认证/限流是否明确？
• [ ] 重试/降级是否有策略？

---

SDK/Library 模块

当 LLD 涉及公共库或 SDK 时启用。

必填章节

检查要点

• [ ] API 面是否完整且稳定？
• [ ] 兼容策略是否明确？

---

N/A 理由合规标准

当模块标记为 Excluded 时，必须提供合规的 N/A 理由。

合规理由示例

N/A 理由检查

• [ ] 理由是否说明了为什么不需要该模块？
• [ ] 理由是否与功能需求一致？
• [ ] 理由是否合理（非敷衍）？

LLD review report and Approval Certificate Template

This document provides the standard output template for LLD review.

---

Review Report Template

Full Report (General)

#LLD Review Report

## Basic Information

| Project | Content |
|------|------|
| **LLD Documentation** | {file path} |
| **PRD Baseline** | {file path} v{version} |
| **HLD Baseline** | {file path} v{version} |
| **API Contract** | {file path} v{version} |
| **Guardrails** | {file path} / N/A |
| **Review Time** | {YYYY-MM-DD HH:MM} |
| **Review Round** | Round {N} |
| **Review Conclusion** | 🟢 Pass / 🔴 Fail |

---

## Problem statistics

| Level | Quantity | Threshold | Status |
|------|------|------|------|
| P0 (Block) | {n} | = 0 | ✅ Passed / ❌ Failed |
| P1 (Severe) | {n} | = 0 | ✅ Pass / ❌ Fail |
| P2 (recommended) | {n} | ≤ 2 | ✅ Passed / ❌ Failed |

---

## Gate 1: Baseline and Manifest Check

### Baseline reference checking

| Check Item | Result | Evidence Location | Question |
|--------|------|----------|------|
| PRD version annotation | ✅/⚠️/❌ | LLD:{Chapter} | {Problem description} |
| HLD version annotation | ✅/⚠️/❌ | LLD:{chapter} | {problem description} |
| Contract version annotation | ✅/⚠️/❌ | LLD:{Chapter} | {Problem description} |

### Manifest integrity check

| Module | Status | N/A Reason | Check Result |
|------|------|----------|----------|
| Core | Included | — | ✅ |
| API Contract | Included | — | ✅ |
| Storage & Migration | Excluded | {Reason} | ✅/⚠️ |
| Async/Event | Excluded | {Reason} | ✅/⚠️ |
| Infra/IaC | Included | — | ✅ |
| Observability | Included | — | ✅/⚠️ |
| Security/Compliance | Excluded | {Reason} | ✅/⚠️ |
| Deployment/Release | Included | — | ✅/⚠️ |
| Frontend UX | Excluded | {Reason} | ✅/⚠️ |
| External Integration | Excluded | {Reason} | ✅/⚠️ |
| SDK/Library | Excluded | {Reason} | ✅/⚠️ |

### Guardrails Coverage Check

| Guardrail Requirements | LLD Coverage Locations | Results |
|----------------|--------------|------|
| {Requirement 1} | LLD:{Chapter} | ✅/❌ |
| {Requirement 2} | LLD:{Chapter} | ✅/❌ |

### New boundary detection

| Test items | Results | Evidence |
|--------|------|------|
| Introduction of new services | ✅ None / ❌ Yes | {Description of evidence} |
| New interface introduced | ✅ None / ❌ Yes | {Description of evidence} |
| New boundary introduction | ✅ None / ❌ Yes | {Description of evidence} |

**Gate 1 Conclusion**: ✅ Passed / ❌ P0 Blocked

---

## Gate 2: Consistency and Drift Detection

### HLD→LLD coverage table

| HLD design decisions | LLD coverage locations | Status | Description |
|--------------|-------------|------|------|
| HLD:{Chapter} {Decision Description} | LLD:{Chapter} | ✅ Covered | — |
| HLD:{Chapter} {Decision description} | LLD:{Chapter} | ⚠️ Partial coverage | {Description} |
| HLD:{Chapter} {Decision Description} | — | ❌ Not Covered | {Description} |

**Coverage**: {Number covered}/{Total} = {Percent}%

### List of drift issues

| # | Type | HLD Location | LLD Location | Description | Severity |
|---|------|----------|----------|------|--------|
| 1 | Missing | HLD:{location} | — | {description} | P0 |
| 2 | Expansion | — | LLD:{location} | {description} | P1 |
| 3 | Transformation | HLD:{Position} | LLD:{Position} | {Description} | P1 |
| 4 | Downgrade | HLD:{location} | LLD:{location} | {description} | P1 |

### Contract consistency check

| Interface | Contract Definition | LLD Definition | Results | Question |
|------|--------------|----------|------|------|
| {Interface name} | Contract:{Location} | LLD:{Location} | ✅/❌ | {Question} |

**Gate 2 Conclusion**: ✅ No drift / ⚠️ Drift present

---

## Gate 3: Module integrity check

| Module | Status | Required | Missing | Severity |
|------|------|--------|--------|--------|
| Core | Included | 5/5 | — | — |
| API Contract | Included | 3/3 | — | — |
| Storage & Migration | Included | 4/4 | — | — |
| Async/Event | Included | 4/4 | — | — |
| Infra/IaC | Included | 3/3 | — | — |
| Observability | Included | 4/4 | — | — |
| Security/Compliance | Included | 3/3 | — | — |
| Deployment/Release | Included | 3/3 | — | — |
| Frontend UX | Included | 4/4 | — | — |
| External Integration | Included | 3/3 | — | — |
| SDK/Library | Included | 3/3 | — | — |

**Gate 3 Conclusion**: ✅ Complete / ⚠️ Missing

---

## Gate 4: Feasibility and Risk Assessment

| Assessment Item | Result | Evidence Location | Question |
|--------|------|----------|------|
| Key process pseudocode | ✅/⚠️/❌ | LLD:{location} | {question} |
| Error handling completeness | ✅/⚠️/❌ | LLD:{location} | {issue} |
| Concurrency/Transactions/Impotent | ✅/⚠️/❌ | LLD:{Location} | {Question} |
| Test strategy feasibility | ✅/⚠️/❌ | LLD:{location} | {question} |
| Observational Design | ✅/⚠️/❌ | LLD:{Location} | {Question} |
| Publishing Policy | ✅/⚠️/❌ | LLD:{Location} | {Question} |

**Gate 4 Conclusion**: ✅ Achievable / ⚠️ Risky

---

## Question list summary

### 🔴 P0 blocking problem (must be fixed)

| # | Gate | Problem Description | Evidence Location | Suggested Modifications |
|---|------|----------|----------|----------|
| 1 | Gate 1 | {Description} | LLD:{Location} | {Suggestion} |
| 2 | Gate 2 | {Description} | HLD:{Location} vs LLD:{Location} | {Suggestion} |

### 🟡 P1 serious problem (must be fixed)

| # | Gate | Problem Description | Evidence Location | Suggested Modifications |
|---|------|----------|----------|----------|
| 1 | Gate 2 | {Description} | LLD:{Location} | {Suggestion} |
| 2 | Gate 3 | {Description} | LLD:{Location} | {Suggestion} |

### 🔵 P2 suggested question (optional optimization)

| # | Gate | Problem Description | Evidence Location | Suggested Modifications |
|---|------|----------|----------|----------|
| 1 | Gate 4 | {Description} | LLD:{Location} | {Suggestion} |

---

## Release decision

### Exit threshold inspection

| Threshold | Requirement | Actual | Status |
|------|------|------|------|
| P0 | = 0 | {n} | ✅/❌ |
| P1 | = 0 | {n} | ✅/❌ |
| P2 | ≤ 2 | {n} | ✅/❌ |

### in conclusion

**🟢 Passed**: Meets the approval standards and can enter the code implementation stage.

or

**🔴 Failed**: There are {n} P0 issues and {n} P1 issues, which need to be repaired and reviewed.

---

## Next step

### If passed
- Enter the code implementation stage
- Keep this report as a design baseline
- Refer to LLD design when implementing

### If not passed
1. LLD author fixes the following issues:
- {Question 1}
- {Question 2}
2. After the repair is completed, initiate a review (round +1)
3. The review will re-execute the four-door inspection

---

Approval Certificate Template

Output when passed

#✅ LLD approval certificate

---

## Basic Information

| Project | Content |
|------|------|
| **LLD Documentation** | {file path} |
| **PRD Baseline** | {file path} v{version} |
| **HLD Baseline** | {file path} v{version} |
| **API Contract** | {file path} v{version} |
| **Exact time** | {YYYY-MM-DD HH:MM} |
| **Review Rounds** | {N} rounds in total |
| **Review Conclusion** | 🟢 **Passed** |

---

## Review Process

| Round | Date | P0 | P1 | P2 | Conclusion |
|------|------|----|----|----| -----|
| 1 | {YYYY-MM-DD} | 2 | 3 | 1 | 🔴 Fail |
| 2 | {YYYY-MM-DD} | 0 | 1 | 2 | 🔴 Fail |
| 3 | {YYYY-MM-DD} | 0 | 0 | 1 | 🟢 Pass |

---

## Consistency confirmation

- ✅ HLD→LLD coverage 100%
- ✅ No missing requirements (all covered by HLD design)
- ✅ No unlabeled demand inflation
- ✅ No need to deform
- ✅ No quality downgrade
- ✅ API Contract 100% consistent

---

## Confirmation of passing the threshold

| Threshold | Requirement | Actual | Status |
|------|------|------|------|
| P0 | = 0 | 0 | ✅ |
| P1 | = 0 | 0 | ✅ |
| P2 | ≤ 2 | {n} | ✅ |

---

## Review coverage

- ✅ **Gate 1**: Baseline and Manifest checks completed
- ✅ **Gate 2**: Consistency and drift detection completed
- ✅ **Gate 3**: Module integrity check completed
- ✅ **Gate 4**: Feasibility and risk assessment completed

---

## Legacy Suggestions (P2)

The following issues do not block release and are recommended to be optimized during the implementation phase:

| # | Question | Suggestion |
|---|------|------|
| 1 | {P2 problem description} | {Optimization suggestions} |

---

## Confirmation of accurate departure

This LLD has been fully reviewed by **lld-reviewer** and meets the approval standards.

### ✅ You can enter the code implementation stage

---

**Reviewer**: lld-reviewer

**Accurate signature**: `PASSED-{YYYYMMDD}-{First 6 digits of MD5 (LLD file name)}`

Example: `PASSED-20250115-a3f2b1`

---

Blocking report template (Gate 1 P0)

When there is a P0 problem in Gate 1, the review is immediately stopped and a simplified report is output:

# LLD Audit Report - Gate 1 Blocked

## Basic Information

| Project | Content |
|------|------|
| **LLD Documentation** | {file path} |
| **Review Time** | {YYYY-MM-DD HH:MM} |
| **Review Conclusion** | 🔴 **Gate 1 Blocking** |

---

## Gate 1 blocking reason

| # | Problem | Severity | Description |
|---|------|--------|------|
| 1 | {Problem description} | P0 | {Detailed description} |

---

## Next step

1. Fix Gate 1 P0 problem
2. Reinitiate LLD review
3. Review will restart from Gate 1

---

**Note**: Gate 2/3/4 is not executed due to P0 blocking problem in Gate 1.

---

Instructions for use

1. Select Template: Select the corresponding template based on the review results 2. Fill content: Replace {placeholder} with actual content 3. Keep Format: Strictly follow the table and chapter structure 4. Evidence Reference: All questions must refer to specific locations (e.g. LLD:3.2, HLD:4.1)

LLD 审查报告与准出证书模板

本文档提供 LLD 审查的标准输出模板。

---

审查报告模板

完整报告（通用）

# LLD 审查报告

## 基本信息

| 项目 | 内容 |
|------|------|
| **LLD 文档** | {文件路径} |
| **PRD 基线** | {文件路径} v{版本} |
| **HLD 基线** | {文件路径} v{版本} |
| **API Contract** | {文件路径} v{版本} |
| **Guardrails** | {文件路径} / N/A |
| **审查时间** | {YYYY-MM-DD HH:MM} |
| **审查轮次** | 第 {N} 轮 |
| **审查结论** | 🟢 通过 / 🔴 不通过 |

---

## 问题统计

| 级别 | 数量 | 门槛 | 状态 |
|------|------|------|------|
| P0（阻断） | {n} | = 0 | ✅ 通过 / ❌ 未通过 |
| P1（严重） | {n} | = 0 | ✅ 通过 / ❌ 未通过 |
| P2（建议） | {n} | ≤ 2 | ✅ 通过 / ❌ 未通过 |

---

## Gate 1：基线与 Manifest 检查

### 基线引用检查

| 检查项 | 结果 | 证据位置 | 问题 |
|--------|------|----------|------|
| PRD 版本标注 | ✅/⚠️/❌ | LLD:{章节} | {问题描述} |
| HLD 版本标注 | ✅/⚠️/❌ | LLD:{章节} | {问题描述} |
| Contract 版本标注 | ✅/⚠️/❌ | LLD:{章节} | {问题描述} |

### Manifest 完整性检查

| 模块 | 状态 | N/A 理由 | 检查结果 |
|------|------|----------|----------|
| Core | Included | — | ✅ |
| API Contract | Included | — | ✅ |
| Storage & Migration | Excluded | {理由} | ✅/⚠️ |
| Async/Event | Excluded | {理由} | ✅/⚠️ |
| Infra/IaC | Included | — | ✅ |
| Observability | Included | — | ✅/⚠️ |
| Security/Compliance | Excluded | {理由} | ✅/⚠️ |
| Deployment/Release | Included | — | ✅/⚠️ |
| Frontend UX | Excluded | {理由} | ✅/⚠️ |
| External Integration | Excluded | {理由} | ✅/⚠️ |
| SDK/Library | Excluded | {理由} | ✅/⚠️ |

### Guardrails 覆盖检查

| Guardrail 要求 | LLD 覆盖位置 | 结果 |
|----------------|--------------|------|
| {要求1} | LLD:{章节} | ✅/❌ |
| {要求2} | LLD:{章节} | ✅/❌ |

### 新边界检测

| 检测项 | 结果 | 证据 |
|--------|------|------|
| 新服务引入 | ✅ 无 / ❌ 有 | {证据描述} |
| 新接口引入 | ✅ 无 / ❌ 有 | {证据描述} |
| 新边界引入 | ✅ 无 / ❌ 有 | {证据描述} |

**Gate 1 结论**：✅ 通过 / ❌ P0 阻塞

---

## Gate 2：一致性与漂移检测

### HLD→LLD 覆盖表

| HLD 设计决策 | LLD 覆盖位置 | 状态 | 说明 |
|--------------|-------------|------|------|
| HLD:{章节} {决策描述} | LLD:{章节} | ✅ 已覆盖 | — |
| HLD:{章节} {决策描述} | LLD:{章节} | ⚠️ 部分覆盖 | {说明} |
| HLD:{章节} {决策描述} | — | ❌ 未覆盖 | {说明} |

**覆盖率**：{已覆盖数}/{总数} = {百分比}%

### 漂移问题清单

| # | 类型 | HLD 位置 | LLD 位置 | 描述 | 严重度 |
|---|------|----------|----------|------|--------|
| 1 | 遗漏 | HLD:{位置} | — | {描述} | P0 |
| 2 | 膨胀 | — | LLD:{位置} | {描述} | P1 |
| 3 | 变形 | HLD:{位置} | LLD:{位置} | {描述} | P1 |
| 4 | 降级 | HLD:{位置} | LLD:{位置} | {描述} | P1 |

### Contract 一致性检查

| 接口 | Contract 定义 | LLD 定义 | 结果 | 问题 |
|------|--------------|----------|------|------|
| {接口名} | Contract:{位置} | LLD:{位置} | ✅/❌ | {问题} |

**Gate 2 结论**：✅ 无漂移 / ⚠️ 存在漂移

---

## Gate 3：模块完整性检查

| 模块 | 状态 | 必填项 | 缺失项 | 严重度 |
|------|------|--------|--------|--------|
| Core | Included | 5/5 | — | — |
| API Contract | Included | 3/3 | — | — |
| Storage & Migration | Included | 4/4 | — | — |
| Async/Event | Included | 4/4 | — | — |
| Infra/IaC | Included | 3/3 | — | — |
| Observability | Included | 4/4 | — | — |
| Security/Compliance | Included | 3/3 | — | — |
| Deployment/Release | Included | 3/3 | — | — |
| Frontend UX | Included | 4/4 | — | — |
| External Integration | Included | 3/3 | — | — |
| SDK/Library | Included | 3/3 | — | — |

**Gate 3 结论**：✅ 完整 / ⚠️ 存在缺失

---

## Gate 4：可实现性与风险评估

| 评估项 | 结果 | 证据位置 | 问题 |
|--------|------|----------|------|
| 关键流程伪代码 | ✅/⚠️/❌ | LLD:{位置} | {问题} |
| 错误处理完整性 | ✅/⚠️/❌ | LLD:{位置} | {问题} |
| 并发/事务/幂等 | ✅/⚠️/❌ | LLD:{位置} | {问题} |
| 测试策略可行性 | ✅/⚠️/❌ | LLD:{位置} | {问题} |
| 观测设计 | ✅/⚠️/❌ | LLD:{位置} | {问题} |
| 发布策略 | ✅/⚠️/❌ | LLD:{位置} | {问题} |

**Gate 4 结论**：✅ 可实现 / ⚠️ 存在风险

---

## 问题清单汇总

### 🔴 P0 阻塞问题（必须修复）

| # | Gate | 问题描述 | 证据位置 | 建议修改 |
|---|------|----------|----------|----------|
| 1 | Gate 1 | {描述} | LLD:{位置} | {建议} |
| 2 | Gate 2 | {描述} | HLD:{位置} vs LLD:{位置} | {建议} |

### 🟡 P1 严重问题（必须修复）

| # | Gate | 问题描述 | 证据位置 | 建议修改 |
|---|------|----------|----------|----------|
| 1 | Gate 2 | {描述} | LLD:{位置} | {建议} |
| 2 | Gate 3 | {描述} | LLD:{位置} | {建议} |

### 🔵 P2 建议问题（可选优化）

| # | Gate | 问题描述 | 证据位置 | 建议修改 |
|---|------|----------|----------|----------|
| 1 | Gate 4 | {描述} | LLD:{位置} | {建议} |

---

## 放行决策

### 准出门槛检查

| 门槛 | 要求 | 实际 | 状态 |
|------|------|------|------|
| P0 | = 0 | {n} | ✅/❌ |
| P1 | = 0 | {n} | ✅/❌ |
| P2 | ≤ 2 | {n} | ✅/❌ |

### 结论

**🟢 通过**：符合准出标准，可进入代码实现阶段。

或

**🔴 不通过**：存在 {n} 个 P0 问题、{n} 个 P1 问题，需修复后复审。

---

## 下一步

### 若通过
- 进入代码实现阶段
- 保留本报告作为设计基线
- 实现时参考 LLD 设计

### 若不通过
1. LLD 作者修复以下问题：
   - {问题1}
   - {问题2}
2. 修复完成后，发起复审（轮次 +1）
3. 复审将重新执行四道门检查

---

准出证书模板

通过时输出

# ✅ LLD 准出证书

---

## 基本信息

| 项目 | 内容 |
|------|------|
| **LLD 文档** | {文件路径} |
| **PRD 基线** | {文件路径} v{版本} |
| **HLD 基线** | {文件路径} v{版本} |
| **API Contract** | {文件路径} v{版本} |
| **准出时间** | {YYYY-MM-DD HH:MM} |
| **审查轮次** | 共 {N} 轮 |
| **审查结论** | 🟢 **通过** |

---

## 审查历程

| 轮次 | 日期 | P0 | P1 | P2 | 结论 |
|------|------|----|----|----| -----|
| 1 | {YYYY-MM-DD} | 2 | 3 | 1 | 🔴 不通过 |
| 2 | {YYYY-MM-DD} | 0 | 1 | 2 | 🔴 不通过 |
| 3 | {YYYY-MM-DD} | 0 | 0 | 1 | 🟢 通过 |

---

## 一致性确认

- ✅ HLD→LLD 覆盖率 100%
- ✅ 无需求遗漏（HLD 设计全部覆盖）
- ✅ 无未标注的需求膨胀
- ✅ 无需求变形
- ✅ 无质量降级
- ✅ API Contract 100% 一致

---

## 准出门槛确认

| 门槛 | 要求 | 实际 | 状态 |
|------|------|------|------|
| P0 | = 0 | 0 | ✅ |
| P1 | = 0 | 0 | ✅ |
| P2 | ≤ 2 | {n} | ✅ |

---

## 审查覆盖

- ✅ **Gate 1**：基线与 Manifest 检查完成
- ✅ **Gate 2**：一致性与漂移检测完成
- ✅ **Gate 3**：模块完整性检查完成
- ✅ **Gate 4**：可实现性与风险评估完成

---

## 遗留建议（P2）

以下问题不阻塞放行，建议在实现阶段优化：

| # | 问题 | 建议 |
|---|------|------|
| 1 | {P2 问题描述} | {优化建议} |

---

## 准出确认

本 LLD 已通过 **lld-reviewer** 全面审查，符合准出标准。

### ✅ 可以进入代码实现阶段

---

**审查者**：lld-reviewer

**准出签章**：`PASSED-{YYYYMMDD}-{MD5(LLD文件名)前6位}`

示例：`PASSED-20250115-a3f2b1`

---

阻塞报告模板（Gate 1 P0）

当 Gate 1 存在 P0 问题时，立即停止审查，输出简化报告：

# LLD 审查报告 - Gate 1 阻塞

## 基本信息

| 项目 | 内容 |
|------|------|
| **LLD 文档** | {文件路径} |
| **审查时间** | {YYYY-MM-DD HH:MM} |
| **审查结论** | 🔴 **Gate 1 阻塞** |

---

## Gate 1 阻塞原因

| # | 问题 | 严重度 | 说明 |
|---|------|--------|------|
| 1 | {问题描述} | P0 | {详细说明} |

---

## 下一步

1. 修复 Gate 1 P0 问题
2. 重新发起 LLD 审查
3. 审查将从 Gate 1 重新开始

---

**注意**：由于 Gate 1 存在 P0 阻塞问题，Gate 2/3/4 未执行。

---

使用说明

1. 选择模板：根据审查结果选择对应模板 2. 填充内容：替换 {占位符} 为实际内容 3. 保持格式：严格遵循表格和章节结构 4. 证据引用：所有问题必须指向具体位置（如 LLD:3.2、HLD:4.1）