审批工作流

审批工作流门控敏感的创建、更新与删除操作。Norbital 使用 准备、门控、提交、结算 生命周期：写入契约先准备拟议的图，审批门再选择直接提交，或临时提交并将其挂起，一份 审批请求 跟踪审查。图创建或更新的每一行都是真实的行，带有 `approval_id` 标记，并由一条 `hold` 修订保存其前像。批准会封存写入并清除标记；拒绝会把每一条被触及的行恢复到其挂起快照。

审批配置位于授权上

审批配置在策略内的 `mutate.new`、`mutate.existing` 或 `delete` 授权上设置——一个 approval 项，其 `flow` 返回 `approveBy(…).thenBy(…)` 或 `noApproval`，另有 `superceded_by`。参见策略。

请求生命周期

  gated mutation
        │
        ▼
  write commits provisionally + hold recorded + request created
        │
        ├── approved ────────► change stands, stamps cleared
        ├── rejected ────────► request closed; every touched row restored
        ├── request changes ─► request closed; every touched row restored
        │
        ├── supersede ───────► approved, as though the superseding
        │                      team had decided every remaining step
        └── withdraw ────────► requestor withdraws; every touched row restored

状态

审查分阶段进行——一个阶段一个团队，同阶段内为备选——请求跟随其状态流转：

ONGOING
APPROVED
REJECTED
CHANGES_REQUESTED
CONFLICTED
WITHDRAWN

报告所筛选的请求状态词汇：

ONGOING
APPROVED
REJECTED ——挂起涉及的每一行都恢复为快照并清除标记
CHANGES_REQUESTED
CONFLICTED
WITHDRAWN ——请求人撤回请求；涉及的每一行同样被恢复

决策

审批人用 APPROVED REJECTED REQUEST_FOR_CHANGE SUPERSEDED 决策——批准、拒绝、请求变更或超级取代——只有未决请求可以被决策。`supersede` 需要原因；已批准但图不再适用的请求会被标记为冲突。

锁

被路由的写入在开启请求的同一事务中临时提交；每个新建或更新的行都已存在并带请求 id 标记：

挂起的创建与更新 ——行已存在并携带拟议值与标记（ approval_id ）之后
挂起的删除 ——行被移除，其前像保留为挂起修订（ approval_id ）

审查正在决定的精确集合记录在请求的 approval_id 的历史修订；一条记录的恢复点用 api.collection_history.<name>.at(id, { before: requestId }) 读取。

超级取代与修订

分阶段审查 ——同一阶段的团队互为备选，阶段按顺序执行；编写 approveBy('Team').thenBy('Other Team') 会在当前阶段之上追加下一阶段。
超级取代团队 ——审批可以点名 superceded_by ：这些团队可以直接完成所有剩余步骤。管理员始终可以 supersede。
冲突 ——无法应用的恢复（未挂起的行此时指向恢复必须删除的行）会保留挂起标记，并把请求标记为 CONFLICTED ，而不是静默提交。

批准与拒绝时

批准会执行恢复 ——清除标记、发布变更、触发 `committed` 通知并关闭请求。拒绝会记录决定，并把每一条被触及的行恢复到其挂起快照：在挂起下诞生的行被删除，其余行被改写，并追加一条 `restore` 修订。

删除审批以同样的方式工作

受审批门控的删除会先移除该行并把快照保留在挂起中；拒绝时会把该行重新插入。

何时使用审批

超过阈值的财务变更
有合规影响的记录变更
敏感主数据的编辑
应当明确分离请求人与审批人角色的变更