进展
功能矩阵
四种前端实现的功能对齐状态与两处有意保留的架构差异。
统计口径
功能矩阵共 29 项，分三组：
| 分组 | 项数 | 说明 |
|---|---|---|
| 核心业务 | 10 | 认证、演示模式、用户、角色、权限、菜单、字典、日志、我的账户、Dashboard 概览 |
| 组织中心 | 8 | 部门、岗位、通讯录、公告、我的公告、站内信、架构图谱、导出 |
| 基础设施 | 11 | i18n、主题、偏好设置、多标签页、DataTable 列设置、命令面板、错误页、异常页菜单、Playground、路由守卫、路由过渡 |
四个前端（React / Vue / Next.js / Nuxt）当前均为 29 / 29，功能已全部对齐。
分母按
docs/feature-matrix.md的表格行数计。这一口径曾三次失真（23 → 27 → 29）， 每次新增功能行都要同步改分母，不能只改表格。
两处有意保留的架构差异
不是功能缺失，是技术栈本身的约束或主动选择：
| 差异项 | 表现 | 为什么保留 |
|---|---|---|
| 页面保活（KeepAlive） | React 端有多标签页保活池，Next.js 端没有 | Next.js 的 App Router 没有对应的保活原语，硬做会破坏其路由模型 |
| 认证传输载体 | React / Vue 走 Authorization: Bearer，Next.js 走 httpOnly Cookie | 两者契约完全一致，只是 Token 存放位置不同；Next 端用 Cookie 换来对 XSS 的天然免疫 |
对齐的判定标准是功能，不是代码
技术栈不同就必然有实现差异。矩阵判定的是功能是否齐备、契约是否一致，不要求四端代码逐行对应。功能对齐优先于像素级对齐——例如四端图表各用本生态最合适的引擎，但对齐同一份数据与同一套 Design Token 取色。
NestJS 侧的对照
后端独立对照 API 契约：48 条路径全部实现（对应 77 个 path+method 操作），每条路径的权限位声明（x-permission）与契约一致。Next.js 与 Nuxt 端作为独立全栈各实现 76 个操作——唯一例外是 GET /health，契约明示它是 NestJS 在 Render 免费层保活专用，两端平台不休眠、不做对等实现。
已完成的关键里程碑
| 时间 | 内容 |
|---|---|
| 09-14 | 菜单可见性修正：只要有 role_menus 记录即视为可见，三端同步 |
| 09-15 | NestJS API 文档 UI 由 Swagger 换为 Scalar（保留 /docs-json） |
| 09-16 | Playground 演示场四端全对齐（Phase A 骨架 + Phase B 内容） |
| 09-18 | Phase 0 演示上线准备完成：只读守卫 DEMO_READONLY + 快捷登录，契约 v1.10.0 |
| 09-19 | Dashboard 概览四端对齐（Phase C）：KPI + 登录趋势 + 角色占比，契约升到 v1.12.0 |
| 09-21 | 演示场第 9 页「加载动画」、第 10 页「组织架构树」四端对齐；功能矩阵 29 项全部对齐 |
| 09-22 | 契约升 v1.14.0：新增 GET /health 存活探针（Render 保活前置） |
部署状态
五个应用目前都还没有正式上线。 规划的平台分工：
| 应用 | 目标平台 |
|---|---|
| React · Vue | Cloudflare Workers（Static Assets） |
| Next.js · Nuxt · website | Vercel |
| NestJS | Render |
统一上线前还有一份待执行清单，其中包含 NestJS 的保活 ping 与 CORS 白名单收敛 —— 详见路线图。