verification-before-completion

name	verification-before-completion
description	强制验证流程——在声称任务完成前执行五步验证，确保改动正确、无破坏、可运行。触发词：「完成」「做完了」「提交」「commit」「收尾」。
allowed-tools	["Read","Grep","Glob","Bash(git *)","Bash(npm *)","Bash(npx *)","Bash(pnpm *)","Bash(yarn *)","Bash(cargo *)","Bash(go *)","Bash(python *)","Bash(pytest *)"]

完成前强制验证

在声明任务完成之前，必须执行以下验证流程。跳过验证 = 未完成——没有例外。

验证流程

步骤 1：文件完整性检查

逐文件、从头到尾复读所有被修改的文件，检查：

• 是否有遗留的 console.log、debugger、print() 调试语句？
• 是否有遗 TODO、FIXME、HACK 等未解决的标记？
• 是否有注释掉的代码块？
• 是否有空 catch 块（catch(e) {}）？
• 是否有未使用的变量、导入、参数？
• 逻辑是否完整——所有分支都有合理返回 / 处理？

步骤 2：调用者完整性检查

用 grep（或 rg）搜索所有被修改的导出（函数、类、类型、接口），确认：

• 每个 export 的调用方是否仍然兼容？
• 签名变更是否影响所有调用处？
• 新增的导出是否确实有调用方？（无调用方 = 死代码，不应提交）
• 删除或重命名的导出是否已更新所有引用？

命令示例：

grep -r --include="*.ts" --include="*.tsx" "exportedFunctionName" src/

步骤 3：构建验证

执行项目的构建命令，确认代码无编译错误：

• 构建成功（无 TypeScript/编译错误）
• 无新增的类型错误（对比改动前后的类型检查结果）

命令示例（根据项目类型选择）：

npm run build
cargo build
go build ./...
python -m compileall .

步骤 4：测试验证

执行项目的测试套件，确认无回归：

• 所有已有测试通过
• 如果有新增逻辑，是否有对应的测试覆盖？

命令示例：

npm test
pytest
cargo test
go test ./...

步骤 5：Lint / 格式化验证

执行项目的代码风格检查：

• Lint 检查无新增警告或错误
• 代码格式符合项目规范

命令示例：

npm run lint
cargo fmt --check
cargo clippy
golangci-lint run

验证失败时的处理

失败类型	处理方式
遗留调试代码	直接删除后重新验证
调用方不兼容	修复所有受影响的调用处
构建失败	修复编译错误直到构建成功
测试失败	分析失败原因——如果与改动相关则修复，如果是已有的不稳定测试则记录
Lint 失败	修复警告和错误后重新 lint

证据输出格式

验证完成后，输出以下格式的验证报告：

## 验证报告

### 步骤 1：文件完整性
- 已复读：[文件列表]
- 遗留问题：[无 / 列出具体问题]

### 步骤 2：调用者检查
- 已检查的导出：[列表]
- 发现破坏性变更：[无 / 列出具体变更及影响的调用方]

### 步骤 3：构建
- 命令：[构建命令]
- 结果：成功 / 失败

### 步骤 4：测试
- 命令：[测试命令]
- 结果：N 通过，0 失败 / N 通过，M 失败

### 步骤 5：Lint
- 命令：[lint 命令]
- 结果：干净 / N 个警告

### 整体结论
[通过 / 未通过——如未通过列出阻塞项]

原则

1. 证据先于声明。 无法提供验证证据 = 任务未完成。
2. 不跳过步骤。 即使改动「很小」，也必须全部走完五步。
3. 失败即阻塞。 构建 / 测试 / lint 任一失败都视为验证未通过。
4. 验证完成后才可提交或声明完成。