# 内测版 v1 上线计划（决策用）

> 口径：内测版的及格线是「多个真实用户能安全使用，核心流程不崩、不串数据、不泄密」，**不是**还原度 97%。功能可以缺、可以标「已知限制」；但身份、权限、数据完整性这三条是红线。
> 当前真实分数：致远复刻度 ~73%、甲方符合度 ~54%（详见 OA-PARITY-AUDIT.md）。

---

## 一、能不能现在直接上线？—— 不建议，差一个「单用户 demo → 多用户系统」的转身

现在整套系统是按**单 demo 用户（张伟/admin）**做的。三件事会在内测第一天、真实多用户一进来就暴露：

1. **没有真实身份**：顶栏、发文作者、各页几乎都硬编码「张伟/工程部」。多人内测时所有人都是张伟 —— 没法用。
2. **待办箱不按人分派（H2）**：现在 `/tasks?type=todo` 不按办理人过滤，每个人登录看到的是**全系统在途事项**，不是「派给我的」。这是 OA 的命脉功能，错了就等于没做。
3. **敏感数据零访问控制（H10）**：机密档案等无 token 即可全量读取。真实数据 + 真实用户，这是合规红线。

这三条不是「功能缺失」，是「核心机制是错的」。必须在上线前解决，否则内测会立刻翻车。

---

## 二、分层计划

### Tier 0 — 上线前必须做（「可多人、安全内测」里程碑）
| 项 | 为什么是阻断级 | 估量 |
|---|---|---|
| **真实登录 + 身份贯通** | 多用户的地基。后端 auth 已有，需：登录门 + 全局 session store + 清掉硬编码「张伟」+ 各页取当前用户 | 中 |
| **待办按办理人分派（H2）** | 每人只看派给自己的待办；advance 时写真实 assignee | 中-大 |
| **敏感数据访问控制（H10）** | 强制 token + 角色校验，机密档案/主数据按权限可见 | 中 |

做完这三项 = 一个**能让一群真人各自登录、各看各的待办、看不到不该看的数据**的系统。这才是内测的最小可用形态。

### Tier 0+（条件性必做）：若内测含真实「钱」流程
| 项 | 触发条件 | 估量 |
|---|---|---|
| **资金支付审批闸（H13）** | 内测要走报销/付款 | 中-大 |
| **验收凭证幂等 + 发票进/销项区分（H12）** | 内测要走合同→付款链 | 中 |

> 若内测**不碰真实资金**（只是让大家点功能、提反馈），这层可以带「已知限制」上线，标注「资金流程为演示态，勿录真实金额」。

### Tier 1 — 带「已知限制」上线，内测期间快速跟进
富文本编辑器 · 统一消息中心（含办理推进的站内提醒）· 条件分支真求值 H1（按公司主体分流）· 转交加签真改派 H3 · 知会并行抄送 H4 · 文件多格式预览。
→ 这些缺了不会崩，内测用户能理解「v1 还没做」。建议写一份「v1 已知限制清单」随版本发出。

### Tier 2 — 内测之后再做（重活/天花板）
实时协同编辑 · 全文检索引擎 · 可拖拽自定义门户 · B 类部门模块深度 CRUD。

---

## 三、我的建议

**把「上线前这一轮」的 Goal 定为 Tier 0**（真实身份 + 待办分派 + 访问控制）。理由：
- 这三项把系统从「单人 demo」变成「可多人安全使用」，是内测的真实门槛；
- 工作量可控（都是有地基的改造，不是从零造引擎）；
- 其余所有缺口都能以「v1 已知限制」体面地带上线，内测本来就是收反馈的。

**若内测要碰真实报销/付款**，则 Goal = Tier 0 + Tier 0+（多加资金完整性两项）。

Tier 1/2 不进上线 Goal，作为内测期间和 v2 的滚动路线图。

---

## 四、上线前还要做的工程收尾（不分 Tier，属必备）
- 关掉/隐藏开发态入口与假数据；「v1 已知限制清单」文档
- 一轮全模块冒烟点击（每个一级菜单可进、不白屏、不 500）
- 备份当前 SQLite + 一份可回滚版本