dev-verification

name	dev-verification
description	在声称工作完成、修复或通过前使用，在提交或创建 PR 前 - 要求运行验证命令并在做任何成功声称前确认输出

完成前验证

概述

未经验证声称工作完成是不诚实，不是效率。

核心原则： 证据先于声称，永远。

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

铁律

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

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

门控函数

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

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

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

常见失败

声称	需要	不足够
测试通过	测试命令输出：0 失败	之前运行，"应该通过"
Linter 干净	Linter 输出：0 错误	部分检查，外推
构建成功	构建命令：exit 0	Linter 通过，日志看起来好
Bug 修复	测试原始症状：通过	代码更改，假设修复
回归测试有效	红-绿循环验证	测试通过一次
Agent 完成	VCS diff 显示更改	Agent 报告"成功"
需求满足	逐行检查清单	测试通过

红旗 - 停止

• 使用"应该"、"可能"、"似乎"
• 验证前表达满意（"太好了！"、"完美！"、"完成了！"等）
• 未经验证就提交/推送/PR
• 信任 agent 成功报告
• 依赖部分验证
• 想"就这一次"
• 累了想结束工作
• 任何暗示成功而没有运行验证的措辞

合理化预防

借口	现实
"现在应该有效"	运行验证
"我有信心"	信心 ≠ 证据
"就这一次"	没有例外
"Linter 通过了"	Linter ≠ 编译器
"Agent 说成功"	独立验证
"我累了"	疲惫 ≠ 借口
"部分检查就够了"	部分证明不了什么
"不同措辞所以规则不适用"	精神高于文字

关键模式

测试：

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

回归测试（TDD 红-绿）：

✅ 编写 → 运行（通过）→ 恢复修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我已经写了回归测试"（没有红绿验证）

构建：

✅ [运行构建] [看：exit 0] "构建通过"
❌ "Linter 通过"（linter 不检查编译）

需求：

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

Agent 委派：

✅ Agent 报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态
❌ 信任 agent 报告

为什么重要

失败记忆：

• 用户说"我不相信你" - 信任破裂
• 未定义函数发布 - 会崩溃
• 缺失需求发布 - 功能不完整
• 错误完成浪费时间 → 重定向 → 返工
• 违反："诚实是核心价值观。如果你撒谎，你会被替换。"

何时应用

总是在以下情况前：

• 任何成功/完成的变体声称
• 任何满意的表达
• 关于工作状态的任何正面陈述
• 提交、PR 创建、任务完成
• 移动到下一个任务
• 委派给 agent

规则适用于：

• 确切短语
• 改写和同义词
• 成功的暗示
• 任何暗示完成/正确性的沟通

底线

验证没有捷径。

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

这是不可协商的。