wangsli/hyb-oa
1
0
派生 0
代码 工单 合并请求 工作流 8 软件包 项目 发布 百科 活动
文件
512a58d40eac0f8ea6c8ab52a4db397da7c8e003
hyb-oa/docs/海音达OA-MVP需求规格说明书.md
T

512 行
47 KiB
Markdown
原始文件 Blame 文件历史

此文件含有模棱两可的 Unicode 字符
此文件含有可能会与其他字符混淆的 Unicode 字符。 如果您是想特意这样的，可以安全地忽略该警告。 使用 Escape 按钮显示他们。
# 海音达 OA 系统 - MVP 需求规格说明书
**版本**：2.0
**日期**：2026-05-09
**范围**：10 人以下科技公司试运行 MVP 需求基线
**状态**：当前 PRD 主事实源
**相关文档**：
- [文档索引](./文档索引.md)：人工审查入口和文档阅读顺序。
- [产品口径文档](./产品口径.md)：关键产品决策与边界。
- [功能状态矩阵](./历史功能状态矩阵.md)：历史实现状态、覆盖证据和完成追踪，不作为 PRD 扩写入口。
- [管理员手册](./管理员手册.md)：试运行配置、企业微信入口和上线操作。
- [员工快速开始](./员工快速上手.md)：员工侧使用说明。
- [报销与发票规则](./报销发票附件规则.md)：报销、发票、OCR、附件的细则。
- [需求 - 统一审批中心规约](./需求-统一审批中心规约.md)：审批中心模块级开发规约。
- [需求 - 报销发票 OCR 规约](./需求-报销发票OCR规约.md)：报销、发票、OCR、附件模块级开发规约。
- [需求 - 企业微信基础设施规约](./需求-企业微信基础设施规约.md)：企业微信入口、免登、绑定、通知、deeplink 和打卡采集边界规约。
- [需求 - 请假考勤修正规约](./需求-请假考勤修正规约.md)：请假、补卡、外出、加班与考勤修正模块级开发规约。
- [需求 - 采购费用审批规约](./需求-采购费用审批规约.md)：采购申请、费用申请、审批、附件和业务关联模块级开发规约。
- [需求 - 合同附件归档规约](./需求-合同附件归档规约.md)：合同台账、编号、非涉密附件、归档、权限和审计模块级开发规约。
- [需求 - 项目轻管理规约](./需求-项目轻管理规约.md)：项目基础信息、成员、里程碑、任务、风险、交付和业务关联模块级开发规约。
- `issues/*.csv`：每轮开发执行合同；需求确认后必须拆 Issue CSV 再开发。
---
## 1. 项目目标与当前路线
### 1.1 背景
海音达需要一套适合 10 人以下科技公司的轻量 OA，用来把报销、采购、费用、合同、项目资料、财务闭环、审计和关键行政数据集中到一个可审计、可回归、可持续迭代的系统中。WFOC 起产品方向调整为“企微优先 + OA 无痛接管”；DBWFOC 进一步修正边界：能复用企业微信成熟功能的 HR/考勤员工日常场景优先使用企业微信，OA 做按域镜像、人工接管、恢复回写、财务闭环和审计中台；采购、合同、项目、财务和高敏附件仍由 OA 主办和存储。WFDG 固定后续开发前必须先过设计规约门禁和企微 API 能力 POC；WDRG 进一步固定后续采用“路线图门禁 + 单功能 Issue CSV”的开发节奏，不再直接进入大规模运行时改造。WCP1 已完成企业微信能力只读 POC 并暴露初始配置缺口；WCPC 已用既有在职测试号复跑通过，结论 `GO_TO_HR_MASTER_SYNC`；WHMS/WHMSLIVE 已完成 HR 主数据镜像实现和受控公网验证；WAPI/WRRA 后路线调整为先运行优先和 WOUA 差异收口。WARCH2 后请假/补卡已归档历史可在 OA 只读查看，下一阶段先走 WROAD2+OPS 测试账号受控上线和每日巡检，再做归档稳定化与打卡摘要留存，不直接进入完整考勤/审批深度镜像。
### 1.2 总目标
- HR/考勤员工日常审批优先复用企业微信成熟能力；OA 同步按域镜像并保留人工接管和恢复回写能力。
- 报销、PDF 发票 OCR、发票查重、付款批次、银行回单、AP 台账、代账交接和财务审计继续由 OA 主办。
- 企业微信作为手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡、人事助手和 HR/考勤员工日常审批主操作端。
- 采购、费用、合同、项目、报销、付款、AP、代账交接和敏感附件不迁移到企业微信原生审批或企业微信附件；企业微信只发送脱敏提醒和 OA deeplink。
- PC 用户可直接访问 OA；手机端优先从企业微信工作台进入 OA 移动端。
- 后续开发必须先有需求事实源和 Issue CSV 执行合同，避免边想边做。
### 1.3 当前平台边界
| 平台 | 定位 | 首批使用方式 | 不承担 |
| --- | --- | --- | --- |
| `hyb-oa` | 财务主系统、OA 主办业务系统、按域镜像、接管和审计中台 | 报销、发票、OCR、付款批次、银行回单、AP 台账、代账交接、采购/合同/项目轻台账、企微 HR/考勤数据镜像和应急接管 | 重造企业微信成熟打卡、人事和 HR/考勤员工日常审批能力；把 OA 主办高敏数据全量镜像到企微 |
| 企业微信 | HR/考勤员工日常主操作端、移动入口和消息通道 | 通讯录、人事助手花名册、打卡规则/排班/日报/月报、请假/补卡/外出/加班审批、假期余额、工作台入口和脱敏消息 | 财务附件主库、报销 OCR、付款批次、代账交接、采购/合同/项目附件主库、OA 审计主库 |
| 飞书 | 已废弃路线 | 不进入首批实现 | 不接入身份、审批、通知、文档或项目主线 |
### 1.4 WFOC 需求分层
| 层级 | 主办方 | 目标 |
| --- | --- | --- |
| 企微主办层 | 企业微信 | 通讯录、人事助手花名册、打卡规则/排班/日报/月报、请假/补卡/外出/加班审批、假期余额。 |
| OA 镜像层 | OA | 按域同步企微主办的人员、部门、HR/考勤审批单、打卡、规则、附件、回调和操作日志，形成可查询、可导出、可审计的副本。 |
| OA 接管层 | OA | 企微不可用时由管理员人工开启 `oa_hr_emergency_mode_v1`，员工通过 OA 账号密码提交 HR/考勤类应急申请。 |
| 恢复回写层 | OA + 企业微信 API | 企微恢复后由 `wecom_recovery_writeback_v1` 对应急数据执行 dry-run、自动回写、失败重试和冲突清单。 |
| 财务主办层 | OA | 报销、PDF 发票 OCR、发票查重、付款批次、银行回单、AP 台账、代账交接继续 OA 主办，不迁移到企微。 |
无痛切换是长期目标，不代表本轮已实现完整替代。完整镜像按域定义：企微主办域镜像到 OA；OA 主办域不反向全量镜像到企微，只发送脱敏标题、业务类型、业务编号、状态和 OA 链接。WEGOV1 后，OA 不重造企业微信完整打卡/考勤/HR 产品，但必须保存企微关键历史、完整外部关联键和必要快照，保证企微不可用时可查看既有数据。WROAD2 后“可受控使用”和“完整镜像增强”分离：先用测试账号 `SMOKE002 -> SMOKE101 + wangshunli` 做 3 天每日脚本化巡检，允许补偿归档写 OA 自建留存库，不写企业微信；外出/加班延期，打卡留存 V1 摘要优先，图片 OCR、复杂 BPM、预算、ERP、银行流水导入等 P2 大功能继续冻结。后续必须按 `wecom_hr_master_sync_v1`、`runtime_first_wecom_enablement`、`WOUA-FIX / WECOM-RUNTIME-READY-V1`、`WAPC1 审批配置准备`、`WAPC2 请假/补卡只读 POC`、`WAPC2F 自动生成 POC 样件`、`WAPC2FLIVE live 创建与 WAPC2 自动复跑`、`WCBK1 回调只读 POC（真实事件已确认）`、`WEGOV1 企微主办治理与自建留存路线修正`、`WACP3/WACP3R 补偿拉取 POC`、`WREAD1 审批可读性与误审批防护门禁`、`WADM1 自建留存/镜像数据模型设计`、`WARCH1 最小自建历史留存实现`、`WARCH2 正式只读历史查询`、`WROAD2+OPS 受控上线与每日巡检`、`WARCH3 归档稳定化`、`WCHECK1 打卡摘要留存`、`WEXT1 外出/加班延期决策`、`wecom_attendance_approval_mirror_v1`（承接旧口径 `wecom_native_approval_mirror_v1`）、`oa_hr_emergency_mode_v1`、`wecom_recovery_writeback_v1` 和 `wecom_ruleops_v1` 分阶段拆 Issue CSV。
### 1.5 DBWFOC 数据边界修正
- 企业微信成熟功能可以作为产品流程、字段、交互和规则参考；参考不等于把业务数据托管到企业微信。
- HR/考勤员工日常审批第一阶段仅限请假、补卡、外出、加班和相关假期余额/考勤解释。
- 采购、费用、合同、项目、报销、付款批次、AP、代账交接和审计继续 OA 主办；审批动作、附件查看、下载、导出和审计仍以 OA 服务端权限为准。
- 采购单附件、合同正文、供应商报价、项目敏感资料、发票原件、银行回单、付款资料和代账资料不上传到企业微信原生审批或企业微信附件。
- OA 主办审批仍可通过企业微信个人应用消息提醒；消息只包含脱敏摘要和 OA deeplink，点击后通过企业微信免登录或账号绑定回到 OA 目标审批页处理。
### 1.6 WFDG 设计规约门禁
WFDG 将 DBWFOC 后的产品方向固化为开发前设计门禁。本节只代表规约冻结，不代表企微 HR/考勤镜像、OA 应急接管、恢复回写或 RuleOps 已实现运行时迁移。
| 业务域 | 主事实源 / 操作端 | OA 职责 | 企微职责 | 附件和审计边界 |
| --- | --- | --- | --- | --- |
| HR 主数据 | 企业微信通讯录 / 人事助手 | 同步员工镜像、账号、角色、绑定、审计和管理员修复 | 员工、部门、主管、职位、手机号、邮箱和在职状态维护 | 同步失败记录 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG` 或可重试失败，不打印完整手机号、Secret、token 或原始 payload |
| 考勤与 HR 日常审批 | 企业微信打卡 / 原生审批 | 镜像请假、补卡、外出、加班、打卡、规则、假期余额和审计；企微故障时人工接管 | 日常提交、审批、打卡采集、规则和风控 | OA 应急单带 `EMERGENCY`；恢复后先 dry-run，再回写；冲突进入人工确认 |
| 报销、采购、合同、项目、付款、AP、代账 | OA | 主办提交、审批、附件、导出、付款批次、审计和代账资料 | 只发送脱敏消息和 OA deeplink | 采购单附件、合同正文、报价、供应商资料、发票、银行回单和代账资料不进入企微原生审批或企微附件 |
| RuleOps | OA + 企业微信 API | AI 草拟、差异报告、dry-run、人工确认、审计和回滚建议 | 接收经确认的审批模板、打卡规则、排班、假期余额或人事字段配置写入 | AI 不得直接改正式规则；每次写入保存前后快照、确认人、API `errcode` 和失败原因 |
`WECOM-CAPABILITY-POC-V1` / WCPC 已按 `CAN_REUSE_NOW`、`NEEDS_CONFIG`、`NEEDS_API_POC`、`KEEP_OA_PRIMARY`、`NOT_SUPPORTED_BY_API` 输出人事助手、通讯录、打卡、审批、假期余额、回调和权限配置能力矩阵，并达到 HR 主数据镜像准入。WHMS/WHMSLIVE 已完成 HR 主数据镜像实现和受控公网验证；WAPI 已固定 API/Secret 口径并复跑 WOUA；WRRA 后明确 `PASS_WITH_FINDINGS` 不能直接放行深度镜像；WOUA-FIX 已将 7 个缺企微测试账号软归档并复检 `oaActiveMissingInWecom=0`，企微缺字段先接受不补；WMSG1 已证明真实企微应用消息和 Deeplink 可用；WAPC1 已固化审批配置准备清单；WAPC2 已提供请假/补卡只读 POC runner；WAPC2FLIVE 已创建 OA-POC 样件并自动复跑通过；WCBK1 已完成真实回调 URL 验证和审批状态事件确认；WACP3R 已自动发现 OA-POC 请假/补卡模板并证明补偿拉取和详情读取可用；WPROC1/WPROC2 已固定自动化优先、非自审、高风险 POC 前置和 process gate；WEGOV1 固定企微主办 + OA 自建留存路线；WARCH1/WARCH2 已完成请假/补卡最小留存和正式只读查询。生产写接口必须单独批准。正式开发顺序为 `wecom_hr_master_sync_v1` -> `runtime_first_wecom_enablement` -> `WOUA-FIX / WECOM-RUNTIME-READY-V1` -> `WAPC1 审批配置准备` -> `WAPC2 请假/补卡只读 POC` -> `WAPC2F 自动生成 POC 样件` -> `WAPC2FLIVE live 创建与 WAPC2 自动复跑` -> `WCBK1 回调只读 POC（真实事件已确认）` -> `WEGOV1 企微主办治理与自建留存路线修正` -> `WACP3/WACP3R 补偿拉取 POC` -> `WREAD1 审批可读性与误审批防护门禁` -> `WADM1 自建留存/镜像数据模型设计` -> `WARCH1 最小自建历史留存实现` -> `WARCH2 正式只读历史查询` -> `WROAD2+OPS 受控上线与每日巡检` -> `WARCH3 归档稳定化` -> `WCHECK1 打卡摘要留存` -> `WEXT1 外出/加班延期决策` -> `wecom_attendance_approval_mirror_v1`（承接旧口径 `wecom_native_approval_mirror_v1`）-> `oa_hr_emergency_mode_v1` -> `wecom_recovery_writeback_v1` -> `wecom_ruleops_v1`。
### 1.7 WDRG 开发路线图门禁
WDRG 将 WFDG 后的设计门禁转化为开发节奏门禁。本节只代表路线图和治理节奏冻结，不代表任何运行时同步、镜像、应急接管、恢复回写或 RuleOps 能力已完成。
| 阶段 | 目标 | 退出门禁 |
| --- | --- | --- |
| `WECOM-CAPABILITY-POC-V1` | 只读或低风险探测人事助手、通讯录、打卡、审批、假期余额、回调和权限配置 | 输出 `CAN_REUSE_NOW`、`NEEDS_CONFIG`、`NEEDS_API_POC`、`KEEP_OA_PRIMARY`、`NOT_SUPPORTED_BY_API` 能力矩阵 |
| `wecom_hr_master_sync_v1` | 企微/人事助手员工、部门、主管、职位、联系方式和在职状态镜像到 OA | OA 可自动创建/更新员工档案、账号、角色、企微绑定和审计 |
| `runtime_first_wecom_enablement` | 优先利用入口、免登/绑定、脱敏消息、deeplink、通讯录 userid 清单、人事助手读取、打卡读取和只读对账 | API/Secret 口径固定，WOUA 差异已分类并有处理决策 |
| `WOUA-FIX / WECOM-RUNTIME-READY-V1` | 收口 OA/企微用户一致性差异和运行优先准入 | 区分真实员工、测试账号、待补企微字段、待清理绑定和 WHMS 批量窗口决策 |
| `WAPC2FLIVE -> WCBK1 -> WACP3/WACP3R -> WREAD1 -> WADM1 -> WARCH1 -> WARCH2` | 先用请假/补卡低风险样例证明审批详情、回调、补偿拉取、可读性、自建留存和只读查询 | 已完成请假/补卡最小链路；仍不代表完整镜像、外出/加班、应急接管或恢复回写 |
| `WROAD2+OPS -> WARCH3 -> WCHECK1 -> WEXT1` | 先测试账号受控上线和每日巡检，再做归档稳定化、打卡摘要留存和外出/加班延期决策 | 3 天巡检报告和归档/打卡摘要边界明确后，再评估完整镜像 |
| `wecom_attendance_approval_mirror_v1` | 企微打卡、请假、补卡、外出、加班、假期余额和审批历史镜像到 OA | WARCH3、WCHECK1 和外出/加班决策完成后再拆；OA 可查询企微 HR/考勤镜像、考勤解释和审计 |
| `oa_hr_emergency_mode_v1` | 企业微信不可用时管理员人工开启 OA HR/考勤应急接管 | 应急单据带 `EMERGENCY` 标记，开启/关闭均有原因、范围、责任人和审计 |
| `wecom_recovery_writeback_v1` | 企微恢复后，OA 应急数据先 dry-run，再回写企微 | 生成成功、失败、跳过和冲突清单，不静默覆盖企微正式记录 |
| `wecom_ruleops_v1` | AI 草拟规则、生成差异报告和 dry-run，人工确认后写入企微 | 保存前后快照、确认人、API `errcode`、失败原因、回滚建议和审计 |
阶段未满足退出条件前不得跳阶段。采购、费用、合同、项目、报销、付款、AP、代账交接和高敏附件继续 OA 主办，不混入企微 HR/考勤开发路线。路线图事实源为 [企微优先开发路线图](./企微优先开发路线图.md)。
### 1.8 WCP1 企业微信能力 POC 结果
WCP1 已按“Live 只读 + 测试员工优先”完成企业微信能力 POC。本节只代表能力分类和后续准入判断，不代表 HR 主数据镜像、考勤/审批镜像、OA 应急接管、恢复回写或 RuleOps 已实现。
| 能力域 | POC 状态 | 当前结论 |
| --- | --- | --- |
| 工作台和基础权限 | `CAN_REUSE_NOW` | 工作台应用 access token 可获取，核心 CorpID/Agent/Secret/OAuth 配置存在。 |
| 通讯录 | `CAN_REUSE_NOW` | HCLT 已证明 `HRWDTEST-20260517214548` create/update/disable 成功，部门读取可用；WCPC 对既有在职测试号的成员读取已通过。 |
| 人事助手 | `CAN_REUSE_NOW_FOR_READ` | 字段配置读取可用；WCPC 对既有在职测试号的花名册读取已通过；资料更新属于写接口，需后续单独批准 POC。 |
| 打卡 | `CAN_REUSE_NOW_FOR_READ` | WCPC 短窗口打卡记录和规则读取已通过；日报、月报、排班等细分能力留到考勤镜像合同继续验证。 |
| 审批与假期余额 | `PARTIAL_NEEDS_CONFIG` | 假期余额读取已通过；WAPC2FLIVE 已生成请假/补卡 OA-POC 模板和低风险测试审批单并复跑只读 POC 通过；真实回调、补偿拉取、镜像数据模型、外出/加班样例或处理决策仍需后续考勤/审批镜像前补齐。 |
| OA 主办高敏审批 | `KEEP_OA_PRIMARY` | 报销、采购、合同、项目、付款、AP 和代账继续 OA 主办，企微只做脱敏消息和 OA deeplink。 |
WCP1 历史结论为 `PAUSE_FOR_CONFIG`，不是 `GO_TO_HR_MASTER_SYNC`；该阻断已由 WCPC 复跑收口。WCP1 报告继续作为初始配置缺口证据保留，当前 HR 主数据镜像准入以 WCPC 结论为准。
### 1.9 WCPC 配置收口
WCPC 是 WCP1 后的配置复跑合同，只处理企业微信后台配置和只读 POC 复跑，不开发运行时功能。2026-05-18 已按用户要求自动查找并使用既有在职低风险测试号 `SMOKE002/测试员工` 复跑，报告只记录脱敏企业微信 userid 前缀 `oa_smoke***`；远端报告 `/tmp/wecom-capability-poc-wcpc-smoke002/summary.json` 的结论为 `GO_TO_HR_MASTER_SYNC`，`nextStageAllowed=true`，`blockingCapabilities=[]`。WHMS 已承接该结论并完成 `wecom_hr_master_sync_v1` 本地实现、部署和受控公网验证；审批模板 ID、审批单号 `sp_no`、真实回调配置、补偿拉取、镜像数据模型和 HR 写接口仍需后续独立合同处理，不得直接跳到考勤/审批镜像、OA 应急接管、恢复回写或 RuleOps。
### 1.10 WHMS 企微 HR 主数据镜像
WHMS 将企业微信通讯录/人事助手作为 HR 主数据源的读取能力落成 OA 镜像能力。本阶段不做考勤/审批镜像、审批回调、恢复回写、RuleOps、HR 写企微接口、采购/合同/财务迁移。
本地实现后的产品能力：
- `wecom_hr_master_sync_v1` 默认 `force_off`；WAPI 后读取口径修正为通讯录读取使用 `WECOM_CONTACT_SECRET` 和 `POST /cgi-bin/user/list_id`，人事助手/花名册读取使用 `WECOM_AGENT_SECRET` 和 `POST /cgi-bin/hr/get_staff_info`，不再靠运行时 Secret fallback 试错。
- 管理员可在 People/人员管理页查看“企微 HR 主数据镜像”卡片，执行 dry-run 预检、确认 apply、查看最近批次和失败摘要；普通员工不可见。
- dry-run 只生成差异报告和同步记录，不写 OA 员工主数据；apply 写入员工档案、部门映射、默认 `employee` 角色、企业微信绑定、主管关系和审计。
- 新员工创建必须具备姓名、手机号、邮箱和部门；缺字段记录 `SKIP missing_required_field`，不生成占位数据。
- 企微不在职状态记录 `needs_offboarding_confirmation`，不自动禁用 OA 账号；离职仍走 OA checklist。
- 已有 OA 员工只更新姓名、部门、职位、直属主管、手机号、邮箱和企微绑定，不覆盖银行账户、身份证、工资、合同附件或历史审批。
当前状态为已部署并完成受控公网验证：`WHMSLIVE` 已将 WHMS 部署到 `https://oa.hyinda.com`，远端应用 migration `20260518184319_wecom_hr_master_sync_v1`；验证窗口临时 `force_on` 后对 `SMOKE002/测试员工`（脱敏 `oa_smoke***`）执行 dry-run 和显式 userids apply，企微读取链路通过，因企微侧缺手机号、邮箱和部门按 `missing_required_field` 跳过，未写 OA 主数据；普通员工访问同步 API 返回 403；最终 `wecom_hr_master_sync_v1=force_off`。尚未对真实员工执行生产批量 apply。WOUA-FIX 后复检为 OA active 5、企微 active 5、匹配 5、OA active 缺企微 0；剩余 5 个企微缺字段按用户决策先不补，1 个归档测试绑定保留审计。WACP3R 已证明请假/补卡补偿拉取和详情读取可用；WARCH1 已补齐最小回调事件、补偿拉取和对账 finding 入库能力。`wecom_attendance_approval_mirror_v1` 仍暂缓到 WARCH1 验收、正式查询/权限边界、外出/加班样例和打卡细项明确后再另建合同。
---
## 2. 软件开发项目流程
后续所有非微小改动按标准软件开发流程推进。流程目标不是增加仪式感，而是保证每轮都有清晰需求、可执行方案、可验证结果、可回滚边界和可追溯记录。WDRG 后，企微优先 HR/考勤路线必须先经过路线图门禁，再进入 POC 和单功能 Issue CSV，避免散点式开发。
| 阶段 | 目标 | 输入 | 输出 | 门禁 |
| --- | --- | --- | --- | --- |
| 1. 需求收集与边界确认 | 明确为什么做、谁使用、解决什么流程问题 | 用户反馈、试运行问题、业务制度、当前 PRD 和模块规约 | 需求描述、目标角色、主流程、必须做、暂不做、验收口径 | 需求不清不得进入开发；高风险歧义必须先澄清 |
| 2. 需求文档冻结 | 形成产品、开发、测试共同事实源 | 主 PRD、模块规约、产品口径文档、历史 Issue | 更新后的 PRD 或模块规约 | 没有事实源更新，不拆开发 Issue |
| 3. Issue CSV 执行合同拆分 | 把需求拆成可独立验收的任务 | 已确认需求文档 | `issues/YYYY-MM-DD_HH-mm-ss-<slug>.csv` | CSV 必须校验通过；每个 Issue 写清范围、验收、测试、依赖 |
| 4. 技术方案设计 | 明确怎么实现和怎么回滚 | Issue CSV、现有代码、数据模型、接口和权限规则 | 实现方案、接口/数据变更说明、风险和回滚策略 | 涉及权限、状态机、迁移、审批规则时必须写回滚策略 |
| 5. 开发实现 | 按 Issue 实现后端、前端、脚本或文档 | 已批准方案和 Issue CSV | 代码或文档变更、必要测试用例、变更说明 | 不顺手改无关问题；跨端任务先稳定后端契约再接前端 |
| 6. 代码审查与自查 | 发现行为回归、权限泄漏、状态非法跳转和漏测 | 完整 diff、Issue CSV、测试结果 | Review 意见、修复记录或确认无阻断问题 | 涉及权限模型、workflow、数据迁移、审批规则时必须重点审查 |
| 7. 测试与回归 | 证明单点和业务链路都可用 | 变更内容、Test_Method、回归脚本、手工验收步骤 | 命令结果、业务流程验证结果、失败项和修复记录 | 后端、前端、PC、移动、企业微信入口按影响范围验证；不能假通过 |
| 8. 部署与发布准备 | 确认环境、配置、资源和回滚路径可用 | 已验证变更、部署脚本、配置清单、回滚策略 | 部署记录、`/ready` 检查、资源版本、配置复核 | 未部署不得告知用户可去公网或企业微信真机测试 |
| 9. 业务验收 | 让目标角色按真实路径确认结果 | 已部署环境、验收账号、样例数据、验收清单 | 验收结论、遗留问题、是否进入试运行 | 用户或指定验收人未确认前，不把体验问题视为关闭 |
| 10. 复盘与下一轮规划 | 把反馈转成下一轮可执行任务 | 验收反馈、线上问题、回归缺口、试运行记录 | 新需求、缺陷清单、下一轮 Issue CSV 草案 | 不直接把反馈插入开发；先回到需求和 Issue CSV |
### 2.1 本项目执行约束
详细测试、视觉验证、SKIP、状态回填和回归门禁以 [测试规约与回归门禁](./测试规约与回归门禁.md) 为准；Issue 生命周期、review、commit、工作区和交付输出以 [开发交付与变更管理规约](./开发交付与变更管理规约.md) 为准。
- 所有非微小改动必须先有需求事实源和 Issue CSV 执行合同。
- 开发前必须说明实现方案；需求或方案不清时先澄清，不靠代码试错。
- `Dev_Status`、`Review1_Status`、`Regression_Status` 只能在对应验证通过后更新为 `DONE`。
- 后端变更至少执行 Prisma 校验、语法检查和相关业务回归；前端变更至少执行 typecheck、build，并按影响范围补 Playwright 或人工视觉验证。
- 涉及 PC、手机、企业微信入口的改动，必须验证入口、布局、deeplink 和移动端体验。
- 涉及生产、公网、企业微信真机或真实 OCR 的结论，必须以部署后 live smoke 为准；未配置真实条件时必须明确 `SKIP` 和原因。
- 提交应按清晰主题小批次完成，commit message 使用中文并引用 Issue ID。
### 2.2 REQ8 当前需求状态表
| 分类 | 当前口径 |
| --- | --- |
| 当前已实现 / 已收口 | R6 小范围试运行主链路；PC6/PA6/FL6/AP6/RI6/LP6；ME6 自动化、公网和代表性真机门禁；MIF7/MIF7T 移动信息架构与真机反馈整改；MIF7TD 公网部署、匿名复检和带凭据 live smoke/OCR。 |
| R7 必需 | 用户确认参与人、角色、时间窗口、回滚联系人、问题登记负责人和每日收口节奏；R7E 公网健康、public bundle、带凭据 live readiness、公网移动矩阵、核心业务流和账号角色只读门禁通过；阻断问题为 0。 |
| R7 后优化 | UX8 真实反馈池、iPhone 12 间距观察项、详情字段扫读性二次优化、移动采购创建能力评估、组织账号主数据治理、图片 OCR 能力、转审扩展和邮件通道完整验收。 |
| 明确不做 / 当前冻结 | ERP 未来不接入 OA；真实支付、图片 OCR、银行流水导入、完整差旅、复杂 BPM、审批设计器、预算重型控制继续不进入当前路线；AI 只允许草拟规则和 dry-run，人工确认后才能写入企微配置。企业微信原生审批从整体冻结调整为 HR/考勤员工日常审批优先复用，采购、费用、合同、项目、财务和报销仍由 OA 主办。 |
### 2.3 P2T 候选优先级
P2T 只做排序和边界确认，不进入当前实现。候选项按 R7 真实反馈和上线风险再拆新 Issue：
| 优先级 | 候选 | 当前边界 |
| --- | --- | --- |
| P2-1 | 企微 HR 主数据与 OA 镜像治理 | WFOC 后改为企微/人事助手为员工主数据源，OA 同步员工档案、账号、角色、绑定和审计；HCLT 仍作为 OA 写企微能力证据，后续方向是先企微后 OA |
| P2-2 | 审批与通知扩展 | 转审扩展到请假/采购/差旅拆 `W2F`；邮件通道和三渠道完整验收另决策；不引入复杂 BPM |
| P2-3 | OCR 与票据增强 | 当前试运行继续 PDF-only；图片 OCR、批量样票和异步体验需另补样票、隐私处理和 provider 回归 |
| P2-4 | 费用/预算/项目轻量增强 | 可评估费用提示和项目关联增强；预算重型控制和正式成本核算继续冻结，ERP 不再作为后续接入项 |
| P2-5 | 运维上线增强 | 备份恢复演练、SLO 门禁和正式上线准备需单独窗口；不在 R7E 预检中做真实恢复 |
ERP 已从“冻结待办”调整为“未来不接入 OA”。其他冻结项不是永久删除，而是当前 MVP/R7 不启动：AI 自动处理、完整差旅、复杂 BPM、审批设计器、预算重型控制。企业微信原生审批不再整体冻结，HR/考勤员工日常审批按 WFOC/DBWFOC 口径优先复用。
---
## 3. 用户角色与典型场景
| 角色 | 主要目标 | 高频动作 | 关键要求 |
| --- | --- | --- | --- |
| 老板/总经理 | 看清公司待办、费用、项目风险和审批瓶颈 | 审批大额事项、看项目和费用摘要、处理关键待办 | 少打扰、信息集中、审批记录可信 |
| 管理员/HR | 维护人员、入口、制度、请假和基础行政 | 员工管理、请假/补卡审核、公告、入离职、权限配置 | 配置清晰、可回退、有审计 |
| 部门主管/项目负责人 | 管团队交付和日常审批 | 审批报销/请假/采购、查看团队状态、跟进项目事项 | 待办清楚、移动端可处理 |
| 普通员工 | 快速提交申请和查状态 | 报销、上传发票、请假、补卡、外出、加班、采购申请、周报 | 手机好用、字段少、失败提示明确 |
| 财务 | 管报销、发票、付款和导出 | 发票查重、OCR 修正、付款标记、财务导出 | 数据完整、附件可追溯、重复票据可控 |
| 系统管理员 | 保障系统可用和可维护 | 部署、备份、恢复、日志、功能开关、企业微信配置 | 不泄露密钥、可定位问题、可回滚 |
---
## 4. MVP 模块优先级
| 优先级 | 模块 | 目标 | 主入口 | 验收口径 |
| --- | --- | --- | --- | --- |
| P0 | 统一审批和镜像中心 | 财务、报销、采购、合同等 OA 主办审批继续在 OA；HR/考勤员工日常审批改为企微主办、OA 镜像 | PC 审批待办、移动审批、企微审批镜像 | OA 主办审批可处理；企微主办审批可同步、查询、审计和应急接管 |
| P0 | 企业微信基础设施 | 手机入口、免登、通知、打卡、人事助手、HR/考勤员工日常审批主操作端 | 企业微信自建应用 `海音达工作台`、企微打卡、企微审批、人事助手 | 员工优先在企微完成成熟流程，OA 获得按域镜像和审计 |
| P0 | 人事生命周期 | 企微/人事助手主源，OA 同步员工、账号、权限、绑定和离职停用 | 企业微信人事/通讯录、OA 人员管理 | 先企微后 OA；OA 可审计、可接管、可在恢复后回写 |
| P0 | 报销/发票/OCR | 员工自助报销，财务可查重和导出 | 报销、移动报销、票据中心 | 上传、OCR、查重、绑定、审批、付款闭环 |
| P0 | 请假与考勤镜像/接管 | 请假、补卡、外出、加班优先企微审批，OA 同步按域镜像并保留应急提交 | 企业微信审批、OA 考勤镜像、OA 应急模式 | 企微正常时员工走企微；企微不可用时管理员人工开启 OA 接管 |
| P1 | 采购/费用审批 | 小团队采购和费用事项留痕 | 采购、审批待办 | 申请、附件、审批、状态更新可用 |
| P1 | 合同与附件归档 | 管合同编号、责任人、归档位置和非涉密附件 | 合同/项目资料或项目页 | 能登记、查询、关联项目和审批记录 |
| P1 | 项目轻管理 | 把费用、采购、差旅、周报挂到项目 | 项目、Portal、周报 | 能看项目事项、风险、费用摘要，不做重型排产 |
| P2 | 预算/支付/AI | 在试运行稳定后按真实反馈增强运营能力 | 管理员备用入口 | 另立 Issue CSV，不进入首批验收；ERP 不进入路线 |
---
## 5. 统一审批中心需求
本章保留总纲口径。审批中心的角色、入口、状态、动作、权限、异常、留痕、审批规则配置矩阵、权限数据范围和验收细节，以 [需求 - 统一审批中心规约](./需求-统一审批中心规约.md) 作为后续开发拆分依据。
### 5.1 范围
WFOC/DBWFOC 后审批分为两类：OA 主办审批和企微主办审批。OA 主办审批仍在 OA 内提交、审批、留痕、归档；企微主办审批仅限 HR/考勤员工日常审批第一阶段，在企业微信内发起和处理，OA 同步按域镜像、附件、审批历史、回调和审计，并在企微不可用时人工接管。
- 报销、费用、采购。
- 合同相关审批和合同台账维护。
- 资产领用、归还、调拨、盘点中的需要留痕动作。
- 后续新增财务、采购、合同、项目类业务审批，默认进入 OA 审批中心。
请假、补卡、外出、加班等 HR/考勤员工日常审批优先复用企业微信原生审批，OA 不再重复开发成熟员工日常流程；旧 OA 提交能力只作为 `oa_hr_emergency_mode_v1` 应急入口保留。采购、费用、合同、项目和财务类 OA 主办审批不进入企业微信原生审批，企业微信只做脱敏提醒和回 OA 处理入口。
### 5.2 审批能力
- 支持草稿、提交、审批中、通过、驳回、退回、撤回、转审、完成等状态语义。
- 审批链优先采用串行多节点；当前阶段不做并行会签。
- 大额或高风险单据通过审批规则配置多级审批，不通过硬编码角色分叉。
- 当前审批人只能处理分配给自己的待办，或者处理分配给自己角色且权限匹配的待办。
- 转审必须记录原因，转给具备对应审批权限的人，并保留转审历史。
- 单据编号由 OA 生成和保存；报销单、采购单、合同编号等应使用统一编号规则或对应业务编号规则。
### 5.3 数据与留痕
- 所有审批动作写入工作流历史。
- 关键例外动作写入审计日志，包括重复发票例外、付款标记、权限变更、附件下载、通知重试。
- 企业微信消息只包含脱敏标题、业务编号、状态和 deeplink，不包含涉密正文、完整发票、合同正文或敏感报价。
### 5.4 验收
- 审批人可在 PC 和移动端看到待办。
- 审批动作完成后，业务单据状态、审批历史、通知和审计记录一致。
- OA 主办审批的企业微信提醒点击后回到 OA 页面处理；企微主办审批由企业微信处理，OA 同步结果和审计镜像。
---
## 6. 报销、发票、OCR、附件与财务导出
本章保留总纲口径。报销、发票、OCR、附件、查重、财务复核、付款、导出、费用类型矩阵、人工验真和验收数据集，以 [需求 - 报销发票 OCR 规约](./需求-报销发票OCR规约.md) 作为后续开发拆分依据；历史细则继续参考 [报销与发票规则](./报销发票附件规则.md)。
### 6.1 用户流程
1. 员工在 PC 或手机端创建报销草稿。
2. 当前试运行上传 PDF 发票进入 OCR；图片可作为普通附件材料，图片 OCR 属后续能力。
3. 系统执行 OCR，识别发票代码、号码、金额、日期、销方、购方等关键字段。
4. 员工确认或修正识别结果，补充费用明细和说明。
5. 系统做发票查重和基础校验。
6. 员工提交报销，进入 OA 审批流。
7. 审批通过后，财务复核并标记付款。
8. 财务按期间、状态、项目、人员导出报销和发票数据。
### 6.2 发票与附件管理
- 发票和附件原始文件以 OA/对象存储为主，不依赖企业微信长期保存。
- 同一发票不得被重复报销；如确需例外，必须由授权财务角色填写原单号和原因。
- OCR 失败时允许重试和人工修正，但必须保留失败原因和修正痕迹。
- 报销完成后，相关发票进入已使用或归档状态，不能被普通员工再次绑定到新单据。
- 普通员工只看到“添加发票、上传附件、提交审批、查看状态”等业务语言，不暴露内部发票池概念。
### 6.3 财务导出
- 财务可按报销状态、付款状态、员工、部门、项目、期间筛选导出。
- 导出数据应包含业务编号、申请人、实际报销人、金额、费用类型、发票摘要、审批状态和付款状态。
- 导出不得包含未授权敏感字段明文。
### 6.4 验收
- 手机上上传 PDF 发票后，能完成 OCR、查重、绑定、提交。
- 报销审批通过后，财务能付款标记并导出。
- 重复发票、OCR 失败、附件缺失、金额不一致等异常有明确提示。
---
## 7. 请假、补卡、外出、加班与考勤口径
本章保留总纲口径。请假、补卡、外出、加班的角色、字段、状态、审批规则、团队状态、日历和考勤解释细节，以 [需求 - 请假考勤修正规约](./需求-请假考勤修正规约.md) 作为后续开发拆分依据。
### 7.1 边界
- 企业微信打卡用于原始采集和规则执行，保留其定位、人脸、Wi-Fi、排班、设备和防作弊能力。
- OA 不重造企业微信打卡规则、定位、人脸识别、排班或防作弊引擎。
- 请假、补卡、外出、加班等考勤修正申请优先在企业微信原生审批中提交和处理。
- OA 先通过 WARCH1/WARCH2 保存并查询请假/补卡已归档历史，再通过 WROAD2+OPS 做测试账号受控巡检；后续 `WCHECK1` 先保存打卡日/月摘要、异常摘要和规则快照。完整 `wecom_attendance_approval_mirror_v1` 需等 WARCH3、WCHECK1 和外出/加班决策完成后再拆。
- 企业微信不可用时，管理员可人工开启 `oa_hr_emergency_mode_v1`，临时开放 OA 提交和审批；应急单据带 `EMERGENCY` 标记并进入恢复回写队列。
### 7.2 用户流程
- 员工正常在企业微信提交请假、补卡；外出和加班当前业务路线先延期，需真实业务需要或用户批准后再做低风险 POC。
- 主管或 HR 正常在企业微信审批；OA 先保存请假/补卡审批详情、审批历史、状态回调和对账 finding，后续再扩展外出/加班和打卡摘要。
- 审批通过后，OA 使用企微审批和打卡数据更新团队状态、日历和考勤镜像。
- 企微故障时，管理员人工开启 OA 应急模式；企微恢复后，OA 通过 `wecom_recovery_writeback_v1` dry-run 后自动回写，冲突进入人工确认。
### 7.3 验收
- 请假提交、审批、撤回、驳回后状态正确。
- 已批准请假能影响团队状态或日历展示。
- 企微正常时员工优先在企业微信提交请假、补卡；OA 展示已归档历史和应急入口状态。外出/加班不作为当前受控上线阻断。
### 7.4 当前完成度校正
REQAUD 复核后，ATTV1 已按“企业微信打卡、OA 审批解释”口径进入实现，本章当前完成度按以下口径读取：
| 项目 | 当前状态 | 说明 |
| --- | --- | --- |
| 请假申请、审批、撤回、编辑和移动查看 | `DONE` | 已有 `leave_requests`、统一审批、PC/移动页面和回归证据。 |
| 请假影响团队状态/日历 | `DONE` | 已批准请假可进入团队状态和日历展示。 |
| 企业微信入口、免登/绑定、通知和 HR/考勤审批 | `REPLANNED_BY_WFOC` | 企业微信继续作为入口、身份和提醒；HR/考勤员工日常审批优先在企微处理，OA 同步镜像；OA 主办审批仍回 OA。 |
| 企业微信打卡运营使用 | `DONE` | 员工继续按公司要求在企业微信打卡；这是企业微信侧能力，不代表 OA 已同步打卡 API。 |
| 企业微信打卡 API 同步到 OA | `PARTIAL` | 已新增 `attendance_unified_v1` 同步批次和打卡摘要表；有已授权调用打卡 API 的自建应用 Secret/API 权限时可同步，缺配置时按 `SKIP` 记录，不伪造通过。`WECOM_CHECKIN_SECRET` 显式优先，未配置时复用已授权工作台应用的 `WECOM_AGENT_SECRET`。 |
| 员工补卡申请审批 | `DONE` | 已新增 OA 考勤修正申请，补卡只解释企微缺卡，不向企业微信写回。 |
| 外出申请审批 | `DONE` | 已新增外出修正申请和 OA 审批，用于月度考勤解释；不重造企微定位风控。 |
| 加班申请审批 | `DONE` | 已新增加班修正申请和 OA 审批，记录加班事实和补偿口径。 |
| 历史 OA 极简打卡 `attendance_v1` | `FROZEN_CLOSED` | OA 自建上下班打卡、管理员补卡和自建月度统计已从正式入口关闭；旧 API 保留但返回 409，历史表不删除。 |
---
## 8. 采购、费用、合同与项目资料
本章保留 P1 总纲口径。采购/费用、合同归档、项目轻管理的字段、状态、权限、异常、验收场景和后续开发拆分建议，分别以 [需求 - 采购费用审批规约](./需求-采购费用审批规约.md)、[需求 - 合同附件归档规约](./需求-合同附件归档规约.md)、[需求 - 项目轻管理规约](./需求-项目轻管理规约.md) 作为后续开发依据；审批动作、状态机、权限和留痕仍以 [需求 - 统一审批中心规约](./需求-统一审批中心规约.md) 为总依据。
### 8.1 采购和费用审批
- 员工可提交采购或费用申请，填写用途、金额、项目、供应商、附件和期望时间。
- 主管、财务或老板按规则审批。
- 审批通过后形成可追溯记录，可关联预算、项目、付款和合同资料。
- 首批优先支持轻量申请和审批，不做复杂招采流程。
### 8.2 合同与附件归档
- 合同管理首批以台账为主：合同编号、名称、客户或供应商、项目、金额、负责人、状态、归档位置。
- 非涉密附件可进入 OA；涉密合同正文、敏感报价、成本细节和客户敏感资料不得进入公网 OA。
- 合同编号应由 OA 统一生成或由管理员登记后校验唯一性。
- 合同相关审批和变更记录应回到 OA 留痕。
### 8.3 项目轻管理
- 项目页只做轻量管理：成员、里程碑、任务、风险、交付记录、费用/采购/差旅关联。
- 不做重型甘特图、资源排产、CRM 或完整项目组合管理。
- 员工的报销、采购、差旅、周报和待办应尽量关联项目，减少另建表格。
### 8.4 验收
- 采购申请可提交、审批和查看状态。
- 合同台账能记录编号、责任人、归档位置和项目关联。
- 项目视图能汇总关键事项，不要求替代专业项目管理工具。
---
## 9. 企业微信基础设施需求
本章保留总纲口径。企业微信入口、免登/绑定、通讯录身份、消息通知、deeplink 和打卡原始采集边界，以 [需求 - 企业微信基础设施规约](./需求-企业微信基础设施规约.md) 作为后续开发拆分依据。
### 9.1 自建应用
- 公司只维护一个企业微信自建应用，建议命名为 `海音达工作台`。
- 手机端默认入口进入 `/mobile`。
- PC 浏览器和普通账号密码登录默认进入 `/portal`。
- 企业微信入口失败时必须保留账号密码登录回退路径。
### 9.2 免登与绑定
- 支持企业微信 OAuth 或免登后识别员工身份。
- 首次未绑定时，员工可使用账号密码登录后在个人设置中完成绑定。
- 一个企业微信身份不得绑定多个员工。
- 员工离职或账号停用后，企业微信入口也不得继续进入业务系统。
### 9.3 消息通知
- OA 主办审批的企业微信消息只做提醒，审批动作回到 OA 页面完成；企微主办 HR/考勤审批在企业微信内处理，OA 同步镜像。
- 消息内容最小化：标题、业务编号、状态、处理入口。
- 发送失败应可重试，不阻断主业务提交或审批。
- 不在消息中发送合同正文、完整发票、敏感报价、银行卡、身份证等敏感内容。
### 9.4 打卡原始采集
- 企业微信打卡数据、打卡规则、日报和月报是 OA 考勤镜像的原始来源。
- `attendance_unified_v1` 当前只同步打卡摘要、批次、脱敏错误码和 raw hash；WFOC/DBWFOC 后续目标是扩展为打卡规则、排班、记录、日报、月报和异常摘要按域镜像。
- 正式考勤统计必须结合企微请假/补卡/外出/加班审批、OA 应急单和恢复回写结果。
---
## 10. 权限、审计、数据安全与非功能要求
### 10.1 权限原则
- 后端是权限单一事实源；前端按钮显隐不等于授权。
- 普通员工只能看和处理自己的单据。
- 审批人只能处理分配给自己的待办或自己角色范围内的待办。
- 财务可处理发票、付款和导出，但不默认拥有系统管理权限。
- HR/管理员可维护人员、组织和基础配置，但敏感操作必须审计。
- 老板/总经理可查看公司级摘要和处理关键审批，但仍应保留操作留痕。
### 10.2 审计要求
以下动作必须可追溯：
- 登录、退出、绑定、解绑、账号停用。
- 单据提交、审批、驳回、退回、撤回、转审。
- 发票上传、OCR 重试、人工修正、重复例外、附件下载。
- 付款标记、财务导出、合同归档、权限变更。
- 企业微信通知发送失败、重试和配置异常。
### 10.3 数据安全
- 密码、密钥、令牌不得写入文档、日志或前端包。
- 银行卡、身份证、手机号等敏感字段对外响应应脱敏。
- 附件下载应有鉴权和有效期控制。
- 涉密合同正文、详细报价、成本细节、敏感客户资料不进入公网 OA。
- 生产环境必须有数据库和文件存储备份，并定期做恢复演练。
### 10.4 非功能要求
- PC 和移动端都应覆盖高频流程。
- 10 人以下团队的常用列表和表单应保持快速响应。
- 关键错误需要给出可操作提示，例如未绑定、权限不足、审批人缺失、OCR 失败、重复发票。
- 部署后必须能通过 `/ready` 检查服务状态。
- 新功能应有可复现测试步骤，无法自动化时写清人工验收步骤。
---
## 11. 暂不做范围
首批 MVP 不做以下事项：
- 不接入飞书，不保留飞书登录、通知、审批、文档或项目管理路线。
- 不把企业微信原生审批用于报销、财务付款、采购、合同、项目等 OA 主办流程；HR/考勤员工日常审批按 WFOC/DBWFOC 口径优先复用企微。
- 不开发复杂 BPM 流程设计器，不做并行会签建模。
- 不依赖付费低代码平台、付费第三方应用或付费项目管理套件。
- 不重造企业微信打卡的定位、人脸识别、Wi-Fi、排班规则。
- 不做完整 CRM、ERP、PLM、甘特排产或项目组合管理。
- 不把聊天记录、会议纪要、涉密合同正文或敏感报价长期保存在 OA。
---
## 12. MVP 验收标准
### 12.1 产品验收
- 老板能在 OA 中看到审批待办、项目/费用摘要和关键风险。
- 员工能在 OA 完成报销、采购等 OA 主办申请，并在企业微信完成请假、补卡、外出、加班等 HR/考勤申请。
- 审批人能在 OA 处理 OA 主办待办，并在企业微信处理 HR/考勤原生审批；OA 能同步镜像。
- 财务能完成发票查重、付款标记和导出。
- 管理员能维护人员、权限、企业微信入口和基础配置。
- 企业微信作为 HR/考勤员工日常审批主操作端，OA 作为按域镜像和应急接管；不得产生无法对账的双轨审批。
### 12.2 流程验收
| 场景 | 验收步骤 |
| --- | --- |
| 报销主流程 | 上传发票 -> OCR -> 绑定明细 -> 提交 -> 审批 -> 付款 -> 导出 |
| 重复发票 | 上传已使用发票 -> 系统阻断 -> 财务授权例外需原因和原单号 |
| 请假流程 | 员工提交请假 -> 主管审批 -> 团队状态或日历更新 |
| 采购流程 | 员工提交采购 -> 审批通过或驳回 -> 状态和附件可追溯 |
| 企业微信入口 | 手机企业微信进入 `/mobile` -> 账号已绑定则直达，未绑定可回退账号密码 |
| 企业微信通知 | 收到审批提醒 -> 点击 deeplink -> 回到 OA 审批页处理 |
| 文档门禁 | 新需求先更新 PRD 或规则文档，再拆 Issue CSV，不直接开发 |
### 12.3 工程验收
- Issue CSV 校验通过。
- 文档 diff 检查通过。
- 涉及后端时执行 Prisma、语法和相关回归脚本。
- 涉及前端时执行 typecheck、build 和相关 Playwright。
- 涉及公网或企业微信真机时，必须部署后检查 `/ready`、前端资源和真实入口。
- 测试和提交证据必须符合 [测试规约与回归门禁](./测试规约与回归门禁.md) 与 [开发交付与变更管理规约](./开发交付与变更管理规约.md)。
---
## 13. 后续 Backlog
后续事项必须另立 Issue CSV，不直接进入当前 MVP：
- 企业微信打卡 live 同步验证和真实考勤数据口径稳定化。
- 补卡、外出、加班的真实使用反馈体验优化。
- 合同台账、合同编号、合同审批和离线档案号的细化。
- 预算控制和付款/AP 运营真实使用反馈优化；ERP 不再规划出站凭证或实时集成。
- 项目轻管理与周报、待办、费用、采购、差旅的进一步联动。
- 全量 E2E 稳定性清理和移动视觉回归。
- 生产备份恢复演练、并发试运行和正式上线复核。
---
## 14. 文档维护规则
- 本文件回答“要做什么、为什么做、先做什么、不做什么、如何验收”。
- `docs/产品口径.md` 记录已经拍板的产品口径。
- `docs/历史功能状态矩阵.md` 记录已经实现了什么和证据在哪里。
- `issues/*.csv` 是每轮开发执行合同。
- 需求变化必须先更新本文件或对应规则文档，再创建新的 Issue CSV。
- 不批量回改旧 Issue CSV 来伪造一致性；历史计划保留为历史快照。
在新工单中引用 查看 Git Blame 复制永久链接