详细设计：执行顺序与交付流

这份文档定义本项目后续继续扩展时，应该按照什么顺序推进任务、设计、开发、自测与沉淀。

标准执行流

推荐每一轮都严格按下面顺序推进：

第一步：确定本轮对象

先确认这次整理的是哪一类对象：

• 页面型案例
• 基础组件型案例
• 方法层升级
• 导航层升级

第二步：圈定复杂度中心

在正式写文档之前，先明确本轮要解决的主问题。

例如：

• 状态中心混乱
• 通信路径隐式
• 扩展协议失控
• 页面容器过重
• 联动链路过长

第三步：形成详细设计

在 docs/ 下补充或更新设计文档，明确：

• 本轮目标
• 文件落位
• 拆分边界
• 交付标准

第四步：进入开发 / 整理阶段

这里的“开发”在本项目里主要指：

• 写案例文档
• 写方法文档
• 更新导航结构
• 调整目录入口

第五步：自测

每次完成后至少做下面几项自测：

• Markdown 链接是否有效
• 新文档是否挂到入口页
• 章节结构是否清晰
• 是否与既有框架一致

第六步：提交与推送

确认自测通过后，再执行：

• git add
• git commit
• git push

第七步：补开发记录

每轮开发结束后，都要把本轮过程、决策和经验写入技术博客型文档，放到 docs/ 目录下。

当前项目建议执行顺序

基于目前已有内容，后续建议按下面顺序继续推进：

• 先完善现有导航与总框架
• 再继续新增单案例文档
• 新增到一定规模后，再做二级导航和专题汇总
• 最后再考虑抽出更偏“最佳实践手册”的内容

每轮交付检查点

每一轮完成时，至少检查下面这些点：

• 有没有新增或更新文档
• 有没有同步更新入口索引
• 有没有进行最小自测
• 有没有写开发记录
• 有没有完成版本提交

为什么要先设计再开发

这个项目现在已经不是一两篇临时笔记，而是一套会持续增长的方法库。

如果不先做规划和详细设计，后续就很容易再次回到“想到哪写到哪”的状态。执行顺序清晰以后，新增案例和维护结构的成本都会低很多。

固化执行清单

为了避免后续里程碑扩展时顺序漂移，后续默认同时遵循这份清单文档：

• 执行清单：里程碑任务开发与交付规范

后续每一轮都应按“任务拆解 -> 详细设计 -> 案例开发 -> 开发记录 -> 自测 -> Git 提交与推送”的顺序执行。