delivery-planlisted

# 交付链路规划器 ## 上游产物：设计稿出过就要排进计划 排顺序的依据是 SRS 的模块依赖。但项目若有 `design-system/`，**计划里要体现两件事**： 1. **`FLOWS.md` 的流程条目是天然的交付切片**——一条流程（含失败分支）做完才算一个可验收单元， 比「按页面排」更接近用户可感知的完成度； 2. **令牌与组件先行**：`tokens.json` 与 `HANDOFF.md` 第 3 节的组件清单要排在业务页面之前， 否则每个页面各写一套样式，后面返工。 调 `page-generator` 时把 `design-system/` 一并传下去（它的**步骤 2.1** 会读）。 设计稿不存在时本节跳过，按 SRS 模块依赖排。 ## 工作模式 | 模式 | 触发场景 | 入口 | |------|---------|------| | **生成模式** | 首次为项目生成交付计划 | → Step A | | **查看模式** | 查看当前进度和推荐 | → Step B | | **更新模式** | 标记功能完成，更新计划 | → Step C | | **自动执行模式** | 按计划连续实现所有功能，不停止不询问 | → Step D | --- ## Step A: 生成模式 ### A1: 扫描项目上下文 Read `../common/prd-to-srs-gate.md` §1，检测 SRS / PRD： ```bash # 查找 SRS（交付计划唯一真���） find dev/SRS/ docs/SRS/ -name "*.md" 2>/dev/null # 新根 + 旧根 find docs/01-需求与规划/ -name "*SRS*.md" -o -name "*需求*说明书*.md" 2>/dev/null # 兼容更旧的路径 # 查找 PRD（须先转写，不可用于本技能） find prd/PRD/ docs/PRD/ -name "*.md" 2>/dev/null # 新根 + 旧根 find docs/ -name "*-PRD.md" 2>/dev/null # 兼容更旧的命名 # 查找已有交付计划 ls dev/plan/delivery-plan-*.md 2>/dev/null ls docs/delivery-plan-*.md 2>/dev/null # 兼容旧根 ls dev/plan/delivery-plan.md docs/delivery-plan.md 2>/dev/null # 兼容旧命名（无项目名） ``` - 若已有 `dev/plan/delivery-plan-{项目名称}.md`（或旧根 `docs/delivery-plan-{项目名称}.md`），询问用户是否覆盖重新生成； 命中旧命名时**顺手 `mv` 成带项目名的新名**再更新，别在旧名上继续追加 - **仅有 PRD、无合格 SRS** → 输出门禁 §3 话术，**中止**，路由 **`req-doc` Step F** - 若无 SRS 也无 PRD → 提示用户先用 `/req-doc` 或 `/prd-writer` + Step F ### A2: 调用 delivery-analyzer ``` subagent_t