A1-A7 治理文档事实源与中文索引
这个提交包含在：
+2
-1
@@ -5,7 +5,8 @@
|
||||
**目的**：描述系统当前实现、当前部署基线和仍待外部环境闭环的部分，为试运行与后续演进提供参考。
|
||||
|
||||
**相关文档**：
|
||||
- [需求规格说明书](./requirements-specification.md)
|
||||
- [文档索引](./文档索引.md)
|
||||
- [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||||
- [实现状态矩阵](./feature-matrix.md)
|
||||
- [试运行覆盖矩阵](trialrun/coverage-matrix.csv)
|
||||
- [人工试运行报告](trialrun/manual-trialrun-report.md)
|
||||
|
||||
+4
-1
@@ -1,8 +1,11 @@
|
||||
# hyb-oa 实现状态矩阵（历史主表 + R70-R90 试运行补充）
|
||||
|
||||
**文档状态**：实现状态与历史证据矩阵，不是 PRD，也不是当前开发排期。
|
||||
**快照日期**：2026-05-05
|
||||
**范围**：`F1-F42`（含 `F19b/F19c/F19d`） + `R1-S2` + `P9A1-P9D1` + `P10E1-P10G1` + `G0-G6` + `H1` + `M1-M4` + `P13-0-P13-8` + `P14-0-P14-8` + `P15A-0-P15A-5` + `P15B-0-P15B-6` + `P16A-0-P16A-6` + `P16B-0-P16B-6` + `P16C-0-P16C-6` + `R9-0-R9-3` + `G2-0-G2-6` + `P17A-0-P17A-6` + `P17B-0-P17B-6` + `P18A-0-P18A-6` + `P18B-0-P18B-6` + `P19-0-P19-6` + `P19IM1-0-P19IM1-6` + `P19ERP1-0-P19ERP1-6` + `P19ERP2-0-P19ERP2-6` + `P19ERP3-0-P19ERP3-6` + `R10-0-R10-4` + `P19MCP1-0-P19MCP1-4` + `P19AI1-0-P19AI1-5` + `P20TRAVEL1-0-P20TRAVEL1-5` + `P20TRAVEL2-0-P20TRAVEL2-5` + `P20TRAVEL3-0-P20TRAVEL3-5` + `P21PWA1-0-P21PWA1-5` + `P21PWA2-0-P21PWA2-5` + `P22PROD1-0-P22PROD1-5` + `R11-0-R11-5`，共 278 项。
|
||||
**事实源**：`issues/2026-02-09_13-39-02-p5-blueprint-v3.csv` + `issues/2026-02-09_23-30-00-p6-p8-remaining-work-master.csv` + `issues/2026-02-10_09-42-31-p9-maintenance-performance-matrix.csv` + `issues/2026-02-10_10-35-30-p10-production-hardening.csv` + `issues/2026-02-11-p11-p12-governance-mobile.csv` + `issues/2026-02-12_01-09-41-p13-l5-governance.csv` + `issues/2026-02-13_00-11-56-p14-l5-operationalization.csv` + `issues/2026-03-06_14-30-00-p15a-l5-permission-decouple.csv` + `issues/2026-03-06_14-30-00-p15b-l5-leave-v1.csv` + `issues/2026-03-07_13-47-05-p16a-l5-master-data-core.csv` + `issues/2026-03-07_16-22-07-p16b-l5-holiday-calendar.csv` + `issues/2026-03-07_17-14-39-p16c-l5-suppliers.csv` + `issues/2026-03-07_18-15-03-r9-g2-p19-roadmap-refresh.csv` + `issues/2026-03-07_18-16-00-g2-l5-cross-domain-bridge.csv` + `issues/2026-03-07_19-33-09-p17a-l5-procurement-core.csv` + `issues/2026-03-07_21-00-37-p17b-l5-procurement-budget-archive.csv` + `issues/2026-03-07_22-02-09-p18a-l5-asset-registry-core.csv` + `issues/2026-03-07_22-34-03-p18b-l5-asset-movements-inventory.csv` + `issues/2026-03-07_23-22-00-p19-l4-integration-readiness.csv` + `issues/2026-03-08_12-18-10-p19-im-1-l5-collaboration-adapter.csv` + `issues/2026-03-08_14-10-53-p19-erp-1-l5-masterdata-journal-bridge.csv` + `issues/2026-03-08_22-46-51-p19-erp-2-l5-procurement-commitment-archive.csv` + `issues/2026-03-09_00-10-00-p19-erp-3-l5-asset-ledger-summary.csv` + `issues/2026-03-09_10-15-00-r10-post-erp3-roadmap-refresh.csv` + `issues/2026-03-09_10-25-00-p19-mcp-1-l4-readonly-tools-baseline.csv` + `issues/2026-03-10_12-54-30-p19-ai-1-l5-suggestion-workbench-refresh.csv` + `issues/2026-03-10_17-32-21-p20-travel-1-l5-request-intake-refresh.csv` + `issues/2026-03-10_21-05-59-p20-travel-2-l5-corporate-payments-refresh.csv` + `issues/2026-03-11_09-57-28-p20-travel-3-l5-reconciliation-erp-bridge-refresh.csv` + `issues/2026-03-11_17-50-39-p21-pwa-1-l5-asset-scan-refresh.csv` + `issues/2026-03-12_04-32-13-p21-pwa-2-l5-offline-deeplink-refresh.csv` + `issues/2026-03-12_16-58-44-p22-prod-1-l5-production-hardening.csv` + `issues/2026-03-13_10-30-00-r11-contract-reconciliation-and-spec-refresh.csv` + `issues/2026-04-26_r70-manual-trialrun.csv` + `issues/2026-04-29_08-39-22-r76-external-trialrun-closeout.csv` + `issues/2026-04-29_09-19-07-r77-ocr-pdf-first.csv` + `issues/2026-04-29_10-14-27-r78-reimbursement-payment-tail.csv` + `issues/2026-05-04_13-11-16-r79-governance-live-readiness.csv` + `docs/trialrun/coverage-matrix.csv`（执行合同与覆盖证据）
|
||||
**当前用途**：判断功能是否做过、证据在哪、历史路线如何演进。
|
||||
**不得误读**：新增需求和优先级以 [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)、[产品口径文档](./product-decisions.md) 和最新 `issues/*.csv` 为准。
|
||||
|
||||
## R70-R90 试运行与外部环境补充（2026-04-28 至 2026-05-05）
|
||||
|
||||
@@ -28,7 +31,7 @@
|
||||
- UI 专项合同（如 `ui-refresh-stage7/8`）属于界面治理线，独立维护，不并入本业务主表统计。
|
||||
- `R11` 属于治理收口阶段：只承接历史 TODO 清账与规格书补齐，不代表新增运行时业务能力。
|
||||
- `首次规划 CSV` 为该 ID 首次出现的执行合同；`首次完成 CSV` 为三状态首次全 `DONE` 的执行合同。
|
||||
- `规格书章节` 优先引用 `docs/requirements-specification.md`；规格未显式覆盖时标注 `N/A`。
|
||||
- `规格书章节` 仍保留历史引用语义；当前 PRD 主事实源已迁移到 `docs/海音达OA-MVP需求规格说明书.md`，`docs/requirements-specification.md` 仅为旧路径跳转。
|
||||
|
||||
| ID | 功能项 | 规格书章节 | 首次规划 CSV | 首次完成 CSV | 完成日期 | 当前状态 | 回归覆盖 | Notes |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
@@ -1,7 +1,10 @@
|
||||
# hyb-oa 实施计划（历史 Phase 1 引导 + 当前执行口径）
|
||||
|
||||
**文档状态**：历史实施计划归档，不是当前执行计划。
|
||||
**日期**：2026-05-04
|
||||
**范围**：保留 2026-02 的引导性实施计划，同时补充当前试运行收口与外部环境闭环口径。
|
||||
**当前用途**：追溯早期里程碑、复用资产和历史技术决策；当前需求与开发优先级以 [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)、[文档索引](./文档索引.md) 和最新 `issues/*.csv` 为准。
|
||||
**不得误读**：下文的 `Phase 1 / P0 / Phase 2` 是历史阶段名，不代表 2026-05-09 之后的当前排期。
|
||||
|
||||
## 当前阶段（2026-05-04）
|
||||
|
||||
@@ -11,6 +14,7 @@
|
||||
2. 外部环境闭环（HTTPS / 企微 / live smoke / 并发）
|
||||
3. 发布门禁与部署 runbook 收口
|
||||
- 当前执行事实源优先级：
|
||||
- 当前 PRD：`docs/海音达OA-MVP需求规格说明书.md`
|
||||
- 最新执行合同：`issues/*.csv`
|
||||
- 业务覆盖：`docs/trialrun/coverage-matrix.csv`
|
||||
- 试运行结论：`docs/trialrun/manual-trialrun-report.md`
|
||||
@@ -22,7 +26,7 @@
|
||||
|
||||
## 0. 前置结论（不可再分叉）
|
||||
- 技术栈：Fastify + Prisma + PostgreSQL（见 `docs/tech_stack_report.md`）
|
||||
- 规格书：以 `docs/requirements-specification.md` 为单一事实源
|
||||
- 当前 PRD：以 `docs/海音达OA-MVP需求规格说明书.md` 为主事实源；`docs/requirements-specification.md` 仅保留为旧路径跳转。
|
||||
|
||||
## 1. 历史：复用资产清单（从 shenzhou-business-suite 迁移到 hyb-oa）
|
||||
| 资产 | 来源 | 复用方式 | 需要改造 |
|
||||
@@ -56,7 +60,7 @@
|
||||
- 代提交授权：`delegation_grants`
|
||||
|
||||
**验收**：
|
||||
- schema 与 `docs/requirements-specification.md` 一致
|
||||
- schema 与当时的 `docs/requirements-specification.md` 一致；当前需求事实源已迁移到 `docs/海音达OA-MVP需求规格说明书.md`
|
||||
- 关键约束可实现（单号唯一、转审原因≥10、费用类型 code 唯一、软禁用等）
|
||||
|
||||
**评审截止（Schema Freeze）**：
|
||||
@@ -161,11 +165,11 @@
|
||||
|
||||
> 状态口径说明（2026-02-09）：
|
||||
> - 已落地：OCR 增强、报表导出、对象存储（MinIO/OSS）、工作流扩展到其他实体（最小骨架）。
|
||||
> - 待推进：企微/钉钉通知（渠道扩展）。
|
||||
> - 历史待推进：企微/钉钉通知（渠道扩展）。当前路线已调整为“企业微信基础设施 + OA 唯一审批中心”，飞书/钉钉不进入首批 MVP。
|
||||
> - 详细状态与证据以 `docs/feature-matrix.md` 与 `issues/2026-02-09_13-39-02-p5-blueprint-v3.csv` 为准。
|
||||
|
||||
- [x] OCR 能力增强（队列化与重试策略）
|
||||
- [ ] 企微/钉钉通知
|
||||
- [ ] 历史项：企微/钉钉通知（当前不作为待开发入口；企微基础设施以新 PRD 与最新 Issue CSV 为准）
|
||||
- [x] 报表导出
|
||||
- [x] 对象存储（MinIO/OSS）
|
||||
- [x] 工作流扩展到其他实体（请假/采购）
|
||||
|
||||
@@ -1,8 +1,10 @@
|
||||
# 集成边界冻结（P19 / P19+IM-1 / P19+ERP-3 / R10 / P19+MCP-1 / P19+AI-1 / P20+TRAVEL-1 / P20+TRAVEL-2 / P20+TRAVEL-3 / P21+PWA-1 / P21+PWA-2）
|
||||
|
||||
**文档状态**：历史集成边界与已实现集成证据，不是当前首批接入清单。
|
||||
**快照日期**：2026-03-12
|
||||
**当前基线**：`P19+IM-1`、`P19+ERP-1`、`P19+ERP-2`、`P19+ERP-3`、`P19+MCP-1`、`P19+AI-1`、`P20+TRAVEL-1`、`P20+TRAVEL-2`、`P20+TRAVEL-3`、`P21+PWA-1` 与 `P21+PWA-2` 已完成；当前运行时已落地企微群机器人 + 深链 + Outbox 异步派发的一期协同适配，以及 ERP 主数据 Pull、报销付款凭证切片、采购双阶段 journal / 归档摘要出站、资产台账摘要出站、Postgres MCP 只读工具基线、报销 / 采购 / 资产详情页 AI 只读建议挂件、差旅申请主单 / 行程段 / 审批预算锁定 / `travel_orders` 关联入站、混合双轨对公支付闭环与批次级对账摘要桥的三期差旅基线，以及浏览器 PWA 下的移动资产扫码、盘点快捷录入与离线队列重放、移动审批 deep link 直达、本地会话快照离线守卫与审批草稿重放。
|
||||
**目标**：在保持核心域稳定的前提下，冻结 ERP / IM / AI / MCP / TRAVEL / PWA 的长期边界，并记录 IM 一期、ERP 三期、AI 一期、差旅三期与 PWA 两期的已实现范围、禁入规则以及 R10 主线闭环后的固定收口结论。
|
||||
**当前路线说明**：2026-05-09 之后首批 MVP 固定为 `hyb-oa` 唯一审批中心 + 企业微信基础设施。飞书路线已废弃；钉钉、小程序、外部 IM 回调审批和付费第三方套件不进入首批。
|
||||
|
||||
## 1. 总体原则
|
||||
|
||||
@@ -113,7 +115,7 @@
|
||||
- 即使 IM 全部关闭，站内通知与邮件仍继续工作
|
||||
|
||||
### 3.5 后续专项建议
|
||||
- `P23+IM-2`：真实 IM 适配器 refresh；已完成企微 webhook 生产化，飞书 / 钉钉 provider 继续 backlog
|
||||
- `P23+IM-2`：真实 IM 适配器 refresh；已完成企微 webhook 生产化。飞书 / 钉钉 provider 仅保留为历史 backlog，不进入当前 MVP 首批路线。
|
||||
- `P19+IM-3`：个人直达与 IM 身份映射
|
||||
- `P19+IM-4`：消息卡片交互与回调审批（仍必须回到 OA 鉴权）
|
||||
|
||||
@@ -255,7 +257,7 @@
|
||||
## 8. 当前阶段明确不做
|
||||
- 不新增新的集成总线表结构
|
||||
- 不接入 ERP 真实写回逻辑
|
||||
- 不接入飞书 / 钉钉真实生产推送
|
||||
- 不接入飞书 / 钉钉真实生产推送；当前首批只保留企业微信基础设施能力
|
||||
- 不新增 AI 写库动作
|
||||
- 不引入绕过工作流与权限体系的外部回调路径
|
||||
|
||||
@@ -284,6 +286,6 @@
|
||||
- PWA 路线已按浏览器 / PWA 栈闭环，不引入原生 App、小程序或双栈移动壳。
|
||||
|
||||
### 9.5 后置 backlog
|
||||
- `P23+IM-2` 已完成企微真实 webhook 出站；飞书 / 钉钉 provider 子项与 `IM-3 / IM-4`、`P22+VEH-1`、`P22+ASSET-FIN-1` 继续作为后置 backlog。
|
||||
- `P23+IM-2` 已完成企微真实 webhook 出站；飞书 / 钉钉 provider 子项与 `IM-3 / IM-4`、`P22+VEH-1`、`P22+ASSET-FIN-1` 仅作为历史后置 backlog，当前 MVP 首批不启动。
|
||||
- 这些方向只保留“触发条件 / 进入时机”的规划地位，不提前写入已完成矩阵或事实源校验器。
|
||||
- 若后续优先级发生变化，必须通过新的路线合同显式改序，不直接口头跳 phase。
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# invoicePool 路由拆分方案（P9A1）
|
||||
|
||||
**文档状态**：一次性重构方案归档，不是当前待办。
|
||||
**当前用途**：追溯 `invoicePool` 路由拆分的边界、兼容策略和回滚思路。
|
||||
**不得误读**：本文不代表当前新需求；报销、发票、OCR、附件规则以 [报销、发票与附件规则](./reimbursement-invoice-rules.md) 和当前 PRD 为准。
|
||||
|
||||
## 1. 背景
|
||||
- 现状：`server/src/routes/invoicePool.js` 超过 2700 行，上传、列表、详情、验真、归档、解绑、OCR 重试等职责集中在单文件。
|
||||
- 风险：
|
||||
@@ -54,4 +58,3 @@
|
||||
- 回滚策略：
|
||||
- 保留 `invoicePool.js` 入口文件与原有注册顺序。
|
||||
- 如发现回归，可将 `verification.js` 调用回切为原文件内联实现（无 schema 变更，无数据回滚）。
|
||||
|
||||
|
||||
@@ -1,349 +1,9 @@
|
||||
# 海音达 OA 系统 - MVP 需求规格说明书
|
||||
# 需求规格说明书旧路径说明
|
||||
|
||||
**版本**：2.0
|
||||
**日期**：2026-05-09
|
||||
**范围**：10 人以下科技公司试运行 MVP 需求基线
|
||||
**状态**：当前 PRD 主事实源
|
||||
**文档状态**：兼容跳转入口，不再作为主编辑入口。
|
||||
|
||||
**相关文档**：
|
||||
- [产品口径文档](./product-decisions.md)：关键产品决策与边界。
|
||||
- [功能状态矩阵](./feature-matrix.md)：历史实现状态、覆盖证据和完成追踪，不作为 PRD 扩写入口。
|
||||
- [管理员手册](./admin-handbook.md)：试运行配置、企业微信入口和上线操作。
|
||||
- [员工快速开始](./employee-quickstart.md)：员工侧使用说明。
|
||||
- [报销与发票规则](./reimbursement-invoice-rules.md)：报销、发票、OCR、附件的细则。
|
||||
- `issues/*.csv`：每轮开发执行合同；需求确认后必须拆 Issue CSV 再开发。
|
||||
当前 PRD 主事实源已改为中文文件名，方便人工审查：
|
||||
|
||||
---
|
||||
- [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||||
|
||||
## 1. 项目目标与当前路线
|
||||
|
||||
### 1.1 背景
|
||||
|
||||
海音达需要一套适合 10 人以下科技公司的轻量 OA，用来把报销、请假、采购、费用、合同、项目资料、审批和基础行政动作集中到一个可审计、可回归、可持续迭代的系统中。系统不追求一次性替代所有办公平台，而是先解决公司内部最容易割裂、最需要留痕的业务流程。
|
||||
|
||||
### 1.2 总目标
|
||||
|
||||
- `hyb-oa` 是唯一业务主系统和唯一正式审批中心。
|
||||
- 所有正式审批在 OA 内提交、审批、留痕、归档。
|
||||
- 企业微信只作为基础设施：手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡原始采集。
|
||||
- PC 用户可直接访问 OA；手机端优先从企业微信工作台进入 OA 移动端。
|
||||
- 后续开发必须先有需求事实源和 Issue CSV 执行合同，避免边想边做。
|
||||
|
||||
### 1.3 当前平台边界
|
||||
|
||||
| 平台 | 定位 | 首批使用方式 | 不承担 |
|
||||
| --- | --- | --- | --- |
|
||||
| `hyb-oa` | 唯一业务主系统和审批中心 | 审批、报销、发票、OCR、请假、采购、合同台账、项目资料、审计归档 | 聊天、会议、在线文档协作 |
|
||||
| 企业微信 | 基础设施 | 手机入口、免登/绑定、通知 deeplink、通讯录身份、打卡原始采集 | 正式审批流、财务附件主库、业务单据主库 |
|
||||
| 飞书 | 已废弃路线 | 不进入首批实现 | 不接入身份、审批、通知、文档或项目主线 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 软件开发项目流程
|
||||
|
||||
后续所有非微小改动按以下流程推进：
|
||||
|
||||
1. 需求收集与边界确认：明确目标用户、业务流程、必须做、暂不做、验收标准。
|
||||
2. 需求文档冻结：更新本文件或对应规则文档，形成产品、开发、测试共同事实源。
|
||||
3. 执行合同拆分：新建 `issues/YYYY-MM-DD_HH-mm-ss-<slug>.csv`，写清范围、验收、测试、依赖。
|
||||
4. 技术方案设计：明确接口、数据模型、权限、状态机、前端入口、回滚策略。
|
||||
5. 开发实现：按 Issue 分后端、前端、QA 阶段推进，不顺手做无关改动。
|
||||
6. 测试与回归：先单点验证，再业务流程回归，最后做 PC/移动/企业微信入口验证。
|
||||
7. 部署与验收：部署后检查 `/ready`、前端资源、关键路径、企业微信真机入口。
|
||||
8. 复盘与下一轮规划：把试运行反馈转成新 Issue CSV，不直接插入开发。
|
||||
|
||||
---
|
||||
|
||||
## 3. 用户角色与典型场景
|
||||
|
||||
| 角色 | 主要目标 | 高频动作 | 关键要求 |
|
||||
| --- | --- | --- | --- |
|
||||
| 老板/总经理 | 看清公司待办、费用、项目风险和审批瓶颈 | 审批大额事项、看项目和费用摘要、处理关键待办 | 少打扰、信息集中、审批记录可信 |
|
||||
| 管理员/HR | 维护人员、入口、制度、请假和基础行政 | 员工管理、请假/补卡审核、公告、入离职、权限配置 | 配置清晰、可回退、有审计 |
|
||||
| 部门主管/项目负责人 | 管团队交付和日常审批 | 审批报销/请假/采购、查看团队状态、跟进项目事项 | 待办清楚、移动端可处理 |
|
||||
| 普通员工 | 快速提交申请和查状态 | 报销、上传发票、请假、补卡、外出、加班、采购申请、周报 | 手机好用、字段少、失败提示明确 |
|
||||
| 财务 | 管报销、发票、付款和导出 | 发票查重、OCR 修正、付款标记、财务导出 | 数据完整、附件可追溯、重复票据可控 |
|
||||
| 系统管理员 | 保障系统可用和可维护 | 部署、备份、恢复、日志、功能开关、企业微信配置 | 不泄露密钥、可定位问题、可回滚 |
|
||||
|
||||
---
|
||||
|
||||
## 4. MVP 模块优先级
|
||||
|
||||
| 优先级 | 模块 | 目标 | 主入口 | 验收口径 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| P0 | 统一审批中心 | 所有正式审批在 OA 内处理 | PC 审批待办、移动审批 | 能提交、审批、驳回、退回、转审、留痕 |
|
||||
| P0 | 企业微信基础设施 | 手机入口、免登、通知、打卡原始采集 | 企业微信自建应用 `海音达工作台` | 手机进入 `/mobile`，通知 deeplink 回 OA |
|
||||
| P0 | 报销/发票/OCR | 员工自助报销，财务可查重和导出 | 报销、移动报销、票据中心 | 上传、OCR、查重、绑定、审批、付款闭环 |
|
||||
| P0 | 请假与考勤修正审批 | 请假、补卡、外出、加班等修正都在 OA 内审批 | 请假、移动审批、团队状态 | 审批后团队状态和考勤口径不破坏 |
|
||||
| P1 | 采购/费用审批 | 小团队采购和费用事项留痕 | 采购、审批待办 | 申请、附件、审批、状态更新可用 |
|
||||
| P1 | 合同与附件归档 | 管合同编号、责任人、归档位置和非涉密附件 | 合同/项目资料或项目页 | 能登记、查询、关联项目和审批记录 |
|
||||
| P1 | 项目轻管理 | 把费用、采购、差旅、周报挂到项目 | 项目、Portal、周报 | 能看项目事项、风险、费用摘要，不做重型排产 |
|
||||
| P2 | 预算/支付/ERP/AI | 在试运行稳定后增强运营能力 | 管理员备用入口 | 另立 Issue CSV，不进入首批验收 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 统一审批中心需求
|
||||
|
||||
### 5.1 范围
|
||||
|
||||
OA 是公司唯一正式审批中心。以下审批必须在 OA 内提交、审批、留痕、归档：
|
||||
|
||||
- 报销、费用、采购。
|
||||
- 合同相关审批和合同台账维护。
|
||||
- 请假、补卡、外出、加班、出差。
|
||||
- 资产领用、归还、调拨、盘点中的需要留痕动作。
|
||||
- 后续新增业务审批，默认也进入 OA 审批中心。
|
||||
|
||||
企业微信原生审批不作为公司正式审批入口，不允许形成“一部分审批在企业微信、一部分审批在 OA”的双轨口径。
|
||||
|
||||
### 5.2 审批能力
|
||||
|
||||
- 支持草稿、提交、审批中、通过、驳回、退回、撤回、转审、完成等状态语义。
|
||||
- 审批链优先采用串行多节点；当前阶段不做并行会签。
|
||||
- 大额或高风险单据通过审批规则配置多级审批，不通过硬编码角色分叉。
|
||||
- 当前审批人只能处理分配给自己的待办，或者处理分配给自己角色且权限匹配的待办。
|
||||
- 转审必须记录原因，转给具备对应审批权限的人，并保留转审历史。
|
||||
- 单据编号由 OA 生成和保存；报销单、采购单、合同编号等应使用统一编号规则或对应业务编号规则。
|
||||
|
||||
### 5.3 数据与留痕
|
||||
|
||||
- 所有审批动作写入工作流历史。
|
||||
- 关键例外动作写入审计日志，包括重复发票例外、付款标记、权限变更、附件下载、通知重试。
|
||||
- 企业微信消息只包含脱敏标题、业务编号、状态和 deeplink，不包含涉密正文、完整发票、合同正文或敏感报价。
|
||||
|
||||
### 5.4 验收
|
||||
|
||||
- 审批人可在 PC 和移动端看到待办。
|
||||
- 审批动作完成后，业务单据状态、审批历史、通知和审计记录一致。
|
||||
- 企业微信提醒点击后回到 OA 页面处理，不能在企业微信原生审批里完成正式审批。
|
||||
|
||||
---
|
||||
|
||||
## 6. 报销、发票、OCR、附件与财务导出
|
||||
|
||||
### 6.1 用户流程
|
||||
|
||||
1. 员工在 PC 或手机端创建报销草稿。
|
||||
2. 上传发票图片、PDF 或必要附件。
|
||||
3. 系统执行 OCR，识别发票代码、号码、金额、日期、销方、购方等关键字段。
|
||||
4. 员工确认或修正识别结果，补充费用明细和说明。
|
||||
5. 系统做发票查重和基础校验。
|
||||
6. 员工提交报销，进入 OA 审批流。
|
||||
7. 审批通过后，财务复核并标记付款。
|
||||
8. 财务按期间、状态、项目、人员导出报销和发票数据。
|
||||
|
||||
### 6.2 发票与附件管理
|
||||
|
||||
- 发票和附件原始文件以 OA/对象存储为主，不依赖企业微信长期保存。
|
||||
- 同一发票不得被重复报销；如确需例外，必须由授权财务角色填写原单号和原因。
|
||||
- OCR 失败时允许重试和人工修正，但必须保留失败原因和修正痕迹。
|
||||
- 报销完成后，相关发票进入已使用或归档状态，不能被普通员工再次绑定到新单据。
|
||||
- 普通员工只看到“添加发票、上传附件、提交审批、查看状态”等业务语言，不暴露内部发票池概念。
|
||||
|
||||
### 6.3 财务导出
|
||||
|
||||
- 财务可按报销状态、付款状态、员工、部门、项目、期间筛选导出。
|
||||
- 导出数据应包含业务编号、申请人、实际报销人、金额、费用类型、发票摘要、审批状态和付款状态。
|
||||
- 导出不得包含未授权敏感字段明文。
|
||||
|
||||
### 6.4 验收
|
||||
|
||||
- 手机拍照或上传发票后，能完成 OCR、查重、绑定、提交。
|
||||
- 报销审批通过后，财务能付款标记并导出。
|
||||
- 重复发票、OCR 失败、附件缺失、金额不一致等异常有明确提示。
|
||||
|
||||
---
|
||||
|
||||
## 7. 请假、补卡、外出、加班与考勤口径
|
||||
|
||||
### 7.1 边界
|
||||
|
||||
- 企业微信打卡用于原始采集，保留其定位、人脸、Wi-Fi、排班和设备能力。
|
||||
- OA 不在首批重造打卡规则、定位、人脸识别或排班引擎。
|
||||
- 请假、补卡、外出、加班等考勤修正申请在 OA 内提交和审批。
|
||||
- 后续可同步企业微信打卡原始记录，再结合 OA 审批形成正式考勤口径。
|
||||
|
||||
### 7.2 用户流程
|
||||
|
||||
- 员工在 OA 提交请假、补卡、外出或加班申请。
|
||||
- 主管或 HR 在 OA 审批。
|
||||
- 审批通过后，团队状态、日历和后续考勤统计使用 OA 的审批结果。
|
||||
- 企业微信打卡异常不直接等于最终考勤异常，最终口径以 OA 汇总为准。
|
||||
|
||||
### 7.3 验收
|
||||
|
||||
- 请假提交、审批、撤回、驳回后状态正确。
|
||||
- 已批准请假能影响团队状态或日历展示。
|
||||
- 文档和界面不引导员工去企业微信原生审批提交请假或补卡。
|
||||
|
||||
---
|
||||
|
||||
## 8. 采购、费用、合同与项目资料
|
||||
|
||||
### 8.1 采购和费用审批
|
||||
|
||||
- 员工可提交采购或费用申请，填写用途、金额、项目、供应商、附件和期望时间。
|
||||
- 主管、财务或老板按规则审批。
|
||||
- 审批通过后形成可追溯记录，可关联预算、项目、付款和合同资料。
|
||||
- 首批优先支持轻量申请和审批，不做复杂招采流程。
|
||||
|
||||
### 8.2 合同与附件归档
|
||||
|
||||
- 合同管理首批以台账为主：合同编号、名称、客户或供应商、项目、金额、负责人、状态、归档位置。
|
||||
- 非涉密附件可进入 OA；涉密合同正文、敏感报价、成本细节和客户敏感资料不得进入公网 OA。
|
||||
- 合同编号应由 OA 统一生成或由管理员登记后校验唯一性。
|
||||
- 合同相关审批和变更记录应回到 OA 留痕。
|
||||
|
||||
### 8.3 项目轻管理
|
||||
|
||||
- 项目页只做轻量管理：成员、里程碑、任务、风险、交付记录、费用/采购/差旅关联。
|
||||
- 不做重型甘特图、资源排产、CRM 或完整项目组合管理。
|
||||
- 员工的报销、采购、差旅、周报和待办应尽量关联项目，减少另建表格。
|
||||
|
||||
### 8.4 验收
|
||||
|
||||
- 采购申请可提交、审批和查看状态。
|
||||
- 合同台账能记录编号、责任人、归档位置和项目关联。
|
||||
- 项目视图能汇总关键事项，不要求替代专业项目管理工具。
|
||||
|
||||
---
|
||||
|
||||
## 9. 企业微信基础设施需求
|
||||
|
||||
### 9.1 自建应用
|
||||
|
||||
- 公司只维护一个企业微信自建应用，建议命名为 `海音达工作台`。
|
||||
- 手机端默认入口进入 `/mobile`。
|
||||
- PC 浏览器和普通账号密码登录默认进入 `/portal`。
|
||||
- 企业微信入口失败时必须保留账号密码登录回退路径。
|
||||
|
||||
### 9.2 免登与绑定
|
||||
|
||||
- 支持企业微信 OAuth 或免登后识别员工身份。
|
||||
- 首次未绑定时，员工可使用账号密码登录后在个人设置中完成绑定。
|
||||
- 一个企业微信身份不得绑定多个员工。
|
||||
- 员工离职或账号停用后，企业微信入口也不得继续进入业务系统。
|
||||
|
||||
### 9.3 消息通知
|
||||
|
||||
- 企业微信消息只做提醒，审批动作必须回到 OA 页面完成。
|
||||
- 消息内容最小化：标题、业务编号、状态、处理入口。
|
||||
- 发送失败应可重试，不阻断主业务提交或审批。
|
||||
- 不在消息中发送合同正文、完整发票、敏感报价、银行卡、身份证等敏感内容。
|
||||
|
||||
### 9.4 打卡原始采集
|
||||
|
||||
- 企业微信打卡数据可作为后续同步来源。
|
||||
- 首批不新增企业微信打卡 API 同步实现。
|
||||
- 正式考勤统计必须结合 OA 的请假、补卡、外出、加班审批结果。
|
||||
|
||||
---
|
||||
|
||||
## 10. 权限、审计、数据安全与非功能要求
|
||||
|
||||
### 10.1 权限原则
|
||||
|
||||
- 后端是权限单一事实源；前端按钮显隐不等于授权。
|
||||
- 普通员工只能看和处理自己的单据。
|
||||
- 审批人只能处理分配给自己的待办或自己角色范围内的待办。
|
||||
- 财务可处理发票、付款和导出，但不默认拥有系统管理权限。
|
||||
- HR/管理员可维护人员、组织和基础配置，但敏感操作必须审计。
|
||||
- 老板/总经理可查看公司级摘要和处理关键审批，但仍应保留操作留痕。
|
||||
|
||||
### 10.2 审计要求
|
||||
|
||||
以下动作必须可追溯：
|
||||
|
||||
- 登录、退出、绑定、解绑、账号停用。
|
||||
- 单据提交、审批、驳回、退回、撤回、转审。
|
||||
- 发票上传、OCR 重试、人工修正、重复例外、附件下载。
|
||||
- 付款标记、财务导出、合同归档、权限变更。
|
||||
- 企业微信通知发送失败、重试和配置异常。
|
||||
|
||||
### 10.3 数据安全
|
||||
|
||||
- 密码、密钥、令牌不得写入文档、日志或前端包。
|
||||
- 银行卡、身份证、手机号等敏感字段对外响应应脱敏。
|
||||
- 附件下载应有鉴权和有效期控制。
|
||||
- 涉密合同正文、详细报价、成本细节、敏感客户资料不进入公网 OA。
|
||||
- 生产环境必须有数据库和文件存储备份，并定期做恢复演练。
|
||||
|
||||
### 10.4 非功能要求
|
||||
|
||||
- PC 和移动端都应覆盖高频流程。
|
||||
- 10 人以下团队的常用列表和表单应保持快速响应。
|
||||
- 关键错误需要给出可操作提示，例如未绑定、权限不足、审批人缺失、OCR 失败、重复发票。
|
||||
- 部署后必须能通过 `/ready` 检查服务状态。
|
||||
- 新功能应有可复现测试步骤，无法自动化时写清人工验收步骤。
|
||||
|
||||
---
|
||||
|
||||
## 11. 暂不做范围
|
||||
|
||||
首批 MVP 不做以下事项：
|
||||
|
||||
- 不接入飞书，不保留飞书登录、通知、审批、文档或项目管理路线。
|
||||
- 不使用企业微信原生审批作为正式审批流。
|
||||
- 不开发复杂 BPM 流程设计器，不做并行会签建模。
|
||||
- 不依赖付费低代码平台、付费第三方应用或付费项目管理套件。
|
||||
- 不重造企业微信打卡的定位、人脸识别、Wi-Fi、排班规则。
|
||||
- 不做完整 CRM、ERP、PLM、甘特排产或项目组合管理。
|
||||
- 不把聊天记录、会议纪要、涉密合同正文或敏感报价长期保存在 OA。
|
||||
|
||||
---
|
||||
|
||||
## 12. MVP 验收标准
|
||||
|
||||
### 12.1 产品验收
|
||||
|
||||
- 老板能在 OA 中看到审批待办、项目/费用摘要和关键风险。
|
||||
- 员工能在 PC 或手机端完成报销、请假、采购等核心申请。
|
||||
- 审批人能在 PC 和移动端处理待办。
|
||||
- 财务能完成发票查重、付款标记和导出。
|
||||
- 管理员能维护人员、权限、企业微信入口和基础配置。
|
||||
- 企业微信只作为入口和提醒，不产生正式审批分叉。
|
||||
|
||||
### 12.2 流程验收
|
||||
|
||||
| 场景 | 验收步骤 |
|
||||
| --- | --- |
|
||||
| 报销主流程 | 上传发票 -> OCR -> 绑定明细 -> 提交 -> 审批 -> 付款 -> 导出 |
|
||||
| 重复发票 | 上传已使用发票 -> 系统阻断 -> 财务授权例外需原因和原单号 |
|
||||
| 请假流程 | 员工提交请假 -> 主管审批 -> 团队状态或日历更新 |
|
||||
| 采购流程 | 员工提交采购 -> 审批通过或驳回 -> 状态和附件可追溯 |
|
||||
| 企业微信入口 | 手机企业微信进入 `/mobile` -> 账号已绑定则直达，未绑定可回退账号密码 |
|
||||
| 企业微信通知 | 收到审批提醒 -> 点击 deeplink -> 回到 OA 审批页处理 |
|
||||
| 文档门禁 | 新需求先更新 PRD 或规则文档，再拆 Issue CSV，不直接开发 |
|
||||
|
||||
### 12.3 工程验收
|
||||
|
||||
- Issue CSV 校验通过。
|
||||
- 文档 diff 检查通过。
|
||||
- 涉及后端时执行 Prisma、语法和相关回归脚本。
|
||||
- 涉及前端时执行 typecheck、build 和相关 Playwright。
|
||||
- 涉及公网或企业微信真机时，必须部署后检查 `/ready`、前端资源和真实入口。
|
||||
|
||||
---
|
||||
|
||||
## 13. 后续 Backlog
|
||||
|
||||
后续事项必须另立 Issue CSV，不直接进入当前 MVP：
|
||||
|
||||
- 企业微信打卡 API 同步和考勤汇总报表。
|
||||
- 补卡、外出、加班的完整移动端体验强化。
|
||||
- 合同台账、合同编号、合同审批和离线档案号的细化。
|
||||
- 预算控制、支付批次、AP 运营和 ERP 出站凭证增强。
|
||||
- 项目轻管理与周报、待办、费用、采购、差旅的进一步联动。
|
||||
- 全量 E2E 稳定性清理和移动视觉回归。
|
||||
- 生产备份恢复演练、并发试运行和正式上线复核。
|
||||
|
||||
---
|
||||
|
||||
## 14. 文档维护规则
|
||||
|
||||
- 本文件回答“要做什么、为什么做、先做什么、不做什么、如何验收”。
|
||||
- `docs/product-decisions.md` 记录已经拍板的产品口径。
|
||||
- `docs/feature-matrix.md` 记录已经实现了什么和证据在哪里。
|
||||
- `issues/*.csv` 是每轮开发执行合同。
|
||||
- 需求变化必须先更新本文件或对应规则文档，再创建新的 Issue CSV。
|
||||
- 不批量回改旧 Issue CSV 来伪造一致性；历史计划保留为历史快照。
|
||||
保留本文件是为了兼容历史文档、历史 Issue CSV 和外部链接。后续新增需求、评审和开发拆分，应优先引用中文主文档。
|
||||
|
||||
@@ -1,7 +1,10 @@
|
||||
# hyb-oa 技术栈与复用报告（定案）
|
||||
|
||||
**文档状态**：历史技术选型定案，保留为架构追溯参考。
|
||||
**日期**：2026-02-05
|
||||
**适用范围**：OA 报销系统（Phase 1）
|
||||
**当前用途**：确认 Fastify + Prisma + PostgreSQL 等基础技术选型来源。
|
||||
**不得误读**：`Phase 1 / P0 / P2` 为早期阶段口径，不代表当前 MVP 需求范围；当前需求以 [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md) 为准。
|
||||
|
||||
## 1. 定案结论（统一口径）
|
||||
| 层级 | 选型 |
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
# 历史 TODO 清账映射（A/C -> B/D/F）
|
||||
|
||||
**文档状态**：历史 TODO 清账证据，不是当前待办列表。
|
||||
**日期**：2026-03-13
|
||||
**范围**：
|
||||
- `issues/2026-02-07-p2-kickoff.csv`
|
||||
- `issues/2026-02-08_14-20-25-p2-ci-and-tests.csv`
|
||||
|
||||
**目标**：对历史 `TODO` 项逐条给出去向：`implemented | superseded | still-open`，并以“后续执行合同 + 当前代码路径”形成可审计证据链。
|
||||
**当前用途**：解释早期 TODO 为什么不再直接推进；新需求必须进入新的 `issues/*.csv`。
|
||||
**不得误读**：本文中的 `still-open=0` 只针对列出的早期 TODO，不代表全项目没有待办。
|
||||
|
||||
## 1. 2026-02-07-p2-kickoff.csv
|
||||
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
# R70 人工业务试运行报告
|
||||
|
||||
**文档状态**：历史人工试运行快照，不代表当前公网部署状态。
|
||||
日期：2026-04-28
|
||||
**当前用途**：追溯 R70-R81 期间本地、公网、企微、OCR 等验证证据。
|
||||
**不得误读**：文中的 `force_off`、公网 `.env`、企微启用状态和开放问题均为当时记录；当前状态应以最新 Issue CSV、部署报告和 live smoke 结果为准。
|
||||
|
||||
## 结论
|
||||
|
||||
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# hyb-oa 文档索引
|
||||
|
||||
**文档状态**：当前人工审查入口。
|
||||
**适用时间**：2026-05-09 之后。
|
||||
|
||||
本索引用来区分“当前事实源”和“历史证据”。查需求、排期、开发范围时，先读当前事实源；排查历史实现、回归证据或旧决策时，再读历史快照和证据文档。
|
||||
|
||||
## 当前事实源
|
||||
|
||||
| 文档 | 用途 | 注意 |
|
||||
| --- | --- | --- |
|
||||
| [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md) | 当前 PRD 主事实源，回答做什么、先做什么、不做什么、如何验收 | 后续需求变更先改这里或对应规则文档，再拆 Issue CSV |
|
||||
| [产品口径文档](./product-decisions.md) | 已拍板的产品边界和业务规则 | 与 PRD 冲突时，以更新后的 PRD 和最新 Issue CSV 为准 |
|
||||
| [报销、发票与附件规则](./reimbursement-invoice-rules.md) | 报销、发票、OCR、附件的细则 | 报销相关开发必须同时参考 |
|
||||
| [产品设计规则基线](./product-design-rules.md) | PC、移动、企业微信 WebView 的视觉和交互规则 | 页面调整必须参考 |
|
||||
| [AGENTS 项目规则](../AGENTS.md) | Agent 协作、Issue CSV、测试和提交规则 | 执行开发前必须遵守 |
|
||||
|
||||
## 当前操作手册
|
||||
|
||||
| 文档 | 用途 | 注意 |
|
||||
| --- | --- | --- |
|
||||
| [管理员手册](./admin-handbook.md) | 管理员上线、企业微信入口、权限、试点配置 | 适合小团队试运行 |
|
||||
| [员工快速上手](./employee-quickstart.md) | 员工侧日常使用说明 | 面向普通员工 |
|
||||
| [试运行与自动化验证 Runbook](./trialrun-runbook.md) | 本地、公网、企业微信试运行操作 | 涉及公网或企业微信真机时必须看 |
|
||||
| [公网 live smoke 与真实 OCR 准备清单](./trialrun/live-smoke-readiness.md) | 公网、真实 OCR、企业微信入口复核准备 | 只有部署后才能给出真机验收结论 |
|
||||
| [真机公网测试清单](./trialrun/real-device-public-checklist.md) | 手机、企业微信、拍照/PDF 上传人工验证 | 用于上线前人工验收 |
|
||||
|
||||
## 实现状态与证据
|
||||
|
||||
| 文档 | 用途 | 注意 |
|
||||
| --- | --- | --- |
|
||||
| [实现状态矩阵](./feature-matrix.md) | 历史实现状态、完成证据、回归覆盖追踪 | 不是 PRD，不作为新增需求来源 |
|
||||
| [试运行覆盖矩阵](./trialrun/coverage-matrix.csv) | 试运行覆盖范围和缺口 | 读取时结合最新 Issue CSV |
|
||||
| [项目级流程矩阵](./trialrun/project-wide-flow-matrix.csv) | 核心业务流、入口、测试覆盖映射 | 用于 QA 和回归规划 |
|
||||
| [人工业务试运行报告](./trialrun/manual-trialrun-report.md) | R70 当时的人工试运行证据 | 是历史快照，不代表当前公网状态 |
|
||||
| [历史 TODO 清账映射](./todo-reconciliation.md) | 旧 TODO 的 implemented / superseded / still-open 追溯 | 不用来生成新需求 |
|
||||
|
||||
## 架构、集成与运维参考
|
||||
|
||||
| 文档 | 用途 | 注意 |
|
||||
| --- | --- | --- |
|
||||
| [系统架构概览](./architecture.md) | 当前架构、部署视图和运行时边界 | 与部署现状有关时需结合最新部署报告 |
|
||||
| [集成边界冻结](./integration-boundaries.md) | ERP、IM、AI、MCP、PWA 等集成边界 | 当前首批路线不接入飞书/钉钉 |
|
||||
| [领域事件清单](./domain-events.md) | 领域事件名和对外事件边界 | 面向集成和异步处理 |
|
||||
| [MCP Tools](./mcp-tools.md) | MCP 工具启用边界 | 未启用的 MCP 不得假设可用 |
|
||||
| [非功能基线](./ops/non-functional-baseline.md) | 安全、性能、回滚、上线最低要求 | 上线和发布前参考 |
|
||||
| [测试策略](./ops/testing-strategy.md) | 自动化测试和门禁策略 | QA 规划参考 |
|
||||
|
||||
## 历史快照与归档参考
|
||||
|
||||
| 文档 | 用途 | 注意 |
|
||||
| --- | --- | --- |
|
||||
| [实施计划](./implementation_plan.md) | 2026-02 Phase 1 引导计划和历史实施思路 | 不是当前执行计划 |
|
||||
| [技术栈与复用报告](./tech_stack_report.md) | 早期技术选型定案和复用说明 | 技术栈仍有参考价值，范围说明已过时 |
|
||||
| [invoicePool 路由拆分方案](./invoice-pool-refactor-plan.md) | 一次性拆分方案归档 | 完成后只作追溯 |
|
||||
| [试点迁移映射清单](./migration-mapping.md) | 旧系统迁移和切换边界 | 仅在迁移/切换专项中使用 |
|
||||
| [国内 OA 与费控系统最佳实践对照](./trialrun/domestic-oa-best-practices.md) | 外部最佳实践调研快照 | 不替代当前 PRD |
|
||||
| [ADR: 移动端路线决策](./adr/adr-mobile-strategy.md) | PWA、RN、小程序路线决策记录 | 保留 ADR 历史结论 |
|
||||
| [ADR: 企业卡/虚拟卡管控能力预研](./adr/adr-enterprise-card-control.md) | 企业卡能力预研记录 | 不进入当前 MVP 首批范围 |
|
||||
|
||||
## 阅读顺序
|
||||
|
||||
1. 要看“现在到底做什么”：读 [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)。
|
||||
2. 要看“某个业务规则为什么这么定”：读 [产品口径文档](./product-decisions.md) 和对应规则文档。
|
||||
3. 要开新开发任务：先更新需求或规则文档，再新建 `issues/*.csv`。
|
||||
4. 要判断功能是否已经做过：读 [实现状态矩阵](./feature-matrix.md) 和最新相关 Issue CSV。
|
||||
5. 要上线或真机验收：读 [试运行与自动化验证 Runbook](./trialrun-runbook.md)、live smoke 清单和最新部署结果。
|
||||
|
||||
## 明确废弃或不进入首批
|
||||
|
||||
- 飞书路线已废弃，不接入登录、通知、审批、文档或项目管理。
|
||||
- 企业微信原生审批不作为正式审批流；企业微信只做入口、免登/绑定、通讯录身份、消息通知和打卡原始采集。
|
||||
- 钉钉、小程序、复杂 BPM、重型项目管理、CRM、完整 ERP 不进入当前 MVP 首批范围。
|
||||
@@ -0,0 +1,350 @@
|
||||
# 海音达 OA 系统 - MVP 需求规格说明书
|
||||
|
||||
**版本**：2.0
|
||||
**日期**：2026-05-09
|
||||
**范围**：10 人以下科技公司试运行 MVP 需求基线
|
||||
**状态**：当前 PRD 主事实源
|
||||
|
||||
**相关文档**：
|
||||
- [文档索引](./文档索引.md)：人工审查入口和文档阅读顺序。
|
||||
- [产品口径文档](./product-decisions.md)：关键产品决策与边界。
|
||||
- [功能状态矩阵](./feature-matrix.md)：历史实现状态、覆盖证据和完成追踪，不作为 PRD 扩写入口。
|
||||
- [管理员手册](./admin-handbook.md)：试运行配置、企业微信入口和上线操作。
|
||||
- [员工快速开始](./employee-quickstart.md)：员工侧使用说明。
|
||||
- [报销与发票规则](./reimbursement-invoice-rules.md)：报销、发票、OCR、附件的细则。
|
||||
- `issues/*.csv`：每轮开发执行合同；需求确认后必须拆 Issue CSV 再开发。
|
||||
|
||||
---
|
||||
|
||||
## 1. 项目目标与当前路线
|
||||
|
||||
### 1.1 背景
|
||||
|
||||
海音达需要一套适合 10 人以下科技公司的轻量 OA，用来把报销、请假、采购、费用、合同、项目资料、审批和基础行政动作集中到一个可审计、可回归、可持续迭代的系统中。系统不追求一次性替代所有办公平台，而是先解决公司内部最容易割裂、最需要留痕的业务流程。
|
||||
|
||||
### 1.2 总目标
|
||||
|
||||
- `hyb-oa` 是唯一业务主系统和唯一正式审批中心。
|
||||
- 所有正式审批在 OA 内提交、审批、留痕、归档。
|
||||
- 企业微信只作为基础设施：手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡原始采集。
|
||||
- PC 用户可直接访问 OA；手机端优先从企业微信工作台进入 OA 移动端。
|
||||
- 后续开发必须先有需求事实源和 Issue CSV 执行合同，避免边想边做。
|
||||
|
||||
### 1.3 当前平台边界
|
||||
|
||||
| 平台 | 定位 | 首批使用方式 | 不承担 |
|
||||
| --- | --- | --- | --- |
|
||||
| `hyb-oa` | 唯一业务主系统和审批中心 | 审批、报销、发票、OCR、请假、采购、合同台账、项目资料、审计归档 | 聊天、会议、在线文档协作 |
|
||||
| 企业微信 | 基础设施 | 手机入口、免登/绑定、通知 deeplink、通讯录身份、打卡原始采集 | 正式审批流、财务附件主库、业务单据主库 |
|
||||
| 飞书 | 已废弃路线 | 不进入首批实现 | 不接入身份、审批、通知、文档或项目主线 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 软件开发项目流程
|
||||
|
||||
后续所有非微小改动按以下流程推进：
|
||||
|
||||
1. 需求收集与边界确认：明确目标用户、业务流程、必须做、暂不做、验收标准。
|
||||
2. 需求文档冻结：更新本文件或对应规则文档，形成产品、开发、测试共同事实源。
|
||||
3. 执行合同拆分：新建 `issues/YYYY-MM-DD_HH-mm-ss-<slug>.csv`，写清范围、验收、测试、依赖。
|
||||
4. 技术方案设计：明确接口、数据模型、权限、状态机、前端入口、回滚策略。
|
||||
5. 开发实现：按 Issue 分后端、前端、QA 阶段推进，不顺手做无关改动。
|
||||
6. 测试与回归：先单点验证，再业务流程回归，最后做 PC/移动/企业微信入口验证。
|
||||
7. 部署与验收：部署后检查 `/ready`、前端资源、关键路径、企业微信真机入口。
|
||||
8. 复盘与下一轮规划：把试运行反馈转成新 Issue CSV，不直接插入开发。
|
||||
|
||||
---
|
||||
|
||||
## 3. 用户角色与典型场景
|
||||
|
||||
| 角色 | 主要目标 | 高频动作 | 关键要求 |
|
||||
| --- | --- | --- | --- |
|
||||
| 老板/总经理 | 看清公司待办、费用、项目风险和审批瓶颈 | 审批大额事项、看项目和费用摘要、处理关键待办 | 少打扰、信息集中、审批记录可信 |
|
||||
| 管理员/HR | 维护人员、入口、制度、请假和基础行政 | 员工管理、请假/补卡审核、公告、入离职、权限配置 | 配置清晰、可回退、有审计 |
|
||||
| 部门主管/项目负责人 | 管团队交付和日常审批 | 审批报销/请假/采购、查看团队状态、跟进项目事项 | 待办清楚、移动端可处理 |
|
||||
| 普通员工 | 快速提交申请和查状态 | 报销、上传发票、请假、补卡、外出、加班、采购申请、周报 | 手机好用、字段少、失败提示明确 |
|
||||
| 财务 | 管报销、发票、付款和导出 | 发票查重、OCR 修正、付款标记、财务导出 | 数据完整、附件可追溯、重复票据可控 |
|
||||
| 系统管理员 | 保障系统可用和可维护 | 部署、备份、恢复、日志、功能开关、企业微信配置 | 不泄露密钥、可定位问题、可回滚 |
|
||||
|
||||
---
|
||||
|
||||
## 4. MVP 模块优先级
|
||||
|
||||
| 优先级 | 模块 | 目标 | 主入口 | 验收口径 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| P0 | 统一审批中心 | 所有正式审批在 OA 内处理 | PC 审批待办、移动审批 | 能提交、审批、驳回、退回、转审、留痕 |
|
||||
| P0 | 企业微信基础设施 | 手机入口、免登、通知、打卡原始采集 | 企业微信自建应用 `海音达工作台` | 手机进入 `/mobile`，通知 deeplink 回 OA |
|
||||
| P0 | 报销/发票/OCR | 员工自助报销，财务可查重和导出 | 报销、移动报销、票据中心 | 上传、OCR、查重、绑定、审批、付款闭环 |
|
||||
| P0 | 请假与考勤修正审批 | 请假、补卡、外出、加班等修正都在 OA 内审批 | 请假、移动审批、团队状态 | 审批后团队状态和考勤口径不破坏 |
|
||||
| P1 | 采购/费用审批 | 小团队采购和费用事项留痕 | 采购、审批待办 | 申请、附件、审批、状态更新可用 |
|
||||
| P1 | 合同与附件归档 | 管合同编号、责任人、归档位置和非涉密附件 | 合同/项目资料或项目页 | 能登记、查询、关联项目和审批记录 |
|
||||
| P1 | 项目轻管理 | 把费用、采购、差旅、周报挂到项目 | 项目、Portal、周报 | 能看项目事项、风险、费用摘要，不做重型排产 |
|
||||
| P2 | 预算/支付/ERP/AI | 在试运行稳定后增强运营能力 | 管理员备用入口 | 另立 Issue CSV，不进入首批验收 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 统一审批中心需求
|
||||
|
||||
### 5.1 范围
|
||||
|
||||
OA 是公司唯一正式审批中心。以下审批必须在 OA 内提交、审批、留痕、归档：
|
||||
|
||||
- 报销、费用、采购。
|
||||
- 合同相关审批和合同台账维护。
|
||||
- 请假、补卡、外出、加班、出差。
|
||||
- 资产领用、归还、调拨、盘点中的需要留痕动作。
|
||||
- 后续新增业务审批，默认也进入 OA 审批中心。
|
||||
|
||||
企业微信原生审批不作为公司正式审批入口，不允许形成“一部分审批在企业微信、一部分审批在 OA”的双轨口径。
|
||||
|
||||
### 5.2 审批能力
|
||||
|
||||
- 支持草稿、提交、审批中、通过、驳回、退回、撤回、转审、完成等状态语义。
|
||||
- 审批链优先采用串行多节点；当前阶段不做并行会签。
|
||||
- 大额或高风险单据通过审批规则配置多级审批，不通过硬编码角色分叉。
|
||||
- 当前审批人只能处理分配给自己的待办，或者处理分配给自己角色且权限匹配的待办。
|
||||
- 转审必须记录原因，转给具备对应审批权限的人，并保留转审历史。
|
||||
- 单据编号由 OA 生成和保存；报销单、采购单、合同编号等应使用统一编号规则或对应业务编号规则。
|
||||
|
||||
### 5.3 数据与留痕
|
||||
|
||||
- 所有审批动作写入工作流历史。
|
||||
- 关键例外动作写入审计日志，包括重复发票例外、付款标记、权限变更、附件下载、通知重试。
|
||||
- 企业微信消息只包含脱敏标题、业务编号、状态和 deeplink，不包含涉密正文、完整发票、合同正文或敏感报价。
|
||||
|
||||
### 5.4 验收
|
||||
|
||||
- 审批人可在 PC 和移动端看到待办。
|
||||
- 审批动作完成后，业务单据状态、审批历史、通知和审计记录一致。
|
||||
- 企业微信提醒点击后回到 OA 页面处理，不能在企业微信原生审批里完成正式审批。
|
||||
|
||||
---
|
||||
|
||||
## 6. 报销、发票、OCR、附件与财务导出
|
||||
|
||||
### 6.1 用户流程
|
||||
|
||||
1. 员工在 PC 或手机端创建报销草稿。
|
||||
2. 上传发票图片、PDF 或必要附件。
|
||||
3. 系统执行 OCR，识别发票代码、号码、金额、日期、销方、购方等关键字段。
|
||||
4. 员工确认或修正识别结果，补充费用明细和说明。
|
||||
5. 系统做发票查重和基础校验。
|
||||
6. 员工提交报销，进入 OA 审批流。
|
||||
7. 审批通过后，财务复核并标记付款。
|
||||
8. 财务按期间、状态、项目、人员导出报销和发票数据。
|
||||
|
||||
### 6.2 发票与附件管理
|
||||
|
||||
- 发票和附件原始文件以 OA/对象存储为主，不依赖企业微信长期保存。
|
||||
- 同一发票不得被重复报销；如确需例外，必须由授权财务角色填写原单号和原因。
|
||||
- OCR 失败时允许重试和人工修正，但必须保留失败原因和修正痕迹。
|
||||
- 报销完成后，相关发票进入已使用或归档状态，不能被普通员工再次绑定到新单据。
|
||||
- 普通员工只看到“添加发票、上传附件、提交审批、查看状态”等业务语言，不暴露内部发票池概念。
|
||||
|
||||
### 6.3 财务导出
|
||||
|
||||
- 财务可按报销状态、付款状态、员工、部门、项目、期间筛选导出。
|
||||
- 导出数据应包含业务编号、申请人、实际报销人、金额、费用类型、发票摘要、审批状态和付款状态。
|
||||
- 导出不得包含未授权敏感字段明文。
|
||||
|
||||
### 6.4 验收
|
||||
|
||||
- 手机拍照或上传发票后，能完成 OCR、查重、绑定、提交。
|
||||
- 报销审批通过后，财务能付款标记并导出。
|
||||
- 重复发票、OCR 失败、附件缺失、金额不一致等异常有明确提示。
|
||||
|
||||
---
|
||||
|
||||
## 7. 请假、补卡、外出、加班与考勤口径
|
||||
|
||||
### 7.1 边界
|
||||
|
||||
- 企业微信打卡用于原始采集，保留其定位、人脸、Wi-Fi、排班和设备能力。
|
||||
- OA 不在首批重造打卡规则、定位、人脸识别或排班引擎。
|
||||
- 请假、补卡、外出、加班等考勤修正申请在 OA 内提交和审批。
|
||||
- 后续可同步企业微信打卡原始记录，再结合 OA 审批形成正式考勤口径。
|
||||
|
||||
### 7.2 用户流程
|
||||
|
||||
- 员工在 OA 提交请假、补卡、外出或加班申请。
|
||||
- 主管或 HR 在 OA 审批。
|
||||
- 审批通过后，团队状态、日历和后续考勤统计使用 OA 的审批结果。
|
||||
- 企业微信打卡异常不直接等于最终考勤异常，最终口径以 OA 汇总为准。
|
||||
|
||||
### 7.3 验收
|
||||
|
||||
- 请假提交、审批、撤回、驳回后状态正确。
|
||||
- 已批准请假能影响团队状态或日历展示。
|
||||
- 文档和界面不引导员工去企业微信原生审批提交请假或补卡。
|
||||
|
||||
---
|
||||
|
||||
## 8. 采购、费用、合同与项目资料
|
||||
|
||||
### 8.1 采购和费用审批
|
||||
|
||||
- 员工可提交采购或费用申请，填写用途、金额、项目、供应商、附件和期望时间。
|
||||
- 主管、财务或老板按规则审批。
|
||||
- 审批通过后形成可追溯记录，可关联预算、项目、付款和合同资料。
|
||||
- 首批优先支持轻量申请和审批，不做复杂招采流程。
|
||||
|
||||
### 8.2 合同与附件归档
|
||||
|
||||
- 合同管理首批以台账为主：合同编号、名称、客户或供应商、项目、金额、负责人、状态、归档位置。
|
||||
- 非涉密附件可进入 OA；涉密合同正文、敏感报价、成本细节和客户敏感资料不得进入公网 OA。
|
||||
- 合同编号应由 OA 统一生成或由管理员登记后校验唯一性。
|
||||
- 合同相关审批和变更记录应回到 OA 留痕。
|
||||
|
||||
### 8.3 项目轻管理
|
||||
|
||||
- 项目页只做轻量管理：成员、里程碑、任务、风险、交付记录、费用/采购/差旅关联。
|
||||
- 不做重型甘特图、资源排产、CRM 或完整项目组合管理。
|
||||
- 员工的报销、采购、差旅、周报和待办应尽量关联项目，减少另建表格。
|
||||
|
||||
### 8.4 验收
|
||||
|
||||
- 采购申请可提交、审批和查看状态。
|
||||
- 合同台账能记录编号、责任人、归档位置和项目关联。
|
||||
- 项目视图能汇总关键事项，不要求替代专业项目管理工具。
|
||||
|
||||
---
|
||||
|
||||
## 9. 企业微信基础设施需求
|
||||
|
||||
### 9.1 自建应用
|
||||
|
||||
- 公司只维护一个企业微信自建应用，建议命名为 `海音达工作台`。
|
||||
- 手机端默认入口进入 `/mobile`。
|
||||
- PC 浏览器和普通账号密码登录默认进入 `/portal`。
|
||||
- 企业微信入口失败时必须保留账号密码登录回退路径。
|
||||
|
||||
### 9.2 免登与绑定
|
||||
|
||||
- 支持企业微信 OAuth 或免登后识别员工身份。
|
||||
- 首次未绑定时，员工可使用账号密码登录后在个人设置中完成绑定。
|
||||
- 一个企业微信身份不得绑定多个员工。
|
||||
- 员工离职或账号停用后，企业微信入口也不得继续进入业务系统。
|
||||
|
||||
### 9.3 消息通知
|
||||
|
||||
- 企业微信消息只做提醒，审批动作必须回到 OA 页面完成。
|
||||
- 消息内容最小化：标题、业务编号、状态、处理入口。
|
||||
- 发送失败应可重试，不阻断主业务提交或审批。
|
||||
- 不在消息中发送合同正文、完整发票、敏感报价、银行卡、身份证等敏感内容。
|
||||
|
||||
### 9.4 打卡原始采集
|
||||
|
||||
- 企业微信打卡数据可作为后续同步来源。
|
||||
- 首批不新增企业微信打卡 API 同步实现。
|
||||
- 正式考勤统计必须结合 OA 的请假、补卡、外出、加班审批结果。
|
||||
|
||||
---
|
||||
|
||||
## 10. 权限、审计、数据安全与非功能要求
|
||||
|
||||
### 10.1 权限原则
|
||||
|
||||
- 后端是权限单一事实源；前端按钮显隐不等于授权。
|
||||
- 普通员工只能看和处理自己的单据。
|
||||
- 审批人只能处理分配给自己的待办或自己角色范围内的待办。
|
||||
- 财务可处理发票、付款和导出，但不默认拥有系统管理权限。
|
||||
- HR/管理员可维护人员、组织和基础配置，但敏感操作必须审计。
|
||||
- 老板/总经理可查看公司级摘要和处理关键审批，但仍应保留操作留痕。
|
||||
|
||||
### 10.2 审计要求
|
||||
|
||||
以下动作必须可追溯：
|
||||
|
||||
- 登录、退出、绑定、解绑、账号停用。
|
||||
- 单据提交、审批、驳回、退回、撤回、转审。
|
||||
- 发票上传、OCR 重试、人工修正、重复例外、附件下载。
|
||||
- 付款标记、财务导出、合同归档、权限变更。
|
||||
- 企业微信通知发送失败、重试和配置异常。
|
||||
|
||||
### 10.3 数据安全
|
||||
|
||||
- 密码、密钥、令牌不得写入文档、日志或前端包。
|
||||
- 银行卡、身份证、手机号等敏感字段对外响应应脱敏。
|
||||
- 附件下载应有鉴权和有效期控制。
|
||||
- 涉密合同正文、详细报价、成本细节、敏感客户资料不进入公网 OA。
|
||||
- 生产环境必须有数据库和文件存储备份，并定期做恢复演练。
|
||||
|
||||
### 10.4 非功能要求
|
||||
|
||||
- PC 和移动端都应覆盖高频流程。
|
||||
- 10 人以下团队的常用列表和表单应保持快速响应。
|
||||
- 关键错误需要给出可操作提示，例如未绑定、权限不足、审批人缺失、OCR 失败、重复发票。
|
||||
- 部署后必须能通过 `/ready` 检查服务状态。
|
||||
- 新功能应有可复现测试步骤，无法自动化时写清人工验收步骤。
|
||||
|
||||
---
|
||||
|
||||
## 11. 暂不做范围
|
||||
|
||||
首批 MVP 不做以下事项：
|
||||
|
||||
- 不接入飞书，不保留飞书登录、通知、审批、文档或项目管理路线。
|
||||
- 不使用企业微信原生审批作为正式审批流。
|
||||
- 不开发复杂 BPM 流程设计器，不做并行会签建模。
|
||||
- 不依赖付费低代码平台、付费第三方应用或付费项目管理套件。
|
||||
- 不重造企业微信打卡的定位、人脸识别、Wi-Fi、排班规则。
|
||||
- 不做完整 CRM、ERP、PLM、甘特排产或项目组合管理。
|
||||
- 不把聊天记录、会议纪要、涉密合同正文或敏感报价长期保存在 OA。
|
||||
|
||||
---
|
||||
|
||||
## 12. MVP 验收标准
|
||||
|
||||
### 12.1 产品验收
|
||||
|
||||
- 老板能在 OA 中看到审批待办、项目/费用摘要和关键风险。
|
||||
- 员工能在 PC 或手机端完成报销、请假、采购等核心申请。
|
||||
- 审批人能在 PC 和移动端处理待办。
|
||||
- 财务能完成发票查重、付款标记和导出。
|
||||
- 管理员能维护人员、权限、企业微信入口和基础配置。
|
||||
- 企业微信只作为入口和提醒，不产生正式审批分叉。
|
||||
|
||||
### 12.2 流程验收
|
||||
|
||||
| 场景 | 验收步骤 |
|
||||
| --- | --- |
|
||||
| 报销主流程 | 上传发票 -> OCR -> 绑定明细 -> 提交 -> 审批 -> 付款 -> 导出 |
|
||||
| 重复发票 | 上传已使用发票 -> 系统阻断 -> 财务授权例外需原因和原单号 |
|
||||
| 请假流程 | 员工提交请假 -> 主管审批 -> 团队状态或日历更新 |
|
||||
| 采购流程 | 员工提交采购 -> 审批通过或驳回 -> 状态和附件可追溯 |
|
||||
| 企业微信入口 | 手机企业微信进入 `/mobile` -> 账号已绑定则直达，未绑定可回退账号密码 |
|
||||
| 企业微信通知 | 收到审批提醒 -> 点击 deeplink -> 回到 OA 审批页处理 |
|
||||
| 文档门禁 | 新需求先更新 PRD 或规则文档，再拆 Issue CSV，不直接开发 |
|
||||
|
||||
### 12.3 工程验收
|
||||
|
||||
- Issue CSV 校验通过。
|
||||
- 文档 diff 检查通过。
|
||||
- 涉及后端时执行 Prisma、语法和相关回归脚本。
|
||||
- 涉及前端时执行 typecheck、build 和相关 Playwright。
|
||||
- 涉及公网或企业微信真机时，必须部署后检查 `/ready`、前端资源和真实入口。
|
||||
|
||||
---
|
||||
|
||||
## 13. 后续 Backlog
|
||||
|
||||
后续事项必须另立 Issue CSV，不直接进入当前 MVP：
|
||||
|
||||
- 企业微信打卡 API 同步和考勤汇总报表。
|
||||
- 补卡、外出、加班的完整移动端体验强化。
|
||||
- 合同台账、合同编号、合同审批和离线档案号的细化。
|
||||
- 预算控制、支付批次、AP 运营和 ERP 出站凭证增强。
|
||||
- 项目轻管理与周报、待办、费用、采购、差旅的进一步联动。
|
||||
- 全量 E2E 稳定性清理和移动视觉回归。
|
||||
- 生产备份恢复演练、并发试运行和正式上线复核。
|
||||
|
||||
---
|
||||
|
||||
## 14. 文档维护规则
|
||||
|
||||
- 本文件回答“要做什么、为什么做、先做什么、不做什么、如何验收”。
|
||||
- `docs/product-decisions.md` 记录已经拍板的产品口径。
|
||||
- `docs/feature-matrix.md` 记录已经实现了什么和证据在哪里。
|
||||
- `issues/*.csv` 是每轮开发执行合同。
|
||||
- 需求变化必须先更新本文件或对应规则文档，再创建新的 Issue CSV。
|
||||
- 不批量回改旧 Issue CSV 来伪造一致性；历史计划保留为历史快照。
|
||||
@@ -1,6 +1,6 @@
|
||||
ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
|
||||
A1,需求事实源盘点与旧文档定位,"盘点现有需求、产品口径、功能矩阵和管理员/员工文档，明确哪些是当前 PRD，哪些是历史证据或实现状态。","1) docs/requirements-specification.md 明确自己是当前 PRD 主事实源；2) docs/feature-matrix.md 被定位为实现状态矩阵，不再作为 PRD 扩写；3) docs/product-decisions.md 继续作为关键产品口径来源；4) 不回改历史 Issue CSV。","人工步骤：阅读 docs/requirements-specification.md 的文档定位章节，确认能区分当前 PRD、产品决策、实现矩阵和执行合同。",manual,DONE,DONE,DONE,docs/requirements-specification.md,"[]","仅整理事实源，不修改业务代码。"
|
||||
A2,重写 MVP 需求总纲 v2.0,"将 docs/requirements-specification.md 从历史 Phase 1 报销规格重写为面向 10 人以下科技公司的 MVP 需求总纲。","1) 文档版本更新到 v2.0；2) 包含项目目标、用户角色、MVP 模块、统一审批中心、企微边界、权限审计、非功能、验收和 backlog；3) 不继续堆历史 Phase 1 实施细节。","人工步骤：检查 docs/requirements-specification.md 是否能回答我们做什么、先做什么、不做什么、谁使用、如何验收。",manual,DONE,DONE,DONE,docs/requirements-specification.md,"[""A1""]","旧 v1.4 内容通过 git 历史保留；如需恢复可按路径回滚该文档。"
|
||||
A3,固化 MVP 模块优先级,"在需求总纲中明确首批 MVP 模块优先级，指导后续 Issue CSV 拆分和开发排序。","1) 统一审批中心为 P0；2) 报销/发票/OCR、请假/补卡/外出/加班、采购/费用、合同/附件归档、企业微信入口通知均有优先级；3) 每个模块写清角色、入口、主流程、数据归档、权限边界、测试方式。","人工步骤：逐项检查 MVP 模块表与模块章节，确认每个模块都有优先级和验收口径。",manual,DONE,DONE,DONE,docs/requirements-specification.md,"[""A2""]","模块优先级用于下一轮执行合同拆分，不代表本轮开发新功能。"
|
||||
A4,明确暂不做范围,"明确飞书、企业微信原生审批、复杂 BPM 设计器、重型项目管理和付费低代码依赖均不进入首批 MVP。","1) 文档明确飞书方案废弃；2) 企业微信原生审批不作为正式审批入口；3) 不依赖付费低代码或付费第三方应用；4) 复杂 BPM、重型项目管理、CRM、完整 ERP 不进入 MVP。","人工步骤：搜索 docs/requirements-specification.md 中的暂不做范围，确认不会误导后续开发接入飞书或企业微信审批。",manual,DONE,DONE,DONE,docs/requirements-specification.md,"[""A2""]","如后续业务方向变化，必须新建 Issue CSV 重新决策。"
|
||||
A5,补齐需求验收与后续开发流程,"把软件开发项目流程、需求到 Issue CSV 的转化规则和 MVP 验收口径写入需求总纲。","1) 文档包含需求事实源 -> Issue CSV -> 方案 -> 开发 -> 测试 -> 部署验收 -> 复盘流程；2) MVP 验收覆盖 PC、移动、企业微信入口、审批、报销、请假、采购和文档检查；3) 本轮只做文档验证，不运行后端/前端构建。","命令：python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-09_15-39-29-mvp-requirements-baseline.csv && git diff --check；人工步骤：确认需求总纲可作为后续开发指挥文档。",python3|git,DONE,DONE,DONE,issues/2026-05-09_15-39-29-mvp-requirements-baseline.csv|docs/requirements-specification.md,"[""A1"",""A2"",""A3"",""A4""]","本轮不部署；完成后提交中文 commit 并引用 A1-A5。"
|
||||
A1,需求事实源盘点与旧文档定位,"盘点现有需求、产品口径、功能矩阵和管理员/员工文档，明确哪些是当前 PRD，哪些是历史证据或实现状态。","1) docs/海音达OA-MVP需求规格说明书.md 明确自己是当前 PRD 主事实源；2) docs/feature-matrix.md 被定位为实现状态矩阵，不再作为 PRD 扩写；3) docs/product-decisions.md 继续作为关键产品口径来源；4) 不回改历史 Issue CSV。","人工步骤：阅读 docs/海音达OA-MVP需求规格说明书.md 的文档定位章节，确认能区分当前 PRD、产品决策、实现矩阵和执行合同。",manual,DONE,DONE,DONE,docs/海音达OA-MVP需求规格说明书.md,"[]","仅整理事实源，不修改业务代码；英文旧路径保留为跳转。"
|
||||
A2,重写 MVP 需求总纲 v2.0,"将 docs/海音达OA-MVP需求规格说明书.md 从历史 Phase 1 报销规格重写为面向 10 人以下科技公司的 MVP 需求总纲。","1) 文档版本更新到 v2.0；2) 包含项目目标、用户角色、MVP 模块、统一审批中心、企微边界、权限审计、非功能、验收和 backlog；3) 不继续堆历史 Phase 1 实施细节。","人工步骤：检查 docs/海音达OA-MVP需求规格说明书.md 是否能回答我们做什么、先做什么、不做什么、谁使用、如何验收。",manual,DONE,DONE,DONE,docs/海音达OA-MVP需求规格说明书.md,"[""A1""]","旧 v1.4 内容通过 git 历史保留；如需恢复可按路径回滚中文主文档。"
|
||||
A3,固化 MVP 模块优先级,"在需求总纲中明确首批 MVP 模块优先级，指导后续 Issue CSV 拆分和开发排序。","1) 统一审批中心为 P0；2) 报销/发票/OCR、请假/补卡/外出/加班、采购/费用、合同/附件归档、企业微信入口通知均有优先级；3) 每个模块写清角色、入口、主流程、数据归档、权限边界、测试方式。","人工步骤：逐项检查 MVP 模块表与模块章节，确认每个模块都有优先级和验收口径。",manual,DONE,DONE,DONE,docs/海音达OA-MVP需求规格说明书.md,"[""A2""]","模块优先级用于下一轮执行合同拆分，不代表本轮开发新功能。"
|
||||
A4,明确暂不做范围,"明确飞书、企业微信原生审批、复杂 BPM 设计器、重型项目管理和付费低代码依赖均不进入首批 MVP。","1) 文档明确飞书方案废弃；2) 企业微信原生审批不作为正式审批入口；3) 不依赖付费低代码或付费第三方应用；4) 复杂 BPM、重型项目管理、CRM、完整 ERP 不进入 MVP。","人工步骤：搜索 docs/海音达OA-MVP需求规格说明书.md 中的暂不做范围，确认不会误导后续开发接入飞书或企业微信审批。",manual,DONE,DONE,DONE,docs/海音达OA-MVP需求规格说明书.md,"[""A2""]","如后续业务方向变化，必须新建 Issue CSV 重新决策。"
|
||||
A5,补齐需求验收与后续开发流程,"把软件开发项目流程、需求到 Issue CSV 的转化规则和 MVP 验收口径写入需求总纲。","1) 文档包含需求事实源 -> Issue CSV -> 方案 -> 开发 -> 测试 -> 部署验收 -> 复盘流程；2) MVP 验收覆盖 PC、移动、企业微信入口、审批、报销、请假、采购和文档检查；3) 本轮只做文档验证，不运行后端/前端构建。","命令：python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-09_15-39-29-mvp-requirements-baseline.csv && git diff --check；人工步骤：确认需求总纲可作为后续开发指挥文档。",python3|git,DONE,DONE,DONE,issues/2026-05-09_15-39-29-mvp-requirements-baseline.csv|docs/海音达OA-MVP需求规格说明书.md,"[""A1"",""A2"",""A3"",""A4""]","本轮不部署；完成后提交中文 commit 并引用 A1-A5。"
|
||||
|
||||
|
@@ -0,0 +1,8 @@
|
||||
ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
|
||||
A1,文档治理执行合同与盘点,"建立本轮文档治理执行合同，盘点当前 docs 目录中的当前事实源、历史快照、过时口径和审计证据。","1) 新 Issue CSV 校验通过；2) 文档治理范围限定在 docs 与本轮 issues；3) 明确不删除历史证据、不批量回改历史 Issue CSV。","命令：python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-09_15-50-55-doc-governance-baseline.csv；人工步骤：确认本轮只治理文档命名、索引、状态头和引用。",python3,DONE,DONE,DONE,issues/2026-05-09_15-50-55-doc-governance-baseline.csv,"[]","不改业务代码、不部署。"
|
||||
A2,主需求文档中文命名与旧路径跳转,"将当前 PRD 主事实源改为中文文件名，并保留英文旧路径作为跳转说明，方便人工审查且不完全断开旧链接。","1) 新主文档为 docs/海音达OA-MVP需求规格说明书.md；2) docs/requirements-specification.md 保留为跳转索引；3) 当前文档引用优先指向中文主文档。","人工步骤：打开 docs/海音达OA-MVP需求规格说明书.md 可看到完整 PRD；打开 docs/requirements-specification.md 可看到迁移说明和中文链接。",manual,DONE,DONE,DONE,docs/requirements-specification.md|docs/海音达OA-MVP需求规格说明书.md,"[""A1""]","旧路径只保留兼容跳转，不再作为主编辑入口。"
|
||||
A3,新增中文文档索引与阅读顺序,"新增 docs/文档索引.md，按当前事实源、操作手册、实现状态与证据、历史快照、已废弃/过时分组。","1) 文档索引能指导老板、开发、测试快速找到当前有效文档；2) 每类文档说明用途和误读风险；3) 明确当前 PRD、产品口径、功能矩阵和 Issue CSV 的职责。","人工步骤：阅读 docs/文档索引.md，确认无需翻目录即可理解哪些文档当前有效、哪些只作追溯。",manual,DONE,DONE,DONE,docs/文档索引.md,"[""A1"",""A2""]","索引是人工审查入口，不替代 Issue CSV 执行合同。"
|
||||
A4,历史过时文档状态头治理,"为历史 Phase、一次性方案、试运行报告和状态矩阵加醒目状态头，避免被误读为当前执行计划。","1) implementation_plan、tech_stack_report、feature-matrix、todo-reconciliation、manual-trialrun-report、invoice-pool-refactor-plan、integration-boundaries 均有状态说明；2) 状态头说明当前用途和不得误读的边界；3) 不删除历史内容。","人工步骤：逐个打开相关文档前 20 行，确认能看到状态说明；命令：rg -n ""文档状态|当前用途|不得误读"" docs。",manual|ripgrep,DONE,DONE,DONE,docs/implementation_plan.md|docs/tech_stack_report.md|docs/feature-matrix.md|docs/todo-reconciliation.md|docs/trialrun/manual-trialrun-report.md|docs/invoice-pool-refactor-plan.md|docs/integration-boundaries.md,"[""A3""]","历史文档保留审计价值，治理方式为标记和索引，不做删除。"
|
||||
A5,修正飞书钉钉企微旧口径,"修正文档中会误导当前路线的飞书、钉钉、企业微信旧口径，固定首批只保留企业微信基础设施，飞书废弃。","1) implementation_plan 不再把企微/钉钉通知列为当前待推进；2) integration-boundaries 明确飞书/钉钉真实适配器为历史 backlog，不进入首批；3) manual-trialrun-report 中旧 force_off 状态标为当时快照。","命令：rg -n ""飞书|钉钉|force_off|Phase 1|当前执行计划"" docs；人工判断命中内容不再与当前 PRD 冲突。",ripgrep|manual,DONE,DONE,DONE,docs/implementation_plan.md|docs/integration-boundaries.md|docs/trialrun/manual-trialrun-report.md|docs/feature-matrix.md,"[""A4""]","不改运行时配置，仅修正文档事实源口径。"
|
||||
A6,引用检查与链接修复,"修复当前文档之间对需求规格、实施计划、功能矩阵和试运行报告的引用，避免人工审查打开过时入口。","1) 当前 docs 中主需求引用优先指向中文 PRD；2) requirements-specification.md 旧路径仅作为跳转；3) 不批量修改历史 Issue CSV；4) 链接相对路径可读。","命令：rg -n ""requirements-specification\\.md|海音达OA-MVP需求规格说明书\\.md|文档索引\\.md"" docs issues/2026-05-09_15-39-29-mvp-requirements-baseline.csv issues/2026-05-09_15-50-55-doc-governance-baseline.csv；人工检查当前引用合理。",ripgrep|manual,DONE,DONE,DONE,docs|issues/2026-05-09_15-39-29-mvp-requirements-baseline.csv|issues/2026-05-09_15-50-55-doc-governance-baseline.csv,"[""A2"",""A3"",""A4"",""A5""]","历史 Issue CSV 保持不可变，必要兼容由旧路径跳转承担。"
|
||||
A7,文档治理验证与提交,"完成文档治理后执行 CSV 校验、diff 检查和关键词复核，回填状态并提交。","1) 新 Issue CSV 校验通过；2) git diff --check 通过；3) 工作区只包含 docs 与本轮 issues 变更；4) commit message 使用中文并引用 A1-A7。","命令：python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-09_15-50-55-doc-governance-baseline.csv && git diff --check && git status --short；人工步骤：确认 docs/文档索引.md 是人工审查入口。",python3|git|manual,DONE,DONE,DONE,docs|issues/2026-05-09_15-50-55-doc-governance-baseline.csv,"[""A1"",""A2"",""A3"",""A4"",""A5"",""A6""]","本轮不部署；完成后提交并说明未部署。"
|
||||
|
在新工单中引用
屏蔽一个用户