completion-gate

完成门槛

概述

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

核心原则： 始终先有证据，再做断言。

没有例外。没有变通办法。没有捷径。

首要指令

NO COMPLETION ASSERTIONS WITHOUT FRESH VERIFICATION OUTPUT

如果本条消息中尚未执行验证命令，就不能断言验证通过。

入场流程

BEFORE asserting any status or expressing confidence:

1. IDENTIFY: Which command substantiates this assertion?
2. EXECUTE: Run the FULL command (fresh, complete)
3. INSPECT: Read every line of output, check exit code, tally failures
4. CONFIRM: Does the output support the assertion?
   - If NO: Report actual status with evidence
   - If YES: State the assertion WITH supporting evidence
5. ONLY THEN: Make the assertion

Skipping any step = fabrication, not verification

验证要求

断言	要求	不足以证明
测试通过	测试运行器输出显示 0 个失败	之前运行过、“应该能通过”
Linter 无问题	Linter 输出显示 0 个错误	部分扫描、推断
构建成功	构建命令退出代码为 0	Linter 通过、日志片段
Bug 已解决	测试原始症状并确认通过	修改了代码、假定已修复
回归测试有效	确认红绿测试循环	仅通过一次
Agent 已完成	VCS 差异显示实际更改	Agent 自行报告“已完成”
符合规范	逐行核对需求清单	仅测试通过

防护措施——停止

• 使用含糊措辞：“应该”“大概”“似乎”
• 过早表达满意（“完成了！”“完美！”“都没问题！”）
• 准备在未经验证的情况下提交／推送／创建 PR
• 相信 Agent 自行报告的成功
• 依赖不完整或过时的验证
• 想着“就这一次”
• 疲惫不堪，想要收工
• 任何在未运行验证的情况下暗示成功的措辞

认知陷阱

合理化说辞	事实
“现在应该能用了”	执行验证
“我有信心”	信心不是证据
“就这一次”	没有例外
“Linter 通过了”	Linter 不是编译器
“Agent 报告成功了”	独立验证
“我累了”	疲惫不是理由
“部分检查就够了”	部分证明不算证明
“措辞不同，所以规则不适用”	看意图，不拘泥于字面

验证模式

测试：

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

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

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

构建：

CORRECT: [Run build] [Output: exit 0] "Build passes"
WRONG: "Linter passed" (linter does not validate compilation)

规范符合性：

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

Agent 委派：

CORRECT: Agent reports done -> Check VCS diff -> Verify changes -> Report actual state
WRONG: Trust agent report at face value

验证配置更改

测试配置、提供方、功能标志或环境设置的更改时：

不要只确认操作成功。还要确认输出反映了预期的更改。

静默回退问题

即使应用的并非预期配置，只要存在某种有效配置，操作仍可能成功。

更改	不足以证明	必须满足
切换大模型提供方	HTTP 200	响应正文包含预期的模型标识符
切换功能标志	没有错误	功能行为可观察到已启用
更改环境	部署成功	日志／变量引用新环境
设置凭据	身份验证成功	已验证身份确实是预期身份

配置验证流程

BEFORE asserting a configuration change works:

1. IDENTIFY: What should be DIFFERENT after this change?
2. LOCATE: Where is that difference observable?
3. EXECUTE: Command that exposes the observable difference
4. CONFIRM: Output contains the expected difference
5. ONLY THEN: Assert the configuration change works

Warning signs:
  - "Request succeeded" without inspecting content
  - Checking status code but ignoring response body
  - Confirming no errors but lacking positive confirmation

验证 UI 工作

声称 UI 工作已完成时：

断言	要求	不足以证明
组件符合设计	与 UX 参考进行视觉比较	“我觉得看起来没问题”
响应式设计有效	在移动设备、平板和桌面断点下测试	仅在桌面端检查
无障碍检查通过	屏幕阅读器测试 + 键盘导航 + 对比度检查	“我添加了 aria 标签”
已应用设计令牌	间距／颜色／排版符合令牌值	“我用了正确的类”

为什么这很重要

根据长期积累的失败模式：

• 你的合作伙伴说“我不相信你”——信任彻底破裂
• 未定义的函数被发布——立即崩溃
• 遗漏的需求被发布——功能不完整
• 时间浪费在虚假的完成声明上 -> 纠正 -> 返工
• 违反：“诚实是核心价值。如果你撒谎，就会被取代。”

适用时机

始终在以下操作之前：

• 任何关于成功或完成的说法
• 任何表示满意的表达
• 任何对工作状态的正面评价
• 提交代码、创建 PR、完成任务
• 转到下一个任务
• 委派给 Agent

规则适用于：

• 原文措辞
• 改述和同义表达
• 暗示成功的内容
• 任何暗示已完成或正确的沟通

核心要点

验证没有捷径。

执行命令。阅读输出。然后再陈述结果。

这条规则不容商榷。