Back to Details

verification-before-completion

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Verification Before Completion

完成前的验证流程

Overview

概述

Claiming work is complete without verification is dishonesty, not efficiency.
Core principle: Evidence before claims, always.
Violating the letter of this rule is violating the spirit of this rule.
未经过验证就宣称工作完成是不诚信的行为，而非高效。
核心原则： 始终先有证据，再做宣称。
违反规则的字面要求，即违反规则的精神内核。

The Iron Law

铁律

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this message, you cannot claim it passes.
无新鲜验证证据，不得宣称工作完成
如果未运行本指南中的验证命令，你无权宣称工作已通过。

The Gate Function

把关流程

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
在宣称任何状态或表达满意之前：

1. 明确：哪些命令可以证明你的宣称？
2. 执行：完整运行该命令（全新、完整的执行）
3. 查看：完整输出内容，检查退出码，统计失败次数
4. 验证：输出结果是否能证实你的宣称？
   - 若不能：说明实际状态并附上证据
   - 若能：在宣称结果时附上证据
5. 仅在此时：做出宣称

跳过任何步骤 = 弄虚作假，而非验证

Common Verification Commands

常见验证命令

Tests:
bash
undefined
测试：
bash
undefined

Preferred: bun

推荐：bun

bun test
bun test

Alternative: npm

替代方案：npm

npm test

**Build:**
```bash
npm test

**构建：**
```bash

Preferred: bun

推荐：bun

bun run build
bun run build

Alternative: npm

替代方案：npm

npm run build

**Lint:**
```bash
npm run build

**代码检查：**
```bash

Preferred: bun

推荐：bun

bun run lint
bun run lint

Alternative: npm

替代方案：npm

npm run lint

**Type check:**
```bash
npm run lint

**类型检查：**
```bash

Preferred: bun

推荐：bun

bunx tsc --noEmit
bunx tsc --noEmit

or: npx tsc --noEmit

或：npx tsc --noEmit

undefined
undefined

Common Failures

常见错误场景

ClaimRequiresNot Sufficient
Tests passTest command output: 0 failuresPrevious run, "should pass"
Linter cleanLinter output: 0 errorsPartial check, extrapolation
Build succeedsBuild command: exit 0Linter passing, logs look good
Bug fixedTest original symptom: passesCode changed, assumed fixed
Regression test worksRed-green cycle verifiedTest passes once
Agent completedVCS diff shows changesAgent reports "success"
Requirements metLine-by-line checklistTests passing
宣称内容所需验证不充分的依据
测试通过测试命令输出：0失败之前的运行结果、“应该能通过”
代码检查无问题代码检查输出：0错误部分检查、主观推断
构建成功构建命令：退出码0代码检查通过、日志看起来正常
漏洞已修复针对原问题的测试通过代码已修改、主观认为已修复
回归测试有效已验证红-green循环测试仅通过一次
Agent已完成任务VCS差异显示有变更Agent报告“成功”
需求已满足逐条核对检查清单测试通过

Red Flags - STOP

危险信号 - 立即停止

  • Using "should", "probably", "seems to"
  • Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
  • About to commit/push/PR without verification
  • Trusting agent success reports
  • Relying on partial verification
  • Thinking "just this once"
  • Tired and wanting work over
  • ANY wording implying success without having run verification
  • 使用“应该”“可能”“似乎”这类表述
  • 未验证就表达满意（如“太棒了！”“完美！”“完成了！”等）
  • 未验证就准备提交/推送/创建PR
  • 轻信Agent的成功报告
  • 依赖部分验证结果
  • 抱有“就这一次例外”的想法
  • 因疲惫想尽快结束工作
  • 任何未提及已运行验证就暗示成功的表述

Rationalization Prevention

避免自我合理化

ExcuseReality
"Should work now"RUN the verification
"I'm confident"Confidence ≠ evidence
"Just this once"No exceptions
"Linter passed"Linter ≠ compiler
"Agent said success"Verify independently
"I'm tired"Exhaustion ≠ excuse
"Partial check is enough"Partial proves nothing
"Different words so rule doesn't apply"Spirit over letter
借口事实
“现在应该能正常运行了”去运行验证命令
“我很有信心”信心≠证据
“就这一次例外”没有例外情况
“代码检查已通过”代码检查≠编译验证
“Agent说已经成功了”独立进行验证
“我太累了”疲惫不能成为借口
“部分检查就足够了”部分验证毫无意义
“表述不同所以规则不适用”规则精神优先于字面表述

Key Patterns

关键规范示例

Tests:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
Regression tests (TDD Red-Green):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
Build:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
Agent delegation:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
测试：
✅ [运行测试命令] [结果：34/34通过] “所有测试已通过”
❌ “现在应该能通过了” / “看起来没问题”
回归测试（TDD红-Green流程）：
✅ 编写测试 → 运行（通过）→ 还原修复代码 → 运行（必须失败）→ 恢复修复代码 → 运行（通过）
❌ “我已经写好回归测试了”（未进行红-green循环验证）
构建：
✅ [运行构建命令] [结果：退出码0] “构建已通过”
❌ “代码检查已通过”（代码检查不验证编译情况）
需求验证：
✅ 重新阅读计划 → 制作检查清单 → 逐项验证 → 报告差距或完成情况
❌ “测试已通过，阶段完成”
Agent任务委托：
✅ Agent报告成功 → 检查VCS差异 → 验证变更内容 → 报告实际状态
❌ 轻信Agent的报告

Why This Matters

为什么这很重要

From failure memories:
  • False claims broke trust
  • Undefined functions shipped - would crash
  • Missing requirements shipped - incomplete features
  • Time wasted on false completion → redirect → rework
  • Violates: "Honesty is a core value. If you lie, you'll be replaced."
来自失败案例的教训：
  • 虚假宣称会破坏信任
  • 未定义的函数被发布，导致程序崩溃
  • 遗漏需求的功能被发布，导致功能不完整
  • 因虚假宣称浪费时间：重新定位问题→返工
  • 违反核心价值观：“诚信是核心价值。若你撒谎，将被替换。”

When To Apply

适用场景

ALWAYS before:
  • ANY variation of success/completion claims
  • ANY expression of satisfaction
  • ANY positive statement about work state
  • Committing, PR creation, task completion
  • Moving to next task
  • Delegating to agents
Rule applies to:
  • Exact phrases
  • Paraphrases and synonyms
  • Implications of success
  • ANY communication suggesting completion/correctness
始终在以下场景前执行：
  • 任何形式的成功/完成宣称
  • 任何表达满意的表述
  • 任何关于工作状态的积极陈述
  • 提交代码、创建PR、标记任务完成
  • 切换到下一个任务
  • 委托任务给Agent
规则适用于：
  • 字面表述
  • 改写和同义词
  • 暗示成功的表述
  • 任何表明工作已完成/正确的沟通内容

The Bottom Line

底线

No shortcuts for verification.
Run the command. Read the output. THEN claim the result.
This is non-negotiable.
验证流程没有捷径。
运行命令。查看输出。然后再宣称结果。
这是不容协商的要求。