Verification（完成前验证）

Purpose

在报告完成之前强制运行检查阶梯并留下可复核证据，消灭「看起来没问题」式的完成声明。 产出的是证据清单：每条为「命令 → 输出关键行」。

When to Use

• 当即将报告任务「完成 / 修复 / 通过」时
• 当改动涉及代码且尚未运行任何检查时
• 当用户质疑改动是否破坏了其他功能时
• 当 CI 失败，需要先在本地复现时

When NOT to Use

• 纯文档 / 注释改动且不触发 lint：跳过阶梯，以 git diff 摘要作为证据
• 定位失败根因：先用 debugging-and-error-recovery，找到根因再回来收尾验证
• 评审代码质量与设计：改用 code-review（本 skill 不做评审）
• 尚未形成改动的探索性阅读：不需要验证阶梯

Inputs

• 项目检查命令（package.json scripts、Makefile 或 CI 配置）：读不到时向用户确认技术栈，禁止猜测命令
• 本次改动文件清单：缺失时先跑 git status + git diff --name-only 收集
• 测试运行方式（runner、过滤参数、是否依赖数据库等外部服务）：缺失时按仓库 README 确认

Workflow

1. Inspect

• git status + git diff --name-only：确定受影响文件与改动规模
• 从 package.json / CI 配置读出实际可用的检查命令与其运行目录（monorepo 注意 workspace）
• 判断各阶梯是否适用：无 UI → 跳过 browser；涉及类型、导入路径或依赖的改动 → 必须跑 build，其余情况 build 按需

2. Plan

• 写下要执行的阶梯顺序与每级具体命令，例如： npx tsc --noEmit → npx eslint . → npx vitest run → npm run build → 浏览器验证（UI 时）
• 对每个计划跳过的级别写明理由（如「纯文档改动，无类型面」）

3. Implement

• 按顺序运行检查阶梯：typecheck → lint → test → build（必要时）→ browser（UI 时）
• 每级失败即停，修复后从该级重跑；不允许只跑通过的部分
• 记录每级的命令、退出码与输出关键行（用例数、错误摘要）

4. Verify

• 确认每级以退出码 0 结束，且输出中的用例数 / 检查文件数非 0（防止命令跑错目录造成的假绿）
• 对照 git diff --name-only：被改路径有对应测试覆盖，或写明覆盖缺口
• 把「命令 → 输出关键行」整理进最终报告

Rules

• 必须按 typecheck → lint → test → build → browser 顺序执行；跳过任何一级都要写明理由
• 证据必须是「命令 + 输出」；禁止用「看起来没问题」「我检查过了」代替运行
• 修复后必须重跑失败级别及其下游级别，不得只重跑通过的部分
• 禁止为通过检查而删除或放宽测试断言；确需改动测试须说明理由并征得用户同意
• 证据清单未写入回复或变更说明前，不得声明完成

Common Failure Modes

Common Rationalizations

Verification

• npx tsc --noEmit（或项目等价命令）→ 退出码 0
• lint 与 test 命令 → 输出含非 0 的用例数 / 文件数，且失败数为 0
• 最终报告含「命令 → 输出关键行」清单，缺任一条不得声明完成

Exit Criteria

• 阶梯每一级要么以退出码 0 通过，要么写明跳过理由
• 报告附命令与输出关键行，第三方可按清单复跑
• 被改路径有对应测试覆盖，或写明覆盖缺口与原因
• 未删除或放宽任何测试断言（如有改动已说明并确认）