csh
1911d2dda3
Use plan-status as the only machine state source for plan queueing, claiming, and finishing. Route record-plan through queue insertion and update templates/prompts to match the single-state model. BREAKING CHANGE: playbook.py -record-spec and main_loop.py record are removed.
74 lines
1.9 KiB
Markdown
74 lines
1.9 KiB
Markdown
# 变更验证模板
|
||
|
||
<!--
|
||
用途：在声明“完成 / 修复 / 可交付”前，用 fresh run 证明改动成立。
|
||
触发：代码、配置、模板、规则修改后；准备交付结果前。
|
||
-->
|
||
|
||
## 验证目标
|
||
|
||
- 这次改动要证明什么
|
||
- 哪些行为必须通过
|
||
- 哪些验证本轮不做
|
||
|
||
## 先读
|
||
|
||
- `AGENT_RULES.md`
|
||
- `memory-bank/progress.md`
|
||
- 如存在：`docs/prompts/custom/verify.md`
|
||
|
||
## 规则
|
||
|
||
- 没有证据，不宣称完成
|
||
- 验证命令必须 fresh run
|
||
- 局部修改优先局部验证
|
||
- 不能运行的验证必须写明原因
|
||
- 不手工改写 `plan-status` 状态块
|
||
- 如本轮来自 `main_loop.py claim`，验证通过不等于 Plan 完成；Plan
|
||
`done` 还必须完成当前 Plan 变更归档/提交
|
||
|
||
## 验证步骤
|
||
|
||
1. 做语法或结构检查，确认改动文件可读、可解析
|
||
2. 运行与本次改动直接相关的验证命令
|
||
3. 记录命令、结果和关键输出
|
||
4. 复核 diff 是否只包含预期修改
|
||
5. 如本轮来自 `main_loop.py claim`，复核 `plan-status` 与当前声明一致
|
||
6. 如本轮来自 `main_loop.py claim` 且结果为 `done`，复核当前 Plan
|
||
相关差异是否已经归档/提交；未归档时只能声明“验证完成”，
|
||
不能声明“Plan 完成”
|
||
7. 汇总未覆盖项和剩余风险
|
||
|
||
## 输出协议
|
||
|
||
```markdown
|
||
## Validated
|
||
- ...
|
||
|
||
## Evidence
|
||
- ...
|
||
|
||
## Not Validated
|
||
- ...
|
||
|
||
## Risks
|
||
- ...
|
||
```
|
||
|
||
## 状态留痕复核
|
||
|
||
- 如本轮来自 `main_loop.py claim`，`plan-status` 是否已经通过
|
||
`main_loop.py finish` 写回
|
||
- 如本轮来自 `main_loop.py claim` 且结果为 `done`，当前 Plan 相关差异
|
||
是否已经归档/提交，或是否已说明无当前 Plan 差异
|
||
|
||
## 停止条件
|
||
|
||
- 关键验证失败时停止并汇报
|
||
- 当前 Plan 相关差异未归档/提交时，不得声明 Plan 完成
|
||
- 证据不足以支持“完成”结论时停止并汇报
|
||
|
||
---
|
||
|
||
**最后更新**：{{DATE}}
|