# M8：从内存态到可持续演进 —— 阶段总结大纲

## 文章定位

- 面向读者：已经看过前几个里程碑、开始关心“为什么要从能跑的 demo 继续往前重构”的开发者
- 文章目标：总结 M8 如何把简历项目从“内存态 + 分散请求”推进到“可持久化 + 可共享契约 + 可真实联调”

## 一、为什么要做 M8

- 前面阶段虽然已经有三端壳，但核心内容流仍偏 demo 化
- 草稿 / 发布流停留在内存态，服务重启后不可持续
- admin / web 内部重复维护类型与请求封装，存在契约漂移风险

## 二、M8 的目标边界

- 只做持久化与共享契约
- 不做完整后台
- 不做 AI 持久化
- 不做 UI 精修

## 三、issue-36：数据库骨架为什么只先做最小版

- 为什么选 `Drizzle + libsql`
- 为什么先立数据库边界与环境配置
- 为什么不急着拆复杂表

## 四、issue-37：为什么是“草稿一份 + 发布快照追加”

- 单份标准简历的业务边界
- `resume_drafts`
- `resume_publication_snapshots`
- 为什么当前阶段 JSON 存储是合理的

## 五、issue-38：如何把内存态服务平滑切到数据库

- 新增 repository 的理由
- 为什么要保持 controller / API 语义尽量稳定
- 持久化测试如何验证“服务重启后数据还在”

## 六、issue-39：为什么只抽最小共享契约

- `packages/api-client` 的定位
- 为什么先抽简历主链路
- 为什么保留 app 内薄封装层，而不是一步删光

## 七、issue-40：真实联调为什么还能暴露新问题

- `db:push` 成功但运行时报表不存在的现象
- 根因：repo root 解析错误，推表库和运行库不一致
- 为什么真实本地冒烟是必要步骤

## 八、M8 最终收获了什么

- 简历草稿 / 发布流可持久化
- admin / web 使用共享契约
- 本地真实链路可演示
- 为后续继续扩展内容模块和更完整后台打稳基础

## 九、这一阶段刻意没做什么

- 没做完整 CMS
- 没做复杂版本管理
- 没做完整 SDK
- 没做部署层优化

## 十、下一阶段怎么接

- 继续完善内容模块与后台体验
- 逐步推进更系统的联调与展示层优化
- 为后续模板化、主题化、更多导出能力预留演进空间
