WF8-2 固化跨业务转审扩展设计

docs/需求-统一审批中心规约.md

@@ -1,7 +1,7 @@
 # 需求 - 统一审批中心规约
 
-**版本**：1.2
-**日期**：2026-05-11
+**版本**：1.3
+**日期**：2026-05-13
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 
@@ -235,7 +235,62 @@
 - 转审不能绕过规则定义的必经老板/总经理、财务或 HR/行政节点；需要例外时必须另走明确改派或规则调整流程并留痕。
 - 若老板/总经理本人提交的单据触发老板/总经理节点，默认阻断或进入明确配置的非本人兜底审批人；本规约不开放自审例外。
 
-REQ8 当前状态：跨业务转审仍是产品目标，但当前 R7 不以扩展到请假、采购或差旅为硬门禁。后续 `W2F` 实现必须单独建 Issue，评审权限模型、状态机、转审次数、通知、历史留痕和回滚策略，并启用 reviewer。
+### 6.2 WF8 转审扩展设计
+
+WF8 阶段只做轻量转审扩展，不进入复杂 BPM、审批设计器、并行会签或自由流程编排。转审的定义是“当前待办任务处理人变更”，不是业务单据申请人变更，也不是审批规则永久改写。
+
+成熟 BPM 和任务中心通常把流程定义、候选处理人和当前任务分配分开管理。WF8 沿用这一思路：规则仍决定必经节点，转审只在当前节点内调整 `assignee_id`，并通过历史和通知留痕。
+
+适用范围：
+
+- 首批覆盖报销、请假、采购三类已接入统一审批中心的待办。
+- 合同、差旅、资产等后续业务沿用同一原则，但必须另走对应连续 Issue 验收。
+- 企业微信只做通知和 deeplink 回 OA，不在企业微信原生审批中完成转审。
+
+发起人规则：
+
+- 只有当前 pending 待办的实际可处理人可以发起转审；有效委托场景下，实际处理人必须写入委托相关 payload。
+- `admin` 单角色不能代替业务审批人发起转审。
+- 已处理、已撤回、已取消、已完成或孤立待办不得转审。
+
+接收人规则：
+
+- 接收人必须是 active 员工。
+- 接收人必须具备当前业务类型对应的审批权限：报销使用 `expense.approve`，请假使用 `leave.approve`，采购使用 `procurement.approve`。
+- 接收人不能是申请人、实际报销人、提交人或当前动作人本人。
+- 仅具备 `admin` 的系统管理员不能作为业务转审接收人。
+- 不得通过转审绕过老板/总经理、财务、HR/行政等规则定义的必经节点。
+
+状态和历史规则：
+
+- 转审保持同一个 workflow instance、同一个 workflow task 和同一个当前审批节点，只更新当前任务处理人。
+- 转审不改变报销、请假、采购的业务状态，不触发财务付款、预算占用确认、ERP 同步、考勤生效或附件归档。
+- 每次转审必须写 `workflow_history`，至少包含原处理人、目标处理人、原因、转审次数和委托上下文。
+- 报销既有 `approval_transfers` 可作为兼容审计表继续保留；请假和采购首批以 `workflow_history` 为事实源，后续如需结构化转审表必须另写迁移方案。
+- 转审成功后通知目标审批人；通知失败不回滚主业务，但必须可追溯。
+
+并发和重复规则：
+
+- 同一任务最多转审 3 次，超过后阻断并提示选择管理员处理或规则修正。
+- 服务端必须在事务内锁定当前任务，防止两个窗口同时转审、审批或退回导致重复结果。
+- 转审不得新建并行待办，不得留下原审批人可继续处理的 pending 任务。
+- 转审后原审批人再次打开旧页面时，应看到任务已变化或无权处理提示。
+
+三类业务副作用边界：
+
+| 业务 | 转审允许影响 | 不允许影响 |
+| --- | --- | --- |
+| 报销 | 当前审批人、审批历史、通知目标 | 发票绑定、附件、财务付款状态、重复票据例外、OCR 状态 |
+| 请假 | 当前审批人、审批历史、通知目标 | 请假天数、余额预占、团队状态、考勤生效结果 |
+| 采购 | 当前审批人、审批历史、通知目标 | 采购明细、附件、预算预检结果、ERP 同步、PO/合同归档 |
+
+回滚和修正路径：
+
+- 转审目标选错但任务仍 pending 时，由当前合法处理人再次转审回正确处理人，并填写修正原因。
+- 目标人停用、离职或权限被回收时，不直接改数据库；由管理员按 ORG8 账号与权限治理流程确认后，通过受审计的改派或规则修正路径处理。
+- 若代码实现引入回归，优先回滚 WF8 代码补丁并复跑 `server/scripts/regression-workflow-actions.sh`；已产生的历史记录不删除，只追加修正说明。
+
+WF8-3、WF8-4、WF8-5 实现前必须基于本设计给技术方案；实现后必须运行转审单测、相关业务流回归，并启用 workflow reviewer 检查状态机、权限、通知和漏测项。
 
 ---
 

issues/2026-05-13_18-23-52-wf8-approval-notification.csv

@@ -1,7 +1,7 @@
 ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
 WF8-0,WF8 连续合同建档,"建立审批与通知增强连续型合同，把转审、通知、催办、邮件通道决策、三渠道验收和审批历史一致性放入同一 CSV。","1) 本 CSV 校验通过；2) 文档索引和状态矩阵指向本合同；3) 不进入复杂 BPM 或审批设计器；4) 不改业务代码；5) 执行前确认 ORG8 角色边界。","流程级验证：python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-13_18-23-52-wf8-approval-notification.csv；rg -n 'WF8|审批|通知' docs/文档索引.md docs/文档事实源状态矩阵.md issues/README.md。",python3|rg|manual,DONE,DONE,DONE,issues/2026-05-13_18-23-52-wf8-approval-notification.csv|docs/文档索引.md|docs/文档事实源状态矩阵.md|issues/README.md,[],CSV validator 和索引 rg 均通过；本次仅合同建档和入口登记，未改业务代码，执行前仍需 ORG8 角色边界和方案批准。
 WF8-1,审批通知需求规约更新,"复核统一审批中心规约，把转审、通知失败、催办、deeplink 和邮件通道决策写清楚或确认已覆盖。","1) 审批和通知边界清楚；2) 不引入复杂 BPM；3) 企业微信审批动作回 OA；4) 邮件是否验收有决策。","流程级验证：rg -n '转审|通知|催办|邮件|deeplink|复杂 BPM|审批设计器' docs/需求-统一审批中心规约.md docs/需求-企业微信基础设施规约.md。",rg|manual,DONE,DONE,DONE,docs/需求-统一审批中心规约.md|docs/需求-企业微信基础设施规约.md,"[""WF8-0""]",统一审批中心规约已覆盖转审、通知失败、催办、deeplink、复杂 BPM 和审批设计器冻结；已补 WF8 邮件通道决策；未改 workflow 代码。
-WF8-2,转审扩展设计,"设计请假、采购和报销的转审扩展规则，明确权限、状态、历史和通知影响。","1) 转审发起人和接收人规则清楚；2) 原审批人和新审批人历史可追溯；3) 不造成重复审批；4) 回滚路径明确。","流程级验证：人工审查状态流；rg -n '转审|delegat|reassign|审批历史|workflow' docs/需求-统一审批中心规约.md server/src。",rg|manual,TODO,TODO,TODO,docs/需求-统一审批中心规约.md|server/src,"[""WF8-1""]",涉及 workflow 状态机必须 reviewer。
+WF8-2,转审扩展设计,"设计请假、采购和报销的转审扩展规则，明确权限、状态、历史和通知影响。","1) 转审发起人和接收人规则清楚；2) 原审批人和新审批人历史可追溯；3) 不造成重复审批；4) 回滚路径明确。","流程级验证：人工审查状态流；rg -n '转审|delegat|reassign|审批历史|workflow' docs/需求-统一审批中心规约.md server/src。",rg|manual,DONE,DONE,DONE,docs/需求-统一审批中心规约.md|server/src,"[""WF8-1""]",已将 docs/需求-统一审批中心规约.md 更新到 1.3 并新增 WF8 转审扩展设计，明确发起人、接收人、状态历史、并发重复、请假采购报销副作用和回滚路径；rg Test_Method 通过；node --check src/routes/workflow.js 通过；npm test -- tests/unit/routes/workflow.transfer.test.js 通过 7 tests。
 WF8-3,请假转审,"实现或补强请假审批转审，保证请假流程和团队状态一致。","1) 请假待办可合法转审；2) 被转审人可审批；3) 历史记录完整；4) 团队状态不被错误更新。","流程级验证：员工提交请假 -> 审批人转审 -> 新审批人通过或驳回 -> 检查请假状态和审批历史。",node|bash|manual,TODO,TODO,TODO,server/src|client/src|server/scripts,"[""WF8-2""]",不扩展考勤 API。
 WF8-4,采购转审,"实现或补强采购审批转审，保证采购状态、附件和审批历史一致。","1) 采购待办可合法转审；2) 附件和状态不丢失；3) 重复转审有防护；4) 历史可追溯。","流程级验证：员工提交采购 -> 审批人转审 -> 新审批人处理 -> 检查采购状态和历史。",node|bash|manual,TODO,TODO,TODO,server/src|client/src|server/scripts,"[""WF8-2""]",不引入复杂预算和供应商准入。
 WF8-5,报销转审复核,"复核既有报销转审能力，补齐权限、历史或通知缺口。","1) 报销转审符合权限；2) 发票和附件不受影响；3) 财务状态不被非法改变；4) 通知到正确处理人。","流程级验证：员工提交报销 -> 审批人转审 -> 新审批人审批 -> 财务查看台账 -> 检查历史和通知。",node|bash|manual,TODO,TODO,TODO,server/src|client/src|server/scripts,"[""WF8-2""]",不得改变付款状态机。