Zc Verification Before Completion

完成前验证

何时使用

• 即将声明“完成”“通过”“已修复”之前
• 提交代码、创建 PR、切换任务之前
• 接收子代理结果之后
• 需要声称实现、修复或交付结果成立时；普通解释与研究结论按其证据来源核对，不套代码测试流程

输入前提

• 已明确当前准备声明什么成立
• 已知道能证明这个声明的验证命令
• 有针对当前变更的新鲜证据，而不是依赖过期结果
• 已区分“局部通过”“阶段通过”“任务完成”分别需要哪些证据

执行步骤

1. IDENTIFY：按声明、变更范围和风险选择检查，包含项目规定的必需门禁
2. RUN：运行这些验证命令；不为凑层级添加无关测试
3. READ：读取退出码、通过/失败摘要、失败上下文及支撑声明的关键输出；输出不完整或全文本身是验收对象时再完整读取
4. VERIFY：判断输出是否真的支撑你的声明
5. CLAIM：只有这时才能给出结论

强化规则

1. Fresh evidence only

• 只接受当前变更之后重新运行得到的验证结果
• CI 历史绿灯或他人口头断言不能替代当前证据；子代理提供的命令、版本与实际输出可核对后复用
• 代码、配置、依赖或环境变化后，重跑受影响检查；无法界定影响时扩大验证
• 当前变更的必需检查已通过且没有新失败、变更或未决风险时，复用本轮证据继续交付，不机械重复运行

2. 声明粒度要精确

• “单元测试通过”不等于“任务完成”
• “本地通过”不等于“CI 通过”
• “修复了一个报错”不等于“回归风险已关闭”
• 声明必须与证据粒度一致，不能扩大结论

3. 高风险变更需要二次核验

• 涉及发布、迁移、权限、安全、计费、数据删除、跨包联动时，至少补一层独立验证
• 二次核验可以是另一条命令、另一环境验证、人工走查，或对关键路径的复跑
• 复杂任务宁可慢一点，也不要用一次侥幸通过代替可靠结论

成功标准

• 结论有实际命令输出支撑
• 不使用“应该”“看起来”“大概”这类措辞替代证据
• 本次风险和项目要求所需的测试、构建、lint、需求对照已确认，不要求每个任务跑齐所有层级
• 子代理证据由主线程复核；证据缺失、过期、可疑或 finding 需复现时再运行相应检查
• 声明范围与验证范围一致
• 高风险改动完成了必要的二次核验

相关原则

• 证据先于断言
• 复杂任务谨慎优先于求快
• 目标导向决定验证粒度
• 历史输出不算当前验证
• 验证是门禁，不是装饰

与其他技能的衔接

• 与 test-driven-development 的红绿循环天然配合
• 与 engineering-principles 配合，用原则层约束“声明什么、验证到什么程度”
• code-review-and-quality 会审查你的验证故事是否成立
• sdd-tdd-workflow 的每个阶段门控都依赖这里的规则