里程碑开发笔记：Dao 交付闭环落地
这轮为什么做
在补完《Dao 核心理论》和《Dao Commit 规范》之后，当前仓库已经有了“为什么这样做”和“如何提交变化”的理论基础，但还没有真正把这套方式落成一个可执行的交付闭环。
如果继续直接推进后续业务主题，团队每做一个里程碑都还需要重新定义文档结构、重新对齐推进顺序、重新约定自测与记录方式。这会让交付节奏不稳定，也会让 Dao 的原则停留在说明层。
所以这一轮先不扩业务边界，而是先把“如何按 Dao 推进里程碑”这件事真正做成当前仓库里的工程能力。
这轮解决了什么
这轮主要解决了四个问题：
- 后续里程碑缺少统一的阶段规划入口
- 里程碑文档缺少固定结构
- 新里程碑启动时缺少脚手架能力
- 子任务闭环、自测和文档沉淀没有标准执行底座
对应的结果是：
- 补齐了阶段里程碑总规划
- 补齐了 M1 的任务拆解、详细设计、开发记录和开发笔记
- 建立了可复用模板
- 建立了
dao:milestone脚手架入口
关键路径
这一轮按下面路径推进：
- 先定义阶段里程碑地图
- 再明确 M1 的任务拆解
- 先梳理主流程、子任务闭环和异常流程
- 再进入详细设计
- 实现模板和脚手架
- 用一次真实生成验证脚手架
- 执行
docs:sync和docs:check - 回写开发记录和本篇笔记
这条路径验证了一件事：Dao 的交付原则不是只能指导内容表达，也可以直接指导工程推进顺序。
设计与实现中的关键判断
判断一：先做最小可用闭环，而不是一开始做全量自动化
这轮没有直接做复杂 CLI，也没有在 M1 就引入太多模板变量，而是先保证：
- 里程碑能被快速初始化
- 文档结构统一
- 自测链路清楚
- 后续能直接复用
这样可以先稳定方法，再逐步扩展能力。
判断二：脚手架必须和文档规范一起存在
只有文档规范，没有执行抓手，后续很容易重新回到随意推进。
只有脚手架，没有设计文档，后续又容易变成“能生成文件，但不知道怎么用”。
所以这轮保持两者并行：
- 用文档定义边界和节奏
- 用脚手架降低执行门槛
判断三：先把 M1 做成第一份示范案例
M1 不只是“交付底座”本身，也是一份真实示范。
后续任何里程碑都可以直接参考这一轮的结构，按相同方式推进。
自测与修复
这一轮自测按三步完成：
1. 脚手架验证
执行：
node scripts/create-dao-milestone.mjs M2 内容治理扩面 /tmp/dao-m2-test
结果：
- 成功生成 4 份标准文档
- 验证了命名、变量替换和输出目录逻辑
2. 文档同步验证
执行：
npm run docs:sync
结果：
- 通过
- 新增 Dao 文档成功进入站点同步链路
3. 站点校验验证
执行：
npm run docs:check
结果：
- 通过
- 构建与质量校验链路正常
本轮没有出现需要二次回修的失败项，因此直接完成自测闭环。
结果与下一步
M1 完成后，当前仓库已经具备：
- 阶段里程碑规划能力
- 标准里程碑文档结构
- 可复用的模板
- 可执行的脚手架入口
- 可直接复用的 M1 示例
下一步最自然的方向，是进入 M2，选定一个真实业务或内容治理主题，用这套方式完整跑通一次“真实里程碑开发”。
这样 Dao 的交付方式就会从“底座建立”进入“业务落地验证”。