ddt-deliverlisted

# ddt-deliver — 按需收口 ## 何时使用 收口不是每次工作的必须步骤。当工作**确实需要交付签收**时再用： - 多个实现切片汇合，需要统一收口的验收记录 - toB 客户验收场景，需要正式交付包与接收确认 - 部署到生产环境，需要部署指南与回滚方案 - 数据迁移，需要迁移验证与回滚证据 - `docs/api/`、`docs/data/`、`docs/design/` 发生变更，需要更新说明 - 客户交付说明、演示脚本 - 降低保障级交付（断网/受限基建）需要显式标注 **小修小改不强制走本 skill**——合并一个 bug fix、更新文档、补测试，通常直接完成即可。 ## 是��要走收口（决策流） ```dot digraph deliver_entry { "本次工作有下游接收方？" [shape=diamond]; "下游是谁？" [shape=diamond]; "走 ddt-deliver 收口" [shape=doublecircle]; "结束（无需 deliver）" [shape=doublecircle]; "判断变更影响面" [shape=box]; "本次工作有下游接收方？" -> "下游是谁？" [label="是"]; "本次工作有下游接收方？" -> "结束（无需 deliver）" [label="否（纯内部小修小改）"]; "下游是谁？" -> "走 ddt-deliver 收口" [label="toB 客户 / 生产部署 / 数据迁移"]; "下游是谁？" -> "走 ddt-deliver 收口" [label="多切片汇合需要统一验收"]; "下游是谁？" -> "判断变更影响面" [label="只改了 docs/api,data,design"]; "判断变更影响面" -> "走 ddt-deliver 收口" [label="下游消费者依赖此契约"]; "判断变更影响面" -> "结束（无需 deliver）" [label="只是内部重构 / 文档微调"]; } ``` 判据靠**问"下游是谁、要什么"**，不靠 LLM "感觉这次比较正式"。如果说不出具体的接收方与他们要的证据，多半就是没下游、直接结束。 ## 按需产物 根据实际场景选择需要的产物，不强制全套： ### 验收记录（`docs/verification/`） 记录验收过程与结论： - 哪些场景经过人工或自动化验证，以什么方式 - 验收通过的证据（测试结果、截图、日志片段） - 已知局限与边界 ### 交付包（`docs/delivery/`） 根据交付类型选择： - **README / 发布说明**：面向接收方的项目定位、快速上手、版本变更 - **部署指南**：环境矩阵、依赖版本、部署步骤、回滚指引 - **演示脚本**：seed 数据命令、演示步骤、预期输出、已知限制 - **客户交付说明**：面向 toB 客户的接收确认材料 ### AI 效能 ROI 报告（按需） 由 `ddt-report.mjs` 产出，读 `.ddt/metrics/*.jsonl` 与 `.ddt/decisions.jsonl`，渲染 `docs/efficiency-report.md`。需要度量数据时按需运行：`ddt-report.mjs`。 ## 降低保障级交付 断网/受限基建下若完整