loom-requesting-code-review

请求代码审查

触发条件

• verification-before-completion 通过后，需要人工代码审查时
• 用户主动要求发起代码审查
• 分支开发完成、准备合并前

完成条件与下一步

• 审查请求已生成并发送
• 下一步：等待审查反馈 → 使用 loom-receiving-code-review 处理反馈

预审查清单

在请求审查前，确保：

• 所有变更已提交
• 编译通过（BUILD_CMD）
• 静态分析通过（VET_CMD）
• 所有测试通过（TEST_CMD）
• 代码符合项目编码红线
• 图后端状态已确认（可用时通过 loom_graph_status 查询，否则注明图查询已跳过）
• 已完成 Standards + Spec 双轴预审查，或已说明跳过某一轴的原因

执行流程

Step1：准备审查材料

1. 确认所有变更已完成
2. 运行验证确保代码质量（读取宪章中的 BUILD_CMD、VET_CMD、TEST_CMD 并执行）

Step2：双轴预审查

请求人工审查前，先对当前 diff 做本地预审查。必须先确定 fixed point，例如用户指定的 commit/branch/tag、PR base、main 或 HEAD~1；fixed point 不明确时先问用户。

Standards 轴

检查代码是否符合项目标准和通用工程质量：

• .loom/rules/constitution.md、ADR、CONTRIBUTING、CODING_STANDARDS 等项目规范。
• 架构分层、模块边界、命名、错误处理、日志、配置、安全和性能。
• 测试质量：是否测行为、是否覆盖边界、是否避免实现耦合。
• 固定坏味道基线：重复、过长函数、霰弹式修改、循环依赖、全局状态、过度 mock、临时兼容层、未解释的复杂度。

Spec 轴

检查实现是否忠实满足来源需求：

• 从 commit message、PR 描述、specs/<date+feature>/spec.md、plan.md、issue/PRD 或用户原始请求定位 spec 来源。
• 对照验收标准、Requirement ID、边界条件和不做范围。
• 缺少 spec 来源时，明确写“Spec 轴跳过：未找到来源”，或向用户请求来源；不得凭想象补需求。

输出必须分成两个独立区块，不合并、不重排：

## Standards

- <finding 或 无发现>

## Spec

- <finding、跳过原因 或 无发现>

## 预审查摘要

- Standards findings: <数量>，worst: <最严重问题或 none>
- Spec findings: <数量/跳过>，worst: <最严重问题或 none>

若任一轴发现 blocker，先修复并重新验证，再生成审查请求。

Step3：整理变更摘要

git diff --stat
git log --oneline -10

Step4：生成审查请求

# 代码审查请求

**功能：** <feature-name>
**分支：** feature/<date>-<feature-name>

## 变更统计

<git diff --stat 输出>

## 主要变更

1. <变更说明 1>
2. <变更说明 2>

## 重点关注

1. 架构设计：xxx
2. 安全性：xxx
3. 性能：xxx

## 自测情况

- [x] 编译通过（BUILD_CMD）
- [x] 静态分析通过（VET_CMD）
- [x] 测试通过（TEST_CMD）
- [x] 代码符合编码红线
- [x] 图后端已同步，或已注明索引查询跳过

## 变更详情

| 文件          | 变更类型 | 说明            |
| ------------- | -------- | --------------- |
| path/to/file1 | 新增     | XxxService 实现 |
| path/to/file2 | 修改     | 新增方法        |

## 审查重点

- [ ] 架构合规性
- [ ] 代码质量
- [ ] 安全性检查
- [ ] 性能影响

约束

• 审查请求必须包含完整的变更摘要
• 必须标注重点关注项
• 必须提供自测情况
• Findings 必须优先于总结，且包含文件/行号或明确的证据来源。
• 缺少 spec 来源时不得伪造 Spec findings。