用途：在把一次改动报告为“已完成”之前，证明它确实存在、确实起作用。绿色构建不等于改动存在——空操作编辑也能编译并通过全部测试，本技能就是补上这一缺口的机械检查。
主要能力与检查步骤：
- 用 grep 搜索你自认为新增的符号、子句或字符串，确认匹配出现在目标文件中，即使构建是绿的也要做。
- 观察新测试在没有修复时失败。修复后才写、且立即通过的测试证明不了修复；要么先写测试，要么暂存改动看它变红，至少断言具体的新行为而非原本就通过的快乐路径。
- 对已修复的评审发现，重读报告行号处的文件；不要凭自己写的提交信息推断“已修复”。
- 命名强制点而非意图。像“无绕过”“必须限流”“不能提权”这类标准要靠机制满足，指出拒绝该行为的类、方法、过滤器或配置指令；说不出就说明未满足。
- 不要把散文当作机制证据。注释、文档字符串、工单描述或 README 只是对代码的叙述，可能过时或从未为真；主张必须引用实现符号。
- 当主张涉及数据时，查询数据。用临时数据库和几行 SQL 验证 LIMIT 截断、遍历返回、两列是否失步等。示例命令：docker run --rm -d --name scratch -e POSTGRES_PASSWORD=scratch postgres；docker exec -i scratch psql -U postgres <<'SQL'；docker rm -f scratch。密码不可省略，官方镜像缺少 POSTGRES_PASSWORD（或 POSTGRES_HOST_AUTH_METHOD=trust）会拒绝启动。
报告方式：逐条说明验证了什么、如何验证，例如“在 file:line grep 了 X”“无改动时测试失败”，不要只写“已验证”。无法验证时说明哪部分、为什么。验证主张要带命令和工具自身的判定；若记录中没有命令，就说明该检查未发生。注意链式命令的退出码陷阱：grep 匹配时退出 0，可能因找到 FAILED 而“成功”，应以成功时为真的谓词结尾（cmd > log 2>&1 && echo PASS || echo FAIL）。质量门与构建判定是独立主张，要分别读取每步状态。
适用场景：行为变更后的自检、修复评审发现后的复核、涉及数据行为的结论、声明后端工作完成前。
限制：资料未提供安装方式、平台支持、收费与价格信息；本技能是流程性检查清单，不替代实际测试与代码审查。