# Task Breakdown

> 任务分解：把 PRD、SRS、设计稿**三份规格产出**切成研发可领的任务包，每个任务带三源坐标 （PRD 章节 + SRS 字段表小节 + 设计稿页面锚点），并先出一份三源缺口报告。 **测试用例不是拆任务的输入，是 QA 环节的绑定物**——任务进 `qa/` 时才与用例对上并查覆盖。 任务落 `issues/` 五格物理文件夹 + `issues/kanban.md` 看板，追到签收进 done。 另接管实现顺序排布、进度追踪与按计划连续实现。 触发场景：(1) "任务分解" "拆任务" "拆成 issue" "切片" "tracer bullet" "看板", (2) "三源对不对得上" "PRD 和 SRS 差在哪" "设计稿有没有漏页", (3) "交付计划" "开发顺序" "下一步做什么" "实现计划" "查看进度", (4) "实现全部功能" "按计划实现所有功能" "自动实现" "一直实现" "连续实现", (5) "哪些卡在 QA" "这个任务验了哪几条用例" "签收" "打回重做"。 挂载点：`pm-master` **阶段 11**（产品侧规格齐备后的收口）与 `dev-master` **阶段 5**（进编码前的排布）—— 同一个技能两处挂载，共用仓库根同一份 `issues/`，不是两份。 不适用：写代码（`page-generator` / `dev-fullstack-product`）、写用例（`pm-test-cases`）、 跑测试（`webapp-testing`）、代码评审（`dev-code-review`）、终检（`verification-before-completion`）、 排障（`systematic-debugging`）、上线审计（`pm-ai-ship-audit`）。

- Skill: `idwong/task-breakdown` (Agent Skill)
- Install (CLI): `npx skillmds@latest add idwong/task-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/idwong/task-breakdown/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: iDWong (https://skillmd.com/u/idwong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/idwong/task-breakdown

---


# task-breakdown：三源任务分解与看板

> 定位：**两条链共用的收口技能**。`pm-master` 阶段 11 用它把产品侧规格收成任务包；
> `dev-master` 阶段 5 用它排出实现顺序并追状态。**同一份技能、同一个 `issues/`，不是两套。**
>
> 你做五件事：**查三源缺口 → 切任务并挂三源坐标 → 排顺序 → 进 QA 时绑用例 → 追到签收**。
> 你**不写代码、不写用例、不跑测试、不做评审**——那几件事分别是 `page-generator`、`pm-test-cases`、
> `webapp-testing`、`dev-code-review` 的活。

## 三源：拆任务的输入

| 源 | 从哪读 | 给任务提供什么 |
|---|---|---|
| **PRD** | `prd/PRD/*.md` | 这件事**为什么做**、业务规则、文案。**项目没有 PRD 时这一格豁免**，见 Step 0 分支 |
| **SRS** | `dev/SRS/*.md`（`SPEC_SOURCE`） | **字段级规格**：字段、类型、必填、校验、枚举、状态流转 |
| **设计稿** | `design-system/`（`FLOWS.md` / `HANDOFF.md` / `*.html`） | 动哪些**页面**、走哪条流程、用哪些组件与令牌 |

**一个任务三个坐标缺一不可**——缺的那一格必须指向 `issues/gaps.md` 的缺口编号，不许留空、不许编。
**唯一例外**：项目根本没有 PRD（纯研发流程）时，PRD 坐标写 `无 PRD（研发流程）`，这不算缺口。

## 测试用例为什么不在三源里

用例是**验收阶段的绑定物**，不是拆任务的输入。三个理由：

1. **研发链里它还没出**。`dev-master` 的测试在**阶段 9**，任务分解在**阶段 5**——
   拿用例当拆任务的硬输入，整条研发链会卡在阶段 5 动不了
2. **粒度对不上**。用例回答「验什么」，任务回答「做什么」，两者不是一一对应；
   拆任务时硬挂 TC 编号，造出来的多半是假对应
3. **它真正有用的时刻是验收**。任务进 `qa/` 时才有意义问「这个任务验完了没有」

所以用例在 **Step E（进 QA）绑定、Step F（签收）核销**，见下方「QA 与用例怎么结合」。

---

## Step 0：三源盘点 + 门禁（每种模式都先跑，不可跳过）

Read `../common/prd-to-srs-gate.md` §1–§2。本技能**不得以 PRD 为规格真源**（PRD 只提供业务意图，
字段级规格只认 SRS）。

```bash
# 源 2：SRS —— 规格真源，硬前置
find dev/SRS/ docs/SRS/ -name "*.md" 2>/dev/null
find docs/01-需求与规划/ -name "*SRS*.md" -o -name "*需求*说明书*.md" 2>/dev/null
# 源 1：PRD —— 业务意图，软前置
find prd/PRD/ docs/PRD/ -name "*.md" 2>/dev/null
# 源 3：设计稿
ls design-system/FLOWS.md design-system/HANDOFF.md design-system/*.html 2>/dev/null
# 上游可选：优先级（任务的 P 级继承它，不现场拍）
ls prd/planning/feature-priority-*.md 2>/dev/null
# QA 用：测试用例（**拆任务时不读**，Step E 进 QA 才读）
ls prd/test/*测试用例*.md dev/test/*测试用例*.md 2>/dev/null
# 本技能已有产出
ls issues/kanban.md issues/gaps.md 2>/dev/null; ls -d issues/ 2>/dev/null
```

分支：

- **有合格 SRS** → 登记 `SPEC_SOURCE=<路径>`，继续
- **有 SRS 但没有 PRD**（走 `dev-master` 研发流程的项目，本来就没有产品侧 PRD 链路）→
  **允许以 SRS 为唯一规格真源**。PRD 坐标统一写 `无 PRD（研发流程）`，**不记缺口、不扫 G1**，
  并在 `gaps.md` 抬头注明一行「本项目无 PRD，业务意图取自 SRS」。
  **不要为此去跑 `pm-prd-spec` 补一份 PRD**——研发流程里没有这一环，硬等 PRD 会把阶段卡死
  （与 `ui-ux-pro-max` 设计稿契约的同类豁免一个口径）
- **仅有 PRD、无 SRS** → 输出门禁 §3 话术，**中止**，路由 `req-doc` **Step F**
- **两者都无** → 路由 `req-doc`（要 SRS）或 `prd-writer`（先要 PRD）
- **设计稿缺** → **不中止**，按 G2 记进缺口报告，该坐标写 `缺（G-00x）`
- **用例缺** → **与本阶段无关**，不记缺口、不中止（它在 QA 环节才登场）
- **已有 `issues/`** → 默认进 **Step D 看板**，不要直接重拆覆盖
- **命中旧的 `dev/plan/delivery-plan-*.md`** → 走文末「从旧交付计划迁移」

---

## 模式表

| 模式 | 触发 | 入口 |
|---|---|---|
| **A 缺口检查** | 首次拆之前必跑；或用户单问「三源对不对得上」 | → A |
| **B 拆任务** | 首次拆，或明确要重拆 | → B |
| **C 排顺序** | 拆完自动接；或「开发顺序」「下一步做什么」 | → C |
| **D 看板** | 「现状」「什么能开工」「谁卡在 QA」「查看进度」 | → D |
| **E 流转** | 开工／实现完进 QA（**此时绑用例**）／解除阻塞 | → E |
| **F 签收** | 验收通过或打回 | → F |
| **G 连跑** | 「实现全部功能」「自动实现」「一直实现」 | → G |

---

## Step A：三源缺口检查（先查漏，再拆）

PRD、SRS、设计稿是**分三次产出**的，彼此漂移几乎必然存在，而现在没有任何技能查这件事。
三类缺口各扫一遍：

| 编号 | 缺口 | 怎么查 | 后果 |
|---|---|---|---|
| **G1** | PRD 写了功能，SRS 无对应字段表 | PRD §4/§5 每个功能点 → SRS 3.5.x 找字段表 | 开发没有字段级规格，只能猜 |
| **G2** | SRS 有字段表，设计稿无对应页面 | SRS 3.3 页面清单 + 3.5.x → `design-system/*.html` 与 `FLOWS.md` | 有规格没界面依据 |
| **G3** | 设计稿有页面或流程分支，PRD 与 SRS 都找不到出处 | `FLOWS.md` 每条流程（**含失败分支**）+ 每个 HTML 页 → 回查 PRD/SRS | 凭空多出来的界面，没人知道该不该做 |

写 `issues/gaps.md`：

<gaps-template>

# 三源缺口报告

_生成日期：[日期]_
_三源：PRD `[路径]` ｜ SRS `[路径]` ｜ 设计稿 `design-system/`_
_缺口 N 条：阻塞 n 条 / 待补 m 条_

## 一、三源缺口（拆任务时查，G1–G3）

| 编号 | 类型 | 缺什么 | 影响的任务 | 严重度 | 处置 |
|---|---|---|---|---|---|
| G-001 | G1 | PRD §4.3 退款规则，SRS 无字段表 | T-012 | **阻塞** | 回 `req-doc` 补 3.5.x |
| G-002 | G3 | `FLOWS.md`「积分抵扣」流程，PRD/SRS 均无出处 | — | 待裁决 | 问用户：补规格还是删这条流程 |

### G-001 ｜ G1 ｜ 阻塞
**PRD 说：** §4.3.2「用户可在发货前申请退款」（原文摘一句）
**SRS 查到：** 3.5 下无 refund 相关字段表
**为什么阻塞：** 退款状态机、可退时限、金额校验全部无规格，开发写不了
**处置：** `req-doc` 补写 3.5.x；补完回本技能重跑 Step A 关闭本条

## 二、QA 覆盖缺口（进 QA 时滚动追加，Q1–Q2）

_本节在任务进 `qa/` 时才有内容，见 Step E。_

| 编号 | 类型 | 任务 | 缺什么 | 处置 |
|---|---|---|---|---|

</gaps-template>

**阻塞级缺口的处理**：告诉用户「有 n 条阻塞缺口，涉及 m 个任务」，问一句——

> 「先把这 n 条补齐再拆，还是照拆、把受影响的任务标成 `backlog/` 等补件？」

**不许自己替用户决定，也不许因为缺口存在就整个中止。**

---

## Step B：拆任务

### B1 切垂直切片

<切片规则>
- 一片穿透**所有集成层**（数据表 → 接口 → 页面），不是某一层的横切
- 一片做完**能独立演示或验证**
- **宁可多而薄，不要少而厚**
- `design-system/FLOWS.md` 里的一条流程（**含失败分支**）是天然的一片，优先照它切
- **令牌与组件先行**：`tokens.json` 与 `HANDOFF.md` 第 3 节的组件清单排在所有业务任务之前，
  否则每页各写一套样式，后面返工
- 认证 / 权限 / 基础数据这类被依赖的任务永远排最前
</切片规则>

每片标两个属性：

- **类型**：`AFK`（一路做完不用等人）/ `HITL`（中途必须有人拍板）。**优先切成 AFK**
- **优先级**：`P1`/`P2`/`P3`。**有 `prd/planning/feature-priority-*.md` 就照它映射**，
  映射不上才自己判，并在备注里写一句为什么

### B2 挂三源坐标

每片逐一填三个坐标，**填不出来就是缺口**，回 Step A 补记再继续：

```
T-012 订单取消
  PRD    §4.3.2 取消规则
  SRS    §3.5.7 order_cancel 字段表 + 状态流转
  设计稿  design-system/mobile-order-detail.html#cancel-sheet
         FLOWS.md「订单取消」含「已发货不可取消」失败分支
```

### B3 过一遍用户

编号列表摆出来，每片显示：标题 ｜ 类型 ｜ 优先级 ｜ 被谁阻塞 ｜ **三源坐标是否齐** ｜ 关联缺口编号。问：

- 粒度对不对（太粗 / 太细）？
- 依赖关系对不对？
- 哪几片该合、哪几片该拆？
- HITL / AFK 标对了吗？
- 缺口任务按「等补件」还是「照做、缺的部分先按 SRS 兜底」？

**改到用户点头再落盘。** 不要拆完直接写文件。

### B4 建目录并落盘

```
issues/                      ← 仓库根，与 prd/ dev/ design-system/ 并列
├─ kanban.md                 看板（按五格真实内容重算，不手写）
├─ gaps.md                   三源缺口 + QA 覆盖缺口
├─ backlog/                  有未解阻塞，或等缺口补件
├─ ready/                    无阻塞，可开工
├─ in-progress/              正在做
├─ qa/                       实现完，待验收（**进这一格时绑用例**）
└─ done/                     已签收
```

扫五格找当前最大编号往下接；一个都没有从 `001` 起。无阻塞 → `ready/`；有阻塞或等缺口 → `backlog/`。
文件名 `NNN-短横线名.md`，**按依赖顺序写**（先写被依赖的，这样"被谁阻塞"能填真实编号）。

<issue-template>

---
id: issue-NNN
title: "[任务标题]"
feature: [模块 slug]
status: ready / backlog
created_at: YYYY-MM-DD
tags: [afk/hitl, p1/p2/p3]
sources:                     # 三源，拆任务时填
  prd:    "prd/PRD/xxx.md#4.3.2"
  srs:    "dev/SRS/xxx.md#3.5.7"
  design: "design-system/mobile-order-detail.html#cancel-sheet"
gaps: []                     # 有缺口就填 [G-001]，且对应坐标写「缺（G-001）」
qa:                          # 进 qa/ 时才填，拆任务时留空
  tests: []                  # 绑定的 TC 编号
  coverage: ""               # full / partial / none
---

# [NNN] [任务标题]

**类型：** HITL / AFK　**优先级：** P1 / P2 / P3　**被谁阻塞：** 无 / [编号]
**涉及端：** 后端 / 管理端 / 移动端 / H5

## 三源坐标

| 源 | 位置 | 这一源给了什么 |
|---|---|---|
| PRD | §4.3.2 取消规则 | 发货前可取消，超时自动关单 |
| SRS | §3.5.7 order_cancel | 字段表 8 个字段 + 5 态状态机 |
| 设计稿 | `mobile-order-detail.html#cancel-sheet` | 取消弹层 + 二次确认 + 失败 toast |

> 任一格写「缺（G-00x）」时，**必须**在下方「做什么」里写清缺的那部分按什么兜底。

---

## 做什么

端到端的行为，用业务语言写。不写文件路径、不贴代码——它们过期最快。
例外：SRS 或详细设计里已定死的状态机 / 字段表 / 类型，贴决策性的那几行并注明出处。

---

## 验收标准

- [ ] 标准 1（可验证）
- [ ] 标准 2

> 带外观、布局、动效的标准另起一行标 **【需人工看】**——它们不进自动化用例，走人工走查。
> **标准怎么写决定 QA 时能不能绑上用例**：写「可验证的行为」，不要写「体验好」。

---

## QA 用例绑定

_进 `qa/` 时由 Step E 填，拆任务时留空。_

---

## 备注

SRS 约束、要跟的既有模式、已定过的决策、关联缺口的兜底方案。

---

## 日志

_推进过程中追加，一次两三行。_

</issue-template>

---

## Step C：排顺序

拓扑排序，**依据按优先级递减**：

1. **依赖**：被依赖的排前（认证／权限／基础数据／令牌与组件）
2. **优先级**：`prd/planning/feature-priority-*.md` 的 P 级
3. **流程完整度**：`FLOWS.md` 一条流程的各片尽量连着做完，别跨流程跳
4. **三端项目默认纵向打通**：一个模块的后端 → 管理端 → 移动端全跑通，再开下一个模块

**依赖必须无环**——检出环就停下来告诉用户是哪几片，不要自己硬断。
排完写进 `kanban.md` 的顺序列，并给出推荐下一片。

---

## Step D：看板

扫五格真实文件 → 重算 `issues/kanban.md` → 输出摘要。

<kanban-template>

# 任务看板

_最后更新：[日期]_
_三源：PRD `[路径]` ｜ SRS `[路径]` ｜ 设计稿 `design-system/`_
_共 N 个任务（AFK n / HITL m）｜ 三源缺口 k 条（阻塞 j 条）｜ QA 覆盖缺口 q 条 → `gaps.md`_

## Backlog（有未解阻塞或等缺口补件）

| 顺序 | 编号 | 标题 | 类型 | 优先级 | 被谁阻塞 | 缺口 |
|---|---|---|---|---|---|---|

## Ready（可开工）

| 顺序 | 编号 | 标题 | 类型 | 优先级 | 三源齐 |
|---|---|---|---|---|---|

## In Progress

| 编号 | 标题 | 类型 | 优先级 | 开工日期 |
|---|---|---|---|---|

## QA（实现完，待验收）

| 编号 | 标题 | 类型 | 优先级 | 进 QA 日期 | 绑定用例 | 覆盖 |
|---|---|---|---|---|---|---|
| 007 | 登录与会话 | AFK | P1 | 09-21 | TC-AUTH-001~008 | 部分（2 条需人工看） |

## Done（已签收）

| 编号 | 标题 | 类型 | 优先级 | 签收日期 | 核销用例 |
|---|---|---|---|---|---|

</kanban-template>

输出摘要示例：

```
任务看板  ｜  SRS: dev/SRS/xxx.md  ｜  三源缺口 2 条（1 条阻塞）｜ QA 覆盖缺口 1 条

Backlog 3 ｜ Ready 5 ｜ In Progress 1 ｜ QA 2 ｜ Done 8   （共 19）

卡住的：
  004 订单状态机   被 002 阻塞（002 在 QA，签收后自动解锁）
  012 退款申请     等 G-001 补件（SRS 无 refund 字段表）

待你验收（QA 2 个）：
  007 登录与会话   TC-AUTH-001~008 已绑，其中 2 条标【需人工看】
  009 商品列表     ⚠ Q-001 无对应用例，需人工走查或回 pm-test-cases 补

推荐下一个：003 权限矩阵（P1，无阻塞，前置 001 已 done，三源齐）
执行：/page-generator 实现权限矩阵
```

---

## Step E：流转

**开工**（`ready/` → `in-progress/`）：物理移动 → frontmatter `status: inprogress` → 日志追加 → 重算看板。

**实现完**（`in-progress/` → `qa/`）—— **这一步要绑用例，见下一节**。

**解除阻塞**：每次有任务进 `qa/` 或 `done/`，扫 `backlog/`，阻塞项已全进 `qa/`/`done/` 的移到 `ready/`
并改 `status`。**每次流转后都要做**，否则看板会骗人。

**缺口补齐**：`gaps.md` 某条关闭时，把挂着它的任务从 `backlog/` 放行到 `ready/`，补全三源坐标，
在日志里记「G-00x 已关闭，坐标补全」。

**发现新缺件**：任务依赖的东西根本不存在 → issue 里追加 `## 缺件` 段 → 移回 `backlog/` →
同步补一条 `gaps.md` → 重算看板。**不要猜着往下做。**

**范围纪律**：一个任务只改与它相关的东西。顺手看见别的问题 → issue 里追加 `## 旁支` 段记下来，**不要顺手改**。

---

## QA 与用例怎么结合

用例在这里、而且只在这里登场。**进 `qa/` 绑定，在 `done/` 前核销。**

### E-QA 绑定（`in-progress/` → `qa/` 时做）

1. **先核测试写了没有**：任务里说要写测试却没写，**不许进 QA**
2. **读用例库**：`prd/test/*测试用例*.md`（产品链未执行的验收用例）与 `dev/test/*测试用例*.md`
   （研发链真跑过的）。两边都有时**以 `dev/test/` 为执行依据、`prd/test/` 为应验范围**
3. **逐条验收标准找用例**：拿任务的「验收标准」去用例库匹配，绑定 TC 编号
4. **判覆盖等级**，写进 frontmatter `qa.coverage`：

| 等级 | 含义 | 怎么走 |
|---|---|---|
| `full` | 每条非【需人工看】的标准都有对应用例 | 正常进 QA |
| `partial` | 有标准找不到用例 | **可以进 QA**，但记一条 `Q1` 缺口，签收时那几条必须人工走查 |
| `none` | 整个任务没有任何用例 | 记 `Q1`，问用户：回 `pm-test-cases` 补，还是本任务只做人工验收 |

5. **反向查用例是否过期**：绑上的用例里引用的规则，回查 PRD/SRS 还在不在。
   对不上就记一条 `Q2`——**用例过期比没用例更危险**，它会验出一个"通过"

6. 把结果写进 issue：

<qa-binding-template>

## QA 用例绑定

**绑定日期：** YYYY-MM-DD　**覆盖等级：** full / partial / none
**用例来源：** `prd/test/xxx.md`（应验范围）／`dev/test/xxx.md`（执行依据）

| 验收标准 | 对应用例 | 结果 |
|---|---|---|
| 发货前可取消 | TC-ORD-014, TC-ORD-015 | 待执行 |
| 已发货拒绝取消并提示 | TC-ORD-016 | 待执行 |
| 取消弹层动效顺滑 | —【需人工看】 | 待走查 |
| 超时自动关单 | **无对应用例（Q-001）** | 待走查 |

**过期用例：** TC-ORD-019 引用的"48 小时可退"在 SRS §3.5.7 已改为 72 小时（Q-002）

</qa-binding-template>

7. 同步把 Q1/Q2 追加进 `gaps.md` 第二节，并在看板 QA 列标出覆盖等级

### F 签收（`qa/` → `done/`）

判据用现成的，不自己发明：

| 看什么 | 谁给结论 |
|---|---|
| 绑定的 TC 是否条条执行且通过 | 测试报告 / `webapp-testing` |
| 【需人工看】与无用例的标准 | 人眼走查 |
| 代码质量、证据行 `file:line` | `dev-code-review` |
| 「说做完了是不是真做完」 | `verification-before-completion` |
| 五阶段交付闭环 | `dev-master/references/delivery-review.md` |

**通过的硬条件**（缺一不可）：

- [ ] 绑定的每条 TC 都有执行结果，且全部通过
- [ ] `coverage` 为 `partial` / `none` 时，缺用例的那几条标准**已人工走查并记录结论**
- [ ] 【需人工看】的标准已走查
- [ ] 过期用例（Q2）已更新或已明确豁免

→ 日志追加 `YYYY-MM-DD 验收通过。已核销 TC-xxx~xxx；人工走查 n 条。依据：[报告路径]` →
`status: done` → 移到 `done/` → 重算看板 + 扫 `backlog/` 解锁 →
五格前四格全空时报「全部任务已签收」，并汇总还没关的 Q1/Q2。

**打回**：

<缺陷段模板>

## 缺陷

**报告日期：** YYYY-MM-DD
**发现于：** TC-xxx 执行失败 / 人工走查 / `dev-code-review` / `verification-before-completion`
**现象：** [实际行为，业务语言]
**期望：** [PRD/SRS/用例里说的应该是什么，**带出处**]

### 验收标准
- [ ] 该现象不再复现
- [ ] 原有验收标准仍然全部满足
- [ ] **有一条用例能挡住它再次发生**（没有就回 `pm-test-cases` 补，记 Q1）

</缺陷段模板>

→ 日志追加 → `status: ready` → 移回 `ready/` → 重算看板 → 告诉用户
`/page-generator 修 [编号]` 或 `/systematic-debugging` 先定位。

**缺陷段落永远不删**——它是这个任务的历史。被打回第二次就追加第二段，不覆盖。
重新进 QA 时**先确认那条「能挡住它」的用例真的有**，没有就记 Q1 并要求人工走查。

---

## Step G：连跑（按计划连续实现）

用户说「实现全部功能」「自动实现」「一直实现」时：

1. 按 Step C 的顺序取 `ready/` 里的第一个（三源齐、无阻塞、优先级最高）
2. 走 Step E 开工 → 调 `page-generator`（单端／已有项目）或 `dev-fullstack-product`（三端 0-1），
   **把该任务的三源坐标整个传下去**（`page-generator` 步骤 2.1 会读 `design-system/`）
3. 完成 → 走 E-QA 绑用例 → 进 `qa/` → 解除阻塞 → 重算看板
4. 回到 1，直到 `ready/` 空

**停下来的四个条件**（其余情况不停、不问）：

- `ready/` 空但 `backlog/` 非空 → 报还卡在什么上（阻塞或缺口）
- 遇到 `HITL` 任务 → 停下来等人拍板
- 命中阻塞级三源缺口 → 停下来，指向 `gaps.md` 对应条目
- 绑用例时判出 `coverage: none` → 停下来问用户：补用例还是只做人工验收

**连跑只跑到 `qa/` 为止。签收永远是人的事**，不要自动进 `done/`。

---

## 两处挂载：pm-master 阶段 11 与 dev-master 阶段 5

**同一个技能、同一个 `issues/`**，区别只在进来时三源齐备到什么程度、用例出没出：

| | `pm-master` 阶段 11 | `dev-master` 阶段 5 |
|---|---|---|
| 上游 | 阶段 7 需求文档 · 阶段 8 设计稿 · 阶段 9 用例都已出齐 | 阶段 1 SRS · 阶段 4 详细设计 · 阶段 6 设计稿 |
| 用例在不在 | **在**（阶段 9 已出）——进 QA 时直接绑 | **还没有**（在它的阶段 9）——绑用例时若为空，按 `coverage: none` 处理并提示先跑 `pm-test-cases` |
| 重心 | **Step A 缺口检查**——三份文档分三次产出，漂移最可能在这儿暴露 | **Step C 排顺序** + Step G 连跑 |
| 出来之后 | 交给 `dev-master`，它从阶段 1 的 SRS 门禁接手，**`issues/` 直接续用不重拆** | 进阶段 7 编码 |

**两个总控不要都起流程**：谁在跑就由谁编排。`issues/` 已存在时一律续用，
重拆会把 `done/` 的历史冲掉。

## 落盘：`issues/` 是仓库根的第四个根

```
仓库根/
├─ prd/             产品链（pm-master）
├─ dev/             研发链（dev-master）
├─ design-system/   设计链
└─ issues/          ← 本技能，两条链共用
```

**断点续跑扫盘必须扫它**：`issues/kanban.md` 存在即视为本阶段已完成。
`docs/**` 是旧根只读兼容。

## 从旧交付计划迁移

命中 `dev/plan/delivery-plan-*.md`（或旧根 `docs/delivery-plan-*.md`）时——
那是已删除的旧交付计划技能的存量产出，只读：

1. 已标 `[完成]` 的功能 → 建成 `done/` 里的任务，日志注明「由旧交付计划迁入，未回溯验收，三源坐标与用例绑定均未补」
2. 未完成的 → **重新按垂直切片切**，不要照抄功能条目当任务（粒度本来就不一样），并补三源坐标
3. 原文件保留**只读存档不删**，顶部加一行「已迁移至 `issues/kanban.md`，本文件不再更新」
4. 迁完跑一遍 Step A：旧计划是只读 SRS 排的，**三源缺口从来没查过**

## 不做什么

- 不写业务代码、不写用例、不跑测试、不做代码评审、不做上线审计
- 不以 PRD 为规格真源（PRD 只给业务意图，字段级规格只认 SRS）
- **不把测试用例当拆任务的输入**——它在 Step E 绑定、Step F 核销
- 三源坐标不许留空、不许编——填不出来就是缺口，记进 `gaps.md`；
  唯一例外是项目无 PRD（纯研发流程），那一格写 `无 PRD（研发流程）`
- 不自动改任务状态：每次流转都由明确事件触发（开工／完成／签收／打回／解除阻塞／缺口关闭）
- 不自动签收：连跑最远到 `qa/`，进 `done/` 永远要人拍板
- 拆片方案没过用户就不落盘
- 看板不手写：永远按五格真实内容重算