slicing-goals-into-dagslisted

# slicing-goals-into-dags —— 把目标切成一张好 board DAG > 把一个目标 / epic **切**成 board 任务依赖图时，用这套敏捷方法论与品味回答"怎么拆出一张好图"；不覆盖"一张已成形的图怎么排期"(那是 master-orchestrator-guide 的 decomposition 一段)。 > > **职责边界:** **切**(carve)归本 skill;**排**(schedule:CPM / 临界路径 / 并行度计算)归 master-orchestrator-guide 的 board 协议 reference;**派**(dispatch)归 master-orchestrator-guide;**执行**单个 task 到验收归 dev-as-ml-loop;**写进** board 归 using-ccm。本 skill 只管"怎么把目标切成图"这一刀。 > **前置条件：只切 settled Goal Contract。** raw request / issue / goal 参数只是证据��先按 `master-orchestrator-guide` 的 `references/goal-contract.md` 澄清转写，并让 `ccm goal check` 返回 `ok`（legacy 板保持兼容），再用本 skill 切当前 revision。若 assurance 仍是 `pending`，只准备 `blocked_on:user` `decision_package`，不用一张精致 DAG 掩盖目标歧义。 --- ## 为什么这一刀最值钱 **你怎么切,定死了后面一切的天花板。** 并行度、多快能 ship、多快拿到反馈——全在切的那一刻就定了,**排期再优、派发再快也救不回一张切坏的图**。一张横切的图,哪怕关键路径算得再准,也照样把价值堆到最后、把本可并行的活人为串成一条线。所以:**切,是高杠杆决策;别急着排和派,先把它切对。** --- ## 心智锚 1:纵切,不要横切 ★硬规则 把目标切成**薄的、端到端的纵向增量**——每一片自己穿过所有需要的层、交付一个用户(或下一个消费者)**真能触碰**的能力;**不要**按技术层横切(全做数据模型 → 全做 API → 全做 UI)。 - **纵切**:`添加支出(端到端:够用的 schema 片 + 一个 endpoint + 最小表单)` / `看列表(端到端)` / `月度图(端到端)`——每片是一根穿层的细线。 - **横切**:`T:数据模型层` → `T:后端层` → `T:前端层` → `T:测试层`——每个节点是一整层。 > **落地**:每个纵切片 = 一个带 `--accept`(自己的 DoD)的 `ccm task`,片之间的真实数据依赖用 `--deps` 连。横切那种"一整层"节点往往**给不出自己的 DoD**——难端点验收,这本身就是切错的信号。命令语法见 `using-ccm`。 横切为什么是默认、又为什么是错的:它**感觉**像工程严谨(地基先打牢),实则把地基做成 serial 瓶颈(并行度=1 直到它完成)、把任何可用价值推到最末、且那个"打牢的地基"是**投机的**(你还没切片,根本不知道下游真正需要什么)。 ### Rationalization Table —— 横切最常见的自我说服 | 你会对自己说 | 现实 | |---|---|