cap-plan

cap-plan — 把已批准的 spec 拆成可执行的 plan.md

入口先执行 ../cap/SKILL.md 的“研发上下文门禁”：.cap 检查不可跳过，知识库注入失败可记录后离线继续。

全程契约：开始实质工作前读取并执行 ../cap-flow/references/progress-protocol.md 与 ../cap-flow/references/task-reconnaissance.md。先播报当前动作和下一步；新任务没有新鲜 .cap/task-context.md 时，先调查当前仓库代码，不能只依赖 PROFILE。

你的唯一职责:读已批准的 spec.md,产出一份 <target-repo>/.cap/plan.md,把需求两级贯通:

spec(已批准)  →  阶段 phase(含 depends_on + wave 波次)  →  任务 task(含三必填字段)

产物必须满足两条铁律(贯穿全文):

• No-Placeholder(无占位红线):任何任务的 action 必须含真实可执行内容(具体文件路径、具体值、 具体命令),不许出现 "TBD / 待定 / 实现细节后补 / 加适当的错误处理 / v1 先这样"。
• 100% Traceability(全覆盖追溯):spec 里每一条需求 / 决策都能指到至少一个任务;反向每个任务都能指回 它实现的需求。靠 Source Audit + Coverage Gate 双向核验(§6)。

引擎 = 一个能 Read/Edit/Bash/Grep 的模型。 不依赖任何后台服务 / 子代理运行时 / 特定目录约定 / 富交互 控件。所有交互用纯文本编号列表,所有产物落纯文件。

---

0. 入口条件（先验，未满足就停）

进入本阶段前确认:

1. <target-repo>/.cap/spec.md 存在。
2. spec 已获批(cap-define 的出口门控已过;STATE 里 spec 状态为 approved)。

硬前置:没有获批的 spec 就拆 plan,等于在没对齐的设计上排兵布阵。两条都满足才往下走。

• 无 spec.md → 停。用编号文本提示用户先走 cap-define:

  没找到 .cap/spec.md。规划需要一份已批准的 spec 作输入。
    1) 现在去跑 cap-define 产出并批准 spec(推荐)
    2) 我手动指给你一个已有的 spec 文件路径
  回个编号。
  

• spec 存在但未确认获批 → 不静默继续。用编号文本让用户确认:

  找到 spec.md,但 STATE 里没看到"已获批"标记。规划会把 spec 当作锁定决策来拆。
    1) spec 已经批了,继续规划
    2) 还没批,我先回 cap-define 走批准门控
  回个编号。
  

本阶段不做需求讨论 / questioning。 那是 cap-define 的事。这里把 spec 当作锁定的输入。若发现 spec 有歧义 / 缺口,不是自己拍板补——而是记进 STATE 的 Decisions log 并按 §6 的 MISSING 流程上报,让用户 决定(加任务 / 拆阶段 / 显式 defer)。

---

1. 可移植前置（每次入口一次性）

共享 references 的位置:本文引用的 role-routing.md、web-review/playbook.md 物理上都在编排器目录 cap-flow/references/ 下,不在本阶段目录里。解析路径一律指向 cap-flow/references/...(相对 skills 根) 或经软链接定位,别当相对本目录读。

与编排器同源的两条降级范式:

1.1 交互降级 —— 纯文本编号选项

凡需用户确认(复杂度分级、MISSING 项处置、最终 plan 确认),优先纯文本编号列表:

需要你定一个:
  1) 选项 A —— 说明
  2) 选项 B —— 说明
回个编号即可。

宿主有结构化提问控件可用,但回退路径必须是上面这种编号文本。默认按编号文本写。

1.2 并行降级 —— 能并行就并行，不能就串行

规划本身通常单会话串行即可(拆任务是连贯推理,不强求并行)。若 spec 覆盖多个独立子系统且环境有 并行能力,可一子系统一分支并行起草分计划;无并行能力 → 串行逐子系统拆。不论哪种,最终合并成一份 plan.md,且单写者写 plan.md / STATE.md(不并发写同一文件)。