决议语义、在途干预与审计红线
前面几页搭好了骨架，这页进入真实业务的复杂场景。一条贯穿始终的暗线是：流程有两个层面——其一是配置时的静态定义（链路、会签、路由、超时）；其二是跑起来之后对在途实例的动态干预（退回、撤回、加签、转交）。我们先把决议动作辨清，再看在途怎么改，最后碰那条最容易出事的红线：审完之后还能不能改？
1 · reject 还是 return?——终止 vs 回退
「不同意」有两种完全不同的语义，混淆它们是审批系统最常见的设计错误：reject 是终止（单据落 rejected 终态，流程结束，要重来得开新一轮）;return 是回退（把单据退回某一步，流程没结束，改完继续走）。下面这张单已经过了主管李雷、正卡在部门总监韩梅手里。你来替韩梅做决议，对比每个动作的后果：
这几个动作里，除了 approve，全是「在途干预」。 退回、转交、撤回——都是在流程已经跑起来之后、动手改这张在途实例的走向。它们和「配置时定义好的链路」是两个层面的事。还有两个常见的在途动作没在按钮里，但同理：加签（运行时往链里插一个审批人，前加签 / 后加签）、减签（去掉一个）。
撤回 (withdraw) 是有条件的。 不是发起人想撤就能撤：常见规则是「只有还没人开始审 / 只到第一级」才能撤；一旦像上面这样已经有人审过，撤回就要更高权限、或转成「作废」并保留已有记录。撤回后改了重提，走的是同一张单的新版本 (revision)，旧版本痕迹留着——不是凭空一张新单。
抄送 / 知会 (CC)。 流程图右侧那个蓝色「财务存档」节点是抄送：它需要知道这件事，但不参与决议——不会卡流程，也没有通过 / 驳回。审批人和抄送人是两种不同角色，别混为一谈。
2 · 行级审批：一张单，n 条子项
前面单据都是「整单一个结果」。但报销单常有多条明细，审批人想逐条批/拒——审批粒度从「单」下沉到「行」。这带出部分批准 (partial approval)：整单结果不再二元，而要把 n 条子项的决议聚合 (roll-up) 回单据状态。勾选若干条，试试批量驳回:
批量是 UI 便利，不是审计便利。「批量驳回 3 条」在记录层面必须拆成 3 条独立留痕（各自的子项、决议、comment）——不能图省事记成一条「批量拒了 3 项」。否则事后审计追不到单条明细的依据。另外注意 roll-up 规则要显式定义：有一条被拒，整单算
partial 还是 rejected？被拒的子项是退回只重走那几条、还是整单重审？都得想清楚。
3 · 审完之后，还能改吗？——审计红线
一个真实问题：一张单已经审完归档 (approved)，这时更高级别的领导说「把主管李雷那一步的意见文案改一下」。这该怎么办？答案取决于要改的是哪个东西，但两种情况的正解是同一句：不原地改，而是版本化 + 追加留痕。
另一种「改节点文案」：改的是流程模板的配置（节点名 / 说明），不是这张单的记录。 那是流程定义 vs 实例 + 版本化的问题：已经跑完或在途的实例，应当绑定它发起时的模板版本快照，改模板只影响未来发起的新单。否则历史会「穿越」——当年审批的人看到的根本不是你现在改的那段文字。这条**「在途实例不随模板迁移」**，是流程版本化里最容易被忽略、出事最狠的一条。
4 · 小结：一张表收束全系列
| 动作 | 层面 | 对单据状态的影响 | 审计 |
|---|---|---|---|
| approve / reject | 决议 | 推进 / 落 rejected 终态 | 记审批人 + 决议 |
| return 退回 | 在途干预 | 回退到某步，不终止 | 记退回目标 + 理由 |
| delegate 转交 / 委托 | 在途干预 | 换处理人，active 不变 | 记「X 代/转交 Y」 |
| withdraw 撤回 | 在途干预（有条件） | 落 withdrawn，改完开新 revision | 记撤回人 + 时机 |
| 加签 / 减签 | 在途干预 | 运行时增删节点 | 记谁加了谁 |
| timeout | 静态定义 → 触发 | 系统代为推进 | 记 system，注明超时 |
| reopen / amend / override | 审完后修正 | 开新轮 / 追加，不覆写 | append，旧记录保留 |