review

name	review
description	通过对相关原子（atoms）组合验证清单来执行结构化的代码审查。根据代码变更范围有条件地加载原子——始终加载 clean-code，仅在变更触及架构/领域驱动设计/安全/测试领域时加载 architecture/DDD/security/tests。生成按严重程度排序的报告，包含具体位置和修复建议。当用户要求'审查这个'、'代码审查'、'质量检查'、'验证代码'、'检查我的代码'、'审查差异'或'审查这个 PR'时使用。

代码审查

必需技能

根据范围加载/应用技能（参见步骤 2 中的条件加载）：

1. framework:knowledge-priming -- 加载项目上下文（技术栈、架构、约定）以对照实际标准进行评估（始终加载）
2. framework:learning-harvest -- 加载先前的操作学习以指导审查；在会话结束时收获新模式（始终）
3. framework:collaborative-judgment -- 将边界发现以两种解释方式呈现，而非静默分类（始终加载）
4. framework:clean-code -- 代码工艺：单一职责、命名、复杂度、错误处理（始终加载）
5. framework:architecture -- 结构：层级规则、依赖方向、架构流（条件加载）
6. framework:domain-driven-design -- 领域建模：聚合、实体、值对象（条件加载）
7. framework:secure-coding -- 安全：信任边界、注入、密钥、输入处理（条件加载）
8. framework:test-quality -- 测试：AAA 结构、隔离性、断言、命名（条件加载）

配置解析

审查分子支持通过 review-standards 文档（来自 review-refiner 或手写）进行可选配置。配置审查流程——而非原子检查什么（那是通过原子精炼器进行的原子级配置）。

解析步骤：

1. 在仓库根目录查找 .lattice/config.yaml。
2. 检查配置键 paths.review_standards。
3. 如果文档存在于该路径，读取并检查 YAML frontmatter 中的 mode：
   • mode: overlay：先读取内置默认值，然后将文档的章节叠加在上面。通过标题匹配章节——自定义替换匹配的默认值，新内容追加。
   • mode: override（或无 mode）：自定义文档具有最高优先级。必须全面。
4. 如果未找到配置或 review-standards 文档，在整个工作流中使用内置默认值（完全向后兼容——与无配置的审查相同）。

review-standards 文档有 7 个章节映射到工作流步骤：

章节	影响步骤
§1 原子加载策略	步骤 2（加载相关原子）
§2 严重程度分类	步骤 4（生成报告）
§3 报告偏好	步骤 4（生成报告）
§4 范围规则	步骤 1（识别差异）
§5 洞察捕获偏好	步骤 5（收获学习并记录审查）
§6 健康日志偏好	步骤 5（收获学习并记录审查）
§7 自定义审查维度	步骤 3（运行针对性验证）

每个步骤注明配置应用的位置，带有"配置覆盖"标注。当不存在 review-standards 文档时，忽略标注并使用默认值。

工作流

步骤 1：识别差异

使用 framework:learning-harvest 加载行为。焦点提示："审查会话——焦点：所有类别"。跨类别的先前学习指导审查——重复出现的模式更可能被标记，已知脆弱区域获得额外关注。

确定要审查的代码并建立范围。

• PR 或提交：使用 git diff 获取变更的文件/行。差异是变更，而非整个代码库。
• 一组文件：用户指定文件。差异就是这些文件。
• 功能或模块：用户指向功能。从代码库中识别相关文件。

分类差异：

1. 触及了哪些架构层级？（根据加载的架构规则）——决定 architecture 是否加载。
2. 是否包含领域代码？（配置 domain_folder 中的文件或包含聚合、实体、值对象的文件）——决定 domain-driven-design 是否加载。
3. 触及安全敏感区域？（认证、授权、输入处理、数据库查询、外部 API 调用、文件 I/O、配置、密钥）——决定 secure-coding 是否加载。
4. 包含测试文件？ ——决定 test-quality 是否加载。

配置覆盖（§4 范围规则）： 如果 review-standards 文档定义了范围规则，在识别差异后应用：

• 目录排除：从差异中移除匹配排除模式的文件，然后再进行分类。
• 目录包含（始终全量扫描）：当差异触及始终全量扫描目录中的文件时，扩展差异以包含该目录中的所有文件。
• 周围代码策略：使用配置的策略（严格/默认/宽松）替代默认值。
• 依赖扩展：如果启用，还包括直接从变更文件导入的文件。

步骤 2：加载相关原子

始终加载：framework:clean-code——适用于所有代码，无论层级/用途。

根据差异分类有条件加载：

条件	加载	原因
差异触及多个层级、添加新文件或更改文件位置	framework:architecture	结构变更可能破坏依赖方向或层级职责
差异包含领域文件夹中的文件或修改领域对象	framework:domain-driven-design	领域变更可能破坏聚合边界、贫血模型或不变量执行
差异触及信任边界（HTTP 处理器、认证、数据库查询、外部 API、密钥、配置）	framework:secure-coding	安全敏感代码需要注入、验证和密钥检查
差异包含测试文件	framework:test-quality	测试代码有自己的质量标准（AAA、隔离性、命名）

当多个原子加载时，独立运行——每个原子的检查清单应用于差异中与其相关的部分。来自不同原子的发现在步骤 4 中合并。

配置覆盖（§1 原子加载策略）： 如果 review-standards 文档定义了原子加载规则，替代（override）或叠加（overlay）在上述表格之上应用：

• 始终加载覆盖：将额外原子移至始终加载（例如，每次审查都加载 secure-coding）。无论配置如何，clean-code 和 knowledge-priming 必须保持始终加载。
• 抑制的原子：列为抑制的原子永不加载，即使差异匹配触发条件。
• 自定义基于路径的触发器：如果差异包含匹配自定义路径模式的文件，无论标准条件如何，都加载关联原子。
• 修改的条件：替换条件原子的触发条件。

步骤 3：运行针对性验证

对于每个加载的原子，对差异应用两遍检查：

第一遍——自我验证清单：遍历原子的自我验证清单（原子 SKILL.md 中的编号项目）。对于每个检查，查看差异中的代码是否违反。记录违规行为，包括：

• 失败的具体检查项
• 确切的文件及行号
• 具体的修复建议

第二遍——反模式扫描：遍历原子的活跃反模式扫描（原子 SKILL.md 中的复选框项目）。对于每个反模式，检查差异是否表现出症状。记录匹配项，包括：

• 反模式名称
• 在差异中观察到的症状
• 针对具体代码的修复方案

范围规则：专注于差异。除非差异中的变更在周围代码中创建新的违规（例如，新依赖破坏了现有文件的依赖规则），否则不审查未更改的代码。当审查周围代码时，注明发现源于差异的影响，而非预先存在的问题。

配置覆盖（§7 自定义审查维度）： 如果 review-standards 文档定义了自定义审查维度，在原子验证遍之后运行：

• 对于每个自定义维度，检查差异是否匹配触发条件。
• 对于匹配的维度，使用相同的两遍方法对差异应用维度的检查清单：检查每个标准，记录发现（包括维度的默认严重程度或分类严重程度、文件位置、建议修复）。
• 自定义维度发现与原子发现在步骤 4 中合并。

步骤 4：生成报告

默认为摘要模式。如果用户要求详细/全面审查，使用完整模式。

摘要模式（默认）：

按严重程度排序呈现主要问题，每项一行。限制最重要的发现数量——不要枚举每个小问题。

对于每个发现：

[严重程度] 文件:行号 -- 描述 (原子名称：检查名称)

严重程度级别：

• critical（严重）——会导致 bug、安全漏洞或数据丢失。必须修复。
• warning（警告）——违反原则并会导致维护痛苦。应该修复。
• suggestion（建议）——可以改进，但当前工作正常。考虑修复。

当发现处于严重程度级别之间的边界时，使用 framework:collaborative-judgment——在行内注明不确定性及两种解释，而非静默分类。

以"做得好的地方"句子结尾，突出差异中的积极方面——良好的命名、适当的错误处理、清晰的测试结构、正确的层级放置。每次审查都应认可哪些地方运作良好，而不仅仅是指出问题。

完整模式（当用户要求详细/全面审查时）：

按原子组织发现。对于每个加载的原子：

## 整洁代码
- [warning] src/services/OrderService.ts:45 -- 函数 `processOrder` 执行验证、
  业务逻辑和持久化（违反单一职责）。将验证提取为卫语句，
  将持久化提取为仓储调用。
- [suggestion] src/services/OrderService.ts:72 -- 参数列表有 5 个参数。
  分组到 `ProcessOrderOptions` 对象中。

## 架构
- [critical] src/domain/Order.ts:12 -- 内层从外层导入
  （`import { DatabaseClient }`）。违反依赖方向规则。
  在内层定义接口，在外层实现。

在所有原子部分之后，添加：

• 做得好的地方：列出 2-3 个积极观察。
• 改进建议（可选）：如果存在超出单个发现的更广泛模式——例如，"考虑提取共享验证层"——在此注明。最多保留 1-2 个建议。

配置覆盖（§2 严重程度分类）： 如果 review-standards 文档定义了自定义严重程度级别或按原子的覆盖：

• 使用自定义严重程度级别定义替代（override）或合并（overlay）上述默认值。
• 应用按原子的严重程度覆盖：如果原子有最小严重性底线，将低于该底线的发现提升。如果原子有最大严重性天花板，将高于该天花板的发现限制。
• §7 中的自定义维度使用此部分的严重程度级别。

配置覆盖（§3 报告偏好）： 如果 review-standards 文档定义了报告偏好：

• 默认模式：使用配置的默认值（摘要或完整）替代摘要。
• 发现上限：对摘要模式应用配置的上限。
• 分组策略：使用配置的分组方式（按严重程度、按原子、按文件）替代默认值。
• "做得好的地方"开关：如果禁用，省略积极观察部分。
• 自定义报告部分：在指定位置包含任何配置的自定义部分。
• 自定义维度发现与原子发现在报告中合并，遵循相同的分组和严重程度排序。

步骤 5：收获学习并记录审查

在呈现报告后，收获学习并记录审查以获取项目健康可见性。

收获学习——使用 framework:learning-harvest 收获行为：

会话上下文："审查会话——对照原子标准进行代码质量评估"。综合并提出本次审查中的跨领域模式——重复出现的质量反模式、反复出现的结构问题、可靠性差距。用户确认哪些内容进入文档。

审查通常是操作学习的高信号生产者，因为它跨功能看到模式。然而，相同的严谨性适用：仅基于本次会话的发现提出模式，仅写入用户确认的内容。

记录审查——追加到 .lattice/reviews/review-log.md：

1. 如果不存在则创建 .lattice/reviews/ 目录。
2. 将结构化摘要追加到 .lattice/reviews/review-log.md。如果不存在，使用 # Review Log 标题创建文件。
3. 格式——每项保持在 8 行以内：

## YYYY-MM-DD — [功能/范围名称]
- **范围**：[文件数量]，[触及的层级]
- **原子**：[为此审查加载的原子]
- **结果**：[严重数量] 严重，[警告数量] 警告，[建议数量] 建议
- **关键发现**：[前 2-3 个具体发现，每项一行]
- **优势**：[一个积极亮点]

4. 健康信号，而非详细报告。保持简洁——要点有助于跟踪趋势，而非复制完整审查。
5. 如果日志超过约 20 项，将最旧的条目移动到文件顶部的单行 ## History 摘要部分。

配置覆盖（§5 洞察捕获偏好）： 如果 review-standards 文档定义了洞察捕获偏好：

• 捕获标准：应用自定义标准（例如，"始终捕获安全发现"）作为向 framework:learning-harvest 提出候选项时的额外指导。

配置覆盖（§6 健康日志偏好）： 如果 review-standards 文档定义了健康日志偏好：

• 自定义字段：在每个日志条目中包含额外字段（例如，"置信度"、"估计修复时间"）。
• 条目上限：使用配置的每行限制替代每项 8 行。
• 历史上限：使用配置的上限替代约 20 项后再滚动。
• 附加指标：在每个条目中包含配置的指标（例如，每文件发现数、最常触发的原子）。
• 历史压缩格式：使用配置的格式用于滚出的条目。