verification-before-completion

完成前验证

只有基于针对实际声明获取的最新证据，才能声称任务已完成。遵循用户授权的范围；仓库说明规定适用的检查，但不授权修改、发布或降低要求。

流程

1. 编辑前明确有歧义的范围。如果某种解释显然更安全，就检查仓库并说明这一安全假设。只有在仍存在实质不同的解释时才提问；等待答复期间不要编辑存在争议的范围。

2. 检查 git status --porcelain 并保留无关改动。运行任何测试套件或迁移之前（包括基线检查），先确认其数据库和服务目标可随意处置（例如专用测试数据库、容器或一次性架构；绝不可使用开发数据库）（proof-integrity.md，验证前检查）。对于依赖项／框架升级、代码生成或迁移，在编写代码前记录现有验证命令集，并在之后原样重新运行。如果基线检查失败，请先报告，再继续。在工作树不干净时验证共享模块，必须使用隔离的基线进行对比。

3. 确定能够证明该声明的命令。对于发布级声明，检查完整的适用链路：构建、类型检查、lint、测试、安全扫描和差异审查；遇到首个失败就停止。阅读项目声明的门禁，并按其要求顺序运行适用于此操作的检查；不要自行增加门禁。

4. 立即运行验证。先前的输出、子 Agent 的报告、信心判断以及改名后的成功表述，都不能代替最新执行结果。

5. 阅读完整输出和退出状态，包括警告、执行／通过数量以及缺失的产物。未执行任何内容的测试套件不能作为证明。确认实际运行的是预期的二进制文件、解释器、源代码修订版本和入口点。

   • 保留原始证据。 显示过滤器可能在丢弃记录或改写字节的同时，生成看似可信的摘要。如果解析、补丁、计数、比较或审查依赖完整记录或精确字节，就使用未过滤的输出。下游的 head、tail 或 cat 无法恢复生产端已过滤的输出。

6. 验证证据是否涵盖相关要求和故障路径。已实现的安全正向能力必须能通过预期入口正常工作；仅包含拒绝路径、存根、模拟或无法触达的实现都只算部分完成。

7. 仅声明证据能够证明的内容。报告结果、运行命令／URL／点击路径、失败或跳过的检查，以及重要的剩余风险。说明较窄的验证范围，并区分确定性测试数据与实际运行行为。

绝不要为了通过检查而降低测试预言的要求。重新生成预期输出前，先审查并说明语义变更的理由。绝不要对受测对象或成功路径进行硬编码。只要干净的审查涵盖相关标准，就可视为有效；只有针对明确指出的剩余风险，才扩大检查范围。

按验证风险选择

• 对于工作区有未提交更改、大范围改动、严格输入验证，或夹具与实时数据来源的情况，请阅读 proof-integrity.md。对于包含无关编辑的共享模块，也请阅读 isolated-verification.md。
• 对于全仓库扫描或“每一项”之类的声明，请阅读 scope-and-sweeps.md。枚举所有未跟踪／忽略的临时状态项目，保留明确的处理结果，移动后重新枚举，并核算已移除的项目。只有待处理和受阻项目均为零，才算完成。
• 对于命令包装器、空结果、汇总总数、已安装的二进制文件或物化的修订版本，请阅读 verification-oracles.md。在解读缺失情况前，必须通过相同的调用方式验证正向控制。
• 对于基准测试结果、加速或性能回退，请阅读 performance-measurement.md。在解读耗时前，先验证已完成的工作和失败项；区分测得的影响与对其成因的解释。
• 对于前端、后端、CLI、基础设施、迁移、软件包、架构、文档或脚本化扫描方面的改动，请阅读 change-strategies.md 中对应的条目。该文档还涵盖对抗性探测、历史重写和过时的审查意见。
• 对于集成边界、回调或孤立状态，请阅读 system-wide-test-check.md。
• 对于交付物分类、处理检查失败、讨论分支范围或遇到提交前检查失败，请阅读 claims-and-failures.md。

失败与交接规则

不要在不作任何更改的情况下反复重试验证，只为碰运气直到通过。修复已获授权的实现问题并重新运行；否则，指出具体阻碍。“预先存在”“环境导致”和“偶发”都需要有证据，证明问题相对于刻意选定的基线存在，或证明其原因已通过独立方式确定。

不要绕过由本次工作导致的提交前检查失败。文档中规定的例外要求复现基线分支上的失败，并且此前已让用户知晓；此技能不赋予任何新的绕过权限。

通过差异和相关命令直接验证委派的工作。将规范符合性与质量分开检查。逐行重新阅读要求：测试通过与满足要求是两种不同的声明。如果新提交或外部状态可能使先前的审查失效，请更新事实和坐标。报告应与决策相关，不要包含空洞的状态章节，也不要编造确定性。