implementlisted

# 带证据执行 `implement` 是 scoped work 的实现入口。它在三件事上严格：**WIP=1 一次只推进一个 slice**、**按风险选择验证强度**、**修改行为时同步相关 docs 和 selected recovery surface**。 ## 路由快照 - **Use when**: 恰好一个 active slice 可以开始改文件，且验证入口足够清楚。 - **Do not use when**: 需求不清、计划不清、失败根因不清、或项目工作面缺失。 - **Route to**: 稳定后转 `review` 或小改直接转 `verify`；失败根因不清转 `diagnose`；范围漂移转 `plan`。 ## 目的 - 当前 active slice 没拿到证据前，不开新 slice。 - 修代码就同步命令、文档或 recovery surface，否则下次会话恢复会失真。 - 验证强度按风险匹配，不机械要求覆盖率。 - 本 lane 可以跑局部检查，但不能声明 ready；ready claim 只能由 `verify` 证明。 - 失败了不靠猜，转 `diagnose`。 ## 何时使用 ### 触发信号 - 用户请求、Spec 或 Executable Plan 能解析出恰好一个 active slice。 - 项目入口、验证命令和 protected paths 足够清楚。 - 用户说「实现」「写代码」「修这个 bug」「让测试过」「让它跑起来」。 - 已经在循环中且当前 slice 还未 verified。 ### 不要使用 - 需求或成功标准不清：先 `brainstorm`。 - active slice 或 planning surface 不清：先 `plan`。 - 项目工作面、验证入口或 recovery surface 不清：先 `harness-builder`。 - 失败已经发生且根因不清：转 `diagnose`。 - 用户其实在问「应该怎么做」：转 `brainstorm`。 ### 路由规则 | 状态 | 下一步 | | --- | --- | | 实现失败、根因不清 | `diagnose` | | 当前 slice 稳定，需评审 | `review` | | 准备声明 ready | `verify` | | 范围变模糊 | `plan` 或 `brainstorm` | | 工作面不清 | `harness-builder` | | 验证路径 blocked | `harness-builder` 或回 `plan` 记录 fallback | ## 先读取这些输入 1. 用户请求、Spec 或 Executable Plan：确认 active slice、non-goals、success criteria、verification path、verification path status 和 required capabilities。 2. selected recovery surface：读取上次进度、决策、风险和 blockers；没有就轻量执行，不强制创建。 3. 与 active slice 直接相关的源代码、测试、配置和 docs。 4. `AGENTS.md` 和 README：确认项目规则、验证命令和 protected paths。 5. `git status --short`：避免和未提交改动相互覆盖。 ##