审批流无法在「运行中」动态确定审批人——审批人在提交时即被 $trigger 快照锁定（动态路由 / 动态会签受阻）

[baozhoutao]

一句话说明

审批流一旦提交，后续各节点的审批人就只能来自提交那一刻的记录快照（$trigger）。流程跑起来之后，无论是「前一个审批人决定下一批审批人」，还是用节点重新算出来的审批人，都喂不进后面的审批节点。这类「运行中动态确定审批人」的能力目前缺失。

核心问题

审批人的解析被绑死在提交时的不可变快照上，缺一条「在节点进入时、按当前实时状态确定审批人」的路径。于是所有动态审批路由（上一步决定下一步审批人 / 动态会签 / 临时指定协办部门 / 依据流程中产生的数据分派）都无法用声明式方式表达。

具体表现（目前已确认的两个口子）

1. {type: 'field'} 审批人只读 $trigger 快照（主证据，已真机确认）：审批人来源为记录字段时，value 锚定 $trigger（schema xRef.objectSource='$trigger'），提交后再改该字段读不到。
2. 审批人无法引用流变量：get_record 能在流程中把实时记录读进流变量，但审批人的 value 只能绑 $trigger、不能指向该变量，所以「先重查再据此定审批人」这条路也走不通。

补充：平台已有的 Reassign（转派）是逐条请求的手动动态改派，能救急；但缺的是声明式、自动的「节点进入时按实时状态定审批人」。

场景（业务视角）

不合格品审批：① 质检部部长审批 → ② 部长在这一步选择要并行会审的几个部门 → ③ 被选部门并行会签 → ④ 工厂长终审。第 ② 步部长选的部门展开成审批人写进记录字段，③ 用该字段当审批人——但 ③ 读的是 ① 提交时的旧快照，读不到部长中途填的人。

对照实验（16.1.0 真机）

审批人（记录字段）何时确定	后续并行节点解析到的审批人
提交之前就定好	✅ 正确（多选用户字段能 fan-out 成多个会审人）
提交之后、流程中途定	❌ 空（读的是 $trigger 提交快照）

顺带确认：多选用户字段 → 多个并行审批人的 fan-out 本身是支持的，问题只在「中途确定读不到」。

期望

支持在节点进入时按实时状态确定审批人。可选实现（由易到通用）：

1. 节点进入时对 field 型审批人按记录 id 重查实时值（最小改动，直接解决主场景）；
2. 允许审批人 value 引用流变量（get_record 刷新后喂给节点），覆盖「先重查再定人」；
3. 提供计算型 / 动态审批人来源（如 type: 'expression' 或节点级 resolver 钩子），一次性覆盖任意「按流程中数据分派」的动态路由。

倾向 #1 保底、#2/#3 作为更通用的演进。

最小复现

1. 对象加多选用户字段 approvers_dynamic（初始空）；
2. 流：节点A（固定审批人，如 type: 'position'）→ 节点B（{type: 'field', value: 'approvers_dynamic'}，behavior: 'unanimous'）；
3. 提交进 A → 审批 A 期间往 approvers_dynamic 写 2 个用户 → 通过 A；
4. 看 B 的 sys_approval_request.pending_approvers：空（期望那 2 人）；
5. 对照：提交前写好 approvers_dynamic → B 正确解析出 2 人。

环境

• @objectstack/spec 16.1.0，运行时 16.x；ApprovalsServicePlugin；流类型 record_change；审批人 {type: 'field'}

[os-zhuang]

代码核实与 P1 实施计划

深入代码核实后，issue 定性成立，但机制归因需一处修正——这反而降低了修复成本。

根因修正：不是「提交时锁定」，而是「数据源冻结」

审批人解析时机已经是 per-node lazy（每个审批节点进入时才解析），并非提交时一次性展开整条链。证据链：approval-node.ts:83 execute → openNodeRequest → expandApprovers（approval-service.ts:389）。

真正的根因是求值数据源被冻结：节点从 variables.get('$record') 取记录（approval-node.ts:92），而 $record 是 flow 启动时注入的触发快照（engine.ts:1710）；挂起时整个变量 Map 序列化进 sys_automation_run.variables_json，恢复时原样反序列化（engine.ts:2005）——全程无任何 DB 重读。{type:'field'} 就是对这份冻结对象做内存索引 record[a.value]（approval-service.ts:445）。

好消息：解析时机的架构已经就位，P1 只需在解析漏斗点把冻结对象换成一次实时重读。

铁证：快照绑定是实现遗留，不是设计

同一审批节点里，team/department/position 型审批人走图数据库实时查询（审批期间组织架构变了会跟着变），而 field/manager 型读冻结快照。同一功能两套时间语义并存 → 快照绑定是遗漏，而非有意设计。

顺带发现三个隐藏缺陷（建议一并修）

1. 多选 fan-out 靠巧合工作：String(['u1','u2']) 恰好产出 'u1,u2'，与 pending_approvers 的 CSV 存储格式偶然兼容，代码里并无显式数组处理。
2. OOO 委派在多选下静默失效：applyOooDelegation('u1,u2') 把整串当单个 userId 查委派规则。
3. 空集 fallback 假 id：解析为空时 fallback 成 type:value 字面量（approval-service.ts:469），靠 Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 admin rescue 兜底——正是最小复现里空/假审批人的来源，语义隐晦。

主流引擎对照

无一主流引擎把审批人锁在提交快照上：BPMN 2.0 规范要求任务实例化时求值 resourceAssignmentExpression；Camunda / Flowable「上一 UserTask 写变量 → 下一 task 引用」是教程级模式；Salesforce related-user-field 审批人进入步骤时读记录当前值；钉钉 / 飞书表单成员控件读当前表单值并支持「上一审批人指定下一步」。本 issue 要的是行业底线能力，非新奇特性。

P1 实施（本次 PR）

• 在 openNodeRequest / expandApprovers 一侧，按 recordId 用 system 身份重读实时记录后再解析（审批路由是平台职责，与 fix(trigger-record-change): 让 record-change 流程种子记录携带公式(formula)字段 (#3426) #3445 formula 回读、notify node templates can't resolve formula/lookup fields — renders blank silently #3426 lookup 方向 A 同精神）。
• 顺修 field 分支显式数组 / CSV 化，OOO 委派逐人应用。
• 记录已删 → 节点显式失败走 error 分支，不静默。
• 不加 snapshot/live 开关（主流引擎均无，避免 config 分叉债）；changeset 走 minor。
• 行为变化仅影响「提交后中途改字段」场景——该场景现产出空/假审批人本就是坏的，故为纯修复。

P2（type:'expression' 审批人 + 节点级空集策略）/ P3（resolver 代码钩子）另行跟进。