审批工作流

审批工作流门控敏感的创建、更新与删除操作。Norbital 使用 先写后锁 模型：变更立即生效，受影响的记录被锁定，一份 审批请求 跟踪审查。批准后变更直接成立并清除锁；拒绝则记录保持——锁定着、保留变更写入的值——工作区自己的活性谓词（`approval_id is null`）在修订之前把它们挡在视野外。

审批配置位于授权上

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

请求生命周期

  gated mutation
        │
        ▼
  write applies + records locked + approval request created
        │
        ├── approved ────────► change stands, locks cleared
        ├── rejected ────────► request settled; row stays locked
        │                      until a revision replaces it
        ├── request changes ─► still active, locks stay
        │
        └── supersede ───────► approved, as though the superseding
                               team had decided every remaining step
        └── withdraw ────────► requestor withdraws, request settled

状态

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

ONGOING
APPROVED
REJECTED
CHANGES_REQUESTED
CONFLICTED
WITHDRAWN

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

ONGOING
APPROVED
REJECTED ——请求人也可以撤回未决请求
CHANGES_REQUESTED
CONFLICTED
WITHDRAWN

决策

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

锁

为防止请求有效期间的冲突编辑，被变更触及的记录以请求 id 保持锁定：

记录写入 ——已写入的行及图中每一行都挂在请求 id（ approval_id ）之后
待删除 ——删除同样是一行；它被同样方式锁定（ approval_id ）

审查正在决定的精确集合记录在请求的 locked_record_refs 中——审查持有的每条记录，根行与关联行都是。

超级取代与修订

分阶段审查 ——同一阶段的团队互为备选，阶段按顺序执行；编写 approveBy('Team').thenBy('Other Team') 会在当前阶段之上追加下一阶段。
超级取代团队 ——审批可以点名 superceded_by ：这些团队可以直接完成所有剩余步骤。配置允许时，管理员始终持有该能力。
冲突 ——批准会重跑钩子并把重建的图与已审图比对；图变化时标记为 CONFLICTED ，而不是静默提交。

批准与拒绝时

因为变更已经生效，批准 不执行任何操作 ——系统清除锁并了结请求：变更成立。明白了结请求并记录决策；行保持锁定，随后的修订将其替换。

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

受审批门控的删除带着请求 id 生效，并保持锁定直到审查结束。

何时使用审批

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