M1详细设计：Dao 交付闭环落地
这份文档说明 M1 将如何把 Dao 的交付原则落成当前仓库中可执行的工程资产。
设计目标
把“按 Dao 推进里程碑”从抽象原则，落成一套可复用的仓库工作流，保证后续每个里程碑都能稳定按相同节奏执行。
为什么 M1 先做交付闭环
当前仓库已经有：
- Dao 核心理论文档
- Dao Commit 规范文档
- Dao 里程碑交付工作流文档
但还缺少三类关键能力：
- 阶段里程碑的总规划入口
- 一套标准化里程碑文档模板
- 一个可以快速起里程碑文档骨架的脚手架
如果没有这三类能力，后续每个里程碑都会重新组织文档、重新定义结构、重新对齐流程，成本会持续偏高。
所以 M1 的重点不是做一个新业务，而是建立“后续业务里程碑如何被稳定交付”的底座。
业务流程设计
本轮的核心流程如下：
主流程
- 确认当前默认里程碑
- 编写任务拆解
- 梳理主流程、分支流程与异常流程
- 编写详细设计
- 开发模板与脚手架
- 运行脚手架验证
- 执行文档同步与构建检查
- 回写开发记录
- 提交当前子任务
子任务闭环流程
- 明确子任务目标
- 实现当前改动
- 进行自测
- 如果失败，则继续修改
- 再次自测，直到通过
- 更新开发记录
- 以 Dao Commit 方式提交
异常流程
如果脚手架生成失败或站点构建失败，则：
- 回到实现阶段定位问题
- 修复模板或脚本逻辑
- 重新执行生成验证
- 重新执行站点校验
目录结构设计
本轮新增资产设计如下：
text
docs/
dao-milestones/
00-阶段里程碑规划.md
01-M1任务拆解-Dao交付闭环落地.md
02-M1详细设计-Dao交付闭环落地.md
03-开发记录-Dao交付闭环落地.md
04-里程碑开发笔记-Dao交付闭环落地.md
scripts/
templates/
dao-milestone/
task.md
design.md
record.md
note.md
create-dao-milestone.mjs脚手架设计
脚手架目标：
- 输入里程碑编号、主题和目标目录
- 自动生成四类标准文档
- 降低后续起步成本
脚手架输入：
- milestone：如
M2 - topic：如
内容治理扩面 - dir：如
docs/dao-milestones
脚手架输出：
- 任务拆解文档
- 详细设计文档
- 开发记录文档
- 里程碑开发笔记文档
模板字段设计
模板至少覆盖这些变量：
{{MILESTONE}}{{TOPIC}}{{DATE}}
保证后续新增里程碑时，只需要替换基础变量即可得到可编辑骨架。
npm 入口设计
新增脚本入口：
npm run dao:milestone -- <milestone> <topic> [dir]
作用：
- 统一执行脚手架
- 降低使用门槛
自测设计
本轮自测分三层：
第一层：脚手架执行验证
- 执行一次脚手架命令
- 检查目标文件是否成功生成
第二层：文档同步验证
- 执行
npm run docs:sync - 确认新增文档进入
docs-site
第三层：构建与校验验证
- 执行
npm run docs:check - 确认站点生成和校验通过
设计约束
本轮继续遵循当前仓库约束：
- 不修改用户已有未提交内容
- 不破坏现有 VitePress 生成链路
- 仅新增与本轮相关的文档和脚本
完成后的预期效果
完成后，当前仓库将具备：
- 一份阶段里程碑总规划
- 一套标准化里程碑文档结构
- 一份完整的 M1 交付示范
- 一个可复用的脚手架能力
这样下一轮真实业务里程碑就不需要从头搭框架，而可以直接进入主题设计和开发。