sdlc-verify

sdlc-verify

每个意图在 sdlc-apply 后默认执行此步骤：实现者检查自己的工作时往往不够严格，也容易漏掉新读者能发现的问题。用户可以针对某个意图或某次运行免除此步骤；否则，不要从 apply 直接进入 close。

评审者不能看过实现过程中的对话。使用一个全新的子 Agent（可以是同一模型），或一个单独的新会话；角色名称或默认调度方式不能证明隔离已实现，因此要确认这一点。实现者不能通过对自己工作的评审。评审者除了 report.md 外不得编辑任何内容。如果没有独立评审途径：critical 级别写一份 blocked 报告；change 级别在 ## Result 中写明“未经独立评审”，由用户决定是否接受。

change 级别是轻量评审：仅检查验收项、差异和受影响的检查。critical 级别还要执行下方的 Spec、迁移和故障路径检查。

交接

只向评审者提供：仓库路径、slug、已提交的候选版本（reviewed_head）、intent.md 中的 base、intent.md 的路径，以及用户明确要求的原文措辞。不要总结已完成的工作或原因。

评审者的工作

1. 检查快照：HEAD 等于 reviewed_head，没有未提交的更改涉及差异中的文件（忽略他人的无关脏文件），步骤已勾选，且已填写 ## Result。否则标记为 blocked。
2. 双向比对用户的措辞、意图和差异：每个要求的结果都已真正实现（不是手动回退方案或测试替身），并且没有加入用户未要求的内容。
3. 阅读完整差异 base..reviewed_head：检查逻辑、信任边界、错误处理、对任何已更改共享契约的调用方造成的回归，以及是否符合现有模式。
4. 自行运行受影响的检查。仅当检查原始输出，且代码、配置和命令完全一致时，才能复用之前的结果；绝不盲目信任他人的说法。
5. 验证每个验收项。对于 UI，在运行中的本地应用里走通主路径和错误路径。对于管道，检查消费者或发出的请求，而不仅是存储的值。对于有状态流程，检查失败和重试后持久化的状态。对于迁移，在一次性数据库上确认从已应用的历史版本升级时保留了数据。
6. 绝不接触生产环境或共享的默认数据库。对于 critical 级别，或存在无关文件脏改动时，在 reviewed_head 的分离检出中运行检查（git worktree add --detach <tmp> <reviewed_head>），之后将其移除。
7. 遇到第一个 CRITICAL 就停止。不要重新运行原始输出已能证明的内容。

将验证范围限定在本次更改及其实际影响范围内。不要重放无关功能的使用流程，也不要重新认证整个产品。

报告

写入 intent/<slug>/report.md，不超过 40 行：

---
slug: example-slug
reviewed_head: <full commit hash>
verdict: pass   # pass | fail | blocked
---

# Report: short name

## Checked
- PASS | <acceptance item or requirement> | <command or action> | <what was observed, evidence path>

## Findings
None. Or: - CRITICAL | WARNING | SUGGESTION: <file:line> what, and what evidence would settle it.

## Not checked
None. Or what and why. For `blocked`: Reason and Recovery lines instead.

pass 需要为每个验收项提供证据、候选版本已提交，且没有 CRITICAL 发现。不要提交报告；close 提交不需要报告（该文件夹会被删除）；在此之前先阅读报告。在 reviewed_head 之后修改已评审文件会使报告过期，需要重新评审。fail 后的修复由 sdlc-apply 完成；新的独立评审者应阅读发现和修复提交，而不是重新评审整个更改。第二次 fail 会终止循环：向用户报告这一结果，并提供范围尽可能小的复现步骤。