| name | review |
| description | 通过对相关原子（atoms）组合验证清单来执行结构化的代码审查。根据代码变更范围有条件地加载原子——始终加载 clean-code，仅在变更触及架构/领域驱动设计/安全/测试领域时加载 architecture/DDD/security/tests。生成按严重程度排序的报告，包含具体位置和修复建议。当用户要求'审查这个'、'代码审查'、'质量检查'、'验证代码'、'检查我的代码'、'审查差异'或'审查这个 PR'时使用。 |
代码审查
必需技能
根据范围加载/应用技能（参见步骤 2 中的条件加载）：
framework:knowledge-priming -- 加载项目上下文（技术栈、架构、约定）以对照实际标准进行评估（始终加载）framework:learning-harvest -- 加载先前的操作学习以指导审查；在会话结束时收获新模式（始终）framework:collaborative-judgment -- 将边界发现以两种解释方式呈现，而非静默分类（始终加载）framework:clean-code -- 代码工艺：单一职责、命名、复杂度、错误处理（始终加载）framework:architecture -- 结构：层级规则、依赖方向、架构流（条件加载）framework:domain-driven-design -- 领域建模：聚合、实体、值对象（条件加载）framework:secure-coding -- 安全：信任边界、注入、密钥、输入处理（条件加载）framework:test-quality -- 测试：AAA 结构、隔离性、断言、命名（条件加载）
配置解析
审查分子支持通过 review-standards 文档（来自 review-refiner 或手写）进行可选配置。配置审查流程——而非原子检查什么（那是通过原子精炼器进行的原子级配置）。
解析步骤：
- 在仓库根目录查找
.lattice/config.yaml。
- 检查配置键
paths.review_standards。
- 如果文档存在于该路径，读取并检查 YAML frontmatter 中的
mode：
mode: overlay：先读取内置默认值，然后将文档的章节叠加在上面。通过标题匹配章节——自定义替换匹配的默认值，新内容追加。mode: override（或无 mode）：自定义文档具有最高优先级。必须全面。
- 如果未找到配置或 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 获取变更的文件/行。差异是变更，而非整个代码库。
- 一组文件：用户指定文件。差异就是这些文件。
- 功能或模块：用户指向功能。从代码库中识别相关文件。
分类差异：
- 触及了哪些架构层级？（根据加载的架构规则）——决定
architecture 是否加载。
- 是否包含领域代码？（配置
domain_folder 中的文件或包含聚合、实体、值对象的文件）——决定 domain-driven-design 是否加载。
- 触及安全敏感区域？（认证、授权、输入处理、数据库查询、外部 API 调用、文件 I/O、配置、密钥）——决定
secure-coding 是否加载。
- 包含测试文件？ ——决定
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：
- 如果不存在则创建
.lattice/reviews/ 目录。
- 将结构化摘要追加到
.lattice/reviews/review-log.md。如果不存在，使用 # Review Log 标题创建文件。
- 格式——每项保持在 8 行以内：
## YYYY-MM-DD — [功能/范围名称]
- **范围**：[文件数量]，[触及的层级]
- **原子**：[为此审查加载的原子]
- **结果**：[严重数量] 严重，[警告数量] 警告，[建议数量] 建议
- **关键发现**：[前 2-3 个具体发现，每项一行]
- **优势**：[一个积极亮点]
- 健康信号，而非详细报告。保持简洁——要点有助于跟踪趋势，而非复制完整审查。
- 如果日志超过约 20 项，将最旧的条目移动到文件顶部的单行
## History 摘要部分。
配置覆盖（§5 洞察捕获偏好）： 如果 review-standards 文档定义了洞察捕获偏好：
- 捕获标准：应用自定义标准（例如，"始终捕获安全发现"）作为向
framework:learning-harvest 提出候选项时的额外指导。
配置覆盖（§6 健康日志偏好）： 如果 review-standards 文档定义了健康日志偏好：
- 自定义字段：在每个日志条目中包含额外字段（例如，"置信度"、"估计修复时间"）。
- 条目上限：使用配置的每行限制替代每项 8 行。
- 历史上限：使用配置的上限替代约 20 项后再滚动。
- 附加指标：在每个条目中包含配置的指标（例如，每文件发现数、最常触发的原子）。
- 历史压缩格式：使用配置的格式用于滚出的条目。
