Back to Details

verify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Evidence before assertion. A claim without a fresh command run behind it is not made.
  1. Name the claim about to be made: "done", "fixed", "passes", "works".
  2. Run the commands that would prove it false: the tests, the build, the linter, and the actual behavior that changed.
  3. When a spec exists at 
    docs/specs/<slug>.md
    , gate criterion by criterion: run each criterion's verification command and quote the output that proves it. Then check the diff against the spec's non-goals; a change inside fenced scope fails the claim even with green tests. A spec that still carries an 
    ## Open decisions
    section is a draft, and a draft proves nothing: no claim can be made against it; route back to 
    drill
    .
  4. Exercise the changed path end to end, not only its unit tests. If the change has a runtime surface, drive it.
  5. Read the output. Passing means the output says passing, not that the command exited.
  6. State what was run and what it showed. If it broke, say it broke, with the output.
Rules:
  • Default stance: reject. A claim is false until fresh output proves it; the implementer's word is not evidence.
  • Never claim from memory of an earlier run; re-run after the last edit.
  • A skipped check is reported as skipped, not implied as passing.
  • Review feedback is a claim: verify it before implementing. Unclear feedback is checked, not obeyed.
  • Partial verification gets a partial claim: "tests pass; behavior not exercised" is honest, "done" is not.
  • Fast path (one-sentence plan, no spec file): the gate is that sentence's criterion, not the whole suite. Run only the tests that exercise the change; the changed path still runs end to end.
  • Deep mode (the 
    deep
    skill is active): exercise the changed path end to end unconditionally and gate every criterion; a partial claim is not accepted as final.
先举证，再宣称。未通过最新命令运行验证的宣称无效。
  1. 明确即将做出的宣称类型："已完成""已修复""已通过""可正常运行"。
  2. 运行可验证宣称是否不成立的命令：测试、构建、代码检查工具（linter），以及验证变更后的实际行为。
  3. 当存在位于
    docs/specs/<slug>.md
    的spec文档时，逐一验证每个判定标准：运行每个标准对应的验证命令，并引用能证明符合标准的输出。随后对比变更内容与spec文档中的非目标内容；即使测试全部通过，若变更涉及受限范围，该宣称仍不成立。若spec文档仍包含
    ## Open decisions
    章节，则视为草稿，草稿不具备证明效力：不能基于草稿做出任何宣称，需回到
    drill
    环节。
  4. 端到端测试变更路径，而不只是运行单元测试。若变更涉及运行时层面，则需实际运行验证。
  5. 查看命令输出。"通过"指输出明确显示通过，而非仅命令执行结束。
  6. 说明运行的命令及结果。若验证失败，需说明失败情况并附上输出内容。
规则：
  • 默认立场：拒绝。在最新输出证明宣称有效之前，该宣称视为不成立；开发者的口头说明不能作为证据。
  • 绝不能依据之前运行的记忆做出宣称；最后一次编辑后必须重新运行验证。
  • 跳过的检查需明确标注为"跳过"，不能默认视为"通过"。
  • 评审反馈视为一种宣称：在执行前需先验证。对于模糊的反馈，应先核实清楚，而非直接执行。
  • 部分验证只能做出部分宣称："测试通过；未验证实际行为"是如实表述，而"已完成"则不是。
  • 快速路径（仅一句描述的计划，无spec文件）：验证标准为该描述中的要求，而非整个测试套件。仅运行与变更相关的测试；但变更路径仍需进行端到端验证。
  • 深度模式（
    deep
    技能激活）：必须无条件端到端测试变更路径，并验证所有判定标准；部分宣称不被视为最终结论。