# 变更验证模板

<!--
用途：在声明“完成 / 修复 / 可交付”前，明确验证范围与证据
触发：代码修改、配置修改、模板修改、规则修改后
-->

## 验证目标

- 这次改动要证明什么？
- 哪些行为必须通过？
- 哪些验证本轮不做？

## 验证步骤

### 1. 语法 / 结构检查

- 确认修改文件可读、可解析、无明显结构错误

### 2. 定向验证

- 只跑与本次改动直接相关的验证命令
- 记录命令、结果和关键输出
- 如仓库存在项目私有验证提示词（例如 `docs/prompts/custom/verify.md`），先读取并执行其中的附加约束

```bash
{{VERIFY_CMD}}
```

### 3. 差异复核

- 核对 diff 是否只包含预期修改
- 确认没有误删、误改、命名漂移或路径漂移

### 4. 状态留痕复核

- `workflow-state.phase` 是否与当前声明一致
- `plan-status` 是否已经通过 `main_loop.py finish` 写回
- 如为代码类任务，`workflow-state` 中是否保留：
  `executor=executing-plans`
  `constraints=karpathy-guidelines,.agents,AGENT_RULES`

### 5. 剩余风险

- 本轮未覆盖的验证
- 环境限制
- 需要人工确认的点

## 输出格式

```markdown
## 验证结果

- 已验证：...
- 证据：...
- 未验证：...
- 风险：...
```

## 原则

- 没有证据，不宣称完成
- 局部修改优先局部验证
- 不能运行的验证要明确写原因
- 不手工改写 `workflow-state` 或 `plan-status` 状态块

---

**最后更新**：{{DATE}}