review-refiner

name	review-refiner
description	促进结构化对话以自定义审查分子的工作方式——包括原子加载规则、严重程度分类、报告格式、范围规则、洞察捕获和健康日志。生成正式的 review-standards.md 文档，供审查分子用作其流程配置。当用户说'自定义审查'、'配置审查'、'审查偏好'、'审查设置'、'更改审查流程'或'设置审查'时使用。

审查精炼器

产出内容

• 输出：.lattice/standards/review-standards.md（或来自 .lattice/config.yaml → paths.review_standards 的自定义路径）
• 两种模式：
  • 叠加模式（mode: overlay）：仅包含与默认值不同的部分的精简文档。审查分子首先读取其内置的默认值，然后将此文档的章节叠加在上面。这是预期的常见情况。
  • 覆盖模式（mode: override）：全面的独立文档，完全替换分子的内置默认值。适用于具有根本不同审查流程的团队。
• 默认模式：叠加模式——仅生成用户想要更改的内容
• 配置键：.lattice/config.yaml 中的 paths.review_standards
• 消费者：审查分子（不是原子——这是第一个分子级配置）
• 模板：读取 ./assets/template.md 以获取完整的文档结构、默认内容和访谈指导注释

范围澄清

此精炼器配置审查流程——审查分子如何编排原子输出。它不配置原子检查什么。

属于此处（流程编排）	属于原子精炼器（质量标准）
哪些原子在何时加载	原子运行什么检查
严重程度级别定义	什么构成违规
报告格式和分组	检查清单项目和反模式
差异范围规则	层级定义、命名规则
洞察捕获偏好	领域建模规则
健康日志格式	安全检查阈值
自定义审查维度	原子特定的验证逻辑

如果用户询问更改原子检查的内容，将他们重定向到适当的原子精炼器（architecture-refiner、clean-code-refiner、ddd-refiner）。

开始之前

检查现有文档

在开始访谈之前，检查自定义文档是否已存在：

1. 读取 .lattice/config.yaml——paths.review_standards 是否指向文件？
2. 如果是，读取该文件。询问用户：
   • "您已经有一个审查标准文档。您想要修订它（更新特定章节）、重新开始（新访谈）还是添加内容（添加新章节）？"
   • 修订：加载现有文档，仅遍历用户想要更改的章节，并就地更新。
   • 重新开始：继续下面的完整访谈流程。
   • 添加内容：跳到用户想要添加的章节（例如，自定义维度）。
3. 如果没有配置或没有现有文档，继续完整访谈流程。

扫描上下文

寻找影响对话的信号：

• 现有审查历史：检查 .lattice/reviews/review-log.md——哪些原子一直在加载？存在什么严重程度模式？是否有重复的发现？
• 现有学习：检查 .lattice/learnings/operational-learnings.md——捕获了什么模式？文件是否在任何类别中变得密集？
• 项目结构：代码库是什么样的？是否有应该排除或始终扫描的目录？
• 现有原子精炼器：哪些原子精炼器已运行？（检查 .lattice/config.yaml 中的 paths.architecture、paths.clean_code、paths.ddd_principles）这告诉您团队关心哪些原子。

在开始时与用户分享相关发现："我查看了您的审查历史并注意到 [模式]。我将将其作为我们对话的上下文。"

如果项目是新的且没有审查历史，使用默认值作为起点继续。

选择模式

对话中的第一个决策。呈现三个选项：

"您希望如何配置您的审查流程？

1. 自定义特定章节（叠加）——保留默认值，仅更改与您的项目不同的部分。这将生成一个精简文档。大多数团队选择此项。
2. 从头开始定义所有内容（覆盖）——遍历所有章节并生成全面的独立文档。
3. 仅添加项目特定章节（叠加并添加）——保留所有默认值不变，为您的团队的具体规则添加新章节（例如，自定义审查维度）。

默认值涵盖了一个坚实的审查工作流。除非您的审查流程需要根本不同，否则推荐选项 1。"

映射选择：

• 选项 1 和 3 → mode: overlay
• 选项 2 → mode: override

促进方法

对话风格

• 一次一个章节。不要一次性倾倒所有问题。按顺序遍历模板。
• 默认值优先。对于每个章节，简要总结默认值，然后询问是否匹配。不要逐字阅读整个默认值——总结要点并询问。
• 记录决策，而非讨论。输出文档作为规范阅读，而非会议记录。"我们讨论了 X 并决定 Y"是错误的。"Y"是正确的。
• 探查，而非审问。当用户的回答模糊时，使用模板指导注释中的探查问题作为后续问题，而非检查清单。

对于叠加模式

这应该很快。许多章节将是"保持原样"。

1. 简要呈现每个章节的默认值（2-3 句摘要，而非完整内容）。
2. 询问："这符合您的项目吗，或者您想要更改它？"
3. 如果用户说匹配 → 跳过它（该章节不会出现在输出中）。
4. 如果用户想要更改 → 深入该章节，讨论具体内容，记录更改。
5. 最后，询问："您是否想要添加任何额外的审查流程偏好？"（例如，自定义维度、额外报告章节）。
6. 仅用户更改或添加的章节出现在输出文档中。

对于覆盖模式

这是彻底的。每个章节都会得到关注并出现在输出中。

1. 完整详细地遍历每个章节。
2. 用户确认、修改或替换每个章节。
3. 所有章节出现在输出中——未更改的使用默认值，已更改的使用用户版本。

常见场景

• "我同意所有内容" → 不需要自定义文档。告诉用户："内置默认值已经激活并符合您的偏好。不需要自定义文档——审查分子将自动使用默认值。"
• "我希望每次审查都有安全检查" → 仅叠加 §1：将 secure-coding 从条件加载移至始终加载。
• "我希望安全发现有更严格的严重程度" → 叠加 §1 + §2（原子加载与按原子的严重程度覆盖耦合）。
• "我们希望从审查中排除生成的代码" → 仅叠加 §4：添加目录排除。
• "我们希望审查中包含性能检查" → 仅叠加 §7：添加"性能模式"自定义维度。
• "我们希望不同的报告格式" → 仅叠加 §3：调整分组、格式或切换"做得好的地方"。
• "我们的洞察文件变得太大了" → 仅叠加 §5：调整修剪阈值或添加分类。

按章节访谈指南

读取 ./assets/template.md 并按照每个章节的 <!-- INTERVIEW GUIDANCE: --> 注释操作。这些注释包含要询问的具体问题、探查问题以及可自定义与固定的内容。

跨章节依赖表

早期章节的决策影响后期章节。当用户更改早期章节时，标记依赖章节：

决策在	影响	如何影响
§1 原子加载	§2、§3、§5、§6	按原子的严重程度覆盖引用原子名称；报告章节映射到加载的原子；洞察类别跟随原子；日志原子名称必须匹配
§2 严重程度	§3、§5、§6、§7	报告排序遵循严重程度级别；捕获标准引用严重程度；日志计数使用严重程度名称；自定义维度需要严重程度分配
§4 范围规则	§1、§7	扩展的范围可能触发更多条件原子；自定义维度遵循范围规则
§7 自定义维度	§2、§3	自定义维度贡献需要严重程度分类和报告放置的发现

当触发依赖时，通知用户："既然您更改了 [X]，我们也应该审查 [Y]——它受该决策影响。"

叠加模式特定章节流程

对于 7 个默认章节中的每一个：

1. 用 2-3 句话总结章节的要点。
2. 询问："这符合您的项目吗？"
3. 是 → 转到下一章节。该章节不会出现在输出中。
4. 否 → 使用模板指导深入章节细节。生成用户版本。
5. 所有 7 个章节之后，询问新章节。
6. 仅用户更改或添加的章节出现在输出文档中。

覆盖模式特定章节流程

对于 7 个默认章节中的每一个：

1. 呈现章节的完整内容。
2. 询问："这可以原样使用，还是您想要修改它？"
3. 原样 → 在输出中包括默认内容不变。
4. 修改 → 讨论更改，生成修改后的版本。
5. 所有 7 个章节之后，询问新章节。
6. 所有章节都进入输出。

输出生成

对于叠加模式

1. YAML frontmatter：mode: overlay
2. 叠加序言文本（来自模板）
3. 仅列出包含章节的目录
4. 仅用户更改或添加的章节
5. 每个章节必须自包含——它是默认值中该章节的完整替换。不要编写差异或部分章节。
6. 章节标题必须与模板完全匹配（审查分子通过标题匹配章节）
7. 新章节（§8+）包含在默认章节之后
8. 页脚包含项目名称、日期、模式

对于覆盖模式

1. YAML frontmatter：mode: override
2. 覆盖序言文本（来自模板）
3. 完整目录（所有 7+ 个章节）
4. 所有章节：未更改的使用默认值，已更改的使用用户版本，新章节在末尾
5. 页脚包含项目名称、日期、模式

两种模式通用

从输出中删除所有 <!-- INTERVIEW GUIDANCE: --> 注释。最终文档是一个干净的规范。

确定输出路径：

1. 如果 .lattice/config.yaml 存在且有 paths.review_standards，使用该路径。
2. 否则，默认为 .lattice/standards/review-standards.md。

写入文档：

1. 如果不存在则创建 .lattice/standards/ 目录（和 .lattice/ 父目录）。
2. 将文档写入确定的路径。

更新配置：

1. 如果 .lattice/config.yaml 不存在，使用以下内容创建它：

   paths:
     review_standards: .lattice/standards/review-standards.md
   

2. 如果 .lattice/config.yaml 存在但没有 paths.review_standards，添加该键。保留所有现有内容。
3. 如果 .lattice/config.yaml 存在且已有该键，则不需要配置更改。

向用户确认： "您的审查标准文档已写入 [叠加|覆盖] 模式的 [路径]。审查分子现在将在运行审查时[在默认值之上 | 替代默认值]使用它。"

文档质量检查

在写入最终文档之前，验证：

叠加模式检查

• 每个包含的章节自包含且完整（不是差异或部分章节）
• 章节标题与模板完全匹配（供审查分子通过标题匹配）
• 没有剩余的 <!-- INTERVIEW GUIDANCE: --> 注释
• frontmatter 有 mode: overlay
• 仅包含已更改/添加的章节——未更改的章节被省略
• 按原子的严重程度覆盖引用实际可加载的原子（§1 ↔ §2 一致性）
• 自定义维度严重程度级别存在于 §2 的严重程度列表中（§7 ↔ §2 一致性）

覆盖模式检查

• 模板中的每个章节都存在（§1 到 §7，以及任何新章节）
• 严重程度级别在所有章节中一致
• 按原子的覆盖引用有效的原子名称
• 自定义维度使用 §2 中定义的严重程度级别
• 报告偏好引用有效的分组策略
• 没有剩余的 <!-- INTERVIEW GUIDANCE: --> 注释
• frontmatter 有 mode: override
• 文档可作为独立规范阅读

两种模式通用

• frontmatter 是有效的 YAML，具有正确的模式值
• 文档是格式良好的 markdown
• 配置文件（.lattice/config.yaml）正确更新
• 输出路径存在且可写
• 跨章节依赖一致（原子名称、严重程度级别、类别）