dvfy

name	dvfy
description	验证证据优先级体系——L1-L5 五级证据、Done 判定门槛矩阵、完成前四问、无法验证处理规范、运行态验证方法指引。触发场景：(1) 标记 InReview 或 Done，(2) 选择证据等级，(3) 判断是否验证充分，(4) 处理无法验证的项，(5) 用户说"验证"、"证据"、"Done"、"验收"
argument-hint	[任务ID] [证据等级]
context	fork
agent	Explore
model	haiku
allowed-tools	["Bash","Read"]
effort	low
hooks	{"TaskCompleted":[{"hooks":[{"type":"command","command":"python3 ${CLAUDE_SKILL_DIR}/../hooks/scripts/task_completed.py 2>/dev/null || true"}]}]}

diwu-verify

证据优先级体系：验证的核心规则。未验证 = 未完成。

---

L1-L5 五级证据表格

等级	名称	说明	示例
L1	运行态证据	真实输出已发生可识别变化	发起请求后返回值变了、页面渲染结果变了、文件产物生成了
L2	调用链证据	底层状态切换已被观测到	日志显示命中新代码路径、数据库记录已写入、状态机已转移
L3	自动化断言	测试/脚本/断言自动判定	单元测试全绿、verify.sh exit 0、assert 通过
L4	表面观察	日志/截图/页面现象（需人工解读）	截图看起来正确、日志无报错、页面能打开
L5	间接推断	代码 diff / 口头说明	"我改了这段代码"、"理论上应该没问题"

默认优先级：L1-3 主判 → L4-5 辅助说明。只有 L5 时不得宣称完成。

---

Done 判定规则与证据门槛矩阵

证据等级组合	判定动作	标注要求
全部 L1-3 通过	Agent 自审后 Done	session 文件逐条标注 PASS + 验证方法
L1-3 部分 + L4 补充	Agent 自审后 Done	L4 项标注「待人工确认」+ 后续验证方式
仅 L4 或 L4-5	不允许 Done	标注 InReview + 「待验证」+ 原因 + 后续方式
仅 L5	禁止宣称完成	保持 InProgress，补充真实验证

与验证方式的映射

证据等级	验证方式	使用场景
L1 运行态	运行态验证	关键链路是否真的经过新代码
L2 调用链	运行态验证	底层状态是否真正切换
L3 自动化断言	自动化验证	task_verify.sh、单元测试
L4 表面观察	手动验证	UI 交互、实机测试
L5 间接推断	—	不作为独立验收依据

---

完成前四问

标记 InReview 前必须回答：

#	问题	回答格式
1	验证的是哪一层？	文档 / 代码 / 配置 / 调用链 / 运行态 / 输出
2	是否真的走到了新链路？	是/否 + 证据（日志/断点/请求追踪）
3	结果是否出现可识别变化？	变化描述 + 变化前后对比
4	哪些部分已验证，哪些未验证？	已验证清单 + 未验证清单

---

无法验证时的处理规范

暂时无法验证时，必须使用三段式模板明确写出：

未验证项: [具体条目]
原因: [为什么现在无法验证：环境/凭据/依赖/时间窗口等]
后续验证方式: [具体步骤或条件，不是"以后再测"这种空话]

禁止行为：

• 用"理论上应该没问题"替代验证
• 将未验证项混入已验证项中不加标注
• 因无法验证而直接跳过该 acceptance 条目

---

运行态验证方法指引

代码层验证（lint/build/测试）通过后，还需确认运行时真的走到新链路：

方法	适用场景	操作
关键点加日志/断言	有源码访问权限	在加载点插入，确认执行路径经过新代码
发起真实请求	API / CLI / Web 服务	确认输出因改动而变化
检查产物生成	构建任务 / 插件项目	验证 hooks 是否触发、产物是否存在且正确
端到端走查	UI / 多模块集成	从用户操作入口走到最终输出，全程有据

对于插件类项目（如 diwu-workflow 本身）：验证 hooks 是否被触发、产物是否被生成、JSON 是否合法。