# 与规划技能的衔接

keel 解决「动手前的纪律」，不替代规划：任务拆解、排期、资源分配交给规划类技能。
本文说明两条管线如何交接，避免职责重叠或出现缝隙。

## 1. 分工边界

| 阶段 | 负责方 | 产出 |
| --- | --- | --- |
| 锚定 + 立规 + 审查 | keel（keel-anchor / keel-spec / keel_review） | SPEC.md（含 AC-xx 验收标准） |
| 假设登记 + 验证 | keel（keel-probe，assumptions 模板） | ASSUMPTIONS.md（风险分级 + 验证结论） |
| 任务拆解 + 排序 | 规划技能 | 任务清单（任务 ← 需求条目） |
| 实现 | 执行技能 / agent 主体 | 代码 |
| 验收 | keel（keel-audit，audit 模板） | AUDIT.md |

**交接条件（keel 侧出口门禁）**：SPEC.md 审查零错误、[高] 假设全部有验证结论。
未满足时规划技能应把任务退回 keel 流程，而不是带着含糊需求往下拆。

## 2. 规格产物如何作为规划输入

### 2.1 需求条目 → 任务

规划的输入单位是 SPEC.md 的「需求」条目（R-xx），不是整份规格：

- 一条 R-xx 对应一个或多个任务；任务描述引用 R-xx 编号；
- 任务验收直接引用 AC-xx：任务完成条件 = 其覆盖的验收标准子集；
- 依赖排序以「验证方法」小节为依据：被验证方法引用的行为先实现。

### 2.2 验收标准 → 测试计划

- AC-xx 是测试用例的源：每条 AC 至少对应一个用例；
- 「验证方法」里给出的命令/脚本优先作为用例骨架；
- 规划中不要新增 AC 之外的「隐性验收」——新增即走变更单。

### 2.3 假设 → 里程碑早期任务

- [高] 假设的验证动作本身是一个任务，排在对应实现任务之前；
- 验证结论回填 ASSUMPTIONS.md 后，该任务才算完成；
- 证伪（❌）会触发规格变更，规划技能需为「证伪→改规格→重拆」预留缓冲。

## 3. 与常见技能类型的协作

- **任务拆解/待办技能**：待办条目的第一行引用来源（R-xx / AC-xx / A-xx），
  保证可追溯；「以后再做」的条目记入待办而非规格，规格冻结不受影响；
- **测试技能（TDD 类）**：先写测试对应 AC-xx，再实现对应 R-xx，
  与 keel 的「验证方法先行」同构；
- **代码审查技能**：审查结论若指向规格缺陷（需求表述、边界遗漏），
  按变更单流程更新 SPEC.md，而非只改代码；
- **复盘/总结技能**：AUDIT.md 的「偏差记录」与「复盘」是总结技能的输入，
  避免重复询问「这轮发生了什么」。

## 4. 变更驱动的双向同步

规格冻结期间出现变更（证伪、新请求）时：

1. 填写 change-request 模板；
2. 批准后更新 SPEC.md 相应小节（需求/验收标准/边界）；
3. 规划技能据此重排受影响任务，标记受影响任务的来源引用；
4. 审计阶段核对变更单是否全部闭环（决策为「推迟」的除外）。

流程上：**变更单是规划重排的触发器，不是事后说明。**

## 5. 最小协作检查单

- [ ] 规划输入是审查合格的 SPEC.md，而不是口头需求；
- [ ] 每个任务可追溯到 R-xx 或 A-xx；
- [ ] 每个 AC-xx 至少有一个测试用例计划；
- [ ] 所有 [高] 假设的验证任务排在实现任务之前；
- [ ] 变更单批准后才允许重排任务与改规格。