sa-submission-check

name	sa-submission_check
description	当准备声称工作已完成、修复或通过时使用，在提交或创建 PR 之前——要求运行验证命令并确认输出，然后再做出任何成功声明；证据永远先于主张

完稿前验证 (Verification Before Completion)

概述

没有验证就声称工作完成是不诚实的，而不是高效的。

核心原则： 证据永远先于主张。

违反规则的字面意思就是违反规则的精神。

铁律

没有新鲜的验证证据，就不做完成声明
(NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE)

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

门控功能

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

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

跳过任何步骤 = 撒谎，而非验证

常见失败

主张	需要	不足以构成
逻辑通过	验证命令输出：0 失败	之前的运行，“应该能过”
格式整洁	Linter 输出：0 错误	部分检查，推断
编译成功	构建命令：退出代码 0	Linter 通过，日志看起来不错
漏洞已修	测试原始症状：通过	代码改了，假设修好了
回归测试工作	红-绿循环验证	测试通过了一次
助理已完成	VCS diff 显示变更	助理报告“成功”
要求已满足	逐行检查清单	测试通过

危险信号 - 停止

• 使用“应该”，“可能”，“似乎”
• 在验证之前表达满意（“太棒了！”，“完美！”，“好了！”，等）
• 准备提交/推送/PR 而未验证
• 信任助理的成功报告
• 依赖部分验证
• 想着“就这一次”
• 累了想结束工作
• 任何暗示成功但未运行验证的措辞

防止合理化

借口	现实
“现在应该行了”	运行验证
“我有信心”	信心 ≠ 证据
“就这一次”	无例外
“Linter 通过了”	Linter ≠ 编译器
“助理说成功了”	独立验证
“我累了”	疲惫 ≠ 借口
“部分检查够了”	部分证明不了什么
“换个说法就不适用规则了”	精神重于字面

关键模式

验证检查:

✅ [运行验证命令] [看到: 34/34 通过] "所有检查通过"
❌ "现在应该通过了" / "看起来正确"

回归测试 (ADW 红-绿):

✅ 撰写 → 运行 (通过) → 撤销修复 → 运行 (必须失败) → 恢复 → 运行 (通过)
❌ "我写了一个回归测试" (没有红-绿验证)

构建/预览:

✅ [运行构建] [看到: 退出代码 0] "构建成功"
❌ "Linter 通过了" (linter 不检查编译)

要求:

✅ 重读计划 → 创建清单 → 验证每一项 → 报告差距或完成
❌ "测试通过，阶段完成"

助理委托:

✅ 助理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任助理报告

为什么这很重要

来自 24 个失败记忆：

• 研究伙伴说“我不相信你”——信任破裂
• 交付了未定义的术语——会造成混淆
• 交付了缺失的要求——功能不完整
• 浪费在虚假完成上的时间 → 重定向 → 返工
• 违反：“诚实是核心价值观。如果你撒谎，你会被替换。”

何时应用

始终在以下情况之前：

• 任何形式的成功/完成声明
• 任何满意的表达
• 任何关于工作状态的积极陈述
• 提交，创建 PR，任务完成
• 移动到下一个任务
• 委托给助理

规则适用于：

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

底线

验证没有捷径。

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

这是不可商量的。