# Bucket C — 多审批人/多节点/多审批模式 L2 验证

**优先级**：P1
**估时**：1.5 天
**状态**：🚧 部分完成（D4 闭环 OK，多审批人场景待下个 PR）

## 背景

矩阵中以下项 **实现 ✓ 但 L2 测试 ❌**：流程设计器和审批引擎都支持，业务设计意图很多，但目前只跑过单人单节点 OR-sign。真实业务里多节点 + 条件 + 多人审批是高频场景。

## batch1 已完成项（2026-05-03）

- ✅ **D4 撤回闭环 E2E**：本 worktree 起独立 Temporal（4033，host network）后跑通 submit → workflow 启动 → withdraw signal → DB 状态 WITHDRAWN 全链路。证据：`/api/v1/form-management/instances/{id}/submit` → `Started workflow approval-FORM_INSTANCE-...` → `Sent signal withdraw to workflow ...` → 前端实例显示"已撤回"。
- ✅ **挂起流程 admin UI**：含 Admin Approve/Reject/Reassign/Force Terminate 4 按钮，双语全覆盖（修了 6 处遗漏的硬编码 zh）
- ✅ **OR-sign 单节点**：之前已验证（baseline）

## 仍未跑的多审批人场景（下个 PR）

阻塞已解除（Temporal 起来了），但多审批人 L2 验证需要造测试数据：5 个测试用户（发起人/M1/M2/财务经理/CC）+ 角色 + 组织架构 + 4 套流程定义（CC / 条件分支 / 并行 / 会签 / 序列签）。这套数据基础设施是独立工作，建议作为下个 PR 的核心。

## 范围

### 1. 多节点流程
- [ ] **#52 CC 节点**：发起人提交后某节点自动 CC 另一用户，CC 用户列表里能看到
- [ ] **#53 条件分支**：造一个"金额 > 1000 走双审批 / 否则走单审批"的流程
- [ ] **#54 并行分支**：两个审批人并行审批，两人都通过才进下一节点

### 2. 审批模式
- [ ] **#55 会签 Countersign**：3 人审批节点，所有人通过才进下一步；任一人驳回即终止
- [ ] **#57 Sequential（序列签）**：3 人按顺序审批，前一人通过后下一人才看到任务
- [ ] **#56 OR-sign（或签）** 已验证 ✓（基线确认）

### 3. 审批人源
- [ ] **#59 By Role**：审批人按"财务经理"角色解析
- [ ] **#60 Department Manager**：审批人 = 发起人部门主管
- [ ] **#61 Initiator's Manager**：审批人 = 发起人直属主管
- [ ] **#62 Manager Chain**：审批人链 = 发起人→主管→主管的主管，按层级走
- [ ] **#63 Department Contact**：（P2，可选）

### 4. 版本审批驳回路径
- [ ] **#66 版本审批驳回**：表单定义版本审核流程中**驳回**路径（当前只跑过 Approve）

### 5. 多用户场景准备
需要造测试用户 + 角色 + 组织架构：
- 发起人（P1）
- 部门主管（M1，P1 的直属主管）
- 二级主管（M2，M1 的主管）
- 财务经理（FM，按角色匹配）
- 抄送对象（CC）

## 实施方式

L2 MCP 测试为主，可能在过程中发现的问题：
- 流程定义解析 bug
- 审批人源解析时机问题
- 节点跳转条件判断 bug

发现的 bug 在本 PR 内修复（小 bug）或登记到 I-bucket（大 bug）。

## 交付物

- L2 双语回归报告
- 矩阵 testing 列升 ✅
- 测试用户 + 流程定义 seed（可选：作为 db:seed 一部分）

## 完成条件

- 上述清单跑过有证据
- 删除本文件