QiufengandClaude Opus 4.8
5e51dc3f56
恢复点(restore point)。别人改崩后可 git reset --hard 回到此提交。 == 此快照内容 == - 后端 oa-backend: 734 控制器 / 711 实体 (Spring Boot 3.2.5 + SQLite, 端口8091) - 前端 modern-ui/app: Vue3+Vite, 约700页 (构建产物已在 oa-backend/src/main/resources/static) - 数据库 oa-backend/data/oa.db: 含全部演示数据 (强制入库, 6.6MB) - 交接文档 go.md + go-code-reference/endpoints/entities/database.md - 多代理建设脚本 .claude/wf-*.js == 状态 == - 对 凯迪科技ERP_20260507.xlsx 合规 MET ~73.3% (PARTIAL 75: 34可建+6种子/bug+35外部硬天花板) - 安全: 5轮红队+5轮复检, default-deny分级鉴权, 连续零可利用 - W3~W7 累计补完436缺口; W8末轮(40缺口)为半成品(源码树可编译但未集成) - 运行: cd oa-backend; java -jar build/libs/oa-backend-0.1.0.jar --server.port=8091; admin/123456 == 排除(gitignore, 可再生) == node_modules / oa-backend/build / .jdks / *.log / Backup-ERP-* / 弃用的OFBiz核心(只保留modern-ui) 完整文件夹备份见同目录 Backup-ERP-20260615-191517/ (含上述全部, 仅缺 node_modules) 时间戳: 20260615-191517 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
65 lines
3.9 KiB
Markdown
65 lines
3.9 KiB
Markdown
# 内测版 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 + 一份可回滚版本
|