Scoped implementation

用户请求、项目规格、计划或 review findings 可直接提供执行范围；review 已授权的修复回边按本轨道状态面记录（state/work_index 出链）接手，不依赖用户复述，无需重新索要授权。行为类改动默认测试驱动，在预先商定的 seams 上先红后绿；无需为常规修改补齐全部流程工件。

流程

1. 阅读相关入口、源码、测试和 git 差异，确定目标行为与必要验证；保护无关用户改动。
2. 确定测试 seams：seam 是观察行为的公共边界，不是实现内部。seams 不明确时先与用户商定，或采用已批准 Spec/plan 记录的验收面；细则读 tdd skill。
3. 行为改动按 tdd 纪律执行：先写失败测试（red），再写刚好让它通过的实现（green），一次一片垂直切片；不预写未来测试、不加投机功能。文档与低风险配置不机械要求先写失败测试。
4. 验证节奏：typecheck 常跑、单个测试文件常跑、完整套件收尾跑一次。新改动影响已验证路径时重跑对应检查；已完成且仍适用的证据可复用，不因换技能重跑。
5. 重构不在 red-green 循环内：行为变绿后的结构收敛由 review 识别、授权后另行整理，不与让测试变绿混在一轮。
6. 更新受影响的用户文档和已有恢复记录；没有变化的文档无需修改，不新建重复状态文件。长任务不等收尾：新证据、被排除的假设或关键决策出现时即写入本轨道 state 的 Evidence（新证据）/Next（续点）行，不写其他轨道文件（state 为单数快照：多轨道换轨时先改写 Objective 头，见 plan 多轨道规则）；持续探索后按需重读当前 plan/任务入口，防目标漂移。
7. 按下述完成条件收尾，或继续已授权的后续步骤。只在实质扩大范围、改变验收或遇到授权边界时询问。

完成条件