@objectstack/plugin-approvals 16.1.0 → 17.0.0-rc.0

package/CHANGELOG.md

@@ -1,5 +1,1028 @@
 # @objectstack/plugin-approvals
 
+## 17.0.0-rc.0
+
+### Minor Changes
+
+- 14252d3: feat(approvals): cross-organization approver targeting — a plant document can
+  require a group-side sign-off (ADR-0105 D9)
+
+  One organization id used to decide three different things at once in
+  `openNodeRequest`: where the request row lives, where its inbox index rows
+  live, and **where its approvers are looked up**. The first two are the
+  request's own organization by definition. The third is not — a group CFO holds
+  her `cfo` position in the GROUP organization while the purchase order she signs
+  off lives in the PLANT organization. `expandPositionUsers('cfo', <plant>)`
+  matched nobody, the slot fell back to the dead `position:cfo` literal, and a
+  group escalation could not be expressed at all.
+
+  An approver may now declare which organization's directory resolves it:
+
+  ```yaml
+  approvers:
+    - { type: position, value: plant_manager, group: plant }
+    - { type: position, value: cfo, organization: $root, group: finance }
+  behavior: per_group
+  ```
+
+  - **`$root` / `$parent`** walk D6's `parent_organization_id` tree, so the two
+    common intents need **no deployment knowledge** — flow metadata is portable
+    across environments while organization ids are minted per deployment. A slug
+    covers what the symbols cannot, notably a **sibling** organization (a
+    shared-services centre approving payables for every plant).
+  - Declared **per approver**, so one node can require a plant manager and a
+    group CFO in parallel. A node-level form cannot express that without
+    splitting into serial nodes, which changes the semantics.
+  - **Bounded, not free:** the target must share a `parent_organization_id` root
+    with the request's organization. The rule reads only the organization tree —
+    never the submitter — so one flow routes identically for everyone.
+
+  Everything else fails loudly rather than quietly:
+
+  - a non-`group` posture **refuses** the declaration (a `group` → `isolated`
+    migration must not silently reroute approvals);
+  - an approver type with no org-scoped directory (`user` / `field` / `manager` /
+    `team`) refuses it too, and a new `approval-approver-cross-org-unsupported`
+    lint catches that at author time;
+  - a targeted approver holding no membership in the request's organization is
+    dropped with a warning naming them — D2's union wall would otherwise hide the
+    request from someone already routed to, so the node's existing
+    `onEmptyApprovers` policy takes over instead of leaving an unopenable task.
+
+  Nothing changes for an approver without `organization`: same resolution, same
+  queries, no extra reads.
+
+- f92096b: fix(approvals): an approval action is recorded against the authenticated caller, never a body field (#3800)
+
+  Every mutating approvals entrypoint takes an `actorId`, and the REST routes
+  filled it from `body.actorId ?? body.actor_id ?? context.userId` — so the body
+  won. The service then authorized _that value_: `pending_approvers.includes(
+input.actorId)` for a decision, `submitter_id === actorId` for a recall. It never
+  checked that the value named the caller.
+
+  So any authenticated user could POST `{"actorId": "<someone else>"}` and have
+  that person's approval recorded, the request finalized, and the owning flow run
+  resumed down the `approve` edge — or name a request's submitter and recall it.
+  With `api.requireAuth` unset the anonymous-deny never fires either, so an
+  unauthenticated request could do the same.
+
+  #3783 drew this line for the _data-write_ identity and called the audit-row half
+  "tolerable". It was not: the same unchecked string was the authorization key, so
+  naming someone else was not a mislabelled audit row, it was how you got through
+  the door.
+
+  The actor is now resolved server-side (`ApprovalService.resolveActor`) on all
+  nine entrypoints — `decide` / `decideNode`, `recall`, `sendBack`, `resubmit`,
+  `reassign`, `remind`, `requestInfo`, `comment`.
+
+  **The rule is not "`actorId` must equal `context.userId`."** A slot can
+  legitimately be keyed by something else: the approver resolver stores the
+  `type:value` literal when a graph lookup finds no holders, and the Console picks
+  from the caller's own identity list — user id, email, or `role:<r>`. The rule is
+  **"the actor must be an identity the server can prove belongs to the caller"**:
+
+  - A **system** context keeps its explicit actor. The SLA sweep's reserved
+    `system:sla` sentinel and the ADR-0043 action link — whose single-use hashed
+    token binds exactly one approver — are unchanged. They are the only callers
+    holding a trustworthy actor with no session behind them.
+  - A caller with **no identity at all** is now refused. This is the anonymous case
+    above.
+  - **No `actorId`, or one naming the caller**, resolves to the caller. This is the
+    common path and what the Console already sends.
+  - **Any other value** is accepted only when the server can prove the caller holds
+    it — `position:<p>` / `role:<p>` against the positions on the resolved authz
+    context, or the caller's own email (one lazy `sys_user` read, taken only when
+    nothing cheaper matched). Otherwise `FORBIDDEN`.
+
+  REST still forwards the body value; it is now a _hint_ the service validates,
+  which is what keeps the email and `type:value` slot cases working.
+
+  **Upgrade note.** A client that deliberately sent another user's `actorId` now
+  gets `403 FORBIDDEN` instead of silently succeeding. Send the action as the
+  acting user's own session — the field can be omitted entirely, and the caller is
+  used. Server-to-server callers that legitimately act for someone else should
+  present a system context, as the SLA sweep and the action link already do.
+
+  This also makes two existing claims true that were previously aspirational: the
+  approval object's declared actions say "`actorId` defaults to the caller
+  server-side… the service remains the authority on who may act", and
+  `attachViewers` documents `can_act` as mirroring "the exact authorization the
+  decision methods enforce".
+
+- fb90784: fix(approvals): the status mirror names the human who caused the transition (#3783)
+
+  When an approval moves, the service writes the new status onto the business
+  record (`approvalStatusField`). That write is what fires the record-change flows
+  bound to that object — so it is the seam "when the invoice is approved, do X"
+  runs through. It presented a bare `{ isSystem: true }` context with **no
+  `userId`**, at six call sites that each know exactly who acted: a submitter
+  submitting, an approver approving, rejecting, sending back, recalling.
+
+  Combined with #3760 — which stopped letting a `runAs:'user'` run with no trigger
+  user touch data — that identity gap made the most natural approvals automation
+  there is unwritable in its obvious form. The cascade inherited no user, so its
+  data nodes were refused, and the author's only way forward was to declare
+  `runAs: 'system'` and take blanket elevation for a case where a perfectly good
+  scoped identity existed at the call site all along.
+
+  The mirror now carries the acting user. It stays `isSystem` — the record is
+  normally locked while its approval is live, so only a platform write can land the
+  status — because elevation and anonymity are separate choices, and this write
+  only ever needed the first. Cascades now run as the deciding user with RLS
+  enforced.
+
+  - **The identity is the authenticated principal, never the request body's
+    `actorId`.** `actorId` arrives from the caller (`body.actorId ?? context.userId`)
+    and is only checked against the pending approver slate, never against the
+    caller. That is tolerable on an audit row; promoting it to the identity of an
+    RLS-scoped write would have turned a mislabelled audit trail into identity
+    spoofing.
+  - **Approval-by-email-link is attributed too.** ADR-0043 action links carry no
+    session, so they used to decide as pure system. The single-use hashed token
+    binds exactly one approver and is re-checked against the live slate at
+    redemption — that is an authentication — so the redeemed decision now presents
+    that approver, and an emailed approval cascades identically to one made in the
+    UI.
+  - **The two machine-driven transitions stay user-less on purpose**: the SLA
+    escalation's auto-decision and the dead-run sweep. `system:sla` and
+    `system:dead-run` are reserved audit actors, not users, and presenting one as a
+    user would put a non-user in `updated_by` and in every downstream flow's
+    identity. A flow that wants to react to those declares `runAs:'system'` — the
+    honest answer, and now a deliberate one rather than an artefact.
+  - **Attribution only — the write is not newly org-scoped.** On an
+    ExecutionContext `tenantId` is a driver-scoping knob, not attribution
+    (ObjectQL turns it into a tenant predicate), so passing the request's org would
+    have silently no-op'd the mirror on a record whose org differs. The automation
+    engine already back-fills a run's `tenantId` from the resolved user's grants.
+
+  **Visible change:** the mirrored record's `updated_by` now names the acting user
+  instead of retaining its previous value — ObjectQL's audit stamping is gated on
+  the write context's `userId` alone, and `isSystem` buys no exemption. That is the
+  attribution this fix is for: the approver who set the record to `approved` is now
+  its last modifier.
+
+- a6c3f38: feat(approvals): expose the pending node's `lockRecord` policy on the request row (#3814, objectui#2902)
+
+  An approval node declares `lockRecord` (default `true`), and the record-lock
+  `beforeUpdate` hook enforces exactly that: `lockRecord: false` and the record
+  stays writable for the whole time the node waits. The behavior was correct and
+  has been since Phase B — but it was **invisible to every client**.
+
+  `rowFromRequest` parses `node_config_json` and projects a whitelist out of it
+  (`__flowLabel`, `__nodeLabel`, `__round`, `escalation.timeoutHours`,
+  `decisionOutputs`). `lockRecord` was never in that list, and no other field on
+  `ApprovalRequestRow` carried the lock either. So the strongest thing a console
+  could learn from `GET /approvals/requests` was _"a pending request exists"_ —
+  from which it can only assume the record is locked.
+
+  That assumption is wrong on every opted-out node, and a flow that chains nodes
+  with different policies makes it visibly wrong: the same UI state renders for
+  "you may edit this" and "the server will reject your save with `RECORD_LOCKED`".
+  The console has no third option — guessing the other way would offer an edit
+  that dies on save.
+
+  `ApprovalRequestRow` now carries **`lock_record: boolean`**, read from the same
+  snapshot the hook reads, with the same `!== false` default. Present on every
+  service read (`openNodeRequest` / `getRequest` / `listRequests`), so the flag a
+  client renders and the rule the server applies cannot drift.
+
+  Additive and backward compatible — nothing to migrate. A client that wants
+  node-accurate lock state reads `request.lock_record`; treat `undefined` (an
+  older backend) as locked, which is the pre-existing behavior.
+
+  The showcase's `showcase_budget_approval` now declares `lockRecord: false` on
+  its single-approver Manager Review and keeps `true` on the multi-approver
+  Executive Review, so both policies are exercised in one flow.
+
+- d75edb9: Approval nodes now resolve `field` / `manager` approvers against the record's **live** state at node entry, not the trigger snapshot the flow froze at submit time (#3447). An earlier step — or the approver of an earlier step — can now write the field that routes a later step's approvers, enabling dynamic routing / dynamic co-sign (e.g. a lead reviewer picking which departments co-review, then those departments resolving as parallel approvers). Graph approvers (team / position / department / tier) already resolved live; this brings the in-record types into line.
+
+  Also fixes two latent defects on the same path: a multi-select user field now fans out into one approver slot per user (previously the array was stringified to a single bogus id), and out-of-office delegation is applied per fanned-out user (previously silently skipped for multi-value fields). When the record can't be re-read (hard-deleted mid-flow, or a backend that can't serve a point read), resolution falls back to the trigger snapshot and warns rather than wedging the flow.
+
+- 57a3bb3: fix(automation,approvals): the run-resume route is gated by the node the run is parked on (#3801)
+
+  `POST /api/v1/automation/:name/runs/:runId/resume` forwarded a caller-supplied
+  `{ inputs, output, branchLabel }` straight into `AutomationEngine.resume`, and
+  `resumeInternal` validated **machine state only** — the concurrent-resume latch,
+  the run exists, the flow exists, the suspended node still exists. Nothing asked
+  _who was calling_.
+
+  Approval nodes suspend and resume through exactly that mechanism. So a resume
+  carrying `branchLabel: 'approve'` walked the approve edge with **no approver
+  check, no `sys_approval_action` row and no status mirror** — the
+  `sys_approval_request` row and the run then disagreed permanently. The only
+  thing standing between the route and the approvals rules was convention; the
+  showcase spelled it out in a comment ("decide via the approvals API, never a raw
+  engine `resume`"), and a comment in an example is not an access control.
+
+  Removing the route was not the fix: it is load-bearing for **screen flows** —
+  the UI flow-runner posts `{ inputs }` there to advance a paused `screen` node.
+  The gate therefore keys on **what the run is parked on**:
+
+  - `ActionDescriptor.resumeAuthority` (`'any'` | `'service'`, default `'any'`) —
+    a pausing node declares who may continue it. `approval` declares `'service'`.
+  - The engine refuses a `'service'` suspension unless the signal carries
+    `RESUME_AUTHORITY_SERVICE` (`@objectstack/spec/contracts`), a **symbol** the
+    owning service stamps in-process — a JSON body can never produce one, so the
+    transport cannot forge it. `ApprovalService` stamps it on the tail of a
+    decision it has already authorized and recorded.
+  - The gate follows a **subflow** pause down to the child the signal would
+    actually reach, so resuming the parent is not a way around it.
+  - Refusal returns `{ success: false, code: 'forbidden' }` and the route answers
+    **403**. Nothing is consumed — the request stays pending and the run stays
+    parked, so the real decision still lands.
+
+  `screen` and `wait` pauses are unchanged, as is every path that already went
+  through the approvals API. What changes for consumers:
+
+  - **FROM:** finishing an approval with
+    `client.automation.resume(flow, runId, { branchLabel: 'approve' })`
+    **TO:** `client.approvals.approve(requestId, …)` (or `.reject` / `.recall`).
+    The old call now answers 403 and changes nothing.
+  - Registering your own pausing node whose continuation belongs to a service
+    rather than to whoever holds the run id? Declare `resumeAuthority: 'service'`
+    on its descriptor and stamp `RESUME_AUTHORITY_SERVICE` on the signal from that
+    service.
+
+  A suspension now records the node type that produced it
+  (`SuspendedRun.nodeType` / `sys_automation_run.node_type`), captured at suspend
+  time so a flow republished mid-pause cannot re-type the node out from under the
+  gate; rows written before this fall back to the flow definition.
+
+- 2fa4ca1: Dynamic approver routing for approval nodes (#3447 P2) — three new declarative capabilities:
+
+  **`expression` approvers.** A new approver type whose CEL expression resolves WHO approves at node entry, over exactly three roots: `current.*` (the record's live state), `trigger.*` (the submit-time snapshot) and `vars.*` (flow variables, incl. upstream node outputs). `record` and bare field names are rejected before evaluation — on this platform `record` always means "the record at event time", which is ambiguous at an approval node — with error messages that prescribe the correct spelling. The optional `resolveAs: 'user' | 'department' | 'position' | 'team'` re-expands each resolved id through the same graph lookups the static types use; with `behavior: 'per_group'` each intermediate value (e.g. each returned department) forms its own sign-off group. A missing key fails the node loudly; only a present-but-empty result counts as an empty slate.
+
+  **`onEmptyApprovers` policy.** What an empty resolved slate does, node-level, for all approver types: `admin_rescue` (default — request opens for privileged takeover, the #3424 behaviour), `fail` (node fails), or `auto_approve` (skip the request, continue down the `approve` edge with `output.autoApproved = true`). To support auto-approve, the automation engine now honours `NodeExecutionResult.branchLabel` on the synchronous completion path — the field existed but was only ever consumed via resume signals.
+
+  **Decision outputs.** `decide(..., { outputs })` hands structured data from the approver to the flow: the author declares allowed keys on the node (`decisionOutputs`), approvers fill values only, and accepted outputs resume the run as `<nodeId>.<key>` variables — a later approval node's expression can read `vars.<nodeId>.picked_departments`, closing "the previous approver picks the next step's approvers" without a record-field detour. Undeclared keys reject the decision; `decision`/`requestId` are reserved. Multi-approver tallies now always pin to the open-time approver snapshot (previously unanimous re-resolved at each decision against the payload snapshot).
+
+  Also: `collectCelRootIdentifiers` is exported from `@objectstack/formula` (shared by the new `os lint` rules and the runtime pre-check, so they can never drift), resolution inputs are audited on the request snapshot as `__resolvedFrom`, and three new lint rules gate expressions, empty-slate policies and reserved output keys at author time.
+
+- 57bab76: Typed `decisionOutputs` declarations (#3447 follow-up). A `decisionOutputs` entry may now be `{ key, label?, type: 'text' | 'user' | 'department' | 'position' | 'team', multiple? }` alongside the bare-string form — a typed entry tells the decision UI to render the matching record picker (id values; `multiple` collects an id array) instead of free text, turning "paste user ids" into "pick people". The type shapes only the input widget: the runtime whitelist works by `key` either way, via the new `normalizeDecisionOutputs` helper exported from `@objectstack/spec/automation` — the single reader of the union shape shared by the service, the request read, and `os lint`. The request read now carries `decision_output_defs` (normalized declarations) alongside the version-skew-safe `decision_outputs` key list.
+
+### Patch Changes
+
+- d058594: fix(approvals): refuse `organization` on directory-less approver types instead
+  of silently ignoring it (ADR-0105 D9)
+
+  `user`, `field` and `manager` return EARLY in `resolveApproverSpec` — they name
+  a person outright rather than expanding a directory. D9's org resolution was
+  placed after those returns, so an `organization` declared on one of them never
+  reached the check: it was silently INERT.
+
+  That is the one behaviour ADR-0105 D9 rules out and the authoring docs
+  explicitly promise against ("`organization` on those is refused at runtime").
+  The `os lint` rule caught it at author time, but the runtime claim was false —
+  and a stored flow that predates the lint, or one assembled programmatically,
+  got no signal at all.
+
+  Resolution now happens at the top of `resolveApproverSpec`, above every early
+  return, so the refusal reaches all three types. The ordinary path is unchanged
+  and still costs nothing: with no `organization` declared the resolver returns
+  the request's organization without reading anything.
+
+  Found by cloud's group-posture dogfood driving a real `group` boot — the
+  resolver's own unit tests could not see it, because they call the resolver
+  directly and never traverse the early return.
+
+- 879ea13: ADR-0105 Phase 0 + Phase 1: group tenancy posture; organization scope as a
+  first-class authorization dimension.
+
+  > This release carries BREAKING spec removals (see "Enforce-or-remove" below)
+  > but is recorded as `minor`: every publishable package is in the Changesets
+  > lockstep group, so one `major` would promote the whole monorepo. Breaking
+  > changes ship as `minor` during the launch window — the migration notes below
+  > are what reach consumers in `CHANGELOG.md`.
+
+  ## Tenancy is now a spectrum (D1)
+
+  `single | group | isolated`, resolved by the `tenancy` service and selected with
+  the new `OS_TENANCY_POSTURE` env var. Existing deployments are unchanged:
+  `OS_TENANCY_POSTURE` unset derives the posture from `OS_MULTI_ORG_ENABLED`
+  (`true` ⇒ `isolated`, else `single`). An unrecognized value throws at boot
+  rather than silently landing in a posture with no organization wall.
+
+  - `single` — no wall (unchanged).
+  - `group` — **new.** Organizations are membership boundaries over one shared
+    dataset; Layer 0 becomes `organization_id IN accessible_org_ids` (union / MOAC
+    semantics). Enforced by the OPEN engine.
+  - `isolated` — today's `multi`, renamed. Behavior, enterprise `org-scoping`
+    probe and degraded-boot handling all unchanged.
+
+  ## Organization scope is a first-class context field (D2)
+
+  `ExecutionContext.accessible_org_ids` — every organization the caller holds a
+  currently-valid membership in (ADR-0091 validity windows) — is resolved once by
+  `resolveAuthzContext` and carried by every transport. The `group` wall reads it
+  directly; RLS policies may reference it as
+  `organization_id IN (current_user.accessible_org_ids)`. An empty or absent set
+  fails the wall closed.
+
+  Only the Layer 0 PREDICATE widens. Composition is untouched: the wall is still
+  computed independently of the RLS compiler, AND-composed outermost, and
+  crossable only by a true `PLATFORM_ADMIN` on a posture-permitting object — so
+  ADR-0095's W1/W2 invariants hold in every posture.
+
+  ## Two P0 correctness fixes (D3, D4) — behavior changes
+
+  **D3 — app-authored org-scoped RLS policies are no longer silently dropped**
+  (finding F1, framework#3539). `collectRLSPolicies` used to strip any policy whose
+  `using` contained the substring `current_user.organization_id` when isolation was
+  inactive, which swallowed app-authored policies as well as the platform's own.
+  Stripping is now decided by PROVENANCE (identity against the shipped
+  declaration). **Upgrade impact:** in a deployment with no organization wall, an
+  app-authored policy referencing the active organization is now RETAINED and
+  fails closed (zero rows) with a one-time warning, where it previously vanished
+  and the object read unscoped. `getReadFilter` shared the defect, so analytics and
+  raw-SQL consumers were affected too. If a policy was only ever meant for
+  multi-org, delete it or install `@objectstack/organizations`.
+
+  **D4 — `viewAllRecords`/`modifyAllRecords` never cross an organization
+  boundary** (finding F2, framework#3540). Under a wall-less posture nothing
+  bounded the wildcard superuser bits `organization_admin` carries, so a
+  deployment that accumulated organizations (personal orgs on signup) made every
+  owner/admin an environment-wide superuser. `auto-org-admin-grant` now grants a
+  de-VAMA'd `organization_admin_no_bypass` variant when no wall is enforced, and
+  revokes the superseded variant whenever the posture changes. **Upgrade impact:**
+  in `single` posture an org owner/admin keeps full CRUD but loses the blanket
+  ownership/sharing/RLS bypass. Deliberate deployment-wide visibility remains
+  available through `admin_full_access` or an explicitly authored permission set —
+  it just stops being a side effect of a better-auth membership role.
+
+  ## Engine-owned organization stamping (D5)
+
+  Under any wall-enforcing posture the engine stamps `organization_id` from the
+  caller's active organization on an insert that omits it, and validates every
+  supplied value against the wall. Idempotent with the enterprise auto-stamp
+  (neither overwrites a supplied value). This also closes a real hole: the
+  pre-existing post-image check required a non-array payload, so a BULK insert
+  could carry a forged `organization_id` per row. One forged row now denies the
+  whole write.
+
+  ## Group structure, extension fields and red-line lints (D6, D7)
+
+  - `sys_organization` gains `parent_organization_id` and `sort_order` — a
+    **reporting dimension only**.
+  - New lint `validateOrgAxisRedLines` (`org-axis-permission-inheritance`,
+    `org-axis-cross-org-bu-grant`), wired into `os lint` / `os compile` /
+    `os validate`: an RLS policy or sharing rule that walks the org tree is an
+    error, as is a business-unit grant on a platform-global object.
+  - Extension fields on better-auth-managed objects ride the existing ADR-0092
+    whitelist. A new guard derives better-auth's real field surface from
+    `getAuthTables()` at the pinned version and fails the build on any name
+    collision, so a library upgrade cannot silently take ownership of a column.
+
+  ## Enforce-or-remove (D11) — BREAKING
+
+  Both removals are of surface that had **zero runtime consumers**, so no
+  behavior changes; authoring them is now a no-op instead of a lint warning.
+
+  - **`PermissionSet.contextVariables` — REMOVED.** The RLS compiler never read
+    it. FROM → TO: a set a policy needs as `field IN (current_user.<key>)` is now
+    supplied by a registered membership resolver (below); a constant belongs in
+    the policy itself as a literal (`status = 'published'`).
+  - **`Territory` / `TerritoryModel` / `TerritoryType` (`security/territory.zod.ts`)
+    — REMOVED.** No runtime object, stack field or resolver existed. FROM → TO:
+    matrix requirements are served by multi-position × business-unit anchoring; a
+    generalized dimension-security module will arrive with its own ADR.
+  - **`ExecutionContext.rlsMembership` — PRODUCTIZED.** The bag the compiler has
+    merged since ADR-0056 finally has a producer: register an
+    `IRlsMembershipResolver` (`@objectstack/spec/contracts`) under the
+    `rls-membership-resolver` service, declaring the keys it owns. Fail-closed by
+    construction — an unresolved key makes its policies drop out. Kernel-owned
+    keys (`accessible_org_ids`, `org_user_ids`, …) are reserved and cannot be
+    overwritten from this seam.
+
+  ## Edition boundary (D12)
+
+  The `group` posture's enforcement primitives ship OPEN — the union wall,
+  `accessible_org_ids` resolution, D5 stamping/validation, the D3/D4 correctness
+  fixes and the D6 lints — because the correctness of a wall is never a paid
+  feature (cloud ADR-0016 铁律「强制免费、治理收费」). `isolated` keeps its existing
+  enterprise `org-scoping` probe, so the current commercial boundary for
+  legal-entity isolation is unchanged by this release.
+
+- 2ba560a: fix(plugin-approvals): give the decision actions a visual hierarchy (objectui#2762 P1-5)
+
+  The `sys_approval_request` decision actions all declared as equal-weight
+  buttons, so the drawer's action bar rendered five identical outlined
+  buttons with no emphasis on the primary path. `approval_approve` now
+  declares `variant: 'primary'` and `approval_reject` declares
+  `variant: 'danger'`, so a metadata-driven renderer highlights Approve and
+  styles Reject as destructive — matching the hierarchy the mobile card
+  already has. Pure metadata; the secondary levers stay unstyled (tertiary).
+
+- 2dda6e7: fix(plugin-approvals): localize the declared decision-action labels (objectui#2762 P0-3)
+
+  The Approval Center's decision drawer rendered the `sys_approval_request`
+  declared actions with their literal metadata labels — English **Approve /
+  Reject / Reassign / Send back / Request info** in a zh-CN workspace, sitting
+  next to the same page's localized 通过 / 拒绝 inbox buttons. The plugin's
+  translation bundle covered fields and views but had no `_actions` node, so
+  the console's `_actions.<name>.label` resolution had nothing to hit.
+
+  - Re-ran `os i18n extract` against the plugin's config: the bundles now carry
+    `_actions` translations (label, confirmText, successMessage, param labels
+    and helpText) for all eight decision actions — `approval_approve`,
+    `approval_reject`, `approval_reassign`, `approval_send_back`,
+    `approval_request_info`, `approval_remind`, `approval_recall`,
+    `approval_resubmit` — in zh-CN, ja-JP and es-ES (en keeps the metadata
+    literals).
+  - The extract also surfaced other untranslated gaps, now filled in all three
+    locales: the `returned` status option, the `sys_approval_action.action`
+    audit options (`reassign` / `remind` / `request_info` / `comment` /
+    `revise` / `resubmit` / `ooo_substitute`), the `attachments` field, and the
+    `my_pending` / `recent` view empty states.
+
+- 474fe39: feat(approvals): declare approver value bindings; retire `queue` approver authoring (#3508)
+
+  - `@objectstack/spec` exports `APPROVER_VALUE_BINDINGS` — the single declaration of how a
+    designer must source each approver row's `value`: `user`/`team`/`department`/`position`
+    are DATA-record lookups on the system directory objects (`sys_user` / `sys_team` /
+    `sys_business_unit` / `sys_position`; `position` commits the machine **name**, the
+    others the row id), `org_membership_level` is a closed enum (`ORG_MEMBERSHIP_LEVELS`),
+    `manager` is auto-resolved, `field` names a trigger-object field, and `queue` is
+    unsupported. Also exports `NON_AUTHORABLE_APPROVER_TYPES`.
+  - `queue` approver type is deprecated-for-authoring: it still parses (stored flows keep
+    loading and rendering) but is published in `xEnumDeprecated`, so designers stop
+    offering it — the runtime has no queue resolution and the slot routes to nobody. The
+    approver `value` xRef now also maps `manager`, so designers can render its
+    auto-resolved state. No authored key is removed; nothing to migrate. If a flow carries
+    `{ type: 'queue' }`, replace it with `team` / `department` / `position` (or a concrete
+    `user`) until a real ownership-queue implementation lands.
+  - `@objectstack/plugin-approvals` now warns at resolution time when a stored `queue`
+    approver is skipped.
+  - `@objectstack/lint` adds `approval-approver-type-unsupported` (warning) for approver
+    types that are declared but not implemented by the runtime.
+
+- 0bc685a: fix(approvals): return decision attachments as file values, not "[object Object]" (#3504)
+
+  `sys_approval_action.attachments` is a `Field.file`, so the column **stores an
+  opaque `sys_file` id** (ADR-0104 D3 — the stored form of every media field). The
+  ObjectQL read path resolves that id into its expanded
+  `{ id, name, size, mimeType, url }` form on the way out. But `rowFromAction`
+  mapped the column with `.map(String)`, collapsing each expanded value to the
+  literal string `"[object Object]"`. Every `listActions` consumer (the approval
+  inbox timeline) then received garbage: the attachment chip had no filename and
+  its id was `"[object Object]"`, so opening it 404'd.
+
+  - `ApprovalActionRow.attachments` is now `ApprovalActionAttachment[]` — the
+    expanded file value plus its id, so a consumer can label and open an
+    attachment without needing read access to the system `sys_file` object (which
+    regular approvers do not have).
+  - Three read forms are accepted: the expanded value (the normal case), a bare id
+    (nothing to expand it into — storage service absent, file not committed), and
+    a legacy inline blob written before file-as-reference (`file_id` /
+    `mime_type`), until the backfill converts it. The id test reuses the
+    platform's `isFileIdToken`, so this and the engine's read resolver cannot
+    disagree about what counts as an id.
+  - The decision _input_ (`ApprovalDecisionInput.attachments`) is unchanged — it
+    still takes fileId strings, which is also exactly what the column stores. Only
+    the read shape changed.
+
+- b949059: fix(approvals): a dead approval run no longer leaves the record RECORD_LOCKED (#3456)
+
+  The record lock is keyed on a **pending** `sys_approval_request`, and it could
+  not tell _the run that owns that request_ from _an unrelated user editing the
+  record_. So a flow that touched its own target record while its own approval was
+  still pending — a manual `resume` with no decision, or a node that writes the
+  record between opening the approval and the decision — died on its own
+  `RECORD_LOCKED`, and the record stayed locked behind the dead run. Recovery
+  existed (#3424 lets an admin `recall`/`reject` to release it) but nothing made it
+  self-healing.
+
+  Both halves are now closed.
+
+  **Prevention — the owning run may write its own record.** The automation engine
+  stamps `flowRunId` onto the run context at setup, alongside `runAs`, and it
+  travels with every data node's ObjectQL context into `ctx.provenance`. The lock
+  hook exempts a write whose `flowRunId` matches the pending request's `flow_run_id`.
+  It is keyed on run identity rather than elevation on purpose: a `runAs:'user'`
+  run stays fully RLS-scoped while it writes. `flowRunId` is pure provenance —
+  server-constructed like `isSystem`, never client-supplied, evaluated by no
+  security middleware, and the only write it permits is to the one record its own
+  run already holds a pending request against.
+
+  **Recovery — a sweep releases records held by runs that died anyway.** A pending
+  request whose owning run has reached a terminal state (`completed`, `failed`,
+  `cancelled`, `timed_out`) can never be decided, so it is finalised as `recalled`
+  — releasing the lock — and audited under the reserved actor `system:dead-run`
+  with the run and its status in the comment, so it is never mistaken for a
+  submitter's withdrawal. It runs on the existing approvals sweep clock, which also
+  covers the case no in-band handler can: a run killed by a process crash.
+
+  The sweep is fail-safe by construction. It acts only on an explicit terminal
+  status from a closed set; `paused` (the normal state of a live approval),
+  `running`, an unrecognised status, an unknown run, a `getRun` that throws, and a
+  deployment with no automation engine are all read as "still alive". The failure
+  mode is "a dead run's lock survives until an admin recalls it" — today's
+  behaviour — never "a live approval is destroyed".
+
+  Also fixes `AutomationEngine.getRun`, which returned the **first** log entry for
+  a run id rather than the latest. A run that pauses and later finishes records two
+  entries under one id, so every suspend-then-finish run — every approval, screen
+  and wait flow — reported itself as `paused` forever, both on the Runs
+  observability surface and to this sweep.
+
+  One shape was left out here and closed separately in #3712: a `runAs:'user'` run
+  with no trigger user (a schedule) resolved no ObjectQL context at all, so it
+  carried no `flowRunId` and stayed subject to the lock. It now passes a
+  provenance-only context — the run id and nothing the security middleware keys on
+  — so it is attributable without acquiring a principal, and its documented
+  unscoped posture (#1888) is unchanged.
+
+- be1c52c: fix(approvals): admin override for a request routed to an unstaffed approver (#3424)
+
+  An `approval` node routed to a `position` (or `team`/`department`) with **no
+  holders** resolved to only the unresolvable `position:<name>` literal in
+  `pending_approvers` — no concrete user was in the slate. Every normal
+  `decide` / `reassign` / `recall` then returned `FORBIDDEN` (not a pending
+  approver) and, with `lockRecord`, the target record stayed `RECORD_LOCKED`
+  forever: a data-availability dead-end with no in-product recovery (the only exit
+  was editing the DB by hand). Very easy to hit in fresh/demo orgs (positions
+  seeded, holders not) and whenever a role is vacated in production.
+
+  A **platform or tenant admin** — the same posture the engine's superuser bypass
+  already trusts — may now act on any _pending_ request to release it: **approve,
+  reject, reassign** it to a real approver, or **recall** it. The override finalizes
+  the request (which releases the record lock, keyed on a pending request); a
+  tenant admin's authority is org-scoped, a platform admin's is not, and the
+  decision is audited under the admin's own id. An admin approval is authoritative,
+  finalizing the node even under `unanimous` / `quorum` / `per_group` rather than
+  counting as one vote among the (empty) slate.
+
+  - `sys_approval_request.viewer` gains `can_override` (server-computed): true for a
+    privileged admin on a pending request. The `approve` / `reject` / `reassign`
+    declared actions OR it into their `visible` gate, so the console surfaces the
+    recovery path without a hand-wired button. Existing approver/submitter gating is
+    unchanged.
+  - `openNodeRequest` now logs a loud warning when a node resolves to **no concrete
+    approver**, so the misconfiguration is visible instead of silently locking the
+    record. The literal-fallback behavior (kept for 15.x slot back-compat) is
+    otherwise unchanged.
+
+- c5ff96d: fix(approvals): a schedule-triggered run can write its own locked record (#3712)
+
+  #3456 let the run that opened a pending approval write its own target record,
+  keyed on `flowRunId`. It worked for every run that resolves an identity and
+  missed the one that doesn't: an effective `runAs:'user'` run with **no trigger
+  user** — a schedule being the canonical case — passed no ObjectQL context at
+  all, so nothing carried the run id and the run still died on its own
+  `RECORD_LOCKED`.
+
+  The blocker was never the lock. It was that "no identity" and "no context" were
+  the same thing on the wire, so a run could not say _who it was_ without also
+  claiming _what it was allowed to do_.
+
+  **A run with no principal now passes provenance alone.**
+  `resolveRunDataContext` returns `{ flowRunId }` — no `userId`, no `positions`,
+  no `permissions`, not even `isSystem: false`. Every principal gate keys on one
+  of those fields (the elevation short-circuit on `isSystem`, the ADR-0103
+  engine-owned write guard and the ADR-0090 D12 delegated-admin gate on `userId`,
+  the empty-principal fall-open on all three), so this context authorizes
+  **identically to no context at all**. The run keeps the documented #1888
+  unscoped posture, its loud `[runAs]` warning, and the
+  `flow-schedule-runas-unscoped` build-time lint. Nothing about what it may touch
+  changed — only that it can now be attributed.
+
+  **Provenance moved out of the hook session, into `ctx.provenance`.** `session`
+  answers _who is calling_ and is absent when no identity envelope was supplied —
+  a distinction real gates depend on (the attachment access gate skips bare-kernel
+  writes on exactly that test). Folding a run id into `session` would have forced
+  an identity-less run to present an empty session, silently turning "no caller"
+  into "an anonymous caller" and narrowing the #1888 fail-open for attachments
+  alone. `HookContext.provenance.flowRunId` says what produced the write; the
+  approvals lock reads it there.
+
+  Also relaxes `BaseEngineOptionsSchema.context` to a partial envelope
+  (`ExecutionContextInput`). `positions`/`permissions`/`isSystem` carry parse-time
+  defaults, which made them _required_ on a caller-supplied option and asserted
+  something untrue — that every data-engine context carries a principal. Callers
+  have always passed slices (`{ isSystem: true }` for a system read); the type now
+  says so.
+
+  Migration: nothing to change unless you read the run id inside a hook. If you
+  wrote `ctx.session.flowRunId`, read `ctx.provenance.flowRunId` instead — the
+  field never shipped under the old name.
+
+- d2a8695: fix(approvals)!: an approval request is visible to its participants, not to the whole tenant (#3590)
+
+  `getRequest` / `listRequests` / `countRequests` deliberately query with
+  `SYSTEM_CTX` to bypass RLS — as the code comments say, the approver-visibility
+  rule spans identity forms RLS cannot model cleanly, so it has to be expressed in
+  the service. Only the **tenant** half of that rule was ever applied. The
+  participant half was named in the comment and never written, so **any
+  authenticated user could read any approval request in their tenant** — its
+  payload snapshot, its full decision history, and (once decision attachments
+  derived their access from the request, #3580) its files.
+
+  `approverId` on `listRequests` is a _filter_, not authorization: omitting it
+  returned the whole tenant.
+
+  A caller now sees a request when they are a participant — the submitter, a
+  current approver (via the normalized approver index, so every identity form the
+  write path recorded is covered), or someone who has already acted on it (a past
+  approver whose slot has moved on, a commenter). Admins with override authority
+  keep the unrestricted view the "all requests" console surface depends on, and a
+  tokenless context sees nothing.
+
+  Keying on the concrete user id is sufficient rather than an approximation:
+  position/team/manager/field approvers are resolved to concrete user ids at open
+  time, and the `type:value` literal is only the fallback for a spec that resolved
+  to _nobody_ — a slot no one can act on either way. So this cannot hide a request
+  from someone who could actually act on it.
+
+  **A write path's own result is not re-gated.** Every operation echoes back the
+  request it just changed; the operation already authorized itself, and re-asking
+  would answer wrong for a context carrying no `userId` (a flow-driven resume, a
+  service-to-service call), turning a successful write into `null`.
+
+  Marked breaking because a client that listed requests without an `approverId`
+  filter and expected the whole tenant will now receive only its own — which is
+  the point.
+
+- 84e7be9: feat(plugin-approvals): expose per-group membership of pending approvers (objectui#2807)
+
+  `per_group` (会签) requests now carry `pending_approver_groups` on the
+  enriched row — a map from each still-pending approver id to the group key(s)
+  it fills (e.g. `{ "u_devadmin": ["finance", "legal"] }`). A client can label
+  each "waiting on" chip with the group it represents instead of showing
+  duplicate, context-free names.
+
+  - Resolved in `attachDecisionProgress` from the same open-time
+    `__approverGroups` snapshot the `decision_progress` groups already use, so
+    the two never disagree.
+  - Only the **pending** slots are mapped (a resolved approver has left
+    `pending_approvers`), and **synthetic** (unnamed, `#N`) group keys are
+    dropped — a `· #0` sub-tag would be noise.
+  - Absent for non-`per_group` behaviors. Display-only; the engine's
+    finalization tally stays authoritative.
+  - Added to the `ApprovalRequestRow` contract in `@objectstack/spec`.
+
+- debc23a: feat(approvals): enrich inbox rows with `payload_labels` (snapshot field labels)
+
+  The approvals inbox summary title-cased raw snapshot machine keys
+  (`assessment_status` → "Assessment Status") because the API sent no field
+  labels. `ApprovalService.enrichRows` now attaches `payload_labels` (snapshot
+  field key → the target object's field label), symmetric with the existing
+  `payload_display` (which resolves the values), and `ApprovalRequestRow` gains
+  the field. For a single-locale project the schema label is already the
+  localized string, so a client can render the human field name (e.g. "考核状态")
+  instead of a prettified English key.
+
+- 0f8ad09: feat(spec)+fix(approvals): publish approver value data sources, order the type enum for authors, stop silent dead approver slots (#3508 / #3807 follow-ups)
+
+  Four follow-ups from browser-verifying the #3508 approver work end to end.
+
+  **`APPROVER_VALUE_SOURCES` — the designer stops guessing where candidates live.**
+  `xRef.map` only ever named a picker KIND (`'team'`), never where that picker's
+  rows come from, so the designer carried its own copy of the data contract — and
+  the first copy was wrong: every directory kind was wired to `GET
+/api/v1/meta/:type`, the metadata REGISTRY, which does not hold `sys_user` /
+  `sys_team` / `sys_business_unit` / `sys_position` rows. Candidates came back
+  empty and the control degraded to free text (#3508). The binding is now
+  projected onto the published JSON schema as `xRef.sources` — `{ source: 'data',
+object, valueField }` for the record-backed kinds, the closed enum inline for
+  `org_membership_level` — derived from `APPROVER_VALUE_BINDINGS` so the two
+  cannot drift, and inheriting its `satisfies` exhaustiveness (a new
+  `ApproverType` member that declares no source is a compile error). Presentation
+  — which field to show, whether to open a people-picker, what subtitle to use —
+  stays a renderer decision.
+
+  **`ApproverType` declaration order is now the authoring recommendation.**
+  objectui#2834 argued for leading with indirect bindings and shipped that order
+  in its own options array — which the Studio inspector never reads: it derives
+  the picker from this enum via the published schema, so `user` still came first.
+  The intent only takes effect if the enum carries it, so the enum now reads
+  `manager, position, department, team, field, expression, org_membership_level,
+user` (deprecated `role` / `queue` still parse and stay out of every picker via
+  `xEnumDeprecated`). Binding one specific person is the least portable choice an
+  author can make — it breaks when the flow moves to another environment (that id
+  does not exist there) and again when that person leaves.
+
+  **A graph approver that expands to nobody no longer does it in silence.**
+  `queue` already warned (#3508); every OTHER graph type — `team`, `department`,
+  `position`, `org_membership_level`, `manager` — fell back to the same
+  unactionable `type:value` literal without a word. That silence is what let
+  #3807 hide for as long as it did: the request opened with an empty slate and
+  the first symptom was a permanently stuck approval (#3424). The fallback stays
+  (15.x slots and substring fixtures depend on it); it now logs the type, value
+  and organization that produced it. `user` / `field` stay quiet — they take the
+  id they were given and never had an "expanded to nobody" state.
+
+  **`plugin-sharing`'s identical org scope is pinned by tests.**
+  `BusinessUnitGraphService.orgScope` has the same strict `organization_id`
+  equality #3807 fixed in approvals. It is unreachable today — every materialized
+  `sys_sharing_rule` carries `organization_id = null`, so the filter is skipped —
+  and widening an authorization path on a defect that cannot currently fire is
+  not a change to make blind. New tests lock both the reachable paths and the
+  divergence itself, so if sharing ever adopts the null-org=env-wide reading it
+  is a deliberate edit to a named test rather than a silent behaviour change.
+
+- 376a061: Surface the approval node's author-declared `decisionOutputs` keys on the request read as `ApprovalRequestRow.decision_outputs` (#3447 P2 UI enablement). The set varies per request (each node declares its own), so it rides the row rather than the object's static action params — a decision UI renders one input per key and POSTs `outputs` with the decision.
+- 3ea7271: fix(approvals): a `department` approver resolves against env-wide business units (#3807)
+
+  `expandBusinessUnitUsers` scoped its `sys_business_unit` reads with a strict
+  `organization_id = <request org>` equality, so a unit whose `organization_id`
+  is `null` was invisible: the seed check found no row, the expansion returned
+  `[]`, and the approver fell back to the dead `department:<id>` literal that
+  routes to nobody.
+
+  That is the normal case, not an edge case. An app's org tree is seeded, and a
+  seed cannot know the organization id the runtime mints at boot, so every seeded
+  unit carries `organization_id = null` — while an approval request always
+  carries an org. Every business unit a flow author could pick therefore resolved
+  to nobody, silently: the request opens, the slate is empty, and (with
+  `lockRecord`) the record stays locked with no one able to act (#3424 is the
+  downstream shape of the same dead end). Verified against a live showcase stack:
+  a `{ type: 'department', value: 'bu_hq_finance' }` approver produced
+  `pending_approvers: "department:bu_hq_finance"` while the unit's member sat
+  right there in `sys_business_unit_member`.
+
+  Both the seed check and the subtree descent now scope to **this org ∪
+  env-wide** — `$or: [{ organization_id: <org> }, { organization_id: null }]` —
+  the same predicate `sys_metadata`'s pending-draft listing settled on for the
+  identical reason (a strict equality silently dropping env-wide rows). The wall
+  between two organizations is unchanged: another org's unit still fails the
+  match, and a null-org parent does not drag another org's child unit into the
+  subtree.
+
+  Note the same strict-equality scope exists in `plugin-sharing`'s
+  `BusinessUnitGraphService.orgScope`. It is not reachable today — every
+  materialized `sys_sharing_rule` row carries `organization_id = null`, so the
+  filter is skipped — and is left alone here rather than widen an
+  access-granting path on a defect that cannot currently fire.
+
+- deb538f: fix(storage): let an object delegate file-read authorization to its service
+
+  Fixes a regression from the governed-download change (ADR-0104 D3 wave 2): a
+  **legitimate approver could see a decision attachment's filename but got 403
+  opening it**, found by driving app-showcase in a browser as a real non-admin
+  approver.
+
+  Cause: a field-owned file's download was authorized by testing whether the
+  caller can READ the owning row. For an ordinary business object that is right —
+  row readability _is_ the access rule. For `sys_approval_action` it is the wrong
+  authority: the audit table is deliberately closed to ordinary approver
+  positions (`operation 'find' … is not permitted for positions [auditor,
+everyone]`), so the test denied the very approver the attachment was filed for.
+  The approvals _service_ has always had the real rule, which is why the timeline
+  listing the attachment returned 200 while the bytes returned 403.
+
+  An object may now name a service to answer the question instead:
+
+  - `ObjectSchema.fileAccessDelegate` — a kernel service that authorizes
+    downloads of files owned by that object's media fields.
+  - `IFileAccessDelegate.authorizeFileRead(recordId, context)` — the contract.
+  - `sys_approval_action` declares `'approvals'`; `ApprovalService.authorizeFileRead`
+    reuses the _same_ gate `listActions` applies (visibility of the parent
+    request) rather than inventing a second, looser rule for the bytes.
+
+  **Fails closed**: a declared delegate that is missing or does not implement the
+  method denies, rather than silently reverting to the raw read it was declared to
+  replace. Objects without the declaration are unchanged.
+
+  Verified in the browser against app-showcase, both sides of the gate: the
+  approver now downloads the real PDF (200), and an anonymous request is still
+  refused (401) — the anonymous capability URL the original change closed stays
+  closed. A decision attachment ends up exactly as readable as the decision it
+  hangs off: never more, and no longer less.
+
+- db48ad5: fix(security,approvals,metadata-core): restore batch routes on the eight objects the #3391 P1 companion fix missed (#3026)
+
+  The #3391 P1 contract made the bulk gate `bulk ∧ derived(child)`: a batch
+  request is admitted only when the object grants the `bulk` **primitive** and the
+  batched child operation is itself allowed. Before that, the `*Many` routes
+  checked only the child verb, so a boilerplate CRUD-five whitelist
+  (`['get','list','create','update','delete']`) batched fine.
+
+  The companion fix — adding the `bulk` primitive wherever an explicit whitelist
+  survived — was applied only inside `platform-objects`. Eight objects carrying
+  the same boilerplate live in other packages and kept the gap, so `/batch`,
+  `createMany`, `updateMany` and `deleteMany` answered `405
+OBJECT_API_METHOD_NOT_ALLOWED` on objects whose single-record create/update/
+  delete were wide open. `data-objectstack` rethrows that 405 without falling back
+  to per-row writes, which surfaced as a hard error on multi-select delete in the
+  Setup grids.
+
+  Objects reclaimed (whitelist now `['get','list','create','update','delete','bulk']`):
+  `sys_capability`, `sys_permission_set`, `sys_position`,
+  `sys_position_permission_set`, `sys_user_permission_set`, `sys_user_position`
+  (plugin-security); `sys_approval_delegation` (plugin-approvals);
+  `sys_view_definition` (metadata-core).
+
+  No new authority is granted: `bulk` only permits batching verbs each object
+  already exposes one record at a time, and every batched row still passes the
+  same row- and field-level permission checks. The whitelists stay explicit rather
+  than being deleted — seven of the eight are `managedBy`, and
+  `reconcileManagedApiMethods` (ADR-0103 D3) early-returns on a non-array
+  `apiMethods`, so dropping the line would silently disable the managed-write
+  backstop.
+
+- 83c161f: feat(automation)!: a flow run with no trigger user may no longer touch data (#3760)
+
+  An effective `runAs:'user'` run that resolves **no trigger user** used to execute
+  its data nodes **UNSCOPED** — it presented no principal, and the data security
+  middleware skips when there is no principal, so the run read and wrote every row.
+  `runAs:'user'` is an access-_narrowing_ declaration; failing to resolve it must
+  never resolve to a grant (ADR-0049). It now **refuses** the operation
+  (`UnscopedRunDataAccessError`), naming `runAs:'system'` as the fix.
+
+  **This was never really about schedules.** The docs, the spec, the runtime
+  warning and the lint all described a schedule-shaped problem, and the lint only
+  ever matched that shape. But the runtime predicate is "no user", and the
+  commonest way to have no user is a **record-change flow fired by a write that
+  carried none**: `isSystem` does _not_ suppress trigger dispatch — only
+  `skipTriggers` does, and exactly three first-party paths set it — so every
+  plugin/service system write, the approvals status mirror, and a `runAs:'system'`
+  flow's own data node dispatched record-change flows with `userId: undefined`.
+  Ordinary users reach those writes routinely (submitting for approval mirrors a
+  status onto the target record), so the fail-open was reachable by unprivileged
+  input and was the common case, not the rare one.
+
+  Deliberately **not** implemented as "inherit the triggering write's posture and
+  run as `isSystem`". That reads like a relabel but is a privilege escalation: the
+  security middleware's `isSystem` short-circuit fires _before_ its
+  package-managed-row, system-row, audience-anchor and delegated-admin gates, all
+  of which a principal-less context still has to clear. Such a run cannot write
+  `sys_user_position` today; as `isSystem` it could. "Unscoped" was never
+  equivalent to "system".
+
+  **Breaking — how to migrate.** A flow that reacts to system writes and needs to
+  act beyond one user's grants declares `runAs: 'system'`, making the elevation
+  explicit and audit-attributable. Otherwise ensure the trigger supplies a user.
+  Flows that touch no data are unaffected (`runAs` is moot), and the failure is
+  isolated: the trigger already swallows flow errors, so the originating write
+  still succeeds. The engine warns at run _setup_, before any node executes.
+
+  **#3712's user-less provenance path is subsumed, not broken.** That fix let a
+  run with no trigger user write its own approval-locked record by carrying a
+  provenance-only ObjectQL context (the run id, nothing else). Such a run can no
+  longer perform a data operation at all — presenting no principal is exactly what
+  made the write unscoped — so it is refused before the lock is consulted. The
+  capability survives via the explicit route: a schedule that must write records
+  declares `runAs:'system'`, which the lock hook exempts on its own `isSystem`
+  branch. The `flowRunId` exemption itself stays live and load-bearing for what
+  #3703 built it for — a `runAs:'user'` run that _does_ have a user — where the
+  exemption is still provenance rather than privilege.
+
+  Also in this change:
+
+  - **`flow-schedule-runas-unscoped` → `flow-runas-unscoped`, and it now fails the
+    build.** It read as a gate and behaved as a comment — `os compile` documented
+    that the flow lint "NEVER fails the build" — which is close to no net at all
+    for the audience it protects, very often an AI generating flows in bulk. It now
+    also covers the other provably user-less triggers (`time_relative`, `api`), per
+    ADR-0073 D5. It still cannot cover `record_change`, which is undecidable at
+    authoring time — that is exactly why the runtime refusal exists.
+  - **Three seed writes stopped firing automation.** The seed loader's pass-2
+    deferred-reference back-fill and both of `AppPlugin`'s basic-insert fallbacks
+    inlined a bare `{ isSystem: true }` instead of the shared seed options, so they
+    seeded with record-change automation live — the self-trigger vector
+    `skipTriggers` exists to prevent, on the writes that skipped it.
+  - **ADR-0073 amended.** Its severity rationale ("an unprivileged user cannot
+    trigger a schedule, so there is no untrusted-input path") is falsified, and its
+    rejection of fail-closed ("breaks legitimate scheduled CRUD — 2/3 example flows
+    relied on the default") expired when those flows were fixed to declare
+    `runAs:'system'`. Refusal is an interim posture, forward-compatible with the
+    ADR's `automation` principal: when that lands, the refusal point becomes the
+    place that resolves it.
+
+- Updated dependencies [50616d9]
+- Updated dependencies [08b5a3d]
+- Updated dependencies [d99aeb3]
+- Updated dependencies [4727eb8]
+- Updated dependencies [f63cd09]
+- Updated dependencies [fa3d0cf]
+- Updated dependencies [af5a224]
+- Updated dependencies [71f76e1]
+- Updated dependencies [37b1346]
+- Updated dependencies [99736a0]
+- Updated dependencies [fe67e34]
+- Updated dependencies [fdb4f50]
+- Updated dependencies [1bd5652]
+- Updated dependencies [14252d3]
+- Updated dependencies [7fb436c]
+- Updated dependencies [879ea13]
+- Updated dependencies [201b31f]
+- Updated dependencies [e2616e0]
+- Updated dependencies [6fdc5c6]
+- Updated dependencies [8b9d71e]
+- Updated dependencies [33f5e23]
+- Updated dependencies [259af21]
+- Updated dependencies [587fc91]
+- Updated dependencies [1986594]
+- Updated dependencies [ad4af62]
+- Updated dependencies [d44dbfa]
+- Updated dependencies [474fe39]
+- Updated dependencies [0bc685a]
+- Updated dependencies [b949059]
+- Updated dependencies [be1c52c]
+- Updated dependencies [c5ff96d]
+- Updated dependencies [84e7be9]
+- Updated dependencies [a6c3f38]
+- Updated dependencies [debc23a]
+- Updated dependencies [0f8ad09]
+- Updated dependencies [8f9689f]
+- Updated dependencies [57a3bb3]
+- Updated dependencies [5f9a987]
+- Updated dependencies [9f060e5]
+- Updated dependencies [bc17d39]
+- Updated dependencies [db02d47]
+- Updated dependencies [0bfdf46]
+- Updated dependencies [376a061]
+- Updated dependencies [7c7e246]
+- Updated dependencies [f35cdc5]
+- Updated dependencies [9ea2bc5]
+- Updated dependencies [c2d9098]
+- Updated dependencies [a227ed7]
+- Updated dependencies [9613396]
+- Updated dependencies [e47b342]
+- Updated dependencies [4ed7ed4]
+- Updated dependencies [2fa4ca1]
+- Updated dependencies [f5a2320]
+- Updated dependencies [deb538f]
+- Updated dependencies [5b89711]
+- Updated dependencies [0c8a22f]
+- Updated dependencies [763931e]
+- Updated dependencies [de9af8a]
+- Updated dependencies [c4df271]
+- Updated dependencies [a41ba5c]
+- Updated dependencies [189854c]
+- Updated dependencies [0e3a226]
+- Updated dependencies [524151c]
+- Updated dependencies [1d4756e]
+- Updated dependencies [720c5ad]
+- Updated dependencies [a8d1e24]
+- Updated dependencies [d1cabaa]
+- Updated dependencies [41642b0]
+- Updated dependencies [4cca74c]
+- Updated dependencies [88ef03e]
+- Updated dependencies [9e2caf3]
+- Updated dependencies [81ce41a]
+- Updated dependencies [85e1e4e]
+- Updated dependencies [dac6a08]
+- Updated dependencies [394b7a1]
+- Updated dependencies [677b591]
+- Updated dependencies [d77d1b7]
+- Updated dependencies [5b79a34]
+- Updated dependencies [c757854]
+- Updated dependencies [0045682]
+- Updated dependencies [2a5f04a]
+- Updated dependencies [4f740b0]
+- Updated dependencies [67452d1]
+- Updated dependencies [4921a95]
+- Updated dependencies [0fc6219]
+- Updated dependencies [605e190]
+- Updated dependencies [c6c59f1]
+- Updated dependencies [b0e78a8]
+- Updated dependencies [f31cc8d]
+- Updated dependencies [f343dc4]
+- Updated dependencies [8269e32]
+- Updated dependencies [74f7339]
+- Updated dependencies [a6c35a2]
+- Updated dependencies [c2f1002]
+- Updated dependencies [db48ad5]
+- Updated dependencies [f163028]
+- Updated dependencies [f07808c]
+- Updated dependencies [7ffc3d3]
+- Updated dependencies [88346ba]
+- Updated dependencies [4631592]
+- Updated dependencies [32ff033]
+- Updated dependencies [5ac93d4]
+- Updated dependencies [93f267f]
+- Updated dependencies [0024abf]
+- Updated dependencies [acbf364]
+- Updated dependencies [5487c20]
+- Updated dependencies [aa8b847]
+- Updated dependencies [7687f7b]
+- Updated dependencies [1659072]
+- Updated dependencies [abceb0d]
+- Updated dependencies [0c302a7]
+- Updated dependencies [6633337]
+- Updated dependencies [f00d8d4]
+- Updated dependencies [503be86]
+- Updated dependencies [cde1975]
+- Updated dependencies [0bc685a]
+- Updated dependencies [c073b8c]
+- Updated dependencies [11949fc]
+- Updated dependencies [b098b0e]
+- Updated dependencies [4d00b13]
+- Updated dependencies [9aa5510]
+- Updated dependencies [57bab76]
+- Updated dependencies [b90086a]
+- Updated dependencies [b95577a]
+- Updated dependencies [83c161f]
+- Updated dependencies [d8c4957]
+- Updated dependencies [f24cb83]
+- Updated dependencies [5dbbb92]
+- Updated dependencies [69f1dfd]
+  - @objectstack/spec@17.0.0-rc.0
+  - @objectstack/platform-objects@17.0.0-rc.0
+  - @objectstack/core@17.0.0-rc.0
+  - @objectstack/formula@17.0.0-rc.0
+  - @objectstack/metadata-core@17.0.0-rc.0
+
 ## 16.1.0
 
 ### Patch Changes