Verification Before Completion Zh

---
name: verification-before-completion-zh
description: 完成前验证、宣布「做完了」「修好了」「测试都过了」之前先跑验证命令、提交与发 PR 前的自检门禁、不许拿旧结果冒充新证据。当用户说「你确定改好了吗」「跑一下测试再说」「别急着说完成」「提交前检查一遍」「这个真的修复了吗」「先验证再下结论」时使用；你自己即将说出「应该没问题了」「看起来对了」「完美」这类话时也必须强制触发。铁律是没有本轮新鲜的验证证据就不能声称任何完成状态。门禁五步——先想清楚哪条命令能证明这个结论、完整跑一遍、读全量输出与退出码、核对输出是否真的支持结论、最后才开口。覆盖测试通过、构建成功、Lint 干净、Bug 修复、回归测试有效、子代理交付、需求逐条满足七类断言，并附常见借口的反驳表。
author: Captain
version: 0.1.0
display_name: "完成前验证门禁"
display_name_en: "Verification Before Completion (zh)"
description_zh: "任何「完成/修好/通过」的说法都必须有本轮新跑出来的证据；给出五步门禁流程、七类断言各自需要的证据、红灯信号与借口反驳表。"
description_en: "Never claim done, fixed, or passing without fresh evidence from this turn; provides a five-step gate, the evidence each class of claim requires, red flags, and a rationalization rebuttal table."
examples_zh:
  - "跑一下测试再说，别急着说完成"
  - "提交前检查一遍，这个真的修复了吗"
  - "你确定改好了吗"
examples_en:
  - "Run the tests before you say it is done"
  - "Verify this is actually fixed before committing"
  - "Show me the evidence, not your confidence"
metadata:
  { "openclaw": { "requires": { "bins": [] }, "os": ["darwin", "linux", "windows"], "emoji": "✅" } }
---

# 完成前验证门禁

**核心原则：先有证据，再下结论。**

违反这条规则的字面意思，就是违反它的精神。绕过措辞（把「测试通过」换成「应该没问题」）不算例外，算违规。

## 铁律

```
没有本轮新鲜的验证证据，不得做出任何完成类断言
```

如果你在**这一条消息里**没有真的跑过那条验证命令，你就不能说它通过了。

## 何时用

**以下动作之前一律适用：**

- 任何形式的「完成 / 修好 / 通过 / 可以了」的说法，包括同义改写与暗示
- 任何表达满意的用词（「搞定」「完美」「漂亮」）
- 提交、推送、创建 PR、关闭工单
- 切换到下一个任务
- 把活派给子代理之后接收它的结果

**适用范围不限于原句**：改写、同义词、暗示成功、任何让人以为工作已完成或正确的表述，都受这条规则约束。

## 门禁流程

```
在做出任何状态断言或表达满意之前：

1. 确认：哪一条命令能证明这个结论？
2. 执行：完整跑一遍（新鲜的、不截断的）
3. 阅读：看全量输出，看退出码，数失败条数
4. 核对：输出是否真的支持这个结论？
   - 不支持：带证据说明真实状态
   - 支持：带证据说出结论
5. 到这一步才允许开口

跳过任何一步 = 撒谎，不是验证
```

示例（先跑，再说）：

```bash
# 1. 确认命令（先发现仓库自己的测试命令，不要默认 npm test）
make test || pytest -q || npm test

# 2-3. 看退出码与失败计数，不要只看最后一行
echo "exit=$?"

# 4. 回归测试要做红-绿往返验证
git stash          # 撤掉修复
pytest tests/test_regression.py -q   # 必须失败
git stash pop      # 恢复修复
pytest tests/test_regression.py -q   # 必须通过
```

## 各类断言需要的证据

| 断言 | 需要的证据 | 不算数的东西 |
|------|-----------|-------------|
| 测试通过 | 测试命令输出，0 失败 | 上一次的运行结果、「应该能过」 |
| Lint 干净 | Lint 输出，0 错误 | 只查了一部分、由此及彼的推断 |
| 构建成功 | 构建命令退出码 0 | Lint 过了、日志看着正常 |
| Bug 已修 | 复现原始症状的用例通过 | 代码改了、想当然认为好了 |
| 回归测试有效 | 红-绿往返验证过 | 测试跑通一次 |
| 子代理完成了 | 版本库 diff 里确实有改动 | 子代理自己报告「成功」 |
| 需求已满足 | 逐条对照的清单 | 测试通过 |

## 红线信号——立刻停

- 用了「应该」「大概」「看起来」「基本上」
- 还没验证就先表达满意（「太好了」「完美」「搞定」）
- 准备提交 / 推送 / 建 PR，但没跑验证
- 相信子代理的成功汇报
- 只做了局部验证就外推到整体
- 心里想「就这一次例外」
- 累了，想赶紧收工
- **任何暗示成功、但你并没有跑过验证的措辞**

## 常见借口与反驳

| 借口 | 现实 |
|------|------|
| 「现在应该能跑通了」 | 那就去跑 |
| 「我很有信心」 | 信心不是证据 |
| 「就这一次」 | 没有例外 |
| 「Lint 过了」 | Lint 不是编译器 |
| 「子代理说成功了」 | 独立复核 |
| 「我累了」 | 疲劳不是豁免 |
| 「局部检查够了」 | 局部什么也证明不了 |
| 「换个说法就不算违规」 | 精神大于字面 |

## 输出契约

宣布状态时，**结论与证据必须同时出现**，格式如下：

```
测试通过（34/34，`pytest -q`，退出码 0，输出无告警）
构建成功（`npm run build`，退出码 0）
需求 3/5 满足；第 4 条未做，原因是 …
```

禁止只有结论没有证据的句子；禁止引用上一轮的运行结果充当本轮证据。

## 子代理交付的特例

子代理汇报「已完成」只是一条**待核实的声明**。收到后必须：

1. 看 `git diff --stat` / `git log`，确认改动真的存在
2. 自己跑一遍验证命令
3. 按真实状态汇报，而不是转述子代理的话

---
改编自 [obra/superpowers](https://github.com/obra/superpowers) 的 `verification-before-completion`（MIT）。改动见 ATTRIBUTION.md。