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>
3.9 KiB
3.9 KiB
内测版 v1 上线计划（决策用）
口径：内测版的及格线是「多个真实用户能安全使用，核心流程不崩、不串数据、不泄密」，不是还原度 97%。功能可以缺、可以标「已知限制」；但身份、权限、数据完整性这三条是红线。 当前真实分数：致远复刻度 ~73%、甲方符合度 ~54%（详见 OA-PARITY-AUDIT.md）。
一、能不能现在直接上线？—— 不建议，差一个「单用户 demo → 多用户系统」的转身
现在整套系统是按**单 demo 用户（张伟/admin）**做的。三件事会在内测第一天、真实多用户一进来就暴露：
- 没有真实身份：顶栏、发文作者、各页几乎都硬编码「张伟/工程部」。多人内测时所有人都是张伟 —— 没法用。
- 待办箱不按人分派（H2）：现在
/tasks?type=todo不按办理人过滤，每个人登录看到的是全系统在途事项，不是「派给我的」。这是 OA 的命脉功能，错了就等于没做。 - 敏感数据零访问控制（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 + 一份可回滚版本