verify

主张之前必须先有证据。没有新近运行的命令作为依据，就不要做出主张。

快速路径：当计划只有一句话且没有规格文件时，门槛就是该句中的标准。只运行能验证变更的测试，同时仍须端到端运行变更路径。如果快速路径任务的门槛第二次未通过，说明任务并非显而易见。停下来，对其运行 drill。

1. 说出你即将做出的主张：“完成”“已修复”“通过”或“可用”。
2. 对主张分类。对于命令可以判定的内容，在这里验证。关于质量的主张现在就交给 rubric 技能处理，无论命令结果如何。关于质量的主张涉及设计、UI、公共接口、名称或文案。若以无法证明为由判定失败，这是路由错误。命令通过永远不能证明质量主张。
3. 运行能够证明该主张为假的命令：测试、构建、代码检查器，以及发生变更的行为。完整门槛包括所有测试、构建和代码检查器。每次提交都要在即将提交的代码树上运行一次。快速路径的门槛是句子中的标准。在一个切片内，测试循环只运行能验证该切片的测试。在规格声明的阶段内，提交使用所触及区域的检查。阶段的最后一次提交运行完整门槛。
4. 当 docs/specs/<slug>.md 中存在规格时，分别对每项标准设置门槛。在切片提交时，对该切片涉及的标准设置门槛。某项标准若对应已声明阶段的结束，则等到该阶段的最后一次提交再设置门槛。当你声称整个工作已完成时，对每项标准设置门槛。只要哈希值仍与代码树匹配，每项结果都取自最新的证据记录。运行每项标准对应的验证命令，并引用证明该项的输出。对于注明 rubric 的标准，使用该评审者的判定。当你声称整个工作已完成时，各项标准就是当前任务清单中的项目。如果没有清单且标准不少于 3 项，就创建一份。只有输出或判定能够证明某项时，才将其标记为完成。没有证据的标准仍保持未完成。然后根据规格中的非目标检查差异。即使测试通过，变更触及排除范围也会导致主张不成立。若规格仍包含 ## Open decisions 部分，则它仍是草案。草案状态下不得做出任何主张。将其退回 drill。
5. 端到端验证变更路径，而不只是运行单元测试。如果变更涉及运行时接口，就实际操作并保留结果。运行时接口包括 UI、CLI、TUI 或服务。保留命令输出、日志、截图或文字记录。如果基分支中有操作指南，就按 app-check.md 所述，用它验证所触及的功能。该操作指南是一个名为 verify-<app> 的项目技能。只有用户提出要求时，才通过同一参考文档编写或更新该操作指南。若运行时接口没有操作指南，用一行话提出编写建议。如果通过代理读取变更路径的结果，请阅读 prove it works。代理包括时间戳、状态文件、缓存值、截图或其他 Agent 提供的报告。检查失败时也要阅读该文档；移植或迁移工作同样如此。
6. 阅读输出。只有输出明确表明通过，才算通过；不能仅凭命令成功退出就认定通过。
7. 说明运行了什么，以及结果表明了什么。如果失败，就说明失败并展示输出。如果规格指定了演示产物，就再次运行该产物来展示演示。不要描述之前的运行。演示可以展示变更有效，但不能证明任何标准。因此，分支上编写的脚本也可以用作演示。

规则：

• 默认答案是否定。除非有新鲜输出证明，否则一项声明就是假的。实施者的话不是证据。
• 绝不要凭对先前运行的记忆做出声明。证据记录是工作树的内容哈希，以及每条命令及其保存的输出。使用 git ls-files -z -co --exclude-standard -- . ':!*.md' | sort -z | xargs -0 sha1sum | sha1sum 获取哈希。在 macOS 上，使用 shasum 代替 sha1sum。如果测试会读取 Markdown，请移除 ':!*.md' 排除项。哈希与工作树匹配的记录是新鲜输出，而不是记忆。再次使用该记录，不要重新运行其中的命令。提交、切换回同一棵树，或仅编辑 Markdown，都不会改变哈希和记录。implement、debug、land 和此技能都会再次使用该记录。下次编辑哈希中的文件时，该记录就会失效。
• 规划每项声明所需的所有命令，并在单次调用中各运行一次。然后将输出对应到判定标准。每条命令都要将完整输出写入文件：> /tmp/verify-<hash>-<name>.log 2>&1。读取并搜索该文件。为了查看更多输出而重新运行命令，属于重复运行。并行运行互不依赖的命令。如果命令之间不共用文件、端口、数据库或构建目录，那么它们就是互不依赖的。判定标准是对已有输出的解读，而不是再次启动测试套件。
• 验证命令是项目的测试运行器、构建工具或代码检查工具。在同一分支上编写的脚本不属于验证命令。即使此类脚本运行通过，也应拒绝依赖它的声明。只有基分支原有形式的 verify-<app> 配方才算数。在被声明的分支上编写或修改的配方，属于该分支的脚本。
• 将跳过的检查报告为已跳过。部分验证只能支持部分声明。“测试通过；未验证行为”是诚实的说法。“已完成”则不是。
• 依赖测量数值的声明，必须说明该数值的限制因素，如数值说明所述。测量数值包括基准测试结果、加速比、延迟、大小、通过率或运行次数。
• 审查反馈也是一项声明。实施前先验证反馈。对于不明确的反馈，先进行核实。未经核实，不要照做。