代码质量检查
对近期编写的代码进行全面质量验证。结合规格合规性、跨层安全性和预提交检查。
步骤 1：识别变更内容
git diff --name-only HEAD
git status
步骤 2：阅读任务产物和适用规格
按顺序阅读当前任务产物：
prd.mddesign.md（如果存在）implement.md（如果存在）
python3 ./.trellis/scripts/get_context.py --mode packages
对于每个变更的包/层，阅读规格索引并遵循其 质量检查 部分：
cat .trellis/spec/<package>/<layer>/index.md
阅读引用的具体指南文件——索引只是一个指针，并非目标本身。
步骤 3：运行项目检查
运行项目的 lint、类型检查和测试命令。在继续之前修复所有失败项。
步骤 4：对照清单评审
代码质量
- Linter 通过？
- 类型检查器通过（如果适用）？
- 测试通过？
- 没有残留的调试日志？
- 没有抑制的警告或类型安全绕过？
测试覆盖率
- 新增函数 → 添加了单元测试？
- 错误修复 → 添加了回归测试？
- 行为变更 → 现有测试已更新？
规格同步
-
.trellis/spec/需要更新吗？（新模式、约定、经验教训）
“如果我修复了一个 bug 或发现了一些不明显的东西，我应该记录下来以便未来的我不会遇到同样的问题吗？” → 如果是，则更新相关的规格文档。
范围纪律
- 是否有任务不需要的代码整理？
- 是否为尚未存在的用例添加了抽象、配置或扩展点？
- 是否为不可能发生的状态添加了推测性的回退？
- 是否有文件更改而验收标准未提及？
- 是否在调用方添加了变通方案，而不是在实际行为所在的位置进行修复？
步骤 5：跨层维度（如果适用）
如果你的变更仅限于单层，请跳过此步骤。
A. 数据流（变更涉及 3 层以上）
- 读取流程正确追踪：存储 → 服务 → API → UI
- 写入流程正确追踪：UI → API → 服务 → 存储
- 类型/模式在层之间正确传递？
- 错误正确传播给调用者？
B. 代码复用（修改常量、创建工具函数）
- 在创建新代码前搜索了现有的类似代码？
grep -r "pattern" src/ - 如果相同的值重复出现，它是否代表一个稳定的概念，其调用者必须同步更改？仅在此情况下才提取——两个仅仅今天碰巧相同的字面量应保持独立。
- 批量修改后，所有出现的地方都已更新？
C. 导入/依赖（创建新文件）
- 正确的导入路径（相对路径与绝对路径）？
- 没有循环依赖？
D. 同层一致性
- 其他使用相同概念的地方是否一致？
步骤 6：报告并修复
报告你发现的每一个违规项。然后：
- 机械性和局部性问题（lint 细节、缺少类型、错误的导入、死分支、失败的断言）→ 就地修复，然后重新运行项目检查。
- 设计或判断性问题（命名共享概念、移动模块边界、更改公共接口、重新分配行为所在位置）→ 记录证据和你的建议，然后停止。不要静默地重写它们。
如果修复会触及当前任务范围之外的文件，请说明并停止，而不是扩大变更范围。