verification-before-completion

完成前验证

概述

未经过验证就声称工作已完成，这不是高效，而是不诚实。

核心原则： 始终先有证据，再做声明。

违反本规则的字面要求，就是违背本规则的精神。

铁律

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

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

门控函数

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
   - If NO: State actual status with evidence
   - If YES: State claim WITH evidence
5. ONLY THEN: Make the claim

Skip any step = lying, not verifying

常见错误

声明	所需证据	不足以证明
测试通过	测试命令输出：0 个失败	之前的运行结果、“应该会通过”
Linter 检查通过	pnpm lint:fix 输出：0 个错误	部分检查、推断
格式检查通过	pnpm format 输出：无更改	目视检查、假设
构建成功	构建命令：退出码为 0	Linter 检查通过、日志看起来正常
Bug 已修复	测试原有症状：通过	代码已更改、假定已修复
回归测试有效	已验证红绿循环	测试只通过一次
Agent 已完成	VCS diff 显示有更改	Agent 报告“成功”
满足需求	逐行核对清单	测试通过
代码质量门禁	pnpm lint:fix + pnpm format 已通过	测试通过

危险信号——停止

• 使用“应该”“可能”“似乎”等说法
• 验证前就表达满意（“太棒了！”“完美！”“完成了！”等）
• 即将提交、推送或创建 PR，却没有验证
• 轻信 Agent 的成功报告
• 依赖不完整的验证
• 心想“就这一次”
• 感到疲惫，想尽快结束工作
• 任何暗示成功、但实际未运行验证的措辞

防止自我辩解

借口	事实
“现在应该能用了”	运行验证
“我有信心”	信心不等于证据
“就这一次”	没有例外
“Linter 通过了”	Linter 不等于编译器
“Agent 说成功了”	独立验证
“我累了”	疲惫不是借口
“部分检查就够了”	部分检查无法证明任何事
“换种说法就不适用这条规则了”	重在精神，不拘泥字面

关键模式

测试：

CORRECT: [Run test command] [See: 34/34 pass] "All tests pass"
WRONG: "Should pass now" / "Looks correct"

回归测试（TDD 红绿循环）：

CORRECT: Write -> Run (pass) -> Revert fix -> Run (MUST FAIL) -> Restore -> Run (pass)
WRONG: "I've written a regression test" (without red-green verification)

构建：

CORRECT: [Run build] [See: exit 0] "Build passes"
WRONG: "Linter passed" (linter doesn't check compilation)

Lint 和格式化（阻断性门禁）：

CORRECT: [Run pnpm lint:fix] [See: 0 errors] [Run pnpm format] [See: no changes] "Lint and format clean"
WRONG: "Code looks formatted" / "No obvious lint issues" / "Should be clean"

需求：

CORRECT: Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
WRONG: "Tests pass, phase complete"

Agent 委派：

CORRECT: Agent reports success -> Check VCS diff -> Verify changes -> Report actual state
WRONG: Trust agent report

为什么这很重要

从失败分析中得出的结论：

• “我不相信你”——信任遭到破坏
• 未定义的函数被发布——运行时会崩溃
• 遗漏的需求被发布——功能不完整
• 时间浪费在虚假的完成声明上 → 重新分派 → 返工
• 违背：“诚实是核心价值观。如果你撒谎，就会被取代。”

适用时机

始终在以下情况之前：

• 任何形式的成功或完成声明
• 任何满意的表达
• 任何关于工作状态的肯定性陈述
• 提交、创建 PR、完成任务
• 转向下一个任务
• 委派给 Agent

规则适用于：

• 原话
• 转述和同义表达
• 暗示成功的说法
• 任何暗示工作已完成或正确的沟通

总结

验证没有捷径。

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

这是不可妥协的。

铁律

1. 绝不在当前会话中运行新的验证命令前声称任务已完成
2. 始终先阅读完整的命令输出，再断言结果——不能只看最后一行或退出代码
3. 绝不用模糊措辞（“应该能通过”“可能可行”）代替运行验证
4. 始终遵循红—绿—重构循环：验证测试失败，修复后通过，再还原并验证测试再次失败
5. 绝不在没有已验证证据证明所有检查（测试、lint、格式）均通过前提交、推送或关闭任务

反模式

反模式	失败原因	正确做法
运行命令前就声称成功	没有证据证明该说法属实	运行命令，阅读完整输出，然后再作出判断
依赖之前运行的结果	上次执行后状态可能已发生变化	始终在当前会话中重新运行验证
只进行部分验证（运行测试但不运行 lint）	即使测试通过，lint 失败也会导致 CI 失败	运行所有检查：测试、pnpm lint:fix、pnpm format
使用“应该”或“可能”之类的措辞	暗示这是推测，而非验证结果	不用模糊措辞；验证后陈述事实
跳过红—绿—重构循环	始终通过的回归测试无法发现任何问题	标记完成前，先还原代码并验证测试失败

记忆协议（强制）

开始前： 阅读 .claude/context/memory/learnings.md

完成后：

• 发现新模式 -> .claude/context/memory/learnings.md
• 发现问题 -> .claude/context/memory/issues.md
• 作出决策 -> .claude/context/memory/decisions.md

假设任务会中断：未记录在记忆中的事，就等于没发生。