name: 验证完成前确认 description: 在声称成功前运行验证命令并确认输出。在提交或创建 PR 前，当要声称工作完成、修复或通过时使用。 version: 1.1.0

完成前验证

概述

声称工作完成而不进行验证是不诚实，不是效率。

核心原则： 总是先有证据，再声称。

违反这条规则的文字就是违反这条规则的精神。

铁律

没有新鲜验证证据，就没有完成声称

如果你没有在此消息中运行验证命令，就不能声称它通过。

门函数

在声称任何状态或表示满意之前：

1. 识别：什么命令证明这个声称？
2. 运行：执行完整命令（新鲜、完整）
3. 阅读：完整输出，检查退出代码，统计失败
4. 验证：输出是否确认声称？
   - 如果否：用证据陈述实际状态
   - 如果是：用证据陈述声称
5. 只有那时：做出声称

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

常见验证命令

测试：

# 首选：bun
bun test

# 替代：npm
npm test

构建：

# 首选：bun
bun run build

# 替代：npm
npm run build

代码检查：

# 首选：bun
bun run lint

# 替代：npm
npm run lint

类型检查：

# 首选：bun
bunx tsc --noEmit

# 或：npx tsc --noEmit

常见失败

声称	要求	不足够
测试通过	测试命令输出：0失败	先前运行，“应该通过”
代码检查干净	代码检查输出：0错误	部分检查，推断
构建成功	构建命令：退出0	代码检查通过，日志看起来好
错误修复	测试原始症状：通过	代码更改，假设修复
回归测试有效	红绿周期验证	测试通过一次
代理完成	版本控制系统差异显示更改	代理报告“成功”
需求满足	逐行检查清单	测试通过

红旗 - 停止

使用“应该”，“可能”，“似乎”
验证前表示满意（“太好了！”，“完美！”，“完成！”等）
即将提交/推送/PR而不验证
信任代理成功报告
依赖部分验证
想“就这一次”
疲倦并想结束工作
任何暗示成功而不运行验证的措辞

合理化预防

借口	现实
“现在应该工作了”	运行验证
“我自信”	自信 ≠ 证据
“就这一次”	无例外
“代码检查通过”	代码检查 ≠ 编译器
“代理说成功”	独立验证
“我疲倦了”	疲劳 ≠ 借口
“部分检查足够”	部分不证明什么
“不同措辞所以规则不适用”	精神优于文字

关键模式

测试：

✅ [运行测试命令] [见：34/34通过] “所有测试通过”
❌ “应该现在通过” / “看起来正确”

回归测试（TDD 红绿）：

✅ 写 → 运行（通过） → 恢复修复 → 运行（必须失败） → 恢复 → 运行（通过）
❌ “我写了一个回归测试”（没有红绿验证）

构建：

✅ [运行构建] [见：退出0] “构建通过”
❌ “代码检查通过”（代码检查不检查编译）

需求：

✅ 重读计划 → 创建检查清单 → 验证每个 → 报告差距或完成
❌ “测试通过，阶段完成”

代理委托：

✅ 代理报告成功 → 检查版本控制系统差异 → 验证更改 → 报告实际状态
❌ 信任代理报告

为什么这很重要

从失败记忆中：

虚假声称破坏了信任
未定义的函数被发送 - 会崩溃
缺失需求被发送 - 不完整功能
时间浪费在虚假完成 → 重定向 → 重新工作
违反：“诚实是核心价值。如果你撒谎，你将被替换。”

何时应用

总是在之前：

任何成功/完成声称的变体
任何满意表达
任何关于工作状态的积极陈述
提交、PR创建、任务完成
移动到下一个任务
委托给代理

规则适用于：

确切短语
转述和同义词
成功的暗示
任何暗示完成/正确性的通信

底线

验证没有捷径。

运行命令。阅读输出。然后声称结果。

这是不可谈判的。