ddt-design-checkpointlisted

# ddt-design-checkpoint — 设计落地闸（资产就位，不是答完表） **它不是设计生成器**——设计本身在 ddt-brainstorming/spec 阶段已产出。 **它不是 ddt-brainstorming 替代**——发散与设计探索在 ddt-brainstorming 里做。 **它不是判断题答卷**——七问每个"是"都必须有**对应的真实落地资产**就位，否则闸不算通过��� ## 为什么这道闸必须真的落地 `ddt-writing-plans` 的输入应该是**已锁定的设计**。若契约、数据模型、架构决策仅以"七问答表"形式停在 spec 末尾，会发生三件事： - plan 基于纸面承诺推任务（"实现 X 接口"，但 X 的契约根本不存在）； - 实现阶段在没有锁定契约的情况下自由发挥； - reviewer 阶段没有锁定的契约可依，**证据先于断言**的原则被破坏。 所以闸的判据不是"答完七问"，而是"资产真的存在或推迟决策真的入账"。 ## 七问完成清单 设计推进到下一落地阶段（单 brief → `ddt-writing-plans`，或大需求 → 逐切片深做）之前，**逐条核对每条的状态**： 1. **`docs/api/` 资产已就位？** 本次设计若新增或修订 API 契约（OpenAPI / RPC schema / 接口签名），对应文件已写入 `docs/api/<name>.{yaml,md}`，内容含调用方/被调方约定。 2. **`docs/data/` 资产已就位？** 若涉及数据模型新增/修订/迁移，对应文件已写入 `docs/data/<name>.md`，内容含字段、约束、迁移路径。 3. **`docs/design/` 资产已就位？** 凡本次涉及**非平凡设计**的——架构图 / 模块拓扑 / 业务流程 / 跨模块时序 / 难点算法（推导、复杂度、边界）/ 重点复杂功能（状态机、并发协议、事务模型、复杂条件分支）/ 数据流（"怎么流"，与 `docs/data/` 的"长什么样"互补）/ 选型 ADR / 跨模块边界决策——都已写入 `docs/design/<topic>.md`，内容含设计意图与理由。 - **"非平凡"判据**（任一命中即必须落地）：动了架构、模块边界、跨模块流程；新增 / 改了数据流；时序敏感的算法或并发协议；状态机或复杂条件分支；选了一个有替代的方案（选型）。 - **合法跳过的极少数情况**（清单之外都不算）：纯重构（不动架构 / 流程 / 算法）、纯依赖升级、纯测试补强、仅文档微调、仅 UI 文本 / 样式微调（且不触及交互流程）。 - `docs/design/` 不是 ADR 专属目录——ADR 只是一种形态。**阅读代码读不出来的设计意图，都属设计留痕**。 4. **`.ddt/decisions.jsonl` 已追加？** 凡需要持久化为团队决策的条目，已经 `ddt-decisions-append.mjs` 追加（写在 spec 里不算）。 5. **`.ddt/changelog.jsonl` 已追加？** 凡构成显著变更的事项，已经 `ddt-changelog-append.mjs` 入账。 6. **开放问题已表态？** 未解决冲突 / 待协同确认项已写明（spec 内或 `docs/design/<topic>-open-questions.md`），且**显式判断为"放行（带已知开放项