verifylisted

# 声明 ready 前验证 `verify` 为一个具体 claim 收集 fresh evidence。它不修复、不重做计划、不清理无关文件，只用当前命令或可用 evidence source 证明当前状态，记录证据边界，并把失败路由到正确 skill。 核心规则：**`verify` 是唯一 ready gate；没有 fresh evidence，就不能声明 ready**。 ## 路由快照 - **Use when**: 需要证明某个 ready claim，且能列出 success criteria 或 verification path。 - **Do not use when**: 实现仍在变化、命令失败未解释、或 success criteria 写不出来。 - **Route to**: PASS 后转 `cleanup`；失败转 `diagnose`；能力缺口转 `harness-builder`；范围不清转 `plan` / `brainstorm`。 ## 目的 把"可以结束"转化为可追溯证据：每条成功标准都必须对应 fresh command、smoke/E2E 或明确的未验证限制。 用结构化 verification record 绑定 claim、路径、最后改动、命令、跳过项、unknown 和 ready verdict。 ## 何时使用 ### 触发信号 - `review` 没有 blocking structural issue，但仍需要最终 fresh evidence。 - 一个 slice 准备从 in-progress 进入 done/ready。 - 用户说「验证一下」「能结束吗」「跑最终检查」「证明它能用」。 - 改动触及 UI、API、auth、persistence、config、build、packaging 或跨组件行为。 - 之前证据在后续文件变化后变 stale。 - 能力缺口可能阻碍真实验证，例如 Web UI 没有浏览器自动化。 ### 不要使用 - 有未解释的失败命令：用 `diagnose`。 - 实现仍在变化：用 `implement`。 - Spec 或成功标准不清：用 `brainstorm` 或 `plan`。 - 任务是单行非行为编辑，用户不需要 tracked evidence。 ## 先读取这些输入 1. ready claim：active slice、success criteria、verification path、verification path status、required capabilities、fallback evidence。 2. selected recovery surface：最近 implementation/review evidence、risks、capability gaps。 3. `git status --short`：确认最后改动后哪些证据已过期。 4. 项目验证入口：README、`AGENTS.md`、package/build/test config。 5. 当前 slice 涉及的 source/test/docs 路径。 ## Evidence Ladder 按风险选择最高价值的最小检查集： 1. static parse / syntax 2. build 3. typecheck 4. lint 5. unit tests 6. integration tests