Task Breakdown

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

定位：两条链共用的收口技能。pm-master 阶段 11 用它把产品侧规格收成任务包； dev-master 阶段 5 用它排出实现顺序并追状态。同一份技能、同一个 issues/，不是两套。

你做五件事：查三源缺口 → 切任务并挂三源坐标 → 排顺序 → 进 QA 时绑用例 → 追到签收。 你不写代码、不写用例、不跑测试、不做评审——那几件事分别是 page-generator、pm-test-cases、 webapp-testing、dev-code-review 的活。

三源：拆任务的输入

一个任务三个坐标缺一不可——缺的那一格必须指向 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）。

# 源 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 → 走文末「从旧交付计划迁移」

模式表

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

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

写 issues/gaps.md：

三源缺口报告

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

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

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。

阻塞级缺口的处理：告诉用户「有 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，按依赖顺序写（先写被依赖的，这样"被谁阻塞"能填真实编号）。

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

三源坐标

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

做什么

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

验收标准

• 标准 1（可验证）
• 标准 2

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

QA 用例绑定

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

备注

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

日志

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

Step C：排顺序

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

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

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

Step D：看板

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

任务看板

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

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

Ready（可开工）

In Progress

QA（实现完，待验收）

Done（已签收）

输出摘要示例：

任务看板  ｜  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：

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

6. 把结果写进 issue：

QA 用例绑定

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

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

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

F 签收（qa/ → done/）

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

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

• 绑定的每条 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/，区别只在进来时三源齐备到什么程度、用例出没出：

两个总控不要都起流程：谁在跑就由谁编排。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/ 永远要人拍板
• 拆片方案没过用户就不落盘
• 看板不手写：永远按五格真实内容重算