# M14 / 里程碑收口 / 编辑体验与公开展示升级

- Issue：`M14 Follow-up / 编辑体验、公开展示与工程收口`
- 里程碑：`M14 编辑体验与亮点表达重构`
- 分支：`fys-dev/feat-m15-issue-161-163-ai-rag-tightening`
- 日期：`2026-04-09`

## 背景

M14 后半段连续承接了公开简历页、后台编辑器、主题切换、拖拽排序、目录重构、工程化入口等多轮跟进优化。虽然每个 issue 都有各自日志，但从里程碑视角看，还缺一份“阶段收口日志”来总结这一段演进的结果与问题。

本次补日志的另一个原因是：部分 M14 follow-up 实际落在了 `M15` 分支上，暴露出“里程碑归属”和“分支命名”没有及时收口的问题，需要明确记录下来，供后续流程修正。

## 本次目标

- 补一份 M14 里程碑级开发日志，汇总本阶段关键改动
- 明确 M14 后半段的实际产出、验证结果与工程收益
- 记录当前分支治理问题，为后续统一回收至 `development` 提供依据

## 非目标

- 不重复覆盖每个 issue 的细节实现过程
- 不额外扩展新的 UI 改版或服务端能力
- 不把本日志替代各 issue 独立开发日志

## TDD / 测试设计

- 里程碑层不新增测试代码，直接汇总本阶段已执行过的类型检查、单测、构建与人工联调
- 重点关注“功能是否闭环”和“工程入口是否统一”，而不是单一组件实现细节

## 实际改动

- 公开简历页完成了侧栏个性化恢复、技能区图表化、词云收口、时间线排版与项目经历层级优化
- 后台编辑器完成了中英文分区编辑、主题切换修复、删除按钮与拖拽排序体验补全
- 共享契约补上了公开链接 icon、兴趣 icon、项目核心功能等字段，并打通了 admin / web / server 三端链路
- 技能图表正式切到 `ECharts`，同时收口成“图表 / 结构”双主视图
- `admin / web` 组件目录按业务域重组，大体积组件拆为容器、展示块与 helper
- 后台重复请求问题已处理，新增 summary/projection 链路，概览与 AI 工作台不再全量拉取 draft
- `summary` 接口完成语言投影收口，后台轻量页面不再携带完整 `zh / en` 双语对象
- 根级工程入口补上 `oxlint + oxfmt`，形成统一 `lint / format / format:check` 工作流

## Review 记录

- 本阶段整体仍围绕 M14“编辑体验与亮点表达重构”的目标展开，没有偏离到全新业务域
- 后半段出现“功能已经属于 M14，但分支已进入 M15 命名”的情况，说明 issue、分支、日志之间的同步动作还不够及时
- 组件重构、summary 收口、OXC 统一入口这几项改动都具备继续沉淀到教程或共享工程规范的价值

## 自测结果

- `pnpm --filter @my-resume/server test` ✅
- `pnpm --filter @my-resume/server typecheck` ✅
- `pnpm --filter @my-resume/admin test` ✅
- `pnpm --filter @my-resume/admin typecheck` ✅
- `pnpm --filter @my-resume/web test` ✅
- `pnpm --filter @my-resume/web typecheck` ✅
- `pnpm lint` ✅
- `pnpm format:check` ✅
- `pnpm legacy:build` ✅

## 遇到的问题

- M14 follow-up 的实现持续时间较长，导致 issue 已经进入下一轮，但分支仍承接旧里程碑需求
- 后台与公开站在主题、目录、长组件拆分上有较多交叉修改，若不及时收口，很容易让主线分支长期落后
- `oxfmt` 接入时暴露出根级 `tailwind.config.cjs` 使用 ESM 写法的历史遗留问题，已在本轮一并修正

## 可沉淀为教程/博客的点

- 如何在 monorepo 中渐进式完成“共享契约 → admin 编辑 → web 展示 → server 投影”的闭环改造
- 如何处理后台大组件拆分、测试下沉与目录按域重组
- 为什么轻量 summary/projection 接口能显著改善后台请求链路
- 在保留 Prettier / ESLint 兼容层的前提下，如何逐步把工程入口统一到 `OXC`

## 后续待办

- 将当前累计分支内容 squash merge 回 `development`，恢复主线的最新状态
- 视情况将本地 `dev` 对齐到 `development`，避免继续形成双主线
- 从更新后的 `development` 重新切出新分支，承接后续 UI 与工程优化
