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

package/CHANGELOG.md

@@ -1,5 +1,1467 @@
 # @objectstack/plugin-approvals
 
+## 17.0.0-rc.1
+
+### Minor Changes
+
+- f5a4ef0: refactor!: ADR-0112 batch 2 — sweep the lowercase error-code emitters (#4003)
+
+  Continues #3841 per ADR-0112. Batch 1 (#3988) settled the vocabulary and closed
+  the set; this batch moves the emitters that still spoke lowercase `snake_case`
+  onto it.
+
+  **Wire-visible change.** Error codes on these surfaces change spelling. Generic
+  conditions collapse onto the standard catalog rather than keeping a synonym:
+  `unauthorized`/`unauthenticated` → `UNAUTHENTICATED`, `forbidden` →
+  `PERMISSION_DENIED`, `not_found` → `RESOURCE_NOT_FOUND`, `internal` →
+  `INTERNAL_ERROR`, `unavailable` → `SERVICE_UNAVAILABLE`, `not_supported` →
+  `NOT_IMPLEMENTED`, `bad_request` → `INVALID_REQUEST`. Domain conditions get codes
+  registered in `ERROR_CODE_LEDGER` (`MARKETPLACE_STORAGE_FAILED`,
+  `PLUGIN_MANIFEST_INVALID`, `ITEM_LOCKED`, `DELIVERY_NOT_ELIGIBLE`, …). Swept:
+  `cloud-connection`, `plugin-auth`, `hono`, `metadata-protocol`, `rest`,
+  `service-messaging`, `service-automation`, `trigger-api`.
+
+  Branch on `error.code` values rather than pattern-matching their case: the
+  console's fix for the same rename (objectui#2977) reads codes case-insensitively
+  for exactly this reason, and that is the pattern to copy in your own consumers if
+  you support servers on both sides of the change.
+
+  **Four routes stop putting a code in the message slot.** The webhook redeliver
+  route, the API-trigger webhook, and two `rest` routes answered
+  `{ success: false, error: '<code>', message }` — the code occupying `error`, the
+  declared object envelope nowhere. They now emit `error: { code, message }`, and
+  three API-trigger branches gained a message they never had. Clients reading
+  `body.error` as a string on those routes must read `body.error.code`.
+
+  **`ConnectorErrorCategory` / `ConnectorRetryStrategy`** (ADR-0112 D9a):
+  `@objectstack/spec` exported two mutually incompatible `ErrorCategory` types and
+  two `RetryStrategy` types. The connector-side pair is renamed; importers of the
+  `integration` subpath update the name. Side effect: the api-side `ErrorCategory`
+  and `RetryStrategy` now appear in the generated API reference at all — the name
+  collision had been silently dropping them.
+
+  **`OAUTH_REGISTER_FAILED` replaces an unbounded code source.** The OAuth client
+  registration route put better-auth's arbitrary `body.error` string straight into
+  `error.code`. The code is now ours and the upstream discriminator moved to
+  `details.upstreamError`.
+
+  **Not swept, deliberately.** `sys_metadata_audit.code` keeps its lowercase values
+  (ADR-0112 D6b): it is persisted audit history, and the same column holds
+  non-error outcomes (`ok`, `lock_override`). Diagnostics records that ship inside a
+  200 keep theirs (D6c), as do field-level codes (D6, #3977) and the CLI's
+  `--json` output contract.
+
+  A `check:error-code-casing` CI guard now fails on a new lowercase literal in a
+  code position, since the ledger's casing rule can only police codes that someone
+  registers.
+
+- 91f4c78: feat(approvals,spec): structured reassign hand-off parties on `sys_approval_action` (#4365)
+
+  A reassign's audit row used to encode "who handed the slot to whom" only inside
+  a default free-text comment — `"<from_id> → <to_id>"`, two raw user ids — which
+  clients could neither parse reliably nor render readably, so the approvals
+  timeline showed opaque identifier soup for the single most important fact of
+  the entry.
+
+  - `sys_approval_action` gains `reassign_from` / `reassign_to`
+    (`lookup('sys_user')`), written by `ApprovalService.reassign()`.
+  - `comment` is pure user input again: nothing is invented when the actor
+    supplies none.
+  - `listActions()` resolves both parties' display names into
+    `reassign_from_name` / `reassign_to_name`, alongside the existing
+    `actor_name`, so timelines can render "from A to B" without extra lookups.
+  - `ApprovalActionRow` (spec contract) declares the four new fields.
+
+  Pre-existing rows keep their legacy comment; clients should prefer the
+  structured fields when present and fall back to `comment` otherwise.
+
+- cd6b9f2: `decisionOutputs` entries may now be declared `required` (objectui#2955). A typed entry `{ key, label?, type?, multiple?, required?: true }` tells the runtime — not just the decision UI — that an approver must supply the value: an **approve** carrying no value, or a blank one (`''`, whitespace, `[]`, an array of blanks), is rejected with `VALIDATION_FAILED` before any write, so the audit row and the request are untouched and the run can never resume past the node with the key missing.
+
+  That gap is what the flag closes. `decisionOutputs` exists so a decision can route the next step (`approvers: [{ type: 'expression', value: 'vars.lead_review.next_reviewers' }]`), but nothing made the approver actually answer: a skipped output resumed the run with the key absent, and the next node either faulted with `EXPRESSION_FAILED` or resolved an empty slate and stalled on `onEmptyApprovers: 'admin_rescue'` — long after the one person who could have filled it in had moved on. `onEmptyApprovers` was the only backstop, and it is a recovery mechanism, not a contract.
+
+  **Reject never requires them.** The run leaves down the `reject` edge, where nothing reads the outputs — demanding routing data to say "no" would trap the rejection. Outputs still ride a reject when the approver filled them in.
+
+  **No elevation bypass.** A one-click email action link and an `auto_approve` SLA escalation both fail the same way rather than advancing into a node that would resolve nobody; the escalation sweep already isolates a throwing request, so that decision stays pending and visibly overdue instead of silently breaking the run downstream. Enforcement is per decision, so on a `unanimous` / `quorum` node every approver supplies the required outputs and the finalizing decision's values are what the flow resumes with.
+
+  `required` rides `normalizeDecisionOutputs`, so it reaches clients on `decision_output_defs` — a decision UI marks the field required and blocks locally instead of round-tripping to a 400. The console side ships in objectui#2955.
+
+### Patch Changes
+
+- 820eff9: fix(spec,plugin-approvals): the two approval vocabularies are derived, not hand-matched (#3786)
+
+  `sys_approval_request.status` and `sys_approval_action.action` spelled their
+  option lists out — five values and twelve — each under a "Keep in sync with
+  `ApprovalStatus` / `ApprovalActionKind` (spec/contracts)" comment, while the
+  contract held the same sets as bare type unions. Seventeen strings matched by
+  hand across a package boundary, with nothing checking them. They did all still
+  agree; the sweep that found them (#3786) verified that verbatim before changing
+  anything.
+
+  Agreeing is not the same as being held, and both directions of drift are quiet:
+
+  - a value the **column** accepts and the contract omits is invisible to every
+    consumer typed against the contract — the row exists and nothing can narrow it;
+  - a value the **contract** declares and the column rejects surfaces only at write
+    time, on whichever tenant first reaches that transition.
+
+  An audit vocabulary is a bad place for either. So the contract now publishes the
+  lists as values — `APPROVAL_STATUSES` and `APPROVAL_ACTION_KINDS` — with
+  `ApprovalStatus` / `ApprovalActionKind` derived from them via
+  `(typeof X)[number]`, and the two columns spread the constants. The per-entry
+  rationale (which action kinds move the flow, which are thread-only, why
+  `returned` differs from `recalled`) moved onto the constants, where the values
+  live.
+
+  **New exports, no behaviour change.** The emitted option lists are byte-identical
+  — verified against the built artifact before and after. Existing imports of the
+  two types are unaffected; the types resolve to the same unions.
+
+  `approval-vocabularies.test.ts` pins the qualifier that derivation alone cannot:
+  the columns agree with the contract _while the spread is there_, and the test
+  fails if either is re-inlined as a literal that has drifted. It also guards the
+  guard (an unresolvable import would compare two empty lists and pass) and asserts
+  the two vocabularies stay distinct, since a copy-paste pointing one column at the
+  other constant would satisfy "derived from the contract" while being the wrong
+  vocabulary entirely.
+
+  Verified by mutation in both directions: adding a value to `APPROVAL_STATUSES`
+  propagates into the built `sys_approval_request.status` options (the derivation
+  is live, not a stale build), and re-inlining a drifted literal fails
+  `sys_approval_request.status offers exactly the contract statuses, in order`.
+
+- 2e836de: chore(packaging): CHANGELOG.md ships in every npm tarball (#4261)
+
+  The AGENTS.md post-task checklist requires breaking changesets to carry their
+  FROM → TO migration because "this text ships to consumers as `CHANGELOG.md`
+  inside the npm package and is what an upgrading agent greps after the tombstone
+  error." That delivery path was severed for 68 of the 69 publishable packages:
+  npm packs `package.json` / `README*` / `LICENSE*` unconditionally but — unlike
+  older npm versions — not `CHANGELOG.md`, and the canonical
+  `"files": ["dist", "README.md"]` whitelist never named it. Measured on npm
+  10.9.7: `npm pack --dry-run` on `@objectstack/types` shipped 3 files while its
+  70KB `CHANGELOG.md` stayed behind. Only `@objectstack/spec` listed it
+  explicitly.
+
+  The tombstone-error scenario is precisely the one where the repo is out of
+  reach — the upgrading agent has `node_modules` and nothing else — so the
+  migration text has to ride in the tarball. Every publishable package now
+  declares `CHANGELOG.md` in `files`, and the canonical whitelist is
+  `["dist", "README.md", "CHANGELOG.md"]`.
+
+  The other half is the gate: `check:published-files` gains a fifth invariant,
+  COMPLETE — a whitelist that fails to cover `CHANGELOG.md` fails the
+  always-required lint job, so the next package cannot silently sever the path
+  again. `@objectstack/spec`'s per-package EXTRA_ENTRIES exemption dissolves
+  into the canonical set.
+
+  Consumer-visible change: one more file per install (the package's changelog,
+  e.g. 70.8KB for `@objectstack/types`), and `grep -r "removed key"
+node_modules/@objectstack/*/CHANGELOG.md` now finds the migration it was
+  promised.
+
+- b5f9397: fix(sharing,runtime): a `sort` passed straight to the engine never ordered anything; migrate every in-repo engine call to canonical QueryAST keys (#4346)
+
+  Two changes with different weights, from one sweep of every in-repo engine
+  call site that still speaks a deprecated alias.
+
+  **The bug — three dropped sorts.** #4346 made the engine fold `filter`→`where`
+  and `top`→`limit` on all six methods. The other four pairs in
+  `RPC_QUERY_ALIAS_SLOTS` (`select`, `sort`, `skip`, `populate`) are folded at
+  the RPC/wire layer only — their values need shape lowering that belongs to
+  those layers — and a **direct `engine.find()` never crosses that layer**. Three
+  call sites passed `sort` there, so it rode onto the AST untouched, every
+  driver's `Array.isArray(query.orderBy)` guard declined to emit an ORDER BY, and
+  the query returned an ordinary-looking, arbitrarily-ordered result:
+
+  | call site                           | asked for                                         | actually got                |
+  | ----------------------------------- | ------------------------------------------------- | --------------------------- |
+  | `share-link-routes.ts`              | shared AI conversation messages, `created_at asc` | messages in arbitrary order |
+  | `runtime/domains/share-links.ts`    | same route, runtime-domain copy                   | same                        |
+  | `share-link-service.ts` `listLinks` | the 200 most recent share links                   | an arbitrary 200            |
+
+  All three combine the dropped sort with a `limit` — the "latest N" shape whose
+  failure #4226 spelled out: an unapplied sort returns rows in arbitrary order,
+  which `limit` then slices into an arbitrary page. #4226 fixed that in the wire
+  normalizer; these calls sit one layer below it. `listLinks` had no test at all,
+  which is why it went unnoticed. Now pinned — on the option bag the engine
+  receives, not on row order, because the failure is that the key never becomes
+  `orderBy` and a fake engine honouring either spelling would pass either way.
+
+  **The cleanup — 27 no-op renames.** Every remaining in-repo engine call passing
+  `filter` now passes `where` (approvals 5, auth 2, reports 6, sharing 11,
+  webhooks 2, plus the one `filters` in a spec doc example). These are strict
+  no-ops since #4346 folds the alias — the point is that the framework stops
+  depending on a spelling it asks users to migrate off, which is a prerequisite
+  for ever retiring the aliases. Service-level `filter` PARAMETERS (each
+  service's own public API, e.g. `listRequests(filter)`) are deliberately
+  untouched — those are not engine option bags.
+
+  Two of the renamed calls were live victims of the #4346 bug rather than
+  cosmetic: `auth-manager`'s `stampIdentitySource` read the table's first row via
+  `findOne({filter})` and counted the whole table via `count({filter})`, so a
+  federated sign-in never stamped `source: 'idp_provisioned'`. #4346 already
+  corrected the behaviour; this makes the call say what it means.
+
+- 9881074: fix(batch): the background walks seek instead of counting, so they stop skipping rows (#4363)
+
+  #4363 made a single paged read a partition of its result set. It could not make
+  a _walk_ one: seven background scans paged with a growing `offset` while writing
+  to the very rows they were reading, and an offset counts into a set those writes
+  are changing. Rows slide past the cursor and are never visited.
+
+  That is not a slow page in any of these — it is a wrong answer wearing the shape
+  of a clean run:
+
+  - **`rebuildApproverIndex`** built its desired state by walking
+    `sys_approval_request WHERE status = 'pending'` with no `orderBy` at all, then
+    **deleted** every index row that state did not explain. A skipped request
+    meant an approver silently dropped from someone's queue. (The loop beside it
+    ordered by `created_at` — not unique, so its pages were never a partition
+    either.)
+  - **`verifyFileReferences`** decides which files nothing references. A record it
+    never visits is reported as an unreferenced file.
+  - **`backfillFileReferences`** and the **pinyin companion backfill** rewrite
+    each row they read, so their own writes were shifting the set out from under
+    the cursor. Records were left unconverted and unsearchable by a run that
+    reported success.
+  - **`scanValueShapes`** exists to vouch that no stored value is off-shape, and
+    it opens a migration gate on that evidence.
+
+  All of them now go through `keysetWalk` (`@objectstack/types`): order by a
+  unique key, and seek past the last one instead of counting from the start. A
+  row's key does not move when the row is updated, and cannot be shifted when
+  another is deleted, so the walk is stable under exactly the mutation these
+  functions perform. It is also O(n) rather than O(n²/page) — measured on
+  Postgres over 2M rows, deep pages cost ~1.1 s by offset against ~0.09 s by seek.
+
+  One deliberate non-conversion: the REST **export** stream keeps its offset. It
+  honors a caller-chosen sort, and a keyset walk would have to re-order the export
+  by `id` to seek — changing what the user asked for to fix a cost. Its pages are
+  already a partition since #4363; only the depth cost remains.
+
+  `keysetWalk` merges the cursor with `$and` rather than spreading it into the
+  caller's filter, so a walk whose own `where` constrains the key column
+  (`{ id: { $in: [...] } }`) keeps that constraint instead of having it silently
+  overwritten. When a `max` cap is set it reads one row beyond the cap to tell
+  "the cap stopped us" from "the source ended exactly there" — without that, a
+  walk that read everything still reports `truncated`, and a caller acting on it
+  goes looking for rows that were never withheld.
+
+  The storage suites' fake engines now **throw** on an `offset` instead of serving
+  one, so the conversion is pinned rather than merely passing.
+
+- cc2de0e: chore(packaging): 20 packages stop publishing their sources, tests and build tooling (#4248)
+
+  These 20 packages declared no `files` field, so npm fell back to packing the
+  whole package directory. `npm pack --dry-run` on `@objectstack/plugin-webhooks`
+  listed **21 files** — 15 under `src/`, three of them unit tests
+  (`auto-enqueuer.test.ts`, `bootstrap-declared-webhooks.test.ts`, …), plus the
+  build-time `scripts/i18n-extract.config.ts`. `dist/` lands on top of that at
+  publish time rather than instead of it, so consumers were installing the
+  TypeScript sources and the test suite alongside the artifact they asked for.
+
+  Each now declares `"files": ["dist", "README.md"]`, matching the 29 packages
+  that already did. Nothing a consumer imports moves: every `main` / `types` /
+  `exports` target in all 20 already resolved inside `dist/`, which the new
+  `check:published-files` guard verifies rather than assumes. The visible change
+  is a smaller install and a smaller dependency-scanning surface — `npm pack` on
+  `@objectstack/plugin-webhooks` now yields 2 files plus `dist/`.
+
+  The other half of the fix is the gate. Half the packages declaring `files` and
+  half not was the #3786 shape — a hand-copied convention with nothing enforcing
+  it, where whoever forgets the line gets no signal at all. `check:published-files`
+  (new, wired into the always-required `lint` job) holds every non-private
+  workspace package to four invariants: `files` is **declared**; it is
+  **sufficient** (covers every entry point, so tightening a whitelist cannot ship
+  a package that fails to resolve); it is **minimal** (admits no test, test-harness
+  config or build script); and anything beyond `dist` + `README.md` is
+  **registered** with a reason, reconciled in both directions so a stale exemption
+  is an error rather than dead text. `@objectstack/spec` is the one package with
+  registered extras — its `.zod.ts` sources, JSON Schemas, liveness ledgers and
+  `CHANGELOG.md` are product, not build input.
+
+  This also closes an assumption #4206 was resting on. Excluding `<pkg>/scripts/**`
+  from the docs-drift implementation test is sound only while no package publishes
+  `scripts/` as runtime code; that held, but it held because someone read all three
+  offenders by hand. It is now checked on every PR.
+
+- Updated dependencies [6a67d7a]
+- Updated dependencies [0ecc656]
+- Updated dependencies [06772eb]
+- Updated dependencies [270650f]
+- Updated dependencies [3aef718]
+- Updated dependencies [1ea6bce]
+- Updated dependencies [c1dcacd]
+- Updated dependencies [ad303ed]
+- Updated dependencies [32ccb23]
+- Updated dependencies [f5a4ef0]
+- Updated dependencies [2d3e255]
+- Updated dependencies [7d7521f]
+- Updated dependencies [5dc4d02]
+- Updated dependencies [05154a1]
+- Updated dependencies [9b6fe7c]
+- Updated dependencies [8c711fb]
+- Updated dependencies [09e4547]
+- Updated dependencies [91f4c78]
+- Updated dependencies [820eff9]
+- Updated dependencies [8d895ff]
+- Updated dependencies [f6472d7]
+- Updated dependencies [78caf51]
+- Updated dependencies [62a789b]
+- Updated dependencies [789ad63]
+- Updated dependencies [2af1988]
+- Updated dependencies [0af50a3]
+- Updated dependencies [2e836de]
+- Updated dependencies [12a19a8]
+- Updated dependencies [41dcda3]
+- Updated dependencies [c8124e5]
+- Updated dependencies [a1a4140]
+- Updated dependencies [c20b875]
+- Updated dependencies [2a37694]
+- Updated dependencies [217e2e6]
+- Updated dependencies [86a71d1]
+- Updated dependencies [d5c75e2]
+- Updated dependencies [03d26f7]
+- Updated dependencies [4384921]
+- Updated dependencies [3c628ce]
+- Updated dependencies [7cb922e]
+- Updated dependencies [1d22114]
+- Updated dependencies [b5f9397]
+- Updated dependencies [ed77493]
+- Updated dependencies [58a03d2]
+- Updated dependencies [dc530b4]
+- Updated dependencies [e59786e]
+- Updated dependencies [bcf1112]
+- Updated dependencies [9774b78]
+- Updated dependencies [b07d829]
+- Updated dependencies [a648e96]
+- Updated dependencies [a47ac06]
+- Updated dependencies [e4c61a7]
+- Updated dependencies [cc60165]
+- Updated dependencies [081aa6f]
+- Updated dependencies [91f4c78]
+- Updated dependencies [e8d0c21]
+- Updated dependencies [45dc446]
+- Updated dependencies [c1d44f7]
+- Updated dependencies [ab9fb5c]
+- Updated dependencies [f985b3f]
+- Updated dependencies [9a4932a]
+- Updated dependencies [f9fc874]
+- Updated dependencies [011b386]
+- Updated dependencies [9881074]
+- Updated dependencies [7777e8f]
+- Updated dependencies [507b92a]
+- Updated dependencies [7309c81]
+- Updated dependencies [20bc1ec]
+- Updated dependencies [90c2b15]
+- Updated dependencies [39eb01b]
+- Updated dependencies [42eeb7d]
+- Updated dependencies [01e124d]
+- Updated dependencies [7ce02eb]
+- Updated dependencies [a13827e]
+- Updated dependencies [7733604]
+- Updated dependencies [40e420f]
+- Updated dependencies [d13004a]
+- Updated dependencies [be7360c]
+- Updated dependencies [cc2de0e]
+- Updated dependencies [5b47ab5]
+- Updated dependencies [b09d8d9]
+- Updated dependencies [b09d8d9]
+- Updated dependencies [8675db6]
+- Updated dependencies [b09d8d9]
+- Updated dependencies [3eb1b2b]
+- Updated dependencies [59b85c0]
+- Updated dependencies [6e357ed]
+- Updated dependencies [d6938bf]
+- Updated dependencies [31e0be9]
+- Updated dependencies [4bfd455]
+- Updated dependencies [ffd2ce2]
+- Updated dependencies [62f8017]
+- Updated dependencies [a831df1]
+- Updated dependencies [f752ee3]
+- Updated dependencies [a1b61e0]
+- Updated dependencies [cd6b9f2]
+- Updated dependencies [2cb6d3c]
+- Updated dependencies [af2a095]
+- Updated dependencies [ec796d5]
+- Updated dependencies [e87fea1]
+- Updated dependencies [c65e529]
+- Updated dependencies [3ca34c1]
+- Updated dependencies [239c3a3]
+- Updated dependencies [94a0bbc]
+- Updated dependencies [d6bfb3d]
+- Updated dependencies [a2266a6]
+- Updated dependencies [d25a0ec]
+- Updated dependencies [667b83e]
+- Updated dependencies [627b188]
+- Updated dependencies [8d4eae7]
+- Updated dependencies [857a6cf]
+- Updated dependencies [65a3a84]
+- Updated dependencies [d5749d7]
+- Updated dependencies [ccd9397]
+- Updated dependencies [bca935b]
+- Updated dependencies [d92c72d]
+- Updated dependencies [c54c822]
+- Updated dependencies [8dcc0f5]
+- Updated dependencies [75b9e51]
+- Updated dependencies [0a2f233]
+- Updated dependencies [8621cdd]
+- Updated dependencies [6f23667]
+- Updated dependencies [5d21a48]
+- Updated dependencies [19365b7]
+- Updated dependencies [b7ed26d]
+- Updated dependencies [68dea0b]
+- Updated dependencies [64f8cbe]
+- Updated dependencies [b3a3d83]
+- Updated dependencies [7a55913]
+- Updated dependencies [35accbf]
+- Updated dependencies [6038de7]
+- Updated dependencies [eb95d97]
+- Updated dependencies [e4c2dc8]
+- Updated dependencies [1bd2795]
+- Updated dependencies [8186a70]
+- Updated dependencies [a329cca]
+- Updated dependencies [6eec18c]
+- Updated dependencies [4d7bebf]
+- Updated dependencies [821ac7a]
+- Updated dependencies [8f81731]
+- Updated dependencies [4965bfa]
+- Updated dependencies [8b50cb3]
+- Updated dependencies [8c2db68]
+- Updated dependencies [22b5e54]
+- Updated dependencies [0166bd5]
+- Updated dependencies [9b702dc]
+- Updated dependencies [ab16331]
+  - @objectstack/spec@17.0.0-rc.1
+  - @objectstack/platform-objects@17.0.0-rc.1
+  - @objectstack/core@17.0.0-rc.1
+  - @objectstack/metadata-core@17.0.0-rc.1
+  - @objectstack/formula@17.0.0-rc.1
+  - @objectstack/types@17.0.0-rc.1
+
+## 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