verification

验证会确认原始请求是否确实得到满足，这与 sniper 不同，sniper 只确认代码是否整洁。验证按 6 个步骤进行：逐字重读原始请求，列出每项验收标准（明确和隐含的），用具体证据（测试输出、日志、截图、差异）逐项验证，运行完整测试套件以检查回归，检查每个修改过的文件以确认没有意外副作用，然后在记录“功能已解决”这一声明前，先将其交由 `challenger` Agent 审核。

第 6 步始终会保存 .claude/apex/docs/verify-{task-slug}.md：仅在当前上下文中声明“已正常运行”无法跨会话留存，而后续关卡（sniper、elicitation）实际检查的正是这一产物。在 APEX 中，它位于 eLicit 和 eXamine 之间：只有验证和 sniper 都通过，任务才算完成。

完成前验证

概述

Sniper 验证代码质量。验证确认功能已得到解决。 结束任何任务前，两者缺一不可。

Sniper 会捕获 lint 错误、SOLID 违规和代码风格问题。验证则确保原始请求确实得到满足——行为正确、输出正确、修复正确。任务即使通过 sniper 且零错误，功能上仍可能有误。

方面	Sniper	验证
关注点	代码质量	功能正确性
检查内容	Lint、SOLID、风格	验收标准、回归、副作用
运行时机	任何代码变更后	将任务标记为完成前
结果	代码整洁	问题解决

---

Agent 工作流

调用后，在将任何任务标记为完成之前，请遵循以下 6 步验证流程。

6 步验证流程

第 1 步：重新阅读原始请求 回到原始 issue、任务描述或用户消息，逐字阅读。不要依赖记忆或假设。

第 2 步：列出所有验收标准 从原始请求中提取所有明确和隐含的要求，并为它们编号。如果请求含糊不清，就列出合理用户会期待的内容。 列出所有属于负责人的请求的部分，包括任务中途提出的补充要求；针对某个实体（垃圾内容、slug、格式）获得的规则也适用于同类实体——用 grep 检查它们是否一致。

第 3 步：使用证据逐项验证标准 针对每项标准，提供具体的解决证据：

• 展示预期行为的测试输出
• 确认修复的日志输出
• 展示 UI 变更的截图
• 展示实现内容的代码差异

**完成前先检查（规范规则）：**打开实际输出——渲染后的页面 / 截图、提取的帧、实际目标的运行时日志（正在运行的开发服务器、真实 DB、已安装的构建）——并说明你在其中看到了什么。测试通过或孤立的测试夹具 ≠ 完成；崩溃修复应先在测试中复现崩溃，而“错误消失” ≠ 行为正确。

第 4 步：检查回归 运行完整测试套件。比较修改前后的结果。不得引入新的失败或警告。

第 5 步：检查副作用 检查每个已修改的文件。确认没有意外改动无关代码。除非确有需要，否则确认依赖项和配置未发生变化。

第 6 步：确认功能问题已解决——质疑，然后写入产物 在写下“原始问题在功能上已解决”之前，必须始终将该结论交由 challenger Agent（或 challenge 技能）审查，并使用全新上下文：结论 = “功能上已解决” + 第 3 至第 5 步的证据，绝不能包含调查推理。这是系统性要求——每个 Verify 门禁都必须执行，没有例外，就像每次 eXamine 都会运行 sniper 一样。只有收到 CONFIRMED 结果（或负责人明确接受的 UNCERTAIN 结果）后，才能给出“功能上已解决”的结论。必须先解决 REFUTED 结论（修复并重新验证），然后才能向负责人提出该结论——这是软门禁，不是硬性否决。

写入 .claude/apex/docs/verify-{task-slug}.md（模板：references/verify-template.md）：检查每个验证步骤；每项标准都附上一条证据（命令输出、日志摘录、截图路径或代码差异）；并附上本步骤的质疑结论。仅在上下文中声明“已生效”无法跨会话保留；书面产物是门禁（sniper、后续 elicitation 阶段）实际检查的保障。然后在回复中明确写出：“原始问题在功能上已解决”，并附上证据摘要，或列出尚未解决的事项。任何没有对应证据的标准都应标为“未验证”，绝不能笼统地归入“已完成”。

{task-slug}：根据 apex-methodology/references/init-tracking.md 确定（git 分支 slug 或活跃的 TaskCreate id）——采用与 elicitation 技能的产物相同的模式。

---

参考指南

资源	路径	内容
检查清单	references/checklist.md	包含所有类别的完整验证清单
常见遗漏项	references/common-misses.md	经常被遗忘的验证项目
产物模板	references/verify-template.md	verify-{task-slug}.md 模板 + task-slug 推导方式

---

与 APEX 集成

在 APEX 工作流中，验证在 eLicit 和 eXamine 之间进行：

Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)

这可确保在验证代码质量之前确认功能正确性。只有验证和 sniper 都通过，任务才算完成。

---

关键规则

规则	原因
绝不能跳过重新阅读原始请求	避免解决错误的问题
每项标准都必须有证据	“能运行”并不能作为证据
运行完整测试套件，而不仅是新增的测试	捕获回归问题
审查所有已修改的文件	捕获意外的副作用
验证和 sniper 都必须通过	没有正确性，再好的质量也毫无用处
第 6 步将 verify-{task-slug}.md 写入磁盘	未持久化的上下文内自我审查会在不同会话间退化