CHANGELOG.md

# @objectstack/types

## 18.0.0-next.1

### Minor Changes

- 3c1a046: fix: a route's catch-all `500` answers its own generic text, never the caught error's message, and `@objectstack/types` exports the writer that does it, `sendServerFault`
  
  Clause-②: yes (widening) — `@objectstack/types` gains one export, `sendServerFault`; nothing is removed, renamed or narrowed, and no response field changes shape.
  
  A declared 5xx does not carry the text of the error it caught: that text can name server internals, such as a path, a host or a table. The REST layer already withheld it. The storage, settings and i18n route families and the share-link routes answer in the nested `{ success: false, error: { code, message } }` envelope and did not: their catch-all `500` sent the caught error's message to the caller.
  
  - **What a caller now reads.** The same `status` and `code` as before, with the route's own generic text as `error.message`: `Internal error` on the storage and i18n routes, the route's message on the settings routes (`Failed to list manifests`, `Failed to read namespace`, `Failed to write namespace`, `Action failed`), and the route's `Failed to …` message on the share-link routes. On the storage routes this includes the metadata store's outage sentence, which an operator now reads in the server log.
  - **What the operator reads.** The original error, stack included, in one `[5xx]` server-fault line. The storage byte routes, which already withheld the text, logged two lines per fault and now log one. A line names the mounted route pattern when the route passes one, never the request URL.
  - **Unchanged.** Every `4xx` answer. The settings `SETTINGS_CRYPTO_UNAVAILABLE` refusal, which keeps its prescription. The authorization-store outage `503`, which keeps its declared code and message. The storage `501 NOT_IMPLEMENTED` answers. On the share-link routes, any error that declares its own `status` keeps the envelope it declares.
  - **`sendServerFault(res, status, code, message, thrown, request?)`** (new, `@objectstack/types`): writes `message` in the declared envelope, and hands `thrown` to the server-fault log with its stack, as the fault's one line. Use it for an arm that answers a caught fault. Keep `sendError` for a `4xx` and for a `5xx` whose text you wrote for the reader. `request` is the mounted route pattern, never the request URL.

### Patch Changes

- Updated dependencies [dac99c2]
- Updated dependencies [66949b7]
- Updated dependencies [7958bdf]
- Updated dependencies [777eed2]
- Updated dependencies [5f37d36]
- Updated dependencies [1912af4]
- Updated dependencies [76815b9]
- Updated dependencies [4d1e4a8]
- Updated dependencies [4cc3ff9]
- Updated dependencies [c056979]
- Updated dependencies [4f68ba1]
- Updated dependencies [107853c]
- Updated dependencies [543b33d]
- Updated dependencies [b529a5c]
- Updated dependencies [1623faf]
- Updated dependencies [b4d573a]
- Updated dependencies [c857a93]
- Updated dependencies [345d1be]
- Updated dependencies [430e5f5]
- Updated dependencies [14a13bc]
- Updated dependencies [ca0bdbc]
- Updated dependencies [572ecfb]
- Updated dependencies [707b3cd]
- Updated dependencies [6673c80]
- Updated dependencies [5e725b8]
- Updated dependencies [eeb95f7]
- Updated dependencies [d89f491]
- Updated dependencies [dc39326]
- Updated dependencies [775ed65]
- Updated dependencies [e4ec6ec]
- Updated dependencies [325a92e]
  - @objectstack/spec@18.0.0-next.1

## 18.0.0-next.0

### Minor Changes

- 5cfd866: feat(sharing): a share-link password can be sent in the `X-Share-Password` header whatever its characters, under a declared encoding (`X-Share-Password-Encoding: utf-8`)
  
  Clause-②: yes (widening)
  
  - **What was missing.** A browser cannot put a character above U+00FF in a request header (`Headers` throws a `TypeError` before the request leaves), and it strips leading and trailing spaces. `createLink` accepts any password, so a link whose password has a CJK character or an emoji could not be opened through the header.
  - **What is now accepted.** A new companion request header, `X-Share-Password-Encoding`, declares how `X-Share-Password` is encoded. Its one value is `utf-8`, compared case-insensitively. Under it, `X-Share-Password` carries the password's UTF-8 bytes percent-encoded, as `encodeURIComponent(password)` produces them, and both public routes (`GET /api/v1/share-links/:token/resolve` and `/:token/messages`) decode it on both mounts: the sharing plugin's routes and the runtime dispatcher's `/share-links` domain. Both read the pair through one helper, `readSharePasswordHeader`, exported from `@objectstack/types` with the header-name constants.
  - **Unchanged.** Without `X-Share-Password-Encoding`, `X-Share-Password` is read raw, exactly as before, so every value a client sends today resolves as it did. That includes a Latin-1 password and a raw password containing `%`; the server never percent-decodes a value nobody declared encoded. The `?password=` query parameter is still read first, and when it is present the header pair is not read.
  - **What is refused.** `X-Share-Password-Encoding` naming any other value, or a password header that is not percent-encoded UTF-8 under `utf-8` (a `%` without two hex digits, octets that are not well-formed UTF-8, a character outside visible ASCII), answers `400 VALIDATION_FAILED` before the token is looked up. It is never compared raw instead. The message names the headers and the rule, never the presented value.
  - **Response headers.** Both public routes now answer `Vary: X-Share-Password, X-Share-Password-Encoding`, still beside `Cache-Control: no-store`.
  - **Cross-origin clients.** `X-Share-Password-Encoding` is in the default CORS preflight allow-list (`DEFAULT_CORS_ALLOW_HEADERS` in `@objectstack/plugin-hono-server`, which the `@objectstack/hono` adapter also applies). A deployment that passes its own `allowHeaders` must add `X-Share-Password-Encoding` beside `X-Share-Password` to let a cross-origin client send an encoded password.
- 8f2e808: feat(meta): the `/meta` item read serves the ADR-0008 version token, `If-None-Match: *` pins a save that expects no row, and the 409 `METADATA_CONFLICT` body carries the current version as data
  
  Clause-②: yes (narrowing)
  
  **BREAKING** for two request shapes on `PUT /api/v1/meta/:type/:name` that were answered `200` before this release and are now refused `400 VALIDATION_ERROR`, with nothing written: an `If-None-Match` header whose value is anything but `*` (an entity-tag, a list, a weak `W/"*"`, an empty value), and an `If-None-Match` header sent beside `If-Match`. Before, the door did not read `If-None-Match` at all and wrote the body, unguarded or under the `If-Match` alone. The remedy: send `If-None-Match: *` alone to save only where no row exists, or `If-Match` with the version you read alone to save only over that version. No first-party client sends `If-None-Match` on a `PUT`: the SDK sends it only on its cached `GET`, and objectui's ETag hook has no caller.
  
  ADR-0008's optimistic lock on `PUT /api/v1/meta/:type/:name` takes the version a client read as `If-Match`, but a client can only send a token it was served, and only a save receipt served one. So the first save after a load could not be pinned: two editors who each loaded an item and saved once overwrote each other. Three additions close that.
  
  - **The read serves the token.** `GET /meta/:type/:name` now carries `version` (declared on `GetMetaItemResponseSchema`): the keyed token of the stored row a save to this item would compare against, at the read's scope (the caller's organization partition and `?package=`) and lifecycle (`?state=draft` for the draft row, the plain read for the active row). It is the same producer and the same row as the save receipt's `version`, so a read after a save serves the receipt's token byte for byte. Send it back as `If-Match`. `null` means no stored row is there (an item served from code or a package artifact, or from a row in a scope the save does not write), so the next save is a create. The cached published-value branch (the default plain read) and `?preview=draft` publish no `version`, as they publish no `lock`; their `ETag` stays the cache validator and is not the token.
  - **"Expect no row" can be said.** `If-None-Match: *` on `PUT /meta/:type/:name` (with `?mode=draft` for a draft) saves only where no row of that lifecycle exists, and is refused `409 METADATA_CONFLICT` once one does. This is the `parentVersion: null` pin `SaveMetaItemRequestSchema` already declared, now reachable over HTTP. The header takes `*` alone: any other value, or `If-None-Match` beside `If-Match`, is refused `400 VALIDATION_ERROR` and nothing is written. No first-party client sends `If-None-Match` on a `PUT`. A save with neither header is last-writer-wins, as before.
  - **The conflict body names the current version as data.** The 409 of the `/meta` item write doors (save, publish, rollback, reset) now carries `currentVersion` beside the unchanged `error` sentence: the token the sentence names, or `null` when no row of the target lifecycle exists (declared as `MetadataConflictErrorSchema`). On the save door it equals the token the next read at the same address serves, so a client offering "reload" or "overwrite" re-pins without parsing prose. The SDK already exposes it as `err.details.currentVersion`.
  - **The receipts' `version` describes are corrected.** `SaveMetaItemResponseSchema.version`, `PublishMetaItemResponseSchema.version` and the package publish door's `published[].version` said "Content hash … currently emitted as `sha256:`" and "409 `metadata_conflict`". The token has been the keyed `hmac-sha256:` digest of the stored content hash since the doors stopped serving the raw hash, and the conflict code on the wire is `METADATA_CONFLICT`. Only the description text moves.
  
  <!-- adr-0087: not-required (no-migration-prescription) A refusal at one runtime write door of two request-header shapes that door never read, not a metadata change: no spec key, export, response field or stored shape is removed, renamed or re-shaped, so there is no tombstone and nothing for `objectstack migrate meta` to rewrite. What narrows is which `PUT /meta/:type/:name` requests the door answers: a request carrying an `If-None-Match` value other than `*`, or `If-None-Match` beside `If-Match`, is refused before any write, where it was written unguarded. The remedy is a choice of precondition only the client can make (which of the two it meant), so no conversion entry can derive it. Census: measured on this repo at the merge base, no first-party sender puts `If-None-Match` on a `PUT` (`@objectstack/client` sends it only from `meta.getCached`, a `GET`); on the objectui checkout, `useETagCache` sets it and has zero in-repo callers. Not measured: third-party and hosted-tenant HTTP clients. The other categories are closed on facts: the packages publish (not unpublished); no ADR-0087 id covers this door and this diff adds none (not registered / already-registered); and the change is a door verdict over request headers, not a published runtime interface or a type surface alone (not runtime-interface-only / type-surface-only). -->
- a45d5d8: fix(auth): a server-side session read no longer renews a browser session behind its cookie (#22258)
  
  **What was wrong.** better-auth's `getSession` renews a session older than `session.updateAge`: it moves `sys_session.expires_at` to `now + expiresIn` and stages the renewed session cookie on that call's own response. Ten doors read the session in-process (`auth.api.getSession`) and answer with their own response, so the renewal landed in the database and its cookie was discarded. The browser kept its old cookie, later `GET /api/v1/auth/get-session` calls found a fresh row and re-issued nothing, and the cookie expired first: a dead cookie beside a live bearer, and every cookie-only path then saw a signed-out user. Measured on a fresh dev stack (better-auth 1.7.3, `expiresIn` 604800 s, `updateAge` 86400 s, a session aged to `now + expiresIn − updateAge − 60 s`): `GET /api/v1/data/:object`, `GET /api/v1/auth/me/permissions`, `GET /api/v1/meta/object`, `GET /api/v1/i18n/locales`, `GET /api/v1/packages`, `GET /api/v1/marketplace/install-local` and the MCP door each moved `expires_at` by +86460 s and set no session cookie.
  
  **The rule now, decided by what the request carries.**
  
  - **A session cookie** (a browser, including a console that sends its cookie beside its bearer): the in-process read passes `query.disableRefresh`. The session renews only through `GET /api/v1/auth/get-session`, which re-issues the cookie with `Max-Age = expiresIn`, so cookie and session expire together. Measured after the change: every door above leaves `expires_at` unchanged on a cookie request and sets no cookie.
  - **No session cookie** (a bearer-only client: `@objectstack/client` outside a browser, the `os` CLI): unchanged. A data read past `updateAge` still renews the session (+86460 s, measured on the same doors), so an active bearer client keeps sliding forward without calling `get-session`. No cookie is ever set on a response to a request that sent none.
  
  **Upgrading.** Nothing to change. A browser session renews whenever the app calls `GET /api/v1/auth/get-session`; a tab that never calls it now signs out at the session's real expiry instead of keeping a live bearer beside a dead cookie.
  
  `@objectstack/types` gains `inProcessSessionReadInput(headers)` (the `getSession` input for an in-process read: the request's own headers, plus `query: { disableRefresh: true }` when they carry a better-auth session cookie), `carriesSessionCookie(headers)` and the `InProcessSessionReadInput` type. A host that calls `auth.api.getSession` itself should read through `inProcessSessionReadInput` for the same reason.
  
  The same rule is applied to the in-process `auth.api.getSession` readers in `@objectstack/plugin-auth`, `@objectstack/plugin-webhooks`, `@objectstack/plugin-sharing`, `@objectstack/service-storage`, `@objectstack/service-settings` and `@objectstack/service-datasource` by their own changeset.
- 6d5191e: An import row for the sandbox's own fault reads the create door's fault sentence, not the runner's diagnostic text (#22741)
  
  Clause-②: yes (widening)
  
  The QuickJS runner raises some `SandboxError`s itself: a hook or action body that runs past its CPU budget or past the wall-clock ceiling, calls a capability it was not granted, or meets a failed install or marshal. These carry no `innerMessage`. `POST /api/v1/data/:object` and `/createMany` answer them `500 INTERNAL_ERROR` `Internal server error`. The sync `/import` row and the `/import/jobs` stored row answered the runner's text instead, for example `hook 'guard' exceeded CPU budget of 50ms (after 3 pump iterations)`.
  
  - **`@objectstack/types`** exports `isSandboxOwnFault(error)`. It is `true` for an error whose `name` is `'SandboxError'` and whose `innerMessage` is not a non-empty string, which is how the runner marks the faults it raises itself. A body's refusal or crash carries `innerMessage` and answers `false`.
  - **`@objectstack/core`**'s import row applies the rule a crashed body already gets: when the sandbox raised the error and the create door answers it with a 5xx, the row's `error` is the door's sentence. The row's `code` is unchanged (`IMPORT_ROW_FAILED`). A driver error, and an error a code-defined hook threw, keep the row text they had.

### Patch Changes

- ec7c7e0: fix(types): a thrown exposure refusal about a second object names that object on the REST body (#22737)
  
  The shared REST error classification gains one arm for `OBJECT_API_DISABLED` and `OBJECT_API_METHOD_NOT_ALLOWED`. Both REST error doors ask it: `mapDataError`, and `resolveErrorResponse` behind `sendThrownError`.
  
  When the thrown error names an object other than the one the route addressed, the body's `object` is that object, and a `405` carries the effective operation set as `allowed`. The generic data door throws this when a nested-relation condition's related object is not served by the API. The new body is the same one the REST door already sends for these codes about the addressed object. Before, the body named the route's object beside a code saying that object was switched off.
  
  An error naming the route's own object, or a door given no route object, answers exactly as before. No code is added.
- 8bc7836: fix(types): the data door answers the sandbox's own fault as a fault, not as "this object does not exist" (#22868)
  
  Clause-②: no
  
  **What was wrong.** The QuickJS runner raises some `SandboxError`s itself. These carry no `innerMessage`. Two of them name the object the hook body addressed: a denied capability on `ctx.api.object(...)` (`capability 'api.read' not granted to hook 'guard' (called ctx.api.object('account').find)`) and a `ctx.api` method the host does not implement (`ctx.api.object('account').find not implemented`). When that object was the one the request named, `mapDataError` read the quoted object name plus the word `not` as an unknown object. `POST /api/v1/data/account` then answered `404 OBJECT_NOT_FOUND` with `Object 'account' is not registered`. Every other runner fault already answered `500 INTERNAL_ERROR`, which is what the runner's contract says these errors are.
  
  **What changes.** `mapDataError` checks `isSandboxOwnFault` first, next to the existing check for a sandboxed body that crashed. An error the sandbox raised itself now answers `500 INTERNAL_ERROR` with `Internal server error`, whatever its text names. The runner's text goes to the server log only. The sync `/import` row and the `/import/jobs` stored row read that same sentence.
  
  **Unchanged.** A driver's unknown-object text (`no such table: account`, `relation "account" does not exist`) still answers `404 OBJECT_NOT_FOUND`. So does the same wording thrown by anything other than the sandbox: the check reads the error's producer, not its words. A hook body's refusal keeps its sentence and status, and a crash keeps its `500`.
- Updated dependencies [317cddd]
- Updated dependencies [fec87e7]
- Updated dependencies [0253192]
- Updated dependencies [bfc15d2]
- Updated dependencies [7aa8d51]
- Updated dependencies [95a8435]
- Updated dependencies [60bcfe7]
- Updated dependencies [d112087]
- Updated dependencies [4806b18]
- Updated dependencies [1802315]
- Updated dependencies [06cc45d]
- Updated dependencies [7de0265]
- Updated dependencies [7895671]
- Updated dependencies [b389e43]
- Updated dependencies [c8b062f]
- Updated dependencies [117d34d]
- Updated dependencies [6729e10]
- Updated dependencies [1920cf3]
- Updated dependencies [41d0d40]
- Updated dependencies [c52bfb4]
- Updated dependencies [c7d6037]
- Updated dependencies [72b26ed]
- Updated dependencies [2d21b9c]
- Updated dependencies [f66fdc7]
- Updated dependencies [9fdb127]
- Updated dependencies [615c696]
- Updated dependencies [968acc8]
- Updated dependencies [111ffff]
- Updated dependencies [12b9daf]
- Updated dependencies [d85615d]
- Updated dependencies [6a06e3b]
- Updated dependencies [0e9e7b7]
- Updated dependencies [0af4f66]
- Updated dependencies [9a0401f]
- Updated dependencies [9c93ce6]
- Updated dependencies [ac9f8bd]
- Updated dependencies [04e776b]
- Updated dependencies [a7df552]
- Updated dependencies [2f70c22]
- Updated dependencies [78f841b]
- Updated dependencies [c565813]
- Updated dependencies [d5a14dd]
- Updated dependencies [93125ae]
- Updated dependencies [56c8844]
- Updated dependencies [d4680d2]
- Updated dependencies [cdeabec]
- Updated dependencies [d7c5c33]
- Updated dependencies [a87d8be]
- Updated dependencies [15ec50e]
- Updated dependencies [db4c45b]
- Updated dependencies [51290bc]
- Updated dependencies [ad381fd]
- Updated dependencies [2b61f2d]
- Updated dependencies [8f2e808]
- Updated dependencies [3b49318]
- Updated dependencies [4e9fe9f]
- Updated dependencies [9ad3d24]
- Updated dependencies [326a90a]
- Updated dependencies [9fe7448]
- Updated dependencies [2e11d90]
- Updated dependencies [4578c56]
- Updated dependencies [c512c25]
- Updated dependencies [215e662]
- Updated dependencies [3d886ee]
- Updated dependencies [d8d0711]
- Updated dependencies [40a6ee5]
- Updated dependencies [5910b5e]
- Updated dependencies [081e6a0]
- Updated dependencies [1884948]
- Updated dependencies [e23eccb]
- Updated dependencies [ac8f2c5]
- Updated dependencies [db9cf80]
- Updated dependencies [e75dced]
- Updated dependencies [9af0005]
- Updated dependencies [440bed6]
- Updated dependencies [b2549a8]
- Updated dependencies [ee8751d]
- Updated dependencies [96e4be4]
- Updated dependencies [35ef501]
- Updated dependencies [faf6348]
- Updated dependencies [557ae7c]
- Updated dependencies [6a3fe25]
- Updated dependencies [7731d70]
- Updated dependencies [3073b72]
- Updated dependencies [c76edeb]
- Updated dependencies [5b12503]
- Updated dependencies [514bf3c]
- Updated dependencies [20e7d52]
- Updated dependencies [b3a3634]
- Updated dependencies [3e72f93]
- Updated dependencies [f89b5f5]
- Updated dependencies [d25b187]
- Updated dependencies [0e00d36]
- Updated dependencies [d748ae8]
- Updated dependencies [dab6bf4]
- Updated dependencies [ed1de8c]
- Updated dependencies [a00cf99]
- Updated dependencies [5fb1746]
- Updated dependencies [29a163f]
- Updated dependencies [e223152]
- Updated dependencies [9f5eca5]
- Updated dependencies [9963322]
- Updated dependencies [b27b894]
- Updated dependencies [02d9f69]
- Updated dependencies [f53f14b]
- Updated dependencies [a800912]
- Updated dependencies [d973c34]
- Updated dependencies [156ddfa]
- Updated dependencies [5081090]
- Updated dependencies [b6eb25f]
- Updated dependencies [165587e]
- Updated dependencies [e04759d]
- Updated dependencies [ea9fd99]
- Updated dependencies [b32ee3e]
- Updated dependencies [e5899a6]
- Updated dependencies [490cb6d]
- Updated dependencies [e865300]
- Updated dependencies [ec7c7e0]
- Updated dependencies [85edd61]
- Updated dependencies [e84aeb3]
- Updated dependencies [322ff1e]
- Updated dependencies [5fc57b3]
- Updated dependencies [581ca7d]
- Updated dependencies [3f0b6f2]
- Updated dependencies [9814035]
- Updated dependencies [55382dc]
- Updated dependencies [b1d701b]
- Updated dependencies [efcbac7]
- Updated dependencies [20028df]
- Updated dependencies [69d4218]
- Updated dependencies [5ce6773]
- Updated dependencies [9432bac]
- Updated dependencies [3f69471]
- Updated dependencies [e5687cb]
- Updated dependencies [1e62f71]
- Updated dependencies [ec7f7f8]
- Updated dependencies [038d4c9]
- Updated dependencies [147a0d1]
- Updated dependencies [1959aac]
- Updated dependencies [1badd31]
- Updated dependencies [55828c5]
- Updated dependencies [7856110]
- Updated dependencies [9b37edb]
- Updated dependencies [a22e67b]
- Updated dependencies [62ce45d]
- Updated dependencies [39e93ef]
- Updated dependencies [02bec6c]
- Updated dependencies [719183f]
- Updated dependencies [8464380]
- Updated dependencies [252a582]
- Updated dependencies [f931e76]
- Updated dependencies [e5f9f01]
- Updated dependencies [ef1fcb2]
- Updated dependencies [ace0a53]
- Updated dependencies [de70e97]
- Updated dependencies [74c4b34]
- Updated dependencies [e040b8c]
- Updated dependencies [f451a59]
- Updated dependencies [ba95607]
- Updated dependencies [b53b949]
- Updated dependencies [ea9fd99]
- Updated dependencies [1e44436]
- Updated dependencies [2acff87]
- Updated dependencies [299a2c6]
- Updated dependencies [e23eccb]
- Updated dependencies [bf492c8]
  - @objectstack/spec@18.0.0-next.0

## 17.7.0

### Minor Changes

- 748b240: feat(types,automation): a host's per-kernel scheduled-work OFF reports the host's own reason (#21110)
  
  Clause-②: yes (widening)
  
  `ScheduledWorkPolicy` (`@objectstack/types`) gains an optional
  `hostDisabledReason`: the host's own sentence for why scheduled work is off on
  this kernel, such as a plan that does not include scheduled flows. A new
  export, `scheduledWorkDisabledReason(policy)`, gives the one answer for why
  scheduled work is not armed under a policy. It returns the host's reason when
  the policy carries one, and `SCHEDULED_WORK_DISABLED_REASON` otherwise.
  
  Every refusal site now reports that answer, read from the same policy reading
  that refused:
  
  - the automation engine's bind log;
  - the reason it records for `getTriggerBindingAudit()` and for the
    `FlowRuntimeState.reason` that `GET /automation/_status` serves;
  - the refusal of `ScheduleTrigger` and `TimeRelativeTrigger` when a host drives
    them directly.
  
  Before this, a kernel that a host turned off through `scheduledWorkPolicy`
  was reported with the deployment sentence. That sentence tells the reader to
  set `OS_AUTOMATION_SCHEDULED_WORK_ENABLED=true`, even on a process where the
  variable is already set, and to a tenant who cannot set it.
  
  Nothing changes without the new field. A policy with no `hostDisabledReason`,
  and the zero-argument deployment resolver `resolveScheduledWorkPolicy()`, which
  never sets it, report `SCHEDULED_WORK_DISABLED_REASON` byte for byte. The field
  is read only when `enabled` is `false`.
  
  To use it, a host that turns one kernel off for its own reason sets
  `hostDisabledReason` on the `enabled: false` policy it already hands to that
  kernel's `AutomationServicePlugin`, `ScheduleTriggerPlugin` and
  `TimeRelativeTriggerPlugin`. Give the same policy to all three, as before, and
  make the reason a whole sentence that names the cause and the remedy. It is
  shown verbatim.
- 6d728b8: feat(types): the driver-fault redaction is exported from types, so a driver's own log lines take the same cut the engine applies
  
  Clause-②: no
  
  - **New exports.** `redactBoundStatement`, `redactStatementFromMessage`, `redactPropagatedDriverFault` and the `DriverFaultOrigin` type are exported from `@objectstack/types`, by name. They moved here from `@objectstack/objectql`, which never exported them from its entries. The cut is unchanged by the move: the same split, the same structural cut at the separator, the same value templates and the same property rules.
  - **Why here.** `@objectstack/driver-sql`, `@objectstack/objectql` and `@objectstack/core` all depend on this package, and `operatorFacingErrorText` lives in it, so this is the lowest package all of them can import the cut from. The module imports only this package's own leak predicate, which is unchanged.
  - **One widening, on the log face.** `redactStatementFromMessage` takes an optional second argument, `{ statementSent: true }`. With it the cut runs without asking the shared leak predicate, as `redactPropagatedDriverFault` already did with the same flag. Without it the function answers exactly as before.
  - **Why minor.** The package gains four exported names, and `redactStatementFromMessage` gains the optional parameter above. No existing export of `@objectstack/types` changes.

### Patch Changes

- 85e29b8: fix(types): `operatorFacingErrorText` answers through the driver-fault redaction, so an operator-facing record carries no statement and no bound value
  
  Clause-②: no
  
  - **What changed.** `operatorFacingErrorText` passes every text it returns through `redactStatementFromMessage`, the one driver-fault redaction in this package. Text it reads off a raw-statement fault's `cause` is cut with `{ statementSent: true }`, which is the cut `@objectstack/driver-sql` applies to its own log line for the same fault. Every other text asks the shared leak predicate, as the engine's own log line does.
  - **What an operator reads now.** The records this helper fills, in `os db clean` and in the metadata migrations and probes, keep the dialect's own diagnostic: the missing column, the failed constraint or the locked database. The value slots the redaction's dialect templates own are cut from it, and the redaction's marker stands where the statement was removed. The records no longer carry the statement or the values bound into it.
  - **What does not change.** Text that is not a driver dump comes back exactly as before, empty text included. The thrown error is not touched: its `code`, `status`, class and `cause` reach every other reader as the driver composed them. The function's signature and the package's exports are unchanged.
- 149153c: Membership under the `auto` policy is settled when the user is created, per ADR-0093 D7.
  
  Clause-②: yes (widening)
  
  - **At creation.** A user created under `auto` is bound to the default organization at creation, and the first session of that creating request carries it. Membership is not decided again when the user signs in later.
  - **One-time backfill.** The ADR-0093 D6 backfill of pre-existing users runs once per deployment, and once per process even if its record cannot be written. Its verdict is recorded in the `sys_migration` ledger with id `adr-0093-membership-backfill`. A pass on a deployment with no organization at all records nothing, and the backfill runs again once the default organization is created. If the ledger is missing or cannot be read, the pass does not run and logs a warning. If the record cannot be written, that is logged as an error. `OS_SKIP_MEMBERSHIP_BACKFILL=1` still disables the pass.
  - **Default organization owner.** The platform admin is bound as owner of the default organization once, by the bootstrap that first decides it, in both the single-org and the walled organizations wiring. The decision is recorded in the same ledger with id `adr-0093-default-org-owner-bind` and held for the rest of the process even if the record cannot be written. After that, a missing default organization is recreated without binding anyone. To recover, an administrator re-adds members, including themselves, through member management. On a kernel without the ledger, the owner is bound only when the bootstrap creates the default organization. If the ledger exists but cannot be read, that call binds nobody and the next trigger decides.
  - **Full scan.** The backfill reads the user and membership tables page by page with no row cap. A scan that cannot read either table in full binds nobody and records nothing. With organizations present but no default target, as in multi-organization deployments, the refusal is recorded.
  - **Upgrade.** The first boot of an upgraded deployment runs the backfill once.
  - **Unchanged.** `invite-only` binds nobody. Multi-organization deployments get no automatic binding. Users created through sign-up, admin create-user, import or SSO are bound under `auto` as before.
  - **Narrowed.** A `sys_user` row inserted straight through the data engine never passes through user creation. Once the backfill is recorded, a later `app:seeded` pass leaves it unbound. That includes users written by a seed that finishes after its inline budget. Code that inserts users this way must write their membership itself; the showcase approval-demo personas now do.
  - **`keysetWalk` (`@objectstack/types`).** The walk now decides that a page did not advance only when it gets back the same cursor key or the same page again. It no longer compares keys in JavaScript string order, which disagrees with database collations and could report a healthy walk as truncated.
  - **New public surface of `@objectstack/plugin-auth` (additive).**
    - `createEnsureDefaultOrganizationOnce` and `EnsureDefaultOrganizationOnceOptions` are the gated bootstrap both wirings call.
    - `ObjectQLAdapterFactoryOptions` adds `onRecordCreated`, passed as the new optional second argument of `createObjectQLAdapterFactory`.
    - `EnsureDefaultOrganizationOptions` gains `bindOnlyOnCreate` and `bindOwner`.
    - `EnsureDefaultOrganizationResult.reason` gains `'owner_bind_decided'`.
    - `BackfillMembershipsResult.reason` gains `'scan-incomplete'`.
    - Code that switches exhaustively over those reasons sees one more member.
  - **`backfillMemberships` (exported) changed behaviour.** Its `limit` option used to cap the rows scanned (default 5000); it is now the page size of a full scan with no cap. The function now needs a reader that can page by `id`; a reader that cannot gets `scan-incomplete` and binds nobody, where it used to bind. A direct call is not gated by the one-time ledger and decides membership again on every call; call it through the one-time pass instead.
  - **Policy switch.** Once a pass under `invite-only` is recorded, switching the policy to `auto` later does not backfill the users who existed then; they get membership through invitation or member management.
  - **Deprecated, not removed.** The ungated `ensureDefaultOrganization`, both plugin-auth's helper and the `@objectstack/organizations` wrapper, is `@deprecated` in favour of `createEnsureDefaultOrganizationOnce`.
- Updated dependencies [ecb6ca0]
- Updated dependencies [135daaa]
- Updated dependencies [22c2d6f]
- Updated dependencies [909229e]
- Updated dependencies [0721848]
- Updated dependencies [bdd3654]
- Updated dependencies [aead296]
- Updated dependencies [ad7c351]
- Updated dependencies [e901c27]
- Updated dependencies [a387354]
- Updated dependencies [f6b7520]
- Updated dependencies [36e4647]
- Updated dependencies [93a54b8]
- Updated dependencies [f623e2f]
- Updated dependencies [96a9719]
- Updated dependencies [41a3c8d]
- Updated dependencies [c52c49d]
- Updated dependencies [cfa4d74]
- Updated dependencies [99589f9]
- Updated dependencies [36ad321]
- Updated dependencies [dcc5ef4]
- Updated dependencies [9b7a0ef]
- Updated dependencies [5a9292e]
- Updated dependencies [1c52a5e]
- Updated dependencies [99e1912]
- Updated dependencies [7ebb543]
- Updated dependencies [3911901]
- Updated dependencies [222ecc2]
- Updated dependencies [3937ad2]
- Updated dependencies [3a6d92f]
- Updated dependencies [7526058]
- Updated dependencies [53fd35e]
- Updated dependencies [23365ea]
- Updated dependencies [32d5769]
- Updated dependencies [16eefc6]
- Updated dependencies [6e33b67]
- Updated dependencies [57cc695]
- Updated dependencies [db3fee3]
- Updated dependencies [4c8363f]
- Updated dependencies [9f13c94]
- Updated dependencies [6d67ad5]
- Updated dependencies [ca0dfb6]
- Updated dependencies [45efcfa]
- Updated dependencies [c9c555a]
- Updated dependencies [68c5ab7]
- Updated dependencies [b793010]
- Updated dependencies [5555047]
- Updated dependencies [aa46322]
- Updated dependencies [100c394]
- Updated dependencies [72217cd]
- Updated dependencies [72af58c]
- Updated dependencies [1289925]
- Updated dependencies [958cfe2]
- Updated dependencies [ced3e1a]
- Updated dependencies [7d674df]
- Updated dependencies [3f1bc81]
- Updated dependencies [72f3c74]
- Updated dependencies [529d971]
- Updated dependencies [16d241a]
- Updated dependencies [4331a6b]
- Updated dependencies [6c5697d]
- Updated dependencies [9a4182a]
- Updated dependencies [41b1333]
- Updated dependencies [f1e4ae5]
- Updated dependencies [eb9ef79]
- Updated dependencies [f83d066]
- Updated dependencies [9e9d693]
- Updated dependencies [6ec54f0]
- Updated dependencies [98eb3b9]
- Updated dependencies [a2aadab]
- Updated dependencies [fe10172]
- Updated dependencies [ed15448]
- Updated dependencies [9d91f58]
- Updated dependencies [9059082]
- Updated dependencies [309224d]
- Updated dependencies [e83c9f6]
- Updated dependencies [045f764]
- Updated dependencies [2df3d13]
- Updated dependencies [07bf21f]
- Updated dependencies [6fb7115]
- Updated dependencies [53021e3]
- Updated dependencies [ba57588]
- Updated dependencies [a43d90a]
- Updated dependencies [607463d]
- Updated dependencies [cab6396]
- Updated dependencies [e864db5]
- Updated dependencies [866683f]
- Updated dependencies [88a39c0]
- Updated dependencies [8e35895]
- Updated dependencies [1f04696]
- Updated dependencies [bab7685]
- Updated dependencies [fb69825]
- Updated dependencies [48eb9c1]
- Updated dependencies [8832655]
- Updated dependencies [100f68b]
- Updated dependencies [8963dbf]
- Updated dependencies [1354e7b]
- Updated dependencies [1cbe165]
- Updated dependencies [15fe567]
- Updated dependencies [0bddffd]
- Updated dependencies [7e0066a]
  - @objectstack/spec@17.7.0

## 17.6.0

### Minor Changes

- 8368f1c: feat(types): the data-error classification table (`mapDataError` and its judgements) is exported from `@objectstack/types` (#20919)
  
  The classification half of `@objectstack/rest`'s error boundary — `mapDataError`
  (a thrown error → the `{ status, body }` ADR-0112 answer, without emitting it),
  `declaredHttpStatus`, `declaredServerFaultAnswer`, `sandboxBusinessMessage`,
  `boundedDeclaredUserMessage`, `boundedDeclaredRefusalMessage` and
  `isEngineDuplicateRecordEnvelope` — moved here unchanged, beside the primitives it
  composes, so the bulk-import runner in `@objectstack/core` judges a failed row with
  the same table the REST door answers with. `@objectstack/rest` keeps the emitters
  and re-exports every name it exported before. The module also exports the eight
  helpers the REST emitters compose (`truncateClientMessage`, `thrownCodeFields`,
  `withoutDeclaredCodePrefix`, `withDeclaredUserMessage`, `isSandboxOrigin`,
  `isSandboxCrash`, `fiveXxArmDisplacesDeclared4xx`, `structuredCodeAnswer`).

### Patch Changes

- b9087d7: CLI help, warnings and refusals no longer cite tracker numbers; each one states the decision behind it in words
  
  Clause-②: no
  
  Several lines the CLI prints sent the reader to an issue-tracker number for the reason behind them. The number goes; where the sentence did not already say what was decided, it now does.
  
  - `os build` / `os validate`: the provider preflight step now reads "Checking that every required capability has a provider installable in this edition...", and the undeclared-key header reads "Undeclared authoring keys (N) — dropped at load; reported here, never refused".
  - `os doctor`: the retired `referenceFilters` row now says the key was removed from FieldSchema as a key no runtime read; the `NODE_ENV` and config-load rows drop their citations.
  - `os serve`: the no-auth refusal says anonymous data access is always denied with no setting that turns that off; the organizations remedies drop their citations.
  - `os meta resync`, `os db clean` and the `os migrate duplicates` / `multi-value-columns` / `recorded-by` / `summary-nulls` descriptions, the `os dev --restart` flag help, the `os storage orphans` closing line and the storage-driver refusals each say what was decided instead of citing it.
  - `os serve`'s unknown-hostname 404 page spells its three short grey colours in six hex digits; they render the same.
  - `@objectstack/types`: the host importer's undeclared-package message says the fallback resolves from the caller once `fallbackImport` is passed, and drops the citation beside "Being merely REACHABLE is not enough".
  
  Text only: no exit code, error code, flag, field or control flow moves. A script that matches the old CLI text (for example the "Checking capability providers" step line) needs the new spelling.
- 00f045d: Provenance comments in `@objectstack/types` were re-anchored
  
  Comment and docblock lines under `src/` that cited tracker numbers which no
  longer resolve on GitHub now cite the commit in this repository's history that
  decided the matter, and say in their own words what was decided. Comments
  only: no error code, refusal text, type, export or runtime behaviour changes.
- Updated dependencies [e5c7d07]
- Updated dependencies [addbbf0]
- Updated dependencies [93d4e0e]
- Updated dependencies [88b484e]
- Updated dependencies [9905e61]
- Updated dependencies [f11b5f2]
- Updated dependencies [0cb72cf]
- Updated dependencies [c1d8051]
- Updated dependencies [a918fe7]
- Updated dependencies [41dcf11]
- Updated dependencies [c46279f]
- Updated dependencies [688ddef]
- Updated dependencies [b1aab1e]
- Updated dependencies [274e162]
- Updated dependencies [0efbdc3]
- Updated dependencies [c8dd8dd]
- Updated dependencies [03cdb9a]
- Updated dependencies [15b586d]
- Updated dependencies [542670d]
- Updated dependencies [e73ee2d]
- Updated dependencies [92fe081]
- Updated dependencies [c4c68ca]
- Updated dependencies [d78a0bd]
- Updated dependencies [5363e2d]
- Updated dependencies [c876a74]
- Updated dependencies [f1e921a]
- Updated dependencies [7a1faf1]
- Updated dependencies [c9d234c]
- Updated dependencies [24d521e]
- Updated dependencies [3a89d45]
- Updated dependencies [f379f57]
- Updated dependencies [05cb2bc]
- Updated dependencies [7510663]
- Updated dependencies [1a75e39]
- Updated dependencies [d7631d5]
- Updated dependencies [d830d71]
- Updated dependencies [1ab9892]
- Updated dependencies [fbec216]
- Updated dependencies [35587f7]
- Updated dependencies [ace770d]
- Updated dependencies [ed54768]
- Updated dependencies [99786f9]
- Updated dependencies [63bfe69]
- Updated dependencies [1940afd]
- Updated dependencies [4f83db5]
- Updated dependencies [f5c7b2c]
- Updated dependencies [6afccda]
- Updated dependencies [671d4c1]
- Updated dependencies [bbcd20c]
- Updated dependencies [c8111a5]
- Updated dependencies [9ad6544]
- Updated dependencies [c9c182e]
- Updated dependencies [4b4ee88]
- Updated dependencies [f10d802]
- Updated dependencies [93e9e42]
- Updated dependencies [ca5408c]
- Updated dependencies [b280546]
- Updated dependencies [975b248]
- Updated dependencies [ebb66aa]
- Updated dependencies [ceee88f]
- Updated dependencies [e18fea6]
- Updated dependencies [f750119]
- Updated dependencies [660a9b2]
- Updated dependencies [f6ccca4]
- Updated dependencies [26437ae]
- Updated dependencies [32d3b3c]
- Updated dependencies [c6b3a01]
- Updated dependencies [bee75ce]
- Updated dependencies [2742e53]
- Updated dependencies [a75311d]
- Updated dependencies [d98bf24]
- Updated dependencies [8368f1c]
- Updated dependencies [31c3996]
- Updated dependencies [95555e7]
- Updated dependencies [a29a0ea]
- Updated dependencies [83480c6]
- Updated dependencies [013f97d]
- Updated dependencies [5d5e679]
- Updated dependencies [e07566b]
- Updated dependencies [11d28c1]
- Updated dependencies [399e3aa]
- Updated dependencies [ba03198]
- Updated dependencies [94608a7]
- Updated dependencies [b3d7a70]
- Updated dependencies [b3917d9]
- Updated dependencies [c27404f]
- Updated dependencies [27c0cf3]
- Updated dependencies [70dae53]
- Updated dependencies [665cab3]
- Updated dependencies [62b90d7]
- Updated dependencies [cb45469]
- Updated dependencies [f3b16fc]
- Updated dependencies [d6d6e87]
- Updated dependencies [df1feae]
- Updated dependencies [336e191]
- Updated dependencies [9bdc6d3]
- Updated dependencies [24c554d]
- Updated dependencies [3dc33b2]
- Updated dependencies [9969228]
- Updated dependencies [95e24b0]
- Updated dependencies [1a4c7f8]
- Updated dependencies [c7396f1]
- Updated dependencies [434c6c7]
- Updated dependencies [4b59a38]
- Updated dependencies [cfa9315]
- Updated dependencies [0803a8b]
- Updated dependencies [0d42104]
- Updated dependencies [a3d7588]
- Updated dependencies [b8191f7]
- Updated dependencies [315888d]
- Updated dependencies [1741c5d]
- Updated dependencies [3711e0b]
- Updated dependencies [a8acee2]
- Updated dependencies [a51920f]
- Updated dependencies [0f6dcac]
- Updated dependencies [682873f]
- Updated dependencies [2123fcc]
  - @objectstack/spec@17.6.0

## 17.5.0

### Minor Changes

- 758ac40: refactor(types): one `isNativeErrorName` reader, so three doors cannot disagree about what a crash is (#17681)
  
  The predicate that decides whether a sandboxed body's `throw` is a business
  REFUSAL (4xx, the author's words relayed) or a CRASH (5xx, the words withheld)
  had **three byte-identical copies** — measured, one distinct 74-character regex
  literal across three packages:
  
  | copy | package | its stated reason for being a copy |
  |:--|:--|:--|
  | `isScriptFaultMessage` | `@objectstack/rest` (`error-response.ts`, #7543) | the original |
  | `isScriptCrash` | `@objectstack/objectql` (`hook-withheld-readonly-fault.ts`) | this package must not depend on `@objectstack/rest` for a regex |
  | `sandboxRefusalMessage` | `@objectstack/runtime` (`sandbox/quickjs-runner.ts`, #17265) | rest declares one export subpath and re-exports nothing from `error-response` |
  
  ⭐ **Every reason is a statement about reaching `@objectstack/rest`, and none of
  them survives moving the rule.** `@objectstack/types` now owns
  `isNativeErrorName` — the name list, the `^` anchor, and the deliberate absence
  of a bare `Error:`. All three packages already depend on it and it depends on
  none of them, so this fold **adds zero dependency edges** and cannot cycle.
  
  ⚠️ The hazard was never style. One copy learning a new native error name and the
  others not means the same throw is a refusal at one door and a crash at the
  next — a crash message **leaked** at one boundary and **withheld** at another.
  #16013's argument for extracting exactly this class applies verbatim: the
  classification is the part nobody may get wrong, so one *tested* helper is worth
  more than N correct copies that must each stay correct forever.
  
  ⛔ **No behaviour changes at any door, per case.** This is a pure refactor and
  the three WRAPPERS are deliberately NOT folded, because they are not the same
  shape and merging them would move a door's answer:
  
  - rest asks a trimmed message and answers a boolean;
  - objectql asks **two** slots — `err.name` **or** `err.innerMessage.trim()` —
    because a code hook and a sandboxed body carry the native name in different
    places;
  - runtime asks the trimmed inner message and answers the **message**, not a
    boolean.
  
  What the three share is the predicate, so the predicate is what moved. Each call
  site keeps its own slot choice and its own trimming, and `isNativeErrorName`
  deliberately does **not** trim for its callers — a contract pinned in its test.
  
  **Shipped rather than `skip-changeset`**, measured on a real build: all four
  packages publish `files[]: ["dist", …]`, and the built `dist` of each carries
  the new call — `@objectstack/types` 4 files, `@objectstack/objectql` 4,
  `@objectstack/rest` 3, `@objectstack/runtime` 2 — with `looksLikeInternalErrorLeak`
  scoring 4 in `types/dist` as the lit control and a nonexistent symbol scoring 0.
  The retired copies are gone from the artifacts too: the regex literal scores
  **0** in `rest/dist`, `objectql/dist` and `runtime/dist`, and **2** in
  `types/dist` (the ESM and CJS bundles).
  
  `@objectstack/types` takes **minor**: a new export is a purely additive widening
  of a published surface, which is at least minor whatever the commit type says.
  The three consumers take `patch` — their artifacts change, their behaviour does
  not.
- c3ebe4a: A producer-declared 5xx **refusal** now keeps its message on the wire, at every door that reads the declaration.
  
  `ApiErrorSchema.refusal` (`@objectstack/spec`) is the producer-side declaration that a 5xx is a deliberate refusal whose `message` is authored for the caller. Until now nothing read it: all three arms that withhold a declared 5xx's prose could tell only that the producer had declared a *status*, so a refusal and a driver fault were sanitised alike and every producer-declared 5xx refusal reached the caller as `"Internal server error"`.
  
  The read is one new function, `declaredRefusalMessage` (`@objectstack/types`), called by all three arms — `declaredServerFaultAnswer` and `resolveErrorResponse`'s 5xx passthrough in `@objectstack/rest`, and `errorResponseBase` in `@objectstack/runtime`. REST's logging follows the same field: a declared refusal is no longer logged as `[REST] Unhandled error`.
  
  **What changes for a caller.** A 5xx whose producer sets `refusal: true` beside a `status` (or `statusCode`) in the 500-599 band and a non-empty `code` now carries that producer's message, bounded exactly as a 4xx message is. The first live case is `GET /api/v1/meta/:type/:name/references` for an unanswerable target, whose ADR-0110 D3 sentence ("Ask the owning object instead: …") reaches an operator again.
  
  **What does not change.** Everything else, and the default is fail-closed: a declared 5xx that carries no `refusal` is withheld exactly as before, an undeclared 5xx still goes through the leak heuristic, and a rewrap that drops the flag is withheld as a fault. A refusal cannot buy leaky prose past `looksLikeInternalErrorLeak` either — the declaration says the prose is *addressed* to the caller, not that it is *safe*.
  
  **For producers.** Setting `refusal: true` on a thrown 5xx is opt-in and additive; a producer that does not set it is unaffected. Platform and driver code must never set it on a fault.
- 0a56d3b: feat(spec,types,triggers)!: `group` runs package-authored scheduled work without a declaration, owning each run's writes per record (#18378)
  
  <!-- adr-0087: not-required (already-registered schedule-flow-acting-organization-required) This amends the EXISTING semantic entry rather than adding one: same authorable key, same deployment switch, same surface, and the entry predates this diff at the merge base. Nothing is renamed, retired or re-typed — the start node's `config` is an open record (ADR-0018), so every flow that parses today parses byte-identically afterwards and `objectstack migrate meta` has nothing new to rewrite. What moves is the BIND-time accept set (it WIDENS) and the RUN-time organization such a flow's writes carry; the entry's own surface/replacement/reason/acceptanceCriteria each gained their `group` row in this diff. -->
  
  `Clause-②: yes (widening)`
  
  **ADR-0087 disposition — `not-required (already-registered)`, not `registered`.**
  The ledger entry this change belongs to already exists
  (`schedule-flow-acting-organization-required`, entry 18) and predates this diff
  at the merge base, so `registered` would assert a registration this PR did not
  make. The entry's `surface`, `replacement`, `reason` and `acceptanceCriteria`
  each gained their `group` row here, the rejected bootstrap-organization arm
  included — recorded because it is the one a later reader will re-propose.
  
  **Marked breaking (`!`) for the behaviour change, not for a narrowing.** Nothing
  that worked stops working and nothing that was admitted becomes refused — the
  accept set WIDENS in one cell. What earns the banner is the other direction: on a
  `group` deployment with the switch already on, flows that were refused at bind
  now arm and run, so clock-driven work appears where an operator had none. That is
  worth reading before upgrading even though no consumer has to change anything.
  
  ## What changes
  
  With `OS_AUTOMATION_SCHEDULED_WORK_ENABLED` on and tenancy posture `group`, a
  time-triggered flow that declares no `config.organization` now **binds and
  runs**, where it was previously refused at bind. The organization its writes
  carry follows the record:
  
  | posture | declaration | a bound run's writes act as |
  |---|---|---|
  | `single` | not read | nothing — the install's one organization resolves beneath each write |
  | `group` | **optional** | declared ⇒ the declaration; undeclared ⇒ **the swept record's own organization** |
  | `isolated` | **required** | the declaration; undeclared ⇒ not armed, unchanged |
  
  A `timeRelative` sweep under `group` reads group-wide — inherent to the posture
  (ADR-0105 D1) — and stamps each run it launches with that record's organization:
  sweep contracts across four plants and each plant's contract yields a run acting
  as that plant, whose notifications reach that plant's inboxes.
  
  ## Why this is not a fallback that guesses
  
  It is the order `sys_automation_run` was **already** ruled to use.
  `ObjectStoreSuspendedRunStore` resolves a run's organization as
  `organizationOf(<subject record>) ?? ctx.tenantId` — subject first, acting
  context as the fallback and never the primary. Before this change those two
  halves disagreed under `group`: the history row was stamped from the record while
  the inbox and delivery rows followed an acting context that could not exist
  there, so they were refused while the tick summarised itself as healthy.
  
  ⚠️ With one stated exception, because the two halves ask different questions:
  the history row is STAMPED (`tenancy.organizationField` wins there) while the
  run's acting organization is a WALL reading that never consults that key. They
  agree on every object where the two coincide — which is every ordinary object,
  since a declared stamp column is what makes them differ and one shipped object
  declares one (`sys_api_key`, deliberately unwalled). Sweeping that object under
  `group` stamps its history row while the run itself acts as nothing: the correct
  pair of answers, not a residue of the old disagreement, and recorded rather than
  smoothed over.
  
  ⛔ A record-less run under `group` that declared nothing still resolves
  **nothing** and is refused at its first tenant-scoped write (`walled-posture`,
  ADR-0112), loudly and by name. The rejected alternative was a fallback to the
  bootstrap organization (`slug='default'`): under a wall that organization is
  minted admin-keyed by the enterprise organizations runtime and may not exist at
  all, and where it does it is whichever organization the platform owner
  registered under — plausibly one plant of many, not the group's head office.
  
  ## Upgrading
  
  **Most deployments: nothing to do.** The switch this depends on is OFF by default
  and ships unreleased alongside this change, so the `group`-is-walled behaviour
  being amended has never appeared in a published version — no released consumer
  can be relying on it.
  
  If you run posture `group` **and** turn the switch on, read your boot log: each
  time-triggered flow's bind line now names which of the three shapes it bound as
  ("as organization '…'", "with per-record acting organization", or "with NO
  acting organization"). Two things to check:
  
  - A flow you expected to act as ONE organization but which binds per-record is
    missing its `config.organization`. Add it — declaring still narrows, bounding
    the sweep's query as well as its identity.
  - A plain `schedule` cron flow that binds "with NO acting organization" has no
    record to derive one from. If it writes notifications, inbox messages or any
    other per-organization row, declare `organization` on its start node; the bind
    line says so, and so does the refusal at the first tick.
  
  ## Which organization a record belongs to — the WALL question, not the stamp one
  
  `@objectstack/metadata-core` gains a second face on the record→organization
  resolver, and the split is the point: `resolveRecordOrganizationField` /
  `createRecordOrganizationResolver` answer **"who is this row ABOUT"** (the STAMP
  question, whose `tenancy.organizationField` limb stays pinned to the three
  sanctioned platform-row writers), while the new
  `resolveRecordWallOrganizationField` / `createRecordWallOrganizationResolver`
  answer **"what is this row WALLED by"** — `tenancy.enabled: false` ⇒ nothing,
  then a declared `tenancy.tenantField`, then the kernel's `organization_id`.
  
  The sweep uses the WALL face, because "which organization does this run act as"
  is a question about the wall. ⛔ It never reads `tenancy.organizationField`: that
  key is declared on exactly one shipped object (`sys_api_key`, deliberately
  unwalled, #8287), and reading it here would turn "the audit trail should follow
  this row's own organization even though nothing walls it" into an acting
  identity. A sweep over such an object resolves **nothing** and takes the
  `walled-posture` refusal at its first tenant-scoped write, which is the honest
  answer. Limbs 1 to 4 are one implementation shared by both faces, pinned as
  such, so the half they agree on cannot drift apart.
  
  **API:** `ScheduledWorkPolicy` gains `runOwnership: 'unscoped' | 'per-record' |
  'declared'`, and `requiresActingOrganization` narrows from "any walled posture"
  to `isolated` only. The two are deliberately separate axes: the boolean decides
  whether BIND refuses, `runOwnership` decides what a run that DID bind carries.
  Inside `@objectstack/trigger-schedule`, both triggers share one bind-line
  vocabulary (`describeScheduleRunOwnership`) so they cannot describe one
  deployment differently. ⚠️ That helper is module-level, NOT a package export: it
  is not re-exported from the package barrel, whose own note says an export whose
  only consumers live inside its own package belongs in a non-barrel module. The
  new PUBLIC surface in this change is `ScheduledRunOwnership` and the
  `runOwnership` key on `@objectstack/types`, plus
  `resolveRecordWallOrganizationField` and
  `createRecordWallOrganizationResolver` on `@objectstack/metadata-core` — and
  those four are what put `Clause-②` at `yes`. Nothing existing is renamed or
  re-typed: both stamp-face exports keep their names, their signatures and their
  answers, limb 0 included.
- 6e3462d: Host importer: a `link:` / `file:` install is now verified by the LOCATION the app declared, so a correctly linked package loads instead of being refused.
  
  The ESM fallback finder (`createHostImporter`) verifies the one directory it consults — `<hostRoot>/node_modules/<key>` — against what the host's own `package.json` declares. Until now it could only do that by NAME, and a `link:` / `file:` value promises no name, so the KEY stood in for one: a package linked exactly as the app asked, whose own manifest happens to be named something else, was refused with `declared-unresolvable` / `MODULE_NOT_FOUND`. Nothing was broken, and the only way out was to stop using a supported linking mode.
  
  Such a declaration does name something checkable — a directory — so the finder now checks that too: `realpath(node_modules/<key>)` against `realpath(resolve(hostRoot, <declared path>))`, both sides canonicalised, compared exactly (no basename matching, no case folding). If they are the same directory, the host declared it and it loads.
  
  This is a second verification axis, not a looser first one. A directory the app declared neither by name nor by path is refused exactly as before, and the finder stays strictly tighter than the CommonJS resolution it backs up, which asks neither question. Unchanged: a plain version range licenses no path; an `npm:` alias is still checked by name; `github:` / tarball URLs and the bare `owner/repo` shorthand name no on-disk location, so they gain nothing; a package that publishes a `require` condition never reaches this fallback at all, so no load that succeeds today changes.
  
  Measured on pnpm 10.33: `link:` symlinks the key at the declared directory and verifies; a `file:` directory install routes through pnpm's virtual store (a copy), so it does not, and keeps today's refusal. The refusal's text now states what the location check compared instead of asserting a limit the finder no longer has.
- 5a95b0e: fix(types,metadata-protocol,metadata,cli): a stored operator record names the dialect again, not the driver's composed refusal
  
  Since the raw-SQL seam began declaring its own fault, `SqlDriver.execute()` no longer
  lets the dialect's error out: it raises `code: DATABASE_ERROR` / `status: 500` with a
  COMPOSED message that discloses neither the statement nor the diagnostic, and carries
  the dialect error whole under a non-enumerable `cause`. That envelope is deliberate and
  is unchanged here.
  
  What changed underneath it is what every consumer STORED. Each migration probe, backfill
  and rename in `@objectstack/metadata-protocol` / `@objectstack/metadata` embedded
  `error.message` into an operator-facing record, so those records began reading
  
      the database refused to run a raw statement
  
  where they used to read
  
      no such column: foo
  
  For a live console that costs nothing — the driver prints the statement and the dialect
  text to its warn sink one line earlier. For a record read later it costs everything:
  whoever opens a customer install's backfill result a week on never had that line, and the
  dialect's words were unrecoverable for them.
  
  `@objectstack/types` now exports `operatorFacingErrorText(error)` — a depth-bounded walk
  of the `cause` chain, shaped like the `matchesDriverError` beside it — and the thirteen
  stored-record sites plus `os db clean`'s console line read through it:
  
  - `runtime-index-preflight` — the per-probe `detail` and the seam-failure fan-out;
  - `seed-tenancy-backfill` — the `absent` detail, the organization-probe report and the
    three per-object warnings;
  - `partial-index-probe` — the `detail` both callers report (and its two module comments,
    which stated the opposite of what happened);
  - `migrate-env-id-to-project-id`, `migrate-project-id-to-environment-id`,
    `migrate-sys-notification-to-event`, `drop-projection-tables` — the per-table `error`;
  - `os db clean` — the `VACUUM failed` line.
  
  Two narrowings are part of the contract, not incidental: an UNDECLARED throw is returned
  on its own message channel, its `cause` never walked, and a declared envelope that is not
  the raw-path one — the typed read exits' terminal, which composes a different sentence —
  is left exactly as it arrived.
  
  That message channel is deliberately NOT byte-identical to what the replaced expressions
  computed. The RULE, rather than a catalogue of cases: an undeclared throw comes back as
  `messageChannelOf(error) || String(error)` — the thrown value's own string `message`, the
  string itself when a string was thrown, and `String(error)` when neither yields text. Every
  difference from the replaced expressions follows from that rule, so read the rule and not a
  list. Illustrations of it, not an exhaustive set: an empty-message `Error` reads its `name`,
  which for a named subclass is that subclass's name rather than `Error` / `TypeError`; a
  thrown non-`Error` reads its own text or `String(error)` where `(e as Error).message` read
  `undefined`, and where `null` / `undefined` threw a `TypeError` out of the catch, so no
  record was written at all and the operation aborted; an object carrying a NON-EMPTY string
  `message` reads it where `err instanceof Error ? … : String(err)` recorded `[object Object]`
  (one carrying an EMPTY `message` still reads `[object Object]`). A thrown EMPTY string reads
  `''`, so this channel is neither always prose nor never empty.
  
  ## The levels, and why they are not uniform
  
  `@objectstack/types` takes **`minor`**: it is the one package here that grows a published
  surface — `operatorFacingErrorText` is a new export, present in `dist/index.d.ts` and in the
  export list. A purely additive widening takes at least `minor`.
  
  The other four take **`patch`**, because none of them widens anything: they are a bug fix in a
  released package, which is exactly what `patch` is for. `@objectstack/driver-sql` is named
  because this change moves its `src/**` — by one ADDED file, the `.test.ts` that pins the helper
  against a real `SqlDriver.execute()` refusal. Its published `dist/` is byte-unchanged by this
  PR: no entry point reaches a test file, and `files` packs `dist` only.
  
  **Not breaking, and deliberately not marked so.** Nothing is removed, renamed or made stricter:
  what moves is the TEXT inside an operator-facing `detail` / `error` field, never a field name
  and never a type. The change these sites were made for is the declared raw-path fault, where
  the record gains the dialect's words in place of the driver's composed placeholder. Every
  other throw now reaches these records through the rule above rather than through the
  expression each site spelled out, so its text can move too — a consequence of the rule, not a
  bounded list of exceptions. At thirteen of the fourteen sites the rule is the whole record,
  and some shapes still record `''` there: a thrown empty string, a thrown empty array, and an
  `Error` whose `name` and `message` are both empty are the ones measured. The fourteenth was
  `seed-tenancy-backfill`'s organization probe, which kept a `|| 'unknown error'` fallback on
  top of the rule, so those same three shapes recorded `'unknown error'` there rather than `''`;
  that fallback was load-bearing — the site read an empty value as "the probe did not fail" —
  and #17167 removed it in this same release, so all fourteen sites now record the channel as
  is and that site carries its failure fact structurally. The sentence being replaced is not a value any
  consumer can have been parsing: it is an opaque human diagnostic. A consumer reading these
  records gets the dialect's words back where it had been getting a placeholder.
- f04be62: feat(types,triggers,service-automation,runtime,cli,spec,lint)!: package-authored scheduled work is a deployment decision — `OS_AUTOMATION_SCHEDULED_WORK_ENABLED`, off by default everywhere (#17396)
  
  <!-- adr-0087: not-required (already-registered schedule-flow-acting-organization-required) entry 18 is the ledger row for this exact surface — the start-node `config.organization` key of a time-triggered flow — and this change REWRITES it rather than adding a sibling: its surface, replacement, reason and acceptance criteria now carry the deployment switch and the posture split, so an upgrader reading `objectstack migrate meta`, `spec-changes.json` or the generated upgrade guide gets the narrowed rule from the one row that was always going to be their channel. A second entry would split one prescription across two rows and let a reader act on half of it. -->
  
  Maintainer ruling, 2026-09-12, verbatim, untranslated:
  
  > schedule 是风险很大的模型，尤其在云端，无算是单独多租户还是每库一租户，可能造成极大的资源浪费。对于单租户或着集团版私有部署，我觉得不需要做限制。定时任务 如果不好处理，现在也没想清楚，有没有可能定义为一个环境变量，根据环境变量控制？
  
  > 如果多租户暂时只接禁用定时任务，完整的考虑一下影响面。
  
  > group 默认也关，云端每库一租户全局默认关
  
  **A new deployment variable, `OS_AUTOMATION_SCHEDULED_WORK_ENABLED`, decides whether this deployment runs PACKAGE-AUTHORED scheduled work at all** — time-triggered flows (`type: 'schedule'` with a `config.schedule` cadence, and the `timeRelative` sweep) and packaged `defineJob` cron jobs. It is read at boot beside `resolveTenancyPosture` and is ⛔ **not** a metadata concept and ⛔ **not** a new spec key: whether a clock-driven workload is affordable is a fact about the deployment — its database, its tenants, its budget — that no package author can know, and a metadata key would ask them to.
  
  **OFF by default, in every posture and in every kernel.** Unset means off; `true` / `1` / `on` / `yes` (case-insensitive) means on. ⛔ Deliberately not the opt-out `!== 'false'` shape `OS_MULTI_ORG_ENABLED` uses, which reads a typo as "on" — here that would arm exactly the workload an operator meant to refuse.
  
  ⛔ **Platform-internal scheduled work is NOT gated** and runs either way: approvals escalation, the lifecycle Reaper, the messaging dispatch loop, membership backfill. The boundary is **authored by a package**, not "runs on the job service" — the platform's own maintenance is part of the runtime a deployment asked for.
  
  **BREAKING**, in two directions, and both land inside the same launch window as #16659 / PR #17334, so no published version ever saw the rule this narrows.
  
  1. **A NARROWING, and it is the one to plan for.** A deployment that upgrades and does nothing runs **no** packaged time-triggered flow and **no** packaged `defineJob`. Anything that was firing from a package stops. ⇒ Set `OS_AUTOMATION_SCHEDULED_WORK_ENABLED=true` if you depend on it. Nothing detects the shape for you at authoring time, by design — but nothing is silent either: every such flow is listed in `getTriggerBindingAudit()` and the `os dev` / `os start` startup summary with a DISTINCT reason, **disabled by deployment policy**, ⛔ never as "binding failed"; the packaged-job loop says so once per app at `info` with the count; and `os doctor` prints the effective value in both states.
  2. **A WIDENING of what binds.** With the switch on and tenancy posture `single`, a time-triggered flow that declares **no** `config.organization` now binds and runs — under #16659 alone it was refused. That posture holds exactly one organization (a second is refused), so the run carries **no** organization and every tenant-scoped insert beneath it resolves that one the way a single-organization install always did; a `timeRelative` sweep there runs **unscoped**. ⛔ Nothing is invented: the key is OMITTED, never filled from the install, the platform organization, or the swept record's own `organization_id`.
  
  **Under a walled posture (`group` / `isolated`) the 2026-09-08 ruling on #16659 stands unchanged**: a time-triggered flow declares `config.organization` or it is not armed, there is no fan-out, and no organization is ever chosen for it. `group` is walled here for a measured reason rather than by analogy — `resolveSystemWriteOrganization` refuses an organization-less system insert under any wall and `TenancyService.defaultOrgId()` answers `null` (ADR-0093 D3), so an organization-less group-wide sweep could read the whole group while every row it inserts is refused. Which organization such a sweep's inserts belong to is not yet decided; until it is, `group` behaves as walled.
  
  **`flow-schedule-organization-missing` is DELETED** from `@objectstack/lint` (the id and its exported constant, `FLOW_SCHEDULE_ORGANIZATION_MISSING`; both are unreleased — they were introduced by the still-unconsumed #16659 changeset in this same window, so no consumer can be holding either). The rule family's criterion is *is this stack enough to know the flow is dead?*, and the honest answer here is no: the deployment switch and the tenancy posture decide it, and neither is in any stack. A finding that is false for the default deployment is noise. ⛔ The near-miss diagnostic did **not** go with it — `describeMissingScheduleOrganization` and its `organizationId` / `tenantId` / … scan still fire at BIND, the one door that can read both facts, and only where the key is actually required.
  
  **ADR-0087 semantic entry 18 (`schedule-flow-acting-organization-required`) is REWRITTEN, not added.** Its acceptance criteria required every time-triggered flow to declare; that is no longer the rule. It now prescribes the two decisions in order — decide the switch, then declare per organization under a wall — and records that `os lint` reporting nothing is the criterion being met rather than a check that was skipped. The unconsumed `.changeset/schedule-trigger-acting-organization.md` carries a banner saying the same, so a reader of either one cannot get the narrower half alone.
  
  **Where the switch is read, and where it is not.** Both triggers gate at `start()`, ahead of the descriptor and the declaration, so an operator on a deployment that was never going to run a flow is not sent to fix a descriptor nothing would have read. `AutomationEngine.activateFlowTrigger` reads the same resolver and does not call `start()` at all when it is off — that is what keeps the audit's reason precise, since a refusal arriving as a THROW can only be reported through the catch that says "Failed to bind". Neither read is cached: the resolver reads `process.env` live, so a host that rebinds after the environment changes sees the value current at the bind. The scope is `schedule` and `time_relative` only — `record_change` and `api` are fired by a caller that already exists and already carries an identity, and a kind added to `FlowTriggerKind` later is OUTSIDE the switch until someone decides otherwise, because a new capability that disappears on arrival is the worse default.

### Patch Changes

- 7f62536: A **declared capability absence** — a 5xx answered because the deployment did not install an optional service — is now reported **once per route per process at `warn`**, naming the missing service, instead of one `error` line per request. Every other 5xx keeps the per-request `error` line #14310 shipped.
  
  Measured before the change, on a stock showcase boot: `GET /api/v1/ai/*` (the cloud-only AI service's declared `501 NOT_IMPLEMENTED`) printed one `error`-level line per request, and Studio opens it unprompted. A deployment that is working exactly as configured was training the channel built to mean "an operator must look" into noise — which is the failure mode `--log-level`-watching operators learn as "skim the errors".
  
  - **What counts as an absence** is the envelope the door composed: a producer-declared 5xx (`declaresServerFault` — the repo's existing declared-5xx predicate) whose ADR-0112 `code` is `NOT_IMPLEMENTED` or `SERVICE_UNAVAILABLE`. Nothing is invented to recognise one; the code the producer already declared *is* the declaration.
  - **The predicate is applied inside the shared funnel** (`logServerFault`, `@objectstack/types`), not at each door, so `sendError`'s nested-envelope exit and the runtime dispatcher read one answer by construction. A door cannot opt in, opt out, or drift.
  - **The dedupe key is (route, process).** A restart reports again, and a second, different route reports on its own — deliberately not a global "first N", which is the shape that hides the second route. A door that supplies no route coordinates is demoted to `warn` but never suppressed: an un-keyed bucket is that same hiding shape.
  - **A thrown 5xx keeps its `error` line even when it declared `501`.** The thrown exit hands the funnel the throw and no envelope `code`, so it is not recognised as an absence — fail-loud for the half that carries a stack.
  
  ⛔ **No wire byte moves.** Status, `code`, `message` and body shape are unchanged at both doors; this changes a log level and a count. The response bytes are pinned in `packages/runtime/src/declared-capability-absence-warn-once.test.ts`, and that block runs green on the pre-change tree too, which is what makes it a before/after measurement rather than a claim.
  
  Operators who were alerting on `[5xx]` at `error` level for an uninstalled optional service will now see one `warn` line per route per process instead. The line says so in its own text: `(declared capability absence — reported once per route per process)`.
- 75237a9: fix(spec)!: `timeDimensions[].dateRange`'s array arm is exactly two string bounds, and each refusal ORIGIN gets a true sentence (#17598; ruling A, decision batch #117 item 3)
  
  <!-- adr-0087: registered analytics-date-range-array-two-bounds-required -->
  
  **BREAKING** accept-set narrowing at `timeDimensions[].dateRange` — shipped as
  `minor` under this repo's launch-window convention for breaking changes
  (`scripts/check-changeset-no-major.mjs`), above the `patch` floor the `fix`
  commit type sets, and the same grade the one comparable precedent took: the
  STRING-arm closing on this same schema is #16041, and it shipped
  `"@objectstack/spec": minor` (`packages/spec/CHANGELOG.md` 17.4.0, under Minor
  Changes). ⚠️ Its driver half #16322 declares `"@objectstack/spec": patch`, but
  that entry is — in that changeset's own words — "a `PROVENANCE_WAIVERS` row
  only", not an accept-set narrowing, so it is not a grade this one is measured
  against. The maintainer
  ruling calls it a "major changeset"; under the launch window that phrase maps to
  the protocol MAJOR the migration registers against (18), not to the changeset's
  bump level, which `scripts/check-changeset-no-major.mjs` reserves. The semantic
  prescription is registered under protocol major 18 as
  `analytics-date-range-array-two-bounds-required`.
  
  ### What changed
  
  `AnalyticsDateRangeSchema`'s array arm was `z.array(z.string())` with **no length
  constraint**, so `['2026-01-01']`, `[]` and `['a', 'b', 'c']` were schema-valid.
  It is now `z.tuple([z.string(), z.string()])` — a tuple rather than a length
  refinement, so the arity is stated to the author's compiler before any parse runs.
  Preset names, two-bound windows and an absent `dateRange` parse byte-identically
  to before.
  
  `analyticsDateRangeRefusalMessage(input)` becomes
  `analyticsDateRangeRefusalMessage(input, origin)`, where `origin` is `'schema'` or
  `'runtime'` and is **required** — there is deliberately no default.
  
  ### Migration: FROM → TO
  
  | You wrote | Write instead |
  | --- | --- |
  | `dateRange: ['2026-01-20']` | `dateRange: ['2026-01-20', '2026-01-20']` — a single day is that day as both bounds, the shape the shipped #16322 table already prescribes |
  | `dateRange: []` | no conversion. An empty array names no window: write the two bounds the widget was meant to show, or omit `dateRange` (it is optional, and absent means the query is not time-bounded) |
  | `dateRange: ['a', 'b', 'c']` | no conversion. Decide which two bounds you meant and write them |
  | `analyticsDateRangeRefusalMessage(value)` | `analyticsDateRangeRefusalMessage(value, 'schema')` at a parse door, `…(value, 'runtime')` past one |
  
  `os migrate meta --from 17` emits the first three as a structured TODO rather than
  rewriting them: rewriting a one-element array to the same day twice at load would
  be the platform deciding, silently, that the author meant one day rather than a
  window whose end they forgot, and for the other two shapes there is nothing to
  decide from.
  
  ### Why it is not a new class of breakage
  
  Since PR #17593 all four analytics faces (`ObjectQLStrategy`, `NativeSQLStrategy`,
  the draft-preview evaluator, `DatasetExecutor.runCompare`) already refused anything
  that is not exactly two bounds with `400 ANALYTICS_DATE_RANGE_UNRECOGNIZED`, so
  every stored range this narrowing refuses was **already failing at query time**.
  The contract door was looser than every reader behind it; this moves the refusal
  to authoring time and states it accurately. Blast radius is the WIDGET, not the
  page: a stored dashboard carrying a now-refused range loses that widget with the
  refusal shown and still loads.
  
  ### The wording half
  
  The shared sentence ended `"Refused at the schema"` and described every refused
  array as `"received an array with a non-string bound"`. For a one-element window
  refused by a face **both clauses were false** — every bound present is a string,
  and it was refused past the schema, not at it — which is why
  `@objectstack/service-analytics` had to overwrite the message rather than reuse it,
  leaving one condition with two wordings. The origin is now a parameter and the
  `received …` clause names the arity and the bad bound separately, so the sentence
  is true for each origin both before and after the arm narrows.
  
  The same rule reaches the WIRE. Narrowing the arm to a tuple gave the union a
  second voice: its arm answers `Too small: expected array to have >=2 items` for
  the very arity the prescription just prescribed, and the ADR-0114 union
  expansion emitted both as `fields[]` entries on `POST /analytics/query` and
  `POST /analytics/dataset/query`. `fieldsFromZodIssues` (`@objectstack/types`),
  the one mapper both doors report through, now drops the branch issues that land
  at the union's OWN path for this refusal — recognised structurally through
  `isAnalyticsDateRangeRefusalIssue`, never by message prose. A refusal that names
  a DEEPER position keeps it: `dateRange: ['2026-01-01', 3]` still reports
  `timeDimensions.0.dateRange.1`, because WHICH bound is not a string is a
  location the prescription does not carry. Every other union expands exactly as
  before. Client-visible effect: one `fields[]` entry for an arity refusal instead
  of two, with the prescriptive one kept.
- 99fcb4a: `FlowRuntimeState` now declares `reason` — the optional sentence saying WHY a flow is not armed — and the automation engine populates it, so `GET /automation/_status` can tell a policy-disabled flow apart from a broken binding (#18235).
  
  Ruling G item 6 on #17396 names three surfaces that must each carry a DISTINCT reason for a flow left unarmed because package-authored scheduled work is switched off, and must never read as "binding failed". Two of them shipped: `getTriggerBindingAudit()` and the CLI startup summary. The third — a console — could not be built: Studio's only status door answers `FlowRuntimeState` rows, and that shape had no field a reason could travel in, so on the wire a policy-disabled flow was `enabled: true, bound: false, triggerType: 'schedule'`, byte-identical to one whose trigger is missing.
  
  **Clause-②: yes (widening)** — one new key on an already-published payload, so the shape a consumer reads against grows. Nothing previously emitted is removed or renamed, and no producer is required to write it.
  
  - **Optional, and additive by measurement.** Every producer of these rows — the engine, and the test doubles in `packages/runtime`, `packages/cli` and `packages/qa/dogfood` — writes `{ name, enabled, bound }` at minimum; a required key would have broken all of them and would demand a reason from rows that have none. The key is absent (not `undefined`-valued) on any row that is bound, disabled, or declares no trigger.
  - **One vocabulary, not a new one.** The sentence is the one `getTriggerBindingAudit()` already answers for the same flow: both doors now read a single private `describeUnboundReason()` on the engine, so Studio and the boot summary cannot drift. A free-form string, matching the two surfaces that already carry this reason; ⛔ consumers render it, they do not parse it.
  - **Read from the RECORD, never re-derived.** The policy sentence comes from the engine's recorded refusal (`policyDisabledFlows`, cleared the moment a flow gets past the gate), never from a live `resolveScheduledWorkPolicy()` read at call time. `_status` is served on demand, arbitrarily long after the bind — re-deriving would report a binding failure for a trigger that was never called, the defect the implementing round of #17396 already caught once.
  - **Wire, not rendering.** `SCHEDULED_WORK_DISABLED_REASON`'s docblock is corrected: Studio's door now carries the reason, while displaying it distinctly remains objectui#9217's card. Declared is not delivered, and reaching the wire is not being shown. The published prose carrying the same claim moves with it — `content/docs/automation/flows.mdx`'s callout said the status door "has no field to say why", which this change makes false; both carriers are corrected in one landing, and neither now claims a console *renders* it.
- a484966: The TypeScript examples in these packages' **published** `README.md` now compile against the package they document — 43 of the 44 blocks the `measure-markdown-ts-blocks` census reported as syntactically valid and wrong, in documents that ship inside the npm tarball.
  
  `README.md` is listed in every one of these packages' `files[]`, so these bytes are the artefact a consumer — or a consumer's AI — reads and copies. What the census counted was not style: the examples named options the packages no longer accept, chained a method that returns a promise, and implemented interfaces they never imported.
  
  The corrections, by class:
  
  - **Legacy option vocabulary.** `@objectstack/client-react`'s hooks take `fields` / `orderBy` / `limit` / `where`, not `select` / `sort` / `top` / `filters`, and `PaginatedResult` carries `records`, not `value`. `@objectstack/service-job` takes `timeoutMs`, `@objectstack/service-queue` takes `maxAttempts`, and `IDataEngine.find` takes `where`.
  - **Async registration used synchronously.** `ObjectKernel.use()` returns `Promise<this>`, so `kernel.use(a).use(b)` does not chain; the examples now `await` each registration. `ObjectKernelConfig` has no `plugins` member.
  - **Interfaces implemented but never imported.** Several plugin examples wrote `implements Plugin` with no import, which bound to the DOM's `Plugin`; they now import `Plugin` / `PluginContext` and declare the required `init`. `PluginContext.getService<T>()` has no default type argument, so the examples that read a service now name its contract.
  - **Removed or never-existing API.** `@objectstack/driver-memory`'s default export is a legacy `onEnable` object that `kernel.use()` refuses — the quick start now registers through `DriverPlugin`; its persistence adapters take an options bag under `persistence.adapter`. `defineStack` has no `driver` key. `@objectstack/rest`'s `RestServer` takes the host `IHttpServer` first and `registerRoutes()` takes no arguments; `RouteManager` is constructed on a server. `@objectstack/spec`'s `ObjectSchema.parse()` returns the value — the `{ success, data }` envelope is `safeParse`'s. `useMutation` has no `onMutate` / mutation context.
  
  No runtime code changed and no gate was added (#18715 ruling F). One block is deliberately left: `@objectstack/knowledge-ragflow`'s README writes `source.options.datasetId`, which is what the shipped adapter reads and what `KnowledgeSourceSchema` does not declare — correcting the document either way would contradict one of the two, so the conflict is reported rather than papered over.
- 288fe9c: `createHostImporter` stops prescribing an install repair for a `link:` / `file:` install that is already correct. The refusal is unchanged; only its wording is.
  
  A host app declaring `{"foo": "link:../bar"}` links `node_modules/foo` to a directory whose manifest may be named anything. `link:`, `file:` and git or tarball URLs name a LOCATION or a remote artefact, never a package, so the specifier carries no name for the ESM-only fallback finder to expect and the KEY stays the expectation — kept deliberately, because widening it would accept any directory sitting at the key and trade a wrong REMEDY for a wrong LOAD. When the linked manifest names something else the finder therefore refuses, and it was reporting that refusal with the `declared-unresolvable` INSTALL wording: run `pnpm install`, check a production prune did not drop it, check the dist was built. Driven on a real symlinked install, all three are measurably false — the finder had just read the manifest at `node_modules/foo`, so the package is on disk, was not pruned, and its `import` target exists. The operator reinstalls, nothing changes, and they go looking for a build that is not broken.
  
  That sub-case now states what was actually measured: the directory it consulted, the name the manifest there carries, the name it expected, and why a location specifier leaves it with only the key. It says outright that this is neither an install nor a declaration problem, and closes with the remedy that does work — make the two names agree, by declaring the linked package under its own name or by renaming the linked manifest to the key. Both ends are pinned as loading.
  
  Unchanged: the refusal itself, its `declared-unresolvable` kind, its `MODULE_NOT_FOUND` code and every consumer branch that reads them; the finder's accept set, which is byte-for-byte what it was — a `link:` install whose manifest matches the key still loads silently, and a plain range or an `npm:` alias whose directory holds a different package still gets the INSTALL wording, because there the install really is the fault. The second verification axis that would make these installs LOAD (comparing `realpath(node_modules/<key>)` against the declared location) is deliberately not built here.
- Updated dependencies [863c7c4]
- Updated dependencies [0f95f43]
- Updated dependencies [825d70f]
- Updated dependencies [6057357]
- Updated dependencies [a60e04d]
- Updated dependencies [abc4b83]
- Updated dependencies [7382c5d]
- Updated dependencies [ea2940d]
- Updated dependencies [7d0f911]
- Updated dependencies [48f5200]
- Updated dependencies [245f360]
- Updated dependencies [d0f1845]
- Updated dependencies [9dcdb77]
- Updated dependencies [6175da8]
- Updated dependencies [0283cb9]
- Updated dependencies [324968e]
- Updated dependencies [7843663]
- Updated dependencies [ce57857]
- Updated dependencies [744a0a3]
- Updated dependencies [c7d4825]
- Updated dependencies [4844840]
- Updated dependencies [fe71032]
- Updated dependencies [74eaab8]
- Updated dependencies [0b788da]
- Updated dependencies [f7a3495]
- Updated dependencies [97f4f8c]
- Updated dependencies [482d34d]
- Updated dependencies [7a25a3e]
- Updated dependencies [839d1b0]
- Updated dependencies [2fc092b]
- Updated dependencies [2dfe070]
- Updated dependencies [6059b29]
- Updated dependencies [88a072e]
- Updated dependencies [d4a1a28]
- Updated dependencies [3d8779d]
- Updated dependencies [0bd7dae]
- Updated dependencies [d34f9b6]
- Updated dependencies [57343f7]
- Updated dependencies [271d6bb]
- Updated dependencies [1e20f81]
- Updated dependencies [38472ce]
- Updated dependencies [8b48903]
- Updated dependencies [2d235bc]
- Updated dependencies [aaacf1d]
- Updated dependencies [9dacf61]
- Updated dependencies [146c291]
- Updated dependencies [4db1bf1]
- Updated dependencies [e0e4a56]
- Updated dependencies [7aae005]
- Updated dependencies [bdb247d]
- Updated dependencies [d5c91dd]
- Updated dependencies [0e51278]
- Updated dependencies [48203ff]
- Updated dependencies [ada2869]
- Updated dependencies [d88a47d]
- Updated dependencies [2f1a6f6]
- Updated dependencies [23fc5d6]
- Updated dependencies [2d34f32]
- Updated dependencies [7b1e4a4]
- Updated dependencies [d7c0241]
- Updated dependencies [9e3c485]
- Updated dependencies [e1796ad]
- Updated dependencies [8271c81]
- Updated dependencies [c9eb773]
- Updated dependencies [fbc12be]
- Updated dependencies [ec2ede0]
- Updated dependencies [4342c99]
- Updated dependencies [132dd13]
- Updated dependencies [d285bf0]
- Updated dependencies [dfeba25]
- Updated dependencies [9059a94]
- Updated dependencies [0a88a80]
- Updated dependencies [2c1011b]
- Updated dependencies [12bb672]
- Updated dependencies [97233b9]
- Updated dependencies [c199772]
- Updated dependencies [f5a7250]
- Updated dependencies [1a2bb9e]
- Updated dependencies [eea7ccc]
- Updated dependencies [097d268]
- Updated dependencies [182bbde]
- Updated dependencies [5ce3705]
- Updated dependencies [24d622b]
- Updated dependencies [0252320]
- Updated dependencies [2eb4724]
- Updated dependencies [e04a0af]
- Updated dependencies [6b97a20]
- Updated dependencies [75237a9]
- Updated dependencies [497655f]
- Updated dependencies [ada7012]
- Updated dependencies [3a9ad22]
- Updated dependencies [6d2571f]
- Updated dependencies [2bf6ef1]
- Updated dependencies [092d460]
- Updated dependencies [09e16a5]
- Updated dependencies [98bd798]
- Updated dependencies [cbcae14]
- Updated dependencies [8261ff7]
- Updated dependencies [24489f1]
- Updated dependencies [fc28c1d]
- Updated dependencies [6d64785]
- Updated dependencies [00c332b]
- Updated dependencies [b3b43b6]
- Updated dependencies [d93400f]
- Updated dependencies [b1d3945]
- Updated dependencies [134b410]
- Updated dependencies [84e6b05]
- Updated dependencies [cb1f274]
- Updated dependencies [5c28cc7]
- Updated dependencies [b0eb9a5]
- Updated dependencies [e233db9]
- Updated dependencies [176b035]
- Updated dependencies [a83dbb6]
- Updated dependencies [d3a2331]
- Updated dependencies [51297e9]
- Updated dependencies [2d892dd]
- Updated dependencies [156792e]
- Updated dependencies [5ba2ec3]
- Updated dependencies [abb01f1]
- Updated dependencies [e64ae15]
- Updated dependencies [02bdeaa]
- Updated dependencies [66abef3]
- Updated dependencies [25c9a83]
- Updated dependencies [ee5812a]
- Updated dependencies [68fea8b]
- Updated dependencies [c049e74]
- Updated dependencies [bb9794a]
- Updated dependencies [d402e32]
- Updated dependencies [63a8eb4]
- Updated dependencies [9a910c4]
- Updated dependencies [adabccf]
- Updated dependencies [340b6dc]
- Updated dependencies [99fcb4a]
- Updated dependencies [55095cc]
- Updated dependencies [0f1cd83]
- Updated dependencies [a3d4c59]
- Updated dependencies [1aa5026]
- Updated dependencies [2b80461]
- Updated dependencies [2bdb81f]
- Updated dependencies [b9d5422]
- Updated dependencies [c7448dc]
- Updated dependencies [627382b]
- Updated dependencies [0b31d90]
- Updated dependencies [4b58dcf]
- Updated dependencies [c23cfb3]
- Updated dependencies [559041d]
- Updated dependencies [e0d0553]
- Updated dependencies [5100c42]
- Updated dependencies [596090e]
- Updated dependencies [5380daa]
- Updated dependencies [00b38d7]
- Updated dependencies [47a9002]
- Updated dependencies [7056ca5]
- Updated dependencies [731f020]
- Updated dependencies [5eebc9e]
- Updated dependencies [72c1640]
- Updated dependencies [5e5ec9f]
- Updated dependencies [170fd83]
- Updated dependencies [922923b]
- Updated dependencies [2cac363]
- Updated dependencies [fc91239]
- Updated dependencies [e6c34f6]
- Updated dependencies [062f5cd]
- Updated dependencies [5d8319f]
- Updated dependencies [43f4766]
- Updated dependencies [8e8ea99]
- Updated dependencies [a484966]
- Updated dependencies [021755a]
- Updated dependencies [b929e0a]
- Updated dependencies [dbd4744]
- Updated dependencies [14a762f]
- Updated dependencies [b146102]
- Updated dependencies [75c0dac]
- Updated dependencies [9bb059d]
- Updated dependencies [07c6f82]
- Updated dependencies [502f179]
- Updated dependencies [f20fe29]
- Updated dependencies [362035c]
- Updated dependencies [7e0bfce]
- Updated dependencies [c120dbd]
- Updated dependencies [32b5831]
- Updated dependencies [74554a3]
- Updated dependencies [e56112c]
- Updated dependencies [aeaaa44]
- Updated dependencies [43460b9]
- Updated dependencies [44a2332]
- Updated dependencies [f34dda6]
- Updated dependencies [488f4f5]
- Updated dependencies [15f9284]
- Updated dependencies [a4ca69a]
- Updated dependencies [1ff3a8f]
- Updated dependencies [61dd96f]
- Updated dependencies [b971924]
- Updated dependencies [6afa59d]
- Updated dependencies [e37ea4d]
- Updated dependencies [8f6d831]
- Updated dependencies [fa29803]
- Updated dependencies [b01bdbc]
- Updated dependencies [adbdbc5]
- Updated dependencies [6cc8dcd]
- Updated dependencies [ba77509]
- Updated dependencies [408ca2e]
- Updated dependencies [ec292cf]
- Updated dependencies [dc0ab6a]
- Updated dependencies [19e58e2]
- Updated dependencies [7e1b048]
- Updated dependencies [342808c]
- Updated dependencies [b3615f1]
- Updated dependencies [0b4022b]
- Updated dependencies [a60c913]
- Updated dependencies [5c5b67f]
- Updated dependencies [3f9e2ea]
- Updated dependencies [77f54bf]
- Updated dependencies [ccccdcc]
- Updated dependencies [48c91e9]
- Updated dependencies [2b52a5b]
- Updated dependencies [0f057b6]
- Updated dependencies [3875ae6]
- Updated dependencies [1c16889]
- Updated dependencies [1912237]
- Updated dependencies [fc29c74]
- Updated dependencies [95fb417]
- Updated dependencies [4ec3987]
- Updated dependencies [5b9402d]
- Updated dependencies [2cf9db7]
- Updated dependencies [dc1b986]
- Updated dependencies [655e8c0]
- Updated dependencies [041c8cf]
- Updated dependencies [e3277c3]
- Updated dependencies [cc6dfd9]
- Updated dependencies [7536721]
- Updated dependencies [9df3934]
- Updated dependencies [0b83e01]
- Updated dependencies [ebc6afe]
- Updated dependencies [6696056]
- Updated dependencies [0e06f3b]
- Updated dependencies [c1dfa52]
- Updated dependencies [2548ba5]
- Updated dependencies [9282578]
- Updated dependencies [ecf90b2]
- Updated dependencies [90ff10a]
- Updated dependencies [2bbebf5]
- Updated dependencies [369bcbe]
- Updated dependencies [3bd28e2]
- Updated dependencies [9347c1f]
- Updated dependencies [c164186]
- Updated dependencies [e7344f0]
- Updated dependencies [4d7e740]
- Updated dependencies [de091b5]
- Updated dependencies [6aa3188]
- Updated dependencies [ae7a35a]
- Updated dependencies [cf55914]
- Updated dependencies [17bd318]
- Updated dependencies [681868c]
- Updated dependencies [2274894]
- Updated dependencies [e462186]
- Updated dependencies [b5853da]
- Updated dependencies [4ac9319]
- Updated dependencies [560b724]
- Updated dependencies [16c5473]
- Updated dependencies [b276d44]
- Updated dependencies [3f86dc5]
- Updated dependencies [172b4cf]
- Updated dependencies [67c98f6]
- Updated dependencies [b98fbc2]
- Updated dependencies [e7f69db]
- Updated dependencies [84156c7]
- Updated dependencies [e0f17a3]
- Updated dependencies [0bf85ea]
- Updated dependencies [1df29df]
- Updated dependencies [8a44ce7]
- Updated dependencies [ca753c0]
- Updated dependencies [8ecbe0f]
- Updated dependencies [6a4aec7]
- Updated dependencies [e4471e6]
- Updated dependencies [e8fcf55]
- Updated dependencies [8d1f7ab]
- Updated dependencies [cfc3bcf]
- Updated dependencies [dd1b803]
- Updated dependencies [03d6cb0]
- Updated dependencies [9e7824a]
- Updated dependencies [08c8484]
- Updated dependencies [93cfc3f]
- Updated dependencies [6ac33a5]
- Updated dependencies [443b2f4]
- Updated dependencies [7e7fab7]
- Updated dependencies [b09ce67]
- Updated dependencies [4df101c]
- Updated dependencies [6a6a17b]
- Updated dependencies [733822c]
- Updated dependencies [a91d12a]
- Updated dependencies [bea6d2e]
- Updated dependencies [f415bcf]
- Updated dependencies [5f9d7d7]
- Updated dependencies [31d281d]
- Updated dependencies [569d4d2]
- Updated dependencies [9e9bb46]
- Updated dependencies [0d7ed5a]
- Updated dependencies [2aa25ef]
- Updated dependencies [0e1afe8]
- Updated dependencies [288611e]
- Updated dependencies [dfd8e39]
- Updated dependencies [28ad7e4]
- Updated dependencies [e6b7d8c]
- Updated dependencies [40b315b]
- Updated dependencies [f2c7eef]
- Updated dependencies [7e36a3c]
- Updated dependencies [5a6267f]
- Updated dependencies [0bbe400]
- Updated dependencies [862b6ce]
- Updated dependencies [80153f5]
- Updated dependencies [26daf0b]
- Updated dependencies [826f327]
- Updated dependencies [7e5246d]
- Updated dependencies [b810ddb]
- Updated dependencies [7dc45eb]
- Updated dependencies [17e4f52]
- Updated dependencies [dcd3bce]
- Updated dependencies [2d91c9a]
- Updated dependencies [b285508]
- Updated dependencies [2c31070]
- Updated dependencies [7db1332]
- Updated dependencies [aeb0557]
- Updated dependencies [1c1b8c8]
- Updated dependencies [05077d4]
- Updated dependencies [ba5927f]
- Updated dependencies [75b2169]
- Updated dependencies [de8c973]
- Updated dependencies [65352b7]
- Updated dependencies [e956924]
- Updated dependencies [2304b16]
- Updated dependencies [c7ad16f]
- Updated dependencies [48efe91]
- Updated dependencies [fb38607]
- Updated dependencies [dc07593]
- Updated dependencies [e967cbd]
- Updated dependencies [8255a51]
- Updated dependencies [d1c01ff]
- Updated dependencies [9e1689f]
- Updated dependencies [b057434]
- Updated dependencies [5f392f0]
- Updated dependencies [a362e0e]
- Updated dependencies [f26fb8e]
- Updated dependencies [0da638c]
- Updated dependencies [041d9fd]
- Updated dependencies [b8ec127]
- Updated dependencies [e81c4e5]
- Updated dependencies [28f9277]
- Updated dependencies [929d9e3]
- Updated dependencies [8a5240a]
- Updated dependencies [c1d54db]
- Updated dependencies [c7af6bd]
- Updated dependencies [1f0b565]
- Updated dependencies [23aa83c]
- Updated dependencies [357f499]
- Updated dependencies [80aef80]
- Updated dependencies [65ad77d]
- Updated dependencies [a61ae59]
- Updated dependencies [fb59fb5]
- Updated dependencies [a54ecaa]
- Updated dependencies [854639b]
- Updated dependencies [44c917a]
- Updated dependencies [613d35a]
- Updated dependencies [e08c8b0]
- Updated dependencies [0ee32ed]
- Updated dependencies [58b36fa]
- Updated dependencies [4792049]
- Updated dependencies [53ec0b1]
- Updated dependencies [0a56d3b]
- Updated dependencies [f8e5790]
- Updated dependencies [d2c1d19]
- Updated dependencies [681871e]
- Updated dependencies [54e8234]
- Updated dependencies [d127f9b]
- Updated dependencies [4bbf766]
- Updated dependencies [c17b494]
- Updated dependencies [d414e2b]
- Updated dependencies [af98a04]
- Updated dependencies [43cbe14]
- Updated dependencies [c86d351]
- Updated dependencies [6e3e546]
- Updated dependencies [c4d1759]
- Updated dependencies [f7a9740]
- Updated dependencies [96451ec]
- Updated dependencies [9cdffbe]
- Updated dependencies [331a1a2]
- Updated dependencies [9788f1e]
- Updated dependencies [3cf6449]
- Updated dependencies [3cf6449]
- Updated dependencies [2bd53f1]
- Updated dependencies [5f9f846]
- Updated dependencies [5d527f7]
- Updated dependencies [5bf2330]
- Updated dependencies [9165d5c]
- Updated dependencies [d9e1587]
- Updated dependencies [07150b3]
- Updated dependencies [143c715]
- Updated dependencies [fb2bccf]
- Updated dependencies [d2badf7]
- Updated dependencies [d64bcb6]
- Updated dependencies [d4f5232]
- Updated dependencies [396eae3]
- Updated dependencies [ecdfc94]
- Updated dependencies [f04be62]
- Updated dependencies [de1a611]
- Updated dependencies [4fba503]
- Updated dependencies [db76982]
- Updated dependencies [5cf58eb]
- Updated dependencies [66e266c]
- Updated dependencies [3b1dab9]
- Updated dependencies [7607076]
- Updated dependencies [1555ed4]
- Updated dependencies [776d64c]
- Updated dependencies [03b19d9]
- Updated dependencies [6154165]
- Updated dependencies [199002b]
- Updated dependencies [ab450f4]
- Updated dependencies [21ab410]
- Updated dependencies [025588a]
- Updated dependencies [a49e8ae]
- Updated dependencies [f3e3d59]
- Updated dependencies [9bd4344]
- Updated dependencies [51efbf1]
- Updated dependencies [9c44eed]
- Updated dependencies [bbca441]
- Updated dependencies [7cd5874]
- Updated dependencies [3cb84d0]
- Updated dependencies [119a02b]
- Updated dependencies [eea8787]
- Updated dependencies [7887077]
- Updated dependencies [29dd1a6]
  - @objectstack/spec@17.5.0

## 17.4.0

### Minor Changes

- 3d3f60e: An approval decision that lands while its flow run strands now says so in fields, not only in prose.
  
  `POST /api/v1/approvals/requests/{id}/reject` — and its sibling decision doors — could produce three coexisting outcomes from one call: the caller read HTTP 500, the request row **was** in its terminal status and had left the pending inbox, and the workflow run was stranded. A caller reading 500 has one honest inference available — "the rejection did not happen" — and it was the wrong one, so scripts and operators retried or escalated against a decision that was already durable. The only carrier of the truth was English prose in `error`, so finding the affected run meant regexing a run id out of a sentence, and nothing said whether that run could be repaired at all.
  
  The 500 stays. A recorded decision whose flow never advances is still a failure and is still reported as one; the door does not become atomic and no decision is ever rolled back. What changed is that it stops discarding what the engine already said:
  
  - **The `RESUME_FAILED` body gains four fields**, additively — `finalized` (always `true`: the decision stands), `decision`, `runId`, and `repairable`. Existing consumers see the same `code`, the same `error` and the same status.
  - **`repairable` carries the engine's own discriminator** — `AutomationResult.status === 'stranded'`, the state stamped on exactly the exit that journals a repair snapshot. `false` is the answer for every other failure, including a lost run: absence of the signal is not repairability, and a repair verb that would refuse is worse than no promise.
  - **`serviceResume` carries `status`** through to the door. It previously read only `success` / `code` / `error`, and the stranded exit reports a `status` and no `code` at all — so the platform's own repairability signal died one line before the envelope was built.
  
  `@objectstack/types` gains `strandedDecisionFailure` / `strandedDecisionDetails` and the `StrandedDecisionDetails` type — the constructor and its recogniser in one module, so the producing service and the REST door cannot drift. A `RESUME_FAILED` raised without that carrier answers exactly the body it always did; the door never synthesises the envelope.

### Patch Changes

- 088f761: `createHostImporter` now loads the `import` build of an ALIASED dual-published package, instead of silently keeping its `require` build.
  
  An alias declaration — `{"dependencies": {"foo": "npm:bar@1"}}` — installs a package whose manifest is named `bar` under the key `foo`. On the path where CommonJS resolution SUCCEEDS, the importer re-decides only the CONDITION (it asks the package which entry an `import()` gets, so the caller's ESM chain and this load share one instance). That re-decision recognised the package root by walking up from the resolved entry until it found a manifest named after the DECLARATION KEY — `foo` — while an aliased install's manifest is named `bar`. The walk therefore never matched, the re-decision produced nothing, and the load fell back to whatever the CommonJS resolver had answered: the `require` condition.
  
  For an aliased dual publish that left the process holding two live copies of one package — the CommonJS build behind the host importer, the `import` build in the caller's own chain — which is exactly the split the condition re-decision exists to remove: a plugin registry, a singleton kernel, a module-level cache, one copy each.
  
  The expectation now comes from the host's own declaration (`npm:name@range`, aliased `workspace:name@range`), the same reading the ESM-only fallback finder has used since it learned about aliases. Nothing about the check's strictness moves: an alias naming one package still does not license a directory holding another, and a non-aliased declaration is still verified against its key. Declarations that name a LOCATION rather than a package (`link:`, `file:`) carry no name to expect, so they keep today's behaviour unchanged.
  
  Measured population for the behaviour change: zero aliased declarations exist across this workspace's 875 dependency declarations, and 867 of 867 installed declarations already match their key — no ordinary, non-aliased install reaches this path.
- c5d6803: Published `.js.map` files no longer embed the complete original source text (`sourcesContent`) — comments included. `sourcemap: true` was esbuild shorthand, and esbuild's own default for `sourcesContent` is `true`; nobody had decided to publish every package's full source (including `@internal`/test-only comments) to npm inside its source maps, it fell out of a default nobody had looked at. Measured before this change: 55 of 57 publishable packages shipped embedded source text, and maps were roughly half of `@objectstack/spec`'s published bytes.
  
  `sourcesContent: false` is now set at one shared place (`scripts/tsup-drop-sources-content.mjs`, wired into every `tsup.config.ts` via tsup's `esbuildOptions` hook — most packages build through the repo-root config directly and pick this up with no config change of their own). `mappings` are untouched, so stack-trace positions still resolve correctly to the original file/line/column; only the embedded source text is gone.
  
  `@objectstack/cli` (built with `tsc`, not `tsup`) never embedded source text to begin with — its maps' `sources` entries point at `src/**` paths that are not part of the published tarball either way. That is not a defect unique to `cli`: every `tsup`-built package's `sources` entries are `../src/**`-relative paths that are equally outside `files: ["dist", …]`, and were merely masked by the embedded content that just stopped shipping. Shipping `src/**` in `files[]` to make `sources` resolve was rejected — it would put most of the removed bytes straight back. So `cli`'s maps are left exactly as `tsc` emits them: this is now the fleet-consistent shape (accurate `mappings`, non-resolving-but-honest `sources` labels, no embedded text), not an outlier.
  
  A new gate, `pnpm check:sourcemap-no-sources-content`, sweeps every built, non-private package's `dist/**/*.map` and fails if any of them carries a non-empty `sourcesContent` array — so a future `tsup.config.ts` that skips the shared hook, or a toolchain upgrade that changes esbuild's default back, is caught rather than silently re-publishing source text.
- Updated dependencies [fe0d9a4]
- Updated dependencies [ecd2158]
- Updated dependencies [f2b5e46]
- Updated dependencies [ed7243d]
- Updated dependencies [6ba0db4]
- Updated dependencies [625b0c3]
- Updated dependencies [233222e]
- Updated dependencies [07f40e5]
- Updated dependencies [ceb4877]
- Updated dependencies [e9fcd6b]
- Updated dependencies [90e7e6d]
- Updated dependencies [2bdabe6]
- Updated dependencies [ca326b5]
- Updated dependencies [8f404a5]
- Updated dependencies [68437d4]
- Updated dependencies [abb140c]
- Updated dependencies [8333a6c]
- Updated dependencies [3e3ecb0]
- Updated dependencies [3030369]
- Updated dependencies [d5d8d50]
- Updated dependencies [e08892d]
- Updated dependencies [ae05f2e]
- Updated dependencies [b548e43]
- Updated dependencies [c463d03]
- Updated dependencies [64bd6a3]
- Updated dependencies [13c48c2]
- Updated dependencies [132742f]
- Updated dependencies [85a2459]
- Updated dependencies [50dc214]
- Updated dependencies [e89fa92]
- Updated dependencies [e9fcd6b]
- Updated dependencies [8976ea1]
- Updated dependencies [56fe8c2]
- Updated dependencies [acabd24]
- Updated dependencies [ab50c8f]
- Updated dependencies [6491463]
- Updated dependencies [89cf4d6]
- Updated dependencies [21c5dcb]
- Updated dependencies [6d4d5d3]
- Updated dependencies [ed5d557]
- Updated dependencies [bca21f7]
- Updated dependencies [e9fcd6b]
- Updated dependencies [1a7a7c9]
- Updated dependencies [e9fcd6b]
- Updated dependencies [ef3a138]
- Updated dependencies [68d5dfd]
- Updated dependencies [3e21cf0]
- Updated dependencies [4cfc93b]
- Updated dependencies [efd6b43]
- Updated dependencies [859ded3]
- Updated dependencies [fa125f3]
- Updated dependencies [74628d9]
- Updated dependencies [a646120]
- Updated dependencies [6f1ce7d]
- Updated dependencies [7778115]
- Updated dependencies [2c753fe]
- Updated dependencies [52804cd]
- Updated dependencies [3f89967]
- Updated dependencies [53cf263]
- Updated dependencies [21aabbc]
- Updated dependencies [9c270bb]
- Updated dependencies [76c8c5a]
- Updated dependencies [a84e1ce]
- Updated dependencies [bf1054a]
- Updated dependencies [d8d2776]
- Updated dependencies [222dc0f]
- Updated dependencies [e9fcd6b]
- Updated dependencies [32c917d]
- Updated dependencies [f9a3c32]
- Updated dependencies [f502898]
- Updated dependencies [af7edfe]
- Updated dependencies [b60f48b]
- Updated dependencies [c78c918]
- Updated dependencies [cf9bda4]
- Updated dependencies [784cb92]
- Updated dependencies [7629f4d]
- Updated dependencies [51df9fd]
- Updated dependencies [a7da4de]
- Updated dependencies [de0bcdd]
- Updated dependencies [70f7d6d]
- Updated dependencies [c677cda]
- Updated dependencies [554a160]
- Updated dependencies [f7da71e]
- Updated dependencies [7f745c3]
- Updated dependencies [5eb24f8]
- Updated dependencies [2a3decc]
- Updated dependencies [cc00df2]
- Updated dependencies [f4e6adf]
- Updated dependencies [ee4a59b]
- Updated dependencies [4db3c61]
- Updated dependencies [5ca314a]
- Updated dependencies [e0af1a8]
- Updated dependencies [414c1fc]
- Updated dependencies [22c0279]
- Updated dependencies [0db2947]
- Updated dependencies [92b5d7f]
- Updated dependencies [613bfbd]
- Updated dependencies [abae16a]
- Updated dependencies [094b8fd]
- Updated dependencies [c7aca0d]
- Updated dependencies [c1d8f98]
- Updated dependencies [8e0b297]
- Updated dependencies [5f7fa1d]
- Updated dependencies [87f0ccc]
- Updated dependencies [aedbaef]
- Updated dependencies [c5d6803]
- Updated dependencies [10d05bb]
- Updated dependencies [69602e5]
- Updated dependencies [c3ce76c]
- Updated dependencies [7936b29]
- Updated dependencies [46803fa]
- Updated dependencies [c2a336c]
- Updated dependencies [9f890d3]
- Updated dependencies [0bb2318]
- Updated dependencies [f7db8f4]
- Updated dependencies [1ecee3e]
- Updated dependencies [9408b7f]
- Updated dependencies [e9fcd6b]
- Updated dependencies [9bcd9be]
- Updated dependencies [b398ad2]
- Updated dependencies [99261a7]
- Updated dependencies [81b426f]
- Updated dependencies [001af1c]
- Updated dependencies [fb77aa5]
- Updated dependencies [581d8f8]
- Updated dependencies [f81afe3]
- Updated dependencies [40a44b9]
- Updated dependencies [7a7fb03]
- Updated dependencies [8fd246d]
  - @objectstack/spec@17.4.0

## 17.3.0

### Minor Changes

- 6a180e4: fix(core,rest,services)!: a permission-store read failure now fails LOUD instead of resolving as an authenticated caller holding zero capabilities (#13279)
  
  **BREAKING** runtime behaviour change on the shared authorization resolver,
  shipped as `minor` under the repo's launch-window convention.
  
  `resolveAuthzContext`'s per-read helper `tryFind` answered a THROWN read exactly
  the way it answered an EMPTY one: `[]`. So an outage of the permission store
  resolved as a well-formed context for an authenticated principal holding no
  capabilities, and the package-management door answered
  `403 FORBIDDEN` — "Reading packages requires the `studio.access` or
  `setup.access` capability." That answer was measured byte-identical
  (`JSON.stringify` equal, against a control that separates two answers which do
  differ) to what a caller who genuinely holds nothing receives. An administrator
  was told they lack a capability, during an outage of the store that holds the
  capability.
  
  Maintainer ruling 2026-08-30, verbatim 「第一批其余同意」: `tryFind` 区分「无行」
  与「读失败」,读失败 fail-loud —— 权限库不可达时不再解析为「已认证零能力」,而是
  响亮拒绝(与真实能力拒绝的 403 可区分)。
  
  Second maintainer ruling the same day (第 5 场总监席决裁批 #9, verbatim 「同意」),
  after implementing the first one showed that "the read failed" is two facts:
  采**选项 A** —— 把 `isMissingTableError` 从 `@objectstack/metadata` 迁至
  `@objectstack/types`(core 已依赖),metadata 保留 re-export 兼容;`tryFind` 仅对
  **未被判定为「表未 provision」**的读失败抛 `AuthzStoreUnavailableError`。
  
  **What changed.** A permission-store read that is issued and throws now raises
  `AuthzStoreUnavailableError`, which carries the EXISTING ADR-0112 wire code
  `SERVICE_UNAVAILABLE` and status `503`. No code is added to the closed wire
  vocabulary and no response envelope gains or loses a key — only which declared
  code an outage selects. Doors that map thrown errors through
  `resolveThrownHttpError` answer 503 with no per-door change.
  
  **What did NOT change**, and is pinned:
  
  - A reachable, genuinely EMPTY store (reads return no rows) still resolves to
    zero capabilities.
  - A genuine capability denial still answers `403 FORBIDDEN` with its message.
  - An ABSENT engine (`ql` unwired, so no read is ever issued) still resolves to
    an empty-but-valid envelope.
  - Anonymous requests never reach the store, so an outage cannot make them loud.
  - A REAL engine whose `sys_*` tables were never provisioned resolves to zero
    capabilities, quietly — pinned to be byte-identical to the empty-store
    envelope, in every dialect spelling and in the production wrapper shape where
    the driver's phrase is on `cause` rather than the outer message.
  
  **The boundary between the two kinds of read failure.** An earlier revision of
  this changeset claimed "embedders without a data plane are unaffected". That
  claim was too broad; it is retracted here, and the gap it named is now closed
  rather than merely disclosed. A read also throws when the table was never
  PROVISIONED — a real engine, wired and reachable, whose `sys_*` tables were
  never created — and that is a supported deployment shape, not an outage. There
  "zero capabilities" is the TRUE answer rather than a fabrication: nothing is
  provisioned, so nothing was withheld. Only an UNREACHABLE store — the ruling's
  own word 不可达 — leaves the capability set unknown, and only an unknown answer
  may not be reported as a denial.
  
  Treating the two alike was measured, not theorised: it turned four CI suites
  red, all from `no such table` on `sys_user` / `sys_member` /
  `sys_user_position` / `sys_user_permission_set`. Ordinary CRUD in
  `@objectstack/client` answered `503`; batch validation errors that owe `400`
  answered `503`, because authorization refused before validation ran; runtime
  notifications answered `401` where authenticated callers must be served `200`;
  and two `.integration.test.ts` noise guards reported that the driver and engine
  diagnostics for `sys_position` stopped being emitted — the eager throw aborted
  the resolution before that later read was ever issued, so a change made to stop
  a failed read being silent had made two other channels silent.
  
  `tryFind` therefore raises `AuthzStoreUnavailableError` only for a read failure
  that is NOT positively identified as an unprovisioned table.
  
  **`isMissingTableError` moved to `@objectstack/types`.** The classifier that
  draws that boundary already existed and was already right — driver-code based
  rather than prose-sniffing, documented so that "cannot say" never means "be
  loud". It lived in `@objectstack/metadata`, which DEPENDS ON `@objectstack/core`,
  so the resolver could not import it. Rather than keep a second copy of a
  security-relevant predicate, the ruling relocated the one classifier to
  `@objectstack/types` — the package core already depends on, and the repo's own
  stated Home rule for a cross-package error predicate ("every consumer of the
  question already depends on it, so adopting the predicate never adds an edge",
  `packages/types/src/unique-violation.ts`). `@objectstack/metadata/errors` still
  exports `isMissingTableError`, re-exported from the new home, so no consumer of
  that published subpath changes.
  
  Its sibling `isSchemaAlreadyExistsError` moved with it — the two are not two
  modules but two signatures over one matcher, and separating them would have
  meant re-rolling the matcher, which is the duplication the module exists to
  prevent. Both are now exported from `@objectstack/types`; the metadata subpath
  deliberately still publishes only `isMissingTableError`, which is the only one
  anything imports through it.
  
  ⚠️ **Signed-off risk, recorded because it is load-bearing.** Gating loudness on
  a driver-error predicate was approved with its false-positive direction stated:
  mis-reading a genuine outage as "table not provisioned" silently restores the
  quiet 403 this change removes, with no thrown error and no other failing test.
  That direction is accepted, not overlooked — the predicate keys on driver codes,
  SQLSTATEs and errnos first, excludes the known superstring traps up front, and
  returns `false` for anything it does not positively recognise, so an
  unrecognised outage stays loud by default. The risk is written beside the
  predicate in `resolve-authz-context.ts` and both directions are pinned by name
  in `authz-store-unavailable.test.ts`. ⛔ Do not widen `isMissingTableError` to
  make a first boot quieter: every widening moves outages into the quiet branch.
  
  **All-transport, not just REST.** Every transport authorizing through
  `resolveAuthzContext` inherits this. Six of the eight production transports
  wrapped the call in a fail-closed `catch` that would have re-silenced the
  outage — measured, not assumed: with the resolver loud but the nets untouched,
  the package door answered `401`, i.e. the outage merely changed disguises. Those
  `catch` blocks now re-raise via `isAuthzStoreUnavailableError` and keep their
  previous behaviour for every other fault. The transport set is rebuilt from
  source and audited for set equality on every test run, so a transport added
  later cannot inherit the old silence unnoticed.
  
  Callers that treat any throw from `resolveAuthzContext` as "anonymous" should
  re-raise `isAuthzStoreUnavailableError(err)` instead: degrading it restores the
  disguise this removes.
  
  <!-- adr-0087: not-required (runtime-interface-only packages/core/src/security/resolve-authz-context.ts#ResolvedAuthzContext, packages/core/src/security/authz-store-unavailable.ts#AuthzStoreUnavailableError) The breaking surface is runtime TypeScript in `@objectstack/core`'s security module and nothing else: `resolveAuthzContext` stops always-resolving and raises `AuthzStoreUnavailableError` when a permission-store read is issued and throws. NO metadata surface is touched in either direction. No Zod schema changes, no `packages/spec` declaration is added or removed, no authorable key moves, no stored row shape changes, and no object definition is edited — a customer's metadata app is byte-for-byte unaffected, so `objectstack migrate meta` has nothing to visit and there is no tombstone to mint. The wire vocabulary is likewise untouched: `SERVICE_UNAVAILABLE` is an EXISTING `StandardErrorCode` member that `HttpStatusErrorCodeMap` already maps to 503, so this change only selects a different DECLARED code for an outage rather than adding one. Both named symbols resolve at HEAD as exported declarations whose files are not `*.zod.ts`, are not under `packages/spec/src/contracts/`, are not object definitions and are not `z.input` projections; neither is referenced in code by any metadata surface (the `packages/spec` hits for `resolveAuthzContext` are comment prose describing the envelope, which this gate masks). The channel that reaches an affected consumer is therefore code review and this changeset, never the upgrade guide: a ledger entry could not express "your fail-closed catch should re-raise this error", because there is no metadata for a migration to rewrite. -->
- 0fb3044: fix(types): load a declared ESM-only host package through `createHostImporter`, and split its failure kind (#14041)
  
  The declared leg's finder is `hostRequire.resolve(pkg)` — a **CommonJS**
  resolution. A host-app package publishing only an `import` condition
  (`{"exports": {".": {"import": "./dist/index.js"}}}`, ordinary for pure-ESM
  publishes outside this workspace) made that resolve throw
  `ERR_PACKAGE_PATH_NOT_EXPORTED`, and the leg classified **every** resolver
  throw as `declared-unresolvable`: the load hard-failed, worded as an INSTALL
  problem — `pnpm install`, un-prune, rebuild — about an install that was fine.
  Nothing the message prescribed could help.
  
  **The finder.** When — and only when — `hostRequire.resolve` throws, the leg
  now consults exactly one directory: `<hostRoot>/node_modules/<name>` (name
  verified against the package's own manifest, then realpath'd, so its
  transitive imports resolve from its real location exactly as on the succeeding
  path). If that package's `exports` names an existing `import`-condition target
  for the requested subpath, it is imported. The fallback is **strictly
  tighter** than the CJS resolution it backs up — no `NODE_PATH`, no walk above
  `hostRoot`, no bare `require`, and Node's invalid-segment refusal mirrored
  before exports resolution (a subpath carrying `''`, `.`, `..` or
  `node_modules` segments is refused exactly as both of Node's resolvers refuse
  it, so a pattern key can never substitute a traversal span into its target) —
  so it cannot reopen the #4719 declaration-gate hole and cannot bypass the
  package encapsulation Node's resolvers enforce: a package reachable only
  through a hoisted store or a parent directory stays refused, even though CJS
  resolution can see it there, and a traversal specifier keeps the hard failure
  it has today. And because the fallback runs only inside a catch that was a
  hard failure before, no currently-succeeding load changes behaviour.
  
  **The split.** When the fallback cannot help either, the failure kind is
  decided by whether any install action could: a package absent from the host's
  `node_modules`, or one whose manifest names a runtime target whose file is
  missing (a dist never built, a partial publish), keeps `declared-unresolvable`
  and the existing INSTALL wording — it is right for both. A package that is
  installed and whose manifest names **no** runtime entry for the subpath under
  either the `require` or the `import` conditions (a `types`-only or
  `browser`-only publish, an unexported subpath) now fails as the new
  `HostImportFailureKind` value **`declared-no-loadable-entry`**, with a message
  about the package's own published shape — the remedy lives in the package,
  and an operator is no longer sent to re-run `pnpm install` against a correct
  install. The new error still carries `code: 'MODULE_NOT_FOUND'`, so every
  existing caller's missing-vs-crashed classification is unchanged, and an
  evaluation crash still propagates untouched with no kind.
  
  Consumers that branch on `HostImportFailureKind` should add an arm for
  `declared-no-loadable-entry`: a two-way branch written against the old
  two-member union will fall into its else leg for the new kind, whose wording
  ("declare it") is wrong for a package that is declared and installed.
- db8c288: fix(types): let `sendError`'s `extra` carry `declaredCode`, so a nested-envelope route can emit the ADR-0112 open channel (#11719)
  
  `ApiErrorSchema` has declared `declaredCode` since #9106 — the open,
  author-authored channel that carries a metadata app's own `.code` verbatim when
  the spelling is not a member of the closed `code` vocabulary. ADR-0112's
  2026-08-17 amendment rules that demote **platform-wide**, and #9232 extended it
  to the flat `/data` door, which emits the pair today.
  
  The shared nested-envelope writer could not. `sendError`'s `extra` was typed
  `Pick<ApiError, 'category' | 'httpStatus' | 'details' | 'requestId'>`, so
  passing a demoted spelling was a **compile error** and every route answering the
  nested envelope dropped it. Nothing invalid shipped — the closed `code` still
  carried the member derived from the status — which is exactly what made the loss
  silent and one-directional: the author's spelling gone, and a consumer told by
  the ADR to read `declaredCode` finding nothing there. Declared-but-unemittable
  is a `declared = enforced` gap, closed here at the one writer rather than per
  module.
  
  Additive: `declaredCode` joins the `Pick`. No existing call site changes, no
  wire byte moves for any body already being emitted, and the contract's accept
  set is untouched — the schema has always permitted the field.
  
  ⛔ Presence still MEANS demotion, and the writer does not re-derive that. The
  caller passes `demotedDeclaredCode(thrown)` (`@objectstack/types`), exactly as
  the flat door's `thrownCodeFields` does; that helper answers `undefined` when
  the producer's spelling is already the vocabulary member sitting in `code`, so a
  registered refusal never carries two spellings of one fact. Vocabulary and
  position stay two decisions (#9232).
  
  Pinned in `response-envelope.test.ts` by driving the real pipeline — a
  sandbox-shaped throw carrying a tenant-authored `.code` through
  `resolveThrownHttpError` and `demotedDeclaredCode` — and by parsing the emitted
  body with the real `ApiErrorSchema`, asserting the field is still on it *after*
  the parse. `ApiErrorSchema` is a plain `z.object` that strips undeclared keys,
  so a `.success` assertion alone would have passed against a schema declaring
  nothing.
- 0e5fe7f: fix(types): let `sendError`'s `extra` carry `userMessage`, so a nested-envelope route can emit the #9934 user-facing channel (#12404)
  
  `ApiErrorSchema` declares `userMessage` — the producer-side opt-in for "this
  exact text is addressed to the END USER" (#9934; maintainer ruling 2026-08-19 on
  objectui#5210, option 1), where **presence IS the marking** and a consumer that
  sees the field renders it verbatim instead of substituting its generic string
  (#3821 preserved by construction, for everything unmarked).
  
  Two of the three doors already emit it: the flat `/data` door through
  `withDeclaredUserMessage` (`@objectstack/rest`) and the dispatcher door through
  `thrown.userMessage` (`@objectstack/runtime`). The shared nested-envelope writer
  could not — `sendError`'s `extra` was typed
  `Pick<ApiError, 'category' | 'httpStatus' | 'details' | 'requestId' | 'declaredCode'>`,
  so passing the field was a **compile error** and every route answering the
  nested envelope dropped it. Nothing invalid shipped, which is what made the loss
  silent and one-directional: the author's deliberate, localized refusal text
  gone, and a consumer told to read `userMessage` finding nothing there.
  Declared-but-unemittable is a `declared = enforced` gap, closed here at the one
  writer rather than per module.
  
  Additive: `userMessage` joins the `Pick`. No existing call site changes, no wire
  byte moves for any body already being emitted, and the contract's accept set is
  untouched — the schema has always declared the field.
  
  The channel is live on both ends, which is what makes this a repair rather than
  a new declared-but-dead surface: a hook opts in at throw time (host-side, or a
  metadata app's sandboxed body whose `e.userMessage` crosses the QuickJS boundary
  through `SANDBOX_ERROR_PASSTHROUGH`), and `resolveThrownHttpError` already
  carries it onto `ThrownHttpError` for every caller of the shared resolver.
  
  ⛔ Unlike `declaredCode`, this field hands the caller **no invariant to
  re-derive**. `declaredCode`'s presence means demotion, so its caller passes
  `demotedDeclaredCode(thrown)`; `userMessage`'s presence means only that the
  producer opted in, which `declaredUserMessage` has already decided (a non-empty
  string, or nothing). The caller passes `thrown.userMessage` straight through,
  exactly as the dispatcher door does. That difference is why `extra` stays an
  explicit `Pick` rather than being derived from `ApiError`'s optional fields: a
  derivation would admit every future optional on the day it lands, with nobody
  asked what obligation the channel hands the caller — and these two fields needed
  opposite answers to exactly that question.
  
  Pinned in `response-envelope.test.ts` by driving the real pipeline — a hook
  refusal shaped like the one `hook-refusal-user-facing-marking.dogfood.test.ts`
  drives, through `resolveThrownHttpError` — and by parsing the emitted body with
  the real `ApiErrorSchema`, asserting the field is still on it *after* the parse,
  paired with a control showing an undeclared sibling being stripped from the same
  body. `ApiErrorSchema` is a plain `z.object` that strips undeclared keys, so a
  `.success` assertion alone would have passed against a schema declaring nothing.
  A blank marking is pinned ABSENT: the writer never invents a marked message for
  a producer that wrote none.
- 87ad30c: fix(types): `isMissingTableError` prefers the table a driver declared it targeted over the caller-supplied `readObject` — new `DRIVER_TARGETED_TABLE` / `declareTargetedTable` / `targetedTableOf` (#13438)
  
  `minor` because the public entry gains three exports; the predicate's signature
  `(error, readObject?)` is **unchanged**, and every existing caller compiles and
  behaves as before unless the error it holds carries a declaration.
  
  **The residual #13324 left behind.** `readObject` lets a caller say which table it
  read, so a phrase naming a *different* relation no longer earns the benign "not
  provisioned yet" verdict. But a caller names its **object**, and a driver compiles
  the statement against the **physical** table — for a federated object (ADR-0015,
  `external.remoteName`) two different names. A genuinely absent remote therefore
  raised a phrase naming `legacy_orders` against a caller naming `crm_order`, and the
  comparison read a real missing table as loud. The mapping lives on the driver
  instance; no call site can fold it away.
  
  **The channel (maintainer ruling 2026-09-01, option 2).** A driver that knows the
  table it targeted declares it on the error it composes:
  
  - `DRIVER_TARGETED_TABLE` — `Symbol.for('objectstack.driver.targetedTable')`, the
    well-known key, from the global registry so a duplicated package resolves it;
  - `declareTargetedTable(error, table)` — the producer's half: defines the name
    **non-enumerable and non-writable** (invisible to `JSON.stringify`, `{ ...err }`,
    `Object.keys`), first declaration wins, an empty or non-string name declares
    nothing;
  - `targetedTableOf(error)` — the reading half, `string | null`.
  
  `isMissingTableError` now compares the phrase against the **declared** table at
  any node of the `cause` chain that carries one — the nearest declaration to the
  dialect phrase wins — and ignores the caller-supplied `readObject` from that node
  down. Without a declaration the comparison is the #13324 one, byte-for-byte. The
  callers stay as they are: `crm_order` is still what they pass, and they never
  learn a federated object's remote name.
  
  **Two consequences, both pinned.** A genuinely absent federated remote reads
  benign again. And because a declaration is evidence the caller did not have, an
  envelope whose phrase names a relation *other* than its declared table reads
  **not benign even through the one-argument published form** — the #13324 verdict,
  reached without the caller's help, in the direction the module docblock calls
  cheap (one error line, never silent data loss). The #13324 narrowing itself does
  not reopen: a different relation's error — a view over a dropped base, a join
  target, a `sys_*` table hit inside the same statement — stays loud with the
  declaration present, on every dialect fixture the existing pins carry.
  
  `@objectstack/driver-sql` adopts the channel in the same release; the pattern is
  one call at any future driver's envelope. `isSchemaAlreadyExistsError` is
  untouched.
- 9735662: fix(security): walled postures elevate only the env-declared platform owner, never the first registrant (#11184, the framework leg of cloud#1509)
  
  **BREAKING** for walled deployments (`OS_TENANCY_POSTURE=group` or
  `isolated`), shipped as `minor` under the repo's launch-window convention for
  breaking changes. Single-org deployments are byte-for-byte unchanged.
  
  Measured defect (cloud#1509): on a walled multi-tenant SaaS with
  `OS_TENANCY_POSTURE=isolated` and `OS_AUTH_MEMBERSHIP_POLICY=invite-only`, the
  FIRST self-registrant received the cross-tenant `admin_full_access` grant
  (`platform_admin`, `isPlatformAdmin: true`) and — because the default-org
  bootstrap binds "the platform admin" — was merged into the deployment's
  Default Organization as its owner. Whoever curls the public sign-up endpoint
  first owned the platform.
  
  Per the maintainer ruling of 2026-08-23 (verbatim:
  「1509 选择 env 指定 owner 邮箱」):
  
  - **Walled postures: platform admin comes ONLY from the env-declared owner.**
    `bootstrapPlatformAdmin` (plugin-security) no longer promotes the oldest
    human user when the requested posture is walled; it promotes exactly the
    account whose email matches the new `OS_PLATFORM_OWNER_EMAIL` variable
    (case-insensitive, matched whenever that account registers — arrival order
    is irrelevant). Self-registrants are never promoted and, since the shared
    `ensureDefaultOrganization` helper binds only the platform admin, are never
    auto-merged into the Default Organization either.
  - **Fail-closed startup refusal.** A walled posture with no
    `OS_PLATFORM_OWNER_EMAIL` declared refuses to boot from `AuthPlugin.init()`
    with a message naming the variable — never a silent fallback to
    first-registrant elevation. The elevation site itself also refuses
    (`reason: 'walled_owner_email_undeclared'`, logged at `error`) as
    defense-in-depth for compositions that reach the bootstrap without
    plugin-auth (`os meta resync`, bare embeddings).
  - **Single-org posture unchanged.** "First user is owner" stays as ruled
    reasonable there; the new variable is never consulted under `single`.
  - The requested posture (`resolveTenancyPosture()`) is deliberately the input,
    so a walled-requested deployment running degraded
    (`OS_ALLOW_DEGRADED_TENANCY=1`) still refuses first-registrant elevation.
  
  Operator action for walled deployments: set `OS_PLATFORM_OWNER_EMAIL` to the
  operator account's email address before upgrading. Deployments that already
  hold a human platform admin are untouched (the bootstrap remains a no-op once
  any human holds the cross-tenant grant); the variable governs installs that
  have not yet minted their admin. `@objectstack/types` gains the
  `resolvePlatformOwnerEmail()` resolver and the `PLATFORM_OWNER_EMAIL_ENV`
  constant; the verify harness declares the owner email (defaulting to its dev
  admin) for walled fixtures.
  
  <!-- adr-0087: not-required (no-migration-prescription) nothing authorable is removed, renamed or narrowed: no spec key, no metadata spelling and no stored row changes shape, so there is nothing for `os migrate meta` to rewrite and no ledger entry to make. The prescription above is a deployment-environment requirement (declare an env var before boot), which the ADR-0087 ledger does not carry — the refusal itself names the variable at startup. -->
- 4d5b4f8: feat(auth): walled deployment's declared owner is email-verified at operator-provisioned creation (#12751)
  
  On a **walled** deployment (`OS_TENANCY_POSTURE` in the wall-enforcing
  family), the account whose email equals the declared platform owner
  (`OS_PLATFORM_OWNER_EMAIL`) is stamped `emailVerified` **at creation** when
  it comes into existence through an **operator provisioning path** — extending
  the #11343 dev-boot seeded-admin precedent to production walled boots
  (maintainer ruling 2026-08-28, cloud#1677: 「运营方创建即视为已验证」; the
  trust anchor is the operator's env-var declaration plus the
  operator-executed creation, not a mailbox round-trip; SMTP stays required
  only for inviting others).
  
  **Which creation paths qualify** (the [#11739] audience taxonomy, not a
  second classification):
  
  - the **bootstrap carve-out** — the very first account on a fresh install
    (zero human users), the one self-serve creation a walled boot admits;
  - **admin create-user / bulk import** (`method: 'admin'`) — an act only an
    authenticated admin session can perform;
  - **SCIM** (`method: 'scim'`) — provisioning executed by the
    operator-registered directory.
  
  **Never**: non-bootstrap self-registration (including an
  invitation-admitted registration typing the owner address), provider-class
  JIT (the IdP asserts its own `emailVerified` at insert), any non-owner
  address, any unwalled posture, and a later email **update** to the owner
  address (the stamp is staged at the admission gate and consumed once by the
  `user.create` before-hook — a seam an update cannot traverse). Dev-boot
  behaviour (#11343) is unchanged.
  
  The `WALLED_OWNER_NO_VERIFICATION_PATH` boot warning now probes the owner
  account's state: a fresh walled boot with no transport and no federated
  sign-in is **silent** (the operator's own first-account creation arrives
  verified — the case this closes), while an owner account that already
  exists **unverified**, a populated store whose bootstrap window is spent,
  and an unanswerable probe keep warning. A settled deployment whose owner is
  verified stops re-warning on every boot.
  
  `@objectstack/types` gains `isEmailVerifiedUserRow` — the [#11343]
  fail-closed verified-representation allow-list, moved from
  `plugin-security`'s private copy so the elevation gate and the boot
  diagnostic read ONE resolution (`plugin-security` now consumes it; no
  behaviour change there).

### Patch Changes

- 101ad2c: fix(types): an aliased install (`"foo": "npm:bar@1"`) is now found by the host importer's ESM-only fallback
  
  `createHostImporter`'s #14041 fallback finder verifies the one directory it
  consults — `<hostRoot>/node_modules/<key>` — by matching that directory's
  `package.json` `name` against the declared package name. An aliased install
  fails that check by construction: `{ "dependencies": { "foo": "npm:bar@1" } }`
  puts a manifest named `bar` at `node_modules/foo`. The finder answered
  `absent`, and an ESM-only aliased package therefore kept the pre-#14041 INSTALL
  wording — a confidently-wrong remedy sending an operator to run `pnpm install`
  against an install that is already correct, on a declaration shape
  `packageNameFromSpecifier`'s own documentation blesses.
  
  The declaration is now parsed for the name it promises: `npm:bar@1`,
  `npm:@acme/x@^2` and the aliased `workspace:bar@*` name the package installed
  under the key, so that is the manifest name the finder expects there. An
  aliased ESM-only package is rescued exactly as a plain one is, and an aliased
  install publishing nothing loadable gets the message about the PACKAGE's own
  shape instead of the INSTALL message.
  
  ⚠️ The manifest-name check itself is NOT loosened — that check is what keeps
  the fallback strictly tighter than the CJS resolution it backs up (#4719's
  declaration gate, from the fallback side). What moved is the EXPECTATION, still
  authored by the host and still read out of the host's own `package.json`: an
  alias naming one package refuses a directory holding another, a non-aliased
  declaration is unchanged, and a value that is not a bare package name — a
  `workspace:` range, an alias carrying a subpath — yields no expectation to move
  to, so the key stays and today's refusal is kept. `link:` and `file:` name a
  LOCATION rather than a package, so no name is derivable from them at all; they
  keep the key expectation, and with it the conservative direction the finder had
  before.
- a81aa9d: fix(types): a DEMOTED `declaredCode` is withheld on a 5xx the producer did not declare (#12509, ADR-0112)
  
  **Wire change, for undeclared server faults only.** When a 5xx has its prose
  withheld, the producer's demoted `declaredCode` is now withheld with it —
  but only when the fallback-to-500 picked that code up from a producer that
  declared no HTTP answer. An author-declared code is untouched at every status.
  
  FROM (`origin/main`, measured through the real routes):
  
  ```
  POST /api/v1/packages/publish   → 500 {"error":{"code":"INTERNAL_ERROR",
      "message":"Internal server error","declaredCode":"SQLITE_ERROR"}}
  POST /api/v1/analytics/query    → 500 {"error":{"code":"INTERNAL_ERROR",
      "message":"Internal server error","httpStatus":500,"declaredCode":"42P01"}}
  ```
  
  TO:
  
  ```
  POST /api/v1/packages/publish   → 500 {"error":{"code":"INTERNAL_ERROR",
      "message":"Internal server error"}}
  POST /api/v1/analytics/query    → 500 {"error":{"code":"INTERNAL_ERROR",
      "message":"Internal server error","httpStatus":500}}
  ```
  
  UNCHANGED — the author-authored channel the ADR-0112 amendment wrote
  `declaredCode` for:
  
  ```
  { status: 503, code: 'ACME_LEDGER_OFFLINE' }
      → 503 {"error":{"code":"SERVICE_UNAVAILABLE",…,"declaredCode":"ACME_LEDGER_OFFLINE"}}
  ```
  
  `SQLITE_ERROR` vs `42P01` names the backend, which is one of the two
  disclosures the 5xx message withhold exists to prevent (the other,
  identifiers, was already covered). Maintainer ruling 2026-08-27, option D.
  
  **What a consumer must know.** A `declaredCode` on a 5xx now means the
  producer declared that fault itself, which is a stronger guarantee than the
  field carried before; nothing that was a *registered* code moves, and no 4xx
  moves. A producer that spells a code but declares no status loses that code
  on a 5xx — declare the status the refusal means and the spelling is kept.
  
  The distinction lives in ONE place, `serverFaultProvenance`
  (`packages/types/src/thrown-http-error.ts`), read by `demotedDeclaredCode` —
  the read every door already makes — so all five emitting exits inherit it and
  no registrar carries a variant. The prose axis of the same ruling (the
  dispatcher door adopting the structural withhold for every declared 5xx
  message) is #12281 and is deliberately not applied here.
- 56c093c: fix(driver-memory): enforce field-level `unique`, so a colliding write is refused instead of landing silently (#13197)
  
  `InMemoryDriver` enforced **no uniqueness at all**. `create` was a
  `table.push()` and `syncSchema` allocated an array, so a `unique: true` field
  was declared-and-not-enforced — the ADR-0078 / Prime-Directive-#10 shape the
  platform refuses everywhere else. A colliding write did not fail; it landed, and
  a read returned both rows.
  
  The motivating instance is the worst-shaped one. The engine's
  `createWithAutonumberResync` re-seeds the counter and re-issues a record number
  when the STORE rejects it as a duplicate, so on a store that rejected nothing
  the whole branch was unreachable: an autonumber allocated out of process
  duplicated an existing business identifier with **no error anywhere**. The
  remedy's location was already ruled in-tree at that method — «uniqueness
  enforcement in the driver, NOT a pre-issue existence probe here» — and this is
  that remedy. Nothing in the new code knows what an autonumber is; the defect was
  that the driver constrained nothing.
  
  **The refusal** carries the ADR-0112 envelope the SQL family answers a conflict
  with: `code: 'UNIQUE_VIOLATION'`, `status: 409`, no `[driver-memory]` prefix. So
  a suite that swaps this driver for SQLite sees one envelope — the parity
  `memory-filter-refusal-envelope.test.ts` already states for the filter family,
  now held for the constraint family. It is checked before the row is written, so
  a refused write leaves the table exactly as it found it, and `updateMany`
  prepares and checks the whole batch before mutating any of it.
  
  **The scoping is `driver-sql`'s, measured — not a simpler invention.** Read off
  `uniqueIndexesFromFields` (ADR-0120 D1/D3) and reproduced arm for arm:
  `unique: 'global'` is platform-wide; bare `true` and `'organization'` are
  per-organization (bare `true` is the POSITIONAL spelling of `'organization'` at
  FIELD level — reading it as `'global'` is the #4986 trap and would make two
  organizations' identical values collide on a constraint neither can see); both
  degrade to a single column when the object has no tenant column, and a `unique`
  declaration on the tenant column itself stays single-column. NULL values stay
  NULL-DISTINCT, exactly as under SQL `UNIQUE`. The D3 NULL-organization fold
  needs no `'__global__'` token here — that sentinel is a SQL-expression artefact,
  and a JavaScript key holds `null` directly.
  
  **Not** widened into: object-level declared `indexes[]` (composite uniques),
  primary keys, or row-level tenant isolation. This driver still refuses to boot
  multi-tenant (#6915) and that guard is untouched.
  
  `@objectstack/types` (`patch`): `isUniqueViolationError` now reads the
  platform's own registered `UNIQUE_VIOLATION` code on the `code` channel. Not
  cosmetic — a conflict that predicate does not recognise leaves the autonumber
  resync unable to re-seed, so the counter stays warm and every following insert
  collides too (#5495's PROBE3 storm), i.e. a silent duplicate traded for a
  non-converging insert loop. It is a tautology rather than a widened heuristic
  (the code already MEANS this condition), and no existing in-repo producer's
  classification changes: `@objectstack/rest`'s own response body is the only
  other site carrying that string, and it is downstream of the predicate.
  
  **Grade.** `minor` for the driver, not `patch`: a write that previously
  succeeded is now refused (`409`), which is an accept-set narrowing under the
  repo's launch-window convention for breaking changes, and the package also gains
  public exports (`UNIQUE_VIOLATION_CODE`, `uniqueConstraintsFromFields`,
  `tenantFieldOf`, `uniqueKeyOf`, `assertNoUniqueViolation`,
  `uniqueViolationError`). `patch` for `@objectstack/types`: no API added or
  removed and no in-repo verdict changes — the limb exists to serve the new
  producer. Fixtures that relied on duplicates landing on a declared-unique field
  must stop declaring `unique`, or stop writing the duplicate; the repo's own
  suites were measured and none did.
- bfe13c8: fix(types,cli): resolve host-declared packages through the `import` condition, and read the cluster registry instead of assuming it (#13330)
  
  `createHostImporter`'s declared leg resolved with `hostRequire.resolve(pkg)` — a
  **CommonJS** resolution, which answers the `require` condition. Every `tsup`
  dual build publishes `{ "import": "./dist/index.js", "require": "./dist/index.cjs" }`,
  so a package loaded through that leg evaluated as its **CommonJS** build while
  the callers (`packages/cli` is `"type": "module"`) held the **ESM** build of the
  same package. The process ended up with two instances of everything the loaded
  package shares with its caller, each with its own module-scope state.
  
  Measured consequence, on the shipped EE multi-node path (ADR-0018): `os serve`
  loaded `@objectstack/service-cluster-redis` through this leg, the driver's
  load-time `registerClusterDriver('redis', …)` ran against the CommonJS copy of
  `@objectstack/service-cluster`, and the ESM `Runtime` read the ESM copy and
  found nothing — `OS_CLUSTER_DRIVER=redis` died at `defineCluster()` with
  `Cluster driver "redis" is not registered`, about a package that was installed,
  declared and resolvable. Any module-scope registry crossing this seam had the
  same defect; the cluster driver is the instance that shipped.
  
  **The seam.** The declared leg now imports the entry the `import` condition
  names. The host anchor is untouched — the CJS resolver still answers *where*
  the package is, because no flagless Node API resolves a bare specifier against
  an arbitrary parent; only the *condition* is re-decided, by reading that
  package's own `exports` map. Deliberately narrow at the **resolution** level —
  no load that works today resolves differently unless the package itself
  publishes a valid, existing import-condition target: a package with no
  `exports` map is untouched (CJS resolution already returned `main`), a package
  publishing no import-condition target is untouched, and anything unreadable or
  absent on disk falls back to the CJS-resolved path. That narrowness does not
  extend to **evaluation**: a dual-published package whose `import` build exists
  but throws while its `require` build works used to mask that break by silently
  loading the CJS build, and now surfaces it — arguably the correct reading of a
  broken published build, but a behaviour change, not a no-op.
  
  **The reading.** A residual split is still possible above the seam — two
  *physical* copies of one package are two instances in any module system, and no
  resolver condition merges them — so `os serve` no longer assumes the driver
  registered. `@objectstack/service-cluster` exports `listClusterDrivers()`, the
  registry `defineCluster()` itself consults, and `serve` queries it after the
  load. The silent `catch` is gone: a driver that loaded but stayed invisible, one
  that could not be resolved, and one that resolved and then crashed now read as
  three different diagnoses instead of arriving as `not registered` one line
  later. An app on an older `@objectstack/service-cluster` has no accessor to
  call; that case is silent — `serve` declines to claim either answer rather
  than printing one.
  
  No behaviour downstream of the diagnosis changed: an absent driver still reaches
  `defineCluster()`'s documented error (`cluster.mdx` §8.1) rather than silently
  downgrading to the in-memory cluster, and the only documented downgrade here —
  a multi-node gate denial — is untouched.
- 22e5236: fix(types,runtime): log every 5xx at `error` level instead of answering it silently (#14310)
  
  A 500 that leaves no server-side line is diagnosed from the browser or not at
  all. Measured on `main`, through the real plugin and the real route handlers: a
  plain `Error` thrown out of a dispatcher route answered `500 INTERNAL_ERROR`
  with **zero** log records at any level — the only evidence was the client's
  console and the response body. That is AGENTS.md "Route & surface ownership §3
  — absence must be loud" inverted, and it is why a `/api/v1/packages` regression
  stayed invisible for a week.
  
  The reporting that already existed was not a substitute, for two independent
  reasons:
  
  - `ErrorReporter.captureException` defaults to `NoopErrorReporter`. A dev
    server — the surface an operator actually watches — wires no APM, so the
    capture was a no-op every time. A log line is the operator's floor; APM is
    opt-in telemetry on top of it.
  - It is fed by `res.__obsRecordedError`, which only the THROWN exit sets. A
    route that catches its own fault and RETURNS a 5xx envelope — how every
    `/packages` handler answers, via `deps.errorFromThrown` — recorded nothing,
    so even a wired reporter never saw those.
  
  **The rule now has one definition.** `logServerFault` (new, in
  `@objectstack/types`) emits exactly one `error`-level record carrying method,
  path, request id, the message and — where the door still holds the throw — the
  stack. It shares a home with `resolveThrownHttpError` for the same reason that
  rule was moved there in #8016: a rule two doors must agree on cannot live
  inside one of them, because `@objectstack/runtime` depends on
  `@objectstack/rest` and an import could only ever point one way.
  
  Wired at each transport's single exit, so a fault costs one line and never two:
  
  - `sendError` — the one writer for every nested-envelope error in the repo. The
    REST direct-mount registrars (the `/api/v1/packages` door that mounts first
    in production) become loud through it with no per-door call, so a door added
    later cannot forget one.
  - The dispatcher's thrown exit (`errorResponseBase`), its returned exit
    (`sendResultBase`) and the AI-route mount that writes its own result.
  
  `packages/rest`'s `/data` doors were already loud via `logUnexpectedRouteError`
  and are untouched.
  
  `error` level is load-bearing: the CLI's default is `warn` and `error` (40)
  outranks `warn` (30), so the record clears `--log-level`'s default without
  bypassing the level system. `--log-level silent` still silences it, which is a
  deliberate instruction rather than the default this fixes.
  
  **4xx stays quiet**, decided once inside the helper rather than at each call
  site — client mistakes are already explained by the response, and logging them
  is how a `?state=draft` probe once printed 45 stack traces in one browsing
  session. The wire body is byte-identical at every door: this adds a side
  effect, never a field.
  
  ⚠️ Behaviour change worth knowing before upgrading: a deployment that answers
  a *declared* 5xx on a polled route — `501 NOT_IMPLEMENTED` from an uninstalled
  optional service, say — now prints one `error` line per request where it
  previously printed none. The band is the one the issue specifies ("4xx may stay
  quiet; 5xx never"); narrowing it for declared capability-absence would be a
  separate contract decision.
- 2cf5a96: An organization no longer stops accepting members at 100 — membership is not a
  limited axis, and the ceiling nobody chose is now stated explicitly
  
  A customer adding users was refused with `Organization membership limit
  reached`. Nothing in this codebase set that ceiling: better-auth's organization
  plugin substitutes a vendor default of **100** for an absent `membershipLimit`
  (`count >= (membershipLimit || 100)` in `routes/crud-members`), and
  `auth-manager` passed `organizationLimit` — how many organizations one user may
  CREATE — while never passing `membershipLimit`, which is a different question.
  
  The two read almost identically in a config block and mean nothing alike, which
  is why the gap survived: the option that WAS set looked like the option that
  was not. In the field the refusal is worse than merely wrong — it arrives while
  an operator is looking at licences and seat counts, and reads as an entitlement
  problem on an axis that carries no entitlement at all. Seats are metered on AI
  usage; plain membership has never been billed.
  
  - `membershipLimit` is now passed explicitly, defaulting to unbounded.
  - `OS_ORG_MEMBERSHIP_LIMIT` is the opt-in for a deployment that DOES want a
    ceiling (a pilot, a trial tenant). Unusable values (empty, non-numeric,
    zero, negative) read as unset rather than as a cap — a typo must not be the
    thing that locks an organization, which is exactly the failure mode being
    fixed.
  - The decision lives in `resolveMembershipLimitOption()` rather than inside the
    plugin-construction expression, so it is testable: the unset case, the
    explicit ceiling, the unusable-value direction, and — deliberately — that the
    chosen value clears the vendor's 100 by a wide margin. If a future
    better-auth changes that default, the test says so instead of leaving an
    unexplained constant behind.
  
  The unbounded value is `Number.MAX_SAFE_INTEGER`, not `Infinity`: the option is
  compared numerically but also travels through option plumbing that may assume a
  finite value, and nine quadrillion members is unlimited by any measure that
  reaches a real deployment.
- Updated dependencies [809d417]
- Updated dependencies [387e231]
- Updated dependencies [f794e4e]
- Updated dependencies [cae2169]
- Updated dependencies [b812a54]
- Updated dependencies [2d4fa75]
- Updated dependencies [0e4e51b]
- Updated dependencies [e84bbf6]
- Updated dependencies [effae80]
- Updated dependencies [d62f990]
- Updated dependencies [c45d8e6]
- Updated dependencies [2e3e8c7]
- Updated dependencies [e621291]
- Updated dependencies [40a93b5]
- Updated dependencies [d5b330d]
- Updated dependencies [dda969c]
- Updated dependencies [1f45690]
- Updated dependencies [277948f]
- Updated dependencies [8bdd955]
- Updated dependencies [f3bbbef]
- Updated dependencies [4f24e9d]
- Updated dependencies [474242f]
- Updated dependencies [63cd487]
- Updated dependencies [bd4aa4e]
- Updated dependencies [803eaab]
- Updated dependencies [f8e8f03]
- Updated dependencies [eae824e]
- Updated dependencies [f6fa22c]
- Updated dependencies [8a483b3]
- Updated dependencies [97bcd99]
- Updated dependencies [df59de0]
- Updated dependencies [96e25a8]
- Updated dependencies [f75a38a]
- Updated dependencies [7a25e7d]
- Updated dependencies [1fa05a6]
- Updated dependencies [c85a265]
- Updated dependencies [dcb10a5]
- Updated dependencies [773a999]
- Updated dependencies [35dffea]
- Updated dependencies [776a098]
- Updated dependencies [5060877]
- Updated dependencies [4f6325d]
- Updated dependencies [52954c0]
- Updated dependencies [2aa8456]
- Updated dependencies [93809a3]
- Updated dependencies [7c0d0c3]
- Updated dependencies [daae7aa]
- Updated dependencies [8dc22d6]
- Updated dependencies [279431e]
- Updated dependencies [948dd6b]
- Updated dependencies [3b4c56c]
- Updated dependencies [ae8edd2]
- Updated dependencies [e25403c]
- Updated dependencies [64baa68]
- Updated dependencies [9fa70d7]
- Updated dependencies [09db64a]
- Updated dependencies [92916e7]
- Updated dependencies [a84f3ea]
- Updated dependencies [f2eaae8]
- Updated dependencies [c09451b]
- Updated dependencies [ba64877]
- Updated dependencies [7345308]
- Updated dependencies [79b6a22]
- Updated dependencies [30d96ab]
- Updated dependencies [f658793]
- Updated dependencies [c95ad19]
- Updated dependencies [e58ea8b]
- Updated dependencies [4a17645]
- Updated dependencies [3795c5f]
- Updated dependencies [8ab926b]
- Updated dependencies [7317cf2]
- Updated dependencies [e25e839]
- Updated dependencies [5997207]
- Updated dependencies [8b13cc8]
- Updated dependencies [4a4a35d]
- Updated dependencies [86e765a]
- Updated dependencies [1d7e76a]
- Updated dependencies [53dc739]
- Updated dependencies [fd289be]
- Updated dependencies [03bf7b1]
- Updated dependencies [f90e820]
- Updated dependencies [18d816a]
- Updated dependencies [e8bd715]
- Updated dependencies [b91c351]
- Updated dependencies [a28a3c0]
- Updated dependencies [daeaaf9]
- Updated dependencies [c459da6]
- Updated dependencies [e914733]
- Updated dependencies [f887e52]
- Updated dependencies [881f8d8]
- Updated dependencies [3bfa1e6]
- Updated dependencies [901355c]
- Updated dependencies [34ce8e7]
- Updated dependencies [33681ea]
- Updated dependencies [4635f3e]
- Updated dependencies [ee3595c]
- Updated dependencies [b2eab95]
- Updated dependencies [93940d4]
- Updated dependencies [3a04b01]
- Updated dependencies [45b9051]
- Updated dependencies [b9e9227]
- Updated dependencies [d395692]
- Updated dependencies [5894d30]
- Updated dependencies [a3765f6]
- Updated dependencies [e22158f]
- Updated dependencies [7404925]
- Updated dependencies [0c2334f]
- Updated dependencies [778c59f]
- Updated dependencies [d2619fd]
- Updated dependencies [6acb11a]
- Updated dependencies [33c5fd3]
- Updated dependencies [20b0fdb]
- Updated dependencies [905019b]
- Updated dependencies [a286411]
- Updated dependencies [98c0d33]
- Updated dependencies [368a82e]
- Updated dependencies [a3d5724]
- Updated dependencies [93ea19b]
- Updated dependencies [9ee2dcf]
- Updated dependencies [8cb96ec]
- Updated dependencies [8f10a79]
- Updated dependencies [6269a55]
- Updated dependencies [0fb8760]
- Updated dependencies [e5ce2ed]
- Updated dependencies [be21955]
- Updated dependencies [bc56e18]
- Updated dependencies [be21955]
- Updated dependencies [a9ee989]
- Updated dependencies [4d0d944]
- Updated dependencies [15d58db]
- Updated dependencies [d63b014]
- Updated dependencies [9abe4e4]
- Updated dependencies [2cc7122]
- Updated dependencies [50d6c92]
- Updated dependencies [9e0ba21]
- Updated dependencies [311433f]
- Updated dependencies [3e5ad08]
- Updated dependencies [9abe4e4]
- Updated dependencies [b7131f3]
- Updated dependencies [e5812fa]
- Updated dependencies [7085f90]
- Updated dependencies [dee4dd4]
- Updated dependencies [ce7e497]
- Updated dependencies [51ecb2f]
- Updated dependencies [9086761]
- Updated dependencies [42a117b]
- Updated dependencies [1401ae7]
- Updated dependencies [4297fe7]
- Updated dependencies [e398863]
- Updated dependencies [d16df74]
- Updated dependencies [f11fc61]
- Updated dependencies [e808890]
- Updated dependencies [8f79379]
- Updated dependencies [e6ca40e]
- Updated dependencies [0c77ea4]
- Updated dependencies [52954c0]
- Updated dependencies [89eb997]
- Updated dependencies [aa5994e]
- Updated dependencies [be93457]
- Updated dependencies [a65db76]
- Updated dependencies [15eb2c9]
- Updated dependencies [5691b07]
- Updated dependencies [2a6122b]
- Updated dependencies [225e769]
- Updated dependencies [8af88dd]
- Updated dependencies [fb5fbb8]
- Updated dependencies [d7b3963]
- Updated dependencies [b72db01]
- Updated dependencies [dce5cd4]
- Updated dependencies [177ebdc]
- Updated dependencies [8d237b4]
- Updated dependencies [2d2e6f0]
- Updated dependencies [2d8dd8d]
- Updated dependencies [22d573e]
- Updated dependencies [b5a2398]
- Updated dependencies [348860c]
- Updated dependencies [5383fa6]
- Updated dependencies [5b3ff63]
- Updated dependencies [1a6a19c]
- Updated dependencies [527e050]
- Updated dependencies [dd33bf9]
- Updated dependencies [4cb2a90]
- Updated dependencies [74a7804]
- Updated dependencies [53d3689]
- Updated dependencies [b3a63d3]
- Updated dependencies [033a34c]
- Updated dependencies [4d25d22]
- Updated dependencies [1ffee51]
- Updated dependencies [5ae4303]
- Updated dependencies [ece4dad]
- Updated dependencies [e9b377e]
- Updated dependencies [146f448]
- Updated dependencies [735f5c7]
- Updated dependencies [a7e18de]
- Updated dependencies [366f895]
- Updated dependencies [dc75ba8]
- Updated dependencies [cce0aa9]
- Updated dependencies [e764507]
- Updated dependencies [cff17af]
- Updated dependencies [39404f3]
- Updated dependencies [ca1965f]
- Updated dependencies [8619f95]
- Updated dependencies [b706af9]
- Updated dependencies [fc9ba76]
- Updated dependencies [0f94cc7]
- Updated dependencies [a11c1a5]
- Updated dependencies [71f9cd1]
- Updated dependencies [ee17d86]
- Updated dependencies [cdbd920]
- Updated dependencies [18c432e]
- Updated dependencies [3c418c4]
- Updated dependencies [fa8715a]
- Updated dependencies [a933ed7]
- Updated dependencies [b3ca463]
- Updated dependencies [a933ed7]
- Updated dependencies [0d4a6a8]
- Updated dependencies [518d5e5]
- Updated dependencies [6643ba1]
- Updated dependencies [eeba2ef]
- Updated dependencies [ec4c4d2]
- Updated dependencies [424f73c]
- Updated dependencies [cccbe51]
- Updated dependencies [a8d6b1d]
- Updated dependencies [e4a7695]
- Updated dependencies [87075b1]
- Updated dependencies [fc58a99]
- Updated dependencies [14cfc00]
- Updated dependencies [1c6f7b4]
- Updated dependencies [e854a53]
- Updated dependencies [dfebfc8]
- Updated dependencies [d028b37]
- Updated dependencies [122ef38]
- Updated dependencies [4a37870]
- Updated dependencies [428f9b2]
- Updated dependencies [aa7ff56]
- Updated dependencies [c41b42e]
- Updated dependencies [c4db311]
- Updated dependencies [750fff5]
- Updated dependencies [c19035e]
- Updated dependencies [ececf7a]
- Updated dependencies [d173125]
- Updated dependencies [8eeca27]
- Updated dependencies [8425c17]
- Updated dependencies [a5ef1d8]
- Updated dependencies [772d5de]
- Updated dependencies [ce80ec2]
- Updated dependencies [b372318]
- Updated dependencies [97a2263]
- Updated dependencies [29d0676]
- Updated dependencies [0169d49]
- Updated dependencies [6bd3231]
- Updated dependencies [d2b5ba8]
- Updated dependencies [b799ac5]
- Updated dependencies [8f74307]
- Updated dependencies [d23dc08]
- Updated dependencies [644ad50]
- Updated dependencies [0da7cd2]
- Updated dependencies [28a5c3e]
- Updated dependencies [4bc18e5]
  - @objectstack/spec@17.3.0

## 17.2.0

### Minor Changes

- 46d34ab: `createHostImporter`: resolve the undeclared fallback from the CALLER, not from `@objectstack/types`
  
  The helper's documented contract said the undeclared case "falls back to the importing
  package's own resolution". It did not. The fallback was a bare `import()` written inside
  `@objectstack/types`, and Node ESM resolves a bare specifier against the module that
  CONTAINS the call — so it resolved from `@objectstack/types`, which under a pnpm-isolated
  layout can see only its own single dependency, `@objectstack/spec`. Measured from an app
  declaring nothing: `@objectstack/plugin-auth`, `@objectstack/plugin-audit` and `chalk` all
  resolve from `packages/cli` and all failed through the helper. Under a hoisted npm/yarn
  layout the same fallback usually does find the caller's dependencies, so the claim was
  green in some installs and absent in others.
  
  `createHostImporter(hostRoot, options)` now takes the caller's resolution base as
  `options.fallbackImport` — the caller's own `import()`, written in the calling module:
  
  ```ts
  createHostImporter(hostRoot, { fallbackImport: (s) => import(s) })
  ```
  
  **minor, not patch, and not major.** New exported API (`HostImporterOptions`,
  `FallbackImport`, a second parameter) makes it additive rather than a fix-only patch. It
  is not a breaking change because the parameter is optional and omitting it keeps the
  previous resolution base exactly — an existing caller compiles and behaves as before. The
  `undeclared` failure text now names that retained default when a caller has not passed a
  base, so the gap reports itself instead of being rediscovered by measurement.
  
  `@objectstack/verify` (patch) passes its own base from `bootStack`. Measured: this changes
  nothing for `@objectstack/organizations`, the only specifier it routes through the helper —
  that package is cloud-private and resolves from nowhere in the framework workspace. It is
  what stops the next app-supplied package added to that path from silently missing
  `packages/verify`'s own dependencies.
  
  A string `parentURL` / `import.meta.url` base was measured on Node v22.22.2 and rejected in
  both spellings: `import.meta.resolve`'s parent argument is silently ignored without
  `--experimental-import-meta-resolve` (a change that would have compiled, run, and pinned
  green while ignoring the base), and `createRequire(parentURL)` is CJS resolution, which
  honours `NODE_PATH` — the hole the declaration gate exists to close, re-opened on the
  fallback path.

### Patch Changes

- Updated dependencies [6936d07]
- Updated dependencies [59eb04d]
- Updated dependencies [9f05b7d]
- Updated dependencies [7d2d112]
- Updated dependencies [5fa0d72]
- Updated dependencies [02b3b07]
- Updated dependencies [914c413]
- Updated dependencies [55809a0]
- Updated dependencies [52db1d1]
- Updated dependencies [5649efb]
- Updated dependencies [2306a76]
- Updated dependencies [e5ea701]
- Updated dependencies [a40dcc1]
- Updated dependencies [def0d3e]
- Updated dependencies [8d0bb79]
- Updated dependencies [5acb58d]
- Updated dependencies [2e3cf95]
- Updated dependencies [4c93387]
- Updated dependencies [a037f7c]
- Updated dependencies [3ee8ddf]
- Updated dependencies [16cef97]
- Updated dependencies [a79bd35]
- Updated dependencies [6ceaa4b]
- Updated dependencies [15ea214]
- Updated dependencies [de19489]
- Updated dependencies [c684d00]
- Updated dependencies [923c424]
- Updated dependencies [1ec36b7]
- Updated dependencies [5f2e54c]
- Updated dependencies [189373b]
- Updated dependencies [35ad101]
- Updated dependencies [ceb33a9]
- Updated dependencies [73d9795]
- Updated dependencies [8012960]
- Updated dependencies [f34f56b]
- Updated dependencies [f399618]
- Updated dependencies [75e9301]
- Updated dependencies [2810695]
  - @objectstack/spec@17.2.0

## 17.1.0

### Minor Changes

- 2f65b1b: `error.code` is a closed vocabulary at every door (#9106, maintainer ruling
  2026-08-16): the runtime dispatcher's thrown-error exits
  (`HttpDispatcher.errorFromThrown`, `dispatcher-plugin`'s `errorResponseBase`,
  `endpoint-executor`'s `endpointErrorAnswer` — the actions door among them) now
  serve the narrowed `code` the shared resolver (`resolveThrownHttpError`,
  `@objectstack/types`) has always computed, exactly as the REST door has since
  #8016. A thrown code that is not a member of `StandardErrorCode ∪
  ERROR_CODE_LEDGER` no longer reaches `error.code`.
  
  It is not dropped: `ApiErrorSchema` declares a new optional `declaredCode`
  field — the open, author-authored channel — and the demoted spelling rides
  there. Presence means demotion: the field is absent whenever the producer's
  code is a vocabulary member (it is already in `error.code`) or the producer
  declared none. The #7867 sandbox passthrough capability is preserved — a
  metadata app's own thrown `.code` still crosses the QuickJS boundary and still
  reaches the wire.
  
  For a metadata app that throws its own code (e.g.
  `Object.assign(new Error('pick another'), { code: 'DUPLICATE' })` in an action
  body) and reads it back from an actions-door failure:
  
  - FROM: `error.code === 'DUPLICATE'`
  - TO: `error.code` is the closed member the status derives (e.g.
    `VALIDATION_ERROR` on a 400) and `error.declaredCode === 'DUPLICATE'`.
    One-line fix: branch on `error.declaredCode` for app-specific spellings;
    branch on `error.code` for platform conditions.
  
  Platform producers are unaffected: every registered code reaches `error.code`
  verbatim, as before (post-#8846 the dispatcher-vocabulary gate holds that set
  registered). Measured before landing (the ruling's binding precondition): no
  existing consumer of the actions door branches on author-authored strings in
  `error.code`.
  
  `@objectstack/types` adds `demotedDeclaredCode(thrown)` — the one definition of
  "which spelling a boundary surfaces beside the closed `code`".
- 79c46da: feat(contract): a hook refusal can mark its message user-facing — `userMessage`, the producer-side opt-in channel (#9934, producer half of objectui#5210)
  
  <!-- adr-0087: not-required (no-migration-prescription) Purely additive: one
  new OPTIONAL field on the two error-envelope schemas, a new shared reader in
  @objectstack/types, and passthrough plumbing at the boundaries. Nothing
  authorable is renamed, retired, aliased or tombstoned, so there is no
  conversion to register. Unmarked errors produce byte-identical wire bodies. -->
  
  The console form deliberately discards the server `message` on 403 and
  substitutes a generic string — the recorded #3821 fix for platform diagnostics
  leaking to end users. That substitution also suppressed every deliberate,
  localized refusal an application hook author wrote (11 real hook guards in the
  objectui#5210 report), and incentivized misusing 400 for permission refusals.
  The maintainer-accepted ruling (2026-08-19, option 1): give the AUTHOR a
  producer-side way to mark a refusal message user-facing, once, at the contract
  level — status-agnostic, with #3821 preserved by construction for everything
  unmarked.
  
  **The marking**: set `userMessage` (non-empty string) on the thrown error at
  throw time. It is a text-carrying field, not a boolean beside `message` — the
  mark and the marked text are one value, so no boundary that rewraps or
  substitutes `message` can promote platform prose into the marked channel, and
  platform/driver code never sets it.
  
  - `@objectstack/spec`: `ApiErrorSchema.userMessage` and
    `EnhancedApiErrorSchema.userMessage` (optional, additive).
  - `@objectstack/types`: `declaredUserMessage(error)` — the ONE "is this
    marked?" read (non-empty string, nothing invented) — and
    `ThrownHttpError.userMessage` on `resolveThrownHttpError`.
  - `@objectstack/rest`: `mapDataError` / `resolveErrorResponse` ride a declared
    marking onto whatever envelope classification chose (flat body top-level
    `userMessage`, truncated at the same #5423 bound as the 4xx message).
  - `@objectstack/runtime`: the QuickJS side-channel carries `userMessage`
    across the sandbox boundary (both directions, joining `code`/`fields`/
    `status`), and the dispatcher door emits it as a declared sibling in the
    nested envelope.
  - `@objectstack/client`: the SDK attaches `err.userMessage` from both wire
    dialects, so a UI renders it verbatim when present and keeps its generic
    substitution when absent.
  
  The consumer half — the console form rendering a marked message instead of the
  generic `form.noPermissionToSave` — is objectui#5210.

### Patch Changes

- 2d0af57: fix(tests): give two default-vitest-timeout cases real margin instead of a bare default (#9311)
  
  Two cases only passed `pnpm test` when they were not competing for CPU — the
  same defect class as the already-closed precedents #3662, #4186, #4485,
  #5421, #6329: a test running under vitest's **default** `testTimeout` /
  `hookTimeout` with no margin for anything heavier than an idle box.
  
  **`packages/types/src/node.test.ts`** — `"falls back to the importing
  package's own resolution when the host does not declare"` is the only case
  in the file that performs a real dynamic `import()` of `@objectstack/spec` (a
  multi-megabyte package); every sibling in the same `describe` block resolves
  a small on-disk fixture or fails fast, all under 10ms. Measured on this box:
  ~0.9-1.1s unloaded, already observed failing at 5061ms against the 5000ms
  default under nothing heavier than `turbo run test --concurrency=2` (#9311's
  own isolation runs). Gave that one case an explicit 30s `testTimeout` — the
  same order of magnitude the repo already uses for subprocess/real-load cases
  (`#3662` precedent) — and left every sub-10ms sibling alone.
  
  **`packages/qa/dogfood/test/semantic-roles.dogfood.test.ts`** — its
  `beforeAll` boots the full showcase stack (ObjectQL + ~45 plugins) through
  `@objectstack/verify`'s `bootStack`, which does not fit vitest's 10s
  `hookTimeout` default with any margin at all: observed failing at 10027ms
  against the 10000ms budget, and this file's own isolated run measured 18.3s
  (vitest `Duration`) / 19.5s wall clock for the whole file even with the box
  otherwise idle. Gave the hook an explicit 180s timeout, matching this
  package's own existing house pattern for the identical
  `bootStack(showcaseStack, …)` call
  (`admin-identity-audit-trail.dogfood.test.ts`'s `beforeAll(…, 180_000)`)
  rather than inventing a new number for the same operation.
  
  **No behaviour change** — both suites already pass; this only gives the two
  timeout-sensitive cases room to finish on a loaded box. The repo's full test
  suite is confirmed green at low concurrency (#9311), so this is margin
  repair, not a product fix. `turbo.json`'s default concurrency is out of scope
  for this change (a maintainer-level default, per #9311's own filing).
- 27a567d: fix(types): teach the internal-leak predicate MySQL's three error templates (#8739)
  
  `looksLikeInternalErrorLeak` decides whether a message is a driver dump that
  must not reach an API client. It is applied at three HTTP boundaries
  (`@objectstack/rest`'s `mapDataError`, `@objectstack/runtime`'s
  dispatcher-plugin and endpoint-executor, the hono adapter) and by
  `@objectstack/objectql`'s log redactor. Its dialect list covered the SQLite
  family and Postgres; on a MySQL deployment it returned `false` for every one of
  these conditions — **silent, not clearing**.
  
  Under the maintainer's 2026-08-15 ruling on #8739, **MySQL is a supported
  deployment target**, not merely a tested dialect — the answer already implied by
  what is published (`OS_DATABASE_DRIVER=mysql` as a documented deployment knob,
  `MysqlConfig` as authorable datasource config, per-field MySQL DDL in
  `types.mdx`) and by a required CI check that stands up a live `mysql:8.0`. A
  supported target's driver text reaches those boundaries in production, so its
  templates belong in the list.
  
  **Now recognised** — one per condition the other two dialects were already
  covered for, each anchored on MySQL's own errmsg template rather than on a bare
  substring:
  
  - `Table 'app.t' doesn't exist` (ER_NO_SUCH_TABLE 1146). MySQL's contracted
    spelling quotes `db.table` as one identifier, so the Postgres
    `relation "t" does not exist` limb could never reach it.
  - `Unknown column 'c' in 'field list'` (ER_BAD_FIELD_ERROR 1054). Both quoted
    parts are required; the second is MySQL's clause name (`field list`,
    `where clause`, `order clause`, `on clause`), and it is what distinguishes the
    driver's template from a sentence that merely calls a column unknown.
  - `Duplicate entry 'x' for key 'i'` (ER_DUP_ENTRY 1062). The `for key` tail plus
    a quoted index is the anchor. This is the one MySQL template whose text embeds
    a **caller's value** rather than an identifier — SQLite's
    `UNIQUE constraint failed: t.c` and Postgres' `violates unique constraint "…"`
    both name only an index — which is why closing this gap was worth a behaviour
    change rather than another comment.
  
  **Deliberately still NOT recognised**, so the boundary of the change is on the
  record rather than inferred:
  
  - **MySQL's ACL family** — `Access denied for user 'u'@'h' to database 'd'`
    (1044), `SELECT command denied to user … for table 't'` (1142) — the
    counterpart of the Postgres `permission denied for table` limb. Nothing in
    this repo has raised one off a live server, and the standing rule in this
    neighbourhood (`unique-violation.ts`) is that a dialect's spelling is added
    once it has been MEASURED off a thrown error, never from a reading of the
    manual. `Access denied` also collides with this platform's own security prose
    (`[Security] Access denied: …`), so a guessed pattern here would over-match —
    and over-matching suppresses diagnostics an operator needs.
  - **MSSQL and Oracle** — `Invalid object name 'sys_metadata'.`,
    `ORA-00942: table or view does not exist` still return `false`.
  - **Prose that shares the keywords without the driver's anchoring** — an import
    summary saying `duplicate entry in the uploaded file`, a mapping message
    saying `Unknown column in the uploaded CSV header`, `The table you selected
    does not exist`. Pinned as negative cases, because a phrasing list that says
    "leak" too often replaces real answers with `Internal server error`.
  
  **The `false`-means-UNCOVERED rule survives the change and keeps a live
  subject.** A `false` here has never meant the text is safe, only that the
  predicate never learned that dialect — the reading a reviewer on PR #8737 got
  wrong while sizing a disclosure residual, which is what produced this card. The
  four `toBe(false)` pins PR #8824 planted as a tripwire for this exact moment
  went red as designed and are rewritten, not deleted: the same three measured
  messages now assert `true`, so a future change that silently drops MySQL
  coverage fails there, and a second block keeps the original `false`-means-
  uncovered shape pointed at MSSQL and Oracle. `declaresServerFault` remains the
  phrasing-independent answer.
  
  **No status mapping moves.** `@objectstack/rest` answers the 409 conflict
  question with `isUniqueViolationError`, above and independently of this
  predicate (#6250), so a MySQL duplicate-entry error is still `409
  UNIQUE_VIOLATION` and a MySQL unknown-column error is still `400 INVALID_FIELD`
  — both decided before the leak branch is reached. The log redactor is unchanged
  too: a bare MySQL diagnostic carries no knex ` - ` separator, so there is no
  statement to cut. Measured across the predicate's full consumer set — types,
  objectql, rest, runtime, metadata-protocol, hono, service-package,
  service-analytics — the only verdicts that moved are the two that measure this
  predicate directly.
  
  No live MySQL deployment leaking through these boundaries was measured; this
  closes a gap in what the boundary recognises, and the card is explicit that no
  leak was demonstrated.
- bbbfcfc: fix(types): `isUniqueViolationError` stops claiming the sentences that say a unique constraint is ABSENT (#8590)
  
  The shared predicate's message limb was a bare `unique constraint`, and a word
  pair is not a condition. Every dialect that can say "this row violated a unique
  constraint" can also say "there is no unique constraint here", and the same two
  words sit adjacent in both — so the predicate answered **true** for errors
  meaning the exact opposite of what it detects. `rest-server.ts` maps that
  verdict to `409 UNIQUE_VIOLATION`, which tells a client to change a value when
  nothing was ever compared, on a status an SDK will not retry.
  
  **Measured on live servers for this fix, all three supported dialect families**
  — SQLite via better-sqlite3, PostgreSQL 16.13 via `pg` 8.22.0, MariaDB 10.11.14
  via `mysql2` 3.23.1, all through knex 3.3.0 — driving each dialect through both
  conditions plus the NOT NULL / FOREIGN KEY near misses:
  
  ```
  sqlite   ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint
             -> was true, WRONG (the reported defect, #8590)
  postgres there is no unique constraint matching given keys for referenced table "t"
             -> was true, WRONG (42830 — found by this fix's dialect sweep)
  postgres there is no unique or exclusion constraint matching the ON CONFLICT specification
             -> false (the pair is not adjacent here)
  mysql    the condition cannot arise: knex compiles to ON DUPLICATE KEY UPDATE,
           which carries no conflict target (confirmed against a live server)
  ```
  
  **Postgres was not clean either, and that chose the fix.** #8590 was filed
  reading the collision as SQLite-only, with Postgres escaping "by luck of word
  order". The sweep raised **42830** — a `FOREIGN KEY` referencing a non-unique
  column — where Postgres puts `unique constraint` adjacent in its own absence
  sentence. The card offered two candidate fixes; only one survives 42830. A
  negative lookahead on SQLite's missing-index sentence is a blocklist that can
  only enumerate absence sentences somebody already tripped over, and it answers
  `true` on 42830. So the limb now requires a **violation phrasing** —
  `unique constraint failed` (SQLite) or `violates unique constraint` (Postgres) —
  which restores the module's own stated default, *unrecognised is `false`*, to
  the message channel.
  
  **Both spellings the retired limb covered are preserved exactly**, which was the
  constraint on the fix: the limb was inherited verbatim from the REST branch
  #6250 replaced and covered SQLite's `UNIQUE constraint failed: t.c` *and*
  Postgres' `... violates unique constraint "..."`. The `unique violation`,
  `duplicate key` and `duplicate entry` limbs are untouched, as are the `code` and
  `errno` channels — MySQL's `Duplicate entry` path never went through the
  narrowed limb at all.
  
  **No user-visible behaviour changes today; this closes a latent inversion.** The
  one site compiling a caller-supplied conflict target (`SqlDriver.upsert`)
  recognises the unbacked target *first* in its catch and throws a refusal
  declaring `status: 400`, and `mapDataError` reads `declaredHttpStatus` before it
  reaches the unique-violation branch — so the 409 was gated off the wire by
  ordering, not by the verdict. That ordering was the only thing standing between
  this and a wrong status, which is why the verdict is now pinned rather than left
  to it. A repo-wide scan of every string literal whose verdict moves found no
  consumer relying on the old answer: all of them are prose, a different
  predicate's vocabulary (`looksLikeInternalErrorLeak` keeps its own list), or
  fixtures asserted through the status-passthrough path.
  
  `unbacked-conflict-target.test.ts`'s pin — written by #8567 to point at itself
  rather than go quietly green — is **inverted, not deleted**, and
  `unique-violation-absence-sentences.test.ts` pins the absence sentences per
  dialect in both directions, including the code channel, so re-reading `code`
  cannot undo the message-side fix from the other side.
- Updated dependencies [56656aa]
- Updated dependencies [07e630e]
- Updated dependencies [2f65b1b]
- Updated dependencies [720ee95]
- Updated dependencies [f287435]
- Updated dependencies [9aa8890]
- Updated dependencies [7c9c1dd]
- Updated dependencies [75b7c24]
- Updated dependencies [d5552ca]
- Updated dependencies [d9813a9]
- Updated dependencies [8640fb2]
- Updated dependencies [2420641]
- Updated dependencies [2ad91c3]
- Updated dependencies [f57fb38]
- Updated dependencies [00777a0]
- Updated dependencies [d491625]
- Updated dependencies [420804d]
- Updated dependencies [716ac9b]
- Updated dependencies [62b1427]
- Updated dependencies [7ea1372]
- Updated dependencies [23abe27]
- Updated dependencies [985a9cd]
- Updated dependencies [a8189ae]
- Updated dependencies [26e70fb]
- Updated dependencies [42b05af]
- Updated dependencies [2b292ce]
- Updated dependencies [abcf853]
- Updated dependencies [8b9eba5]
- Updated dependencies [d575779]
- Updated dependencies [94f7ef8]
- Updated dependencies [c5ac5e4]
- Updated dependencies [a777944]
- Updated dependencies [dd88e1c]
- Updated dependencies [856527c]
- Updated dependencies [870f710]
- Updated dependencies [79c46da]
- Updated dependencies [7ff3975]
- Updated dependencies [29d055b]
- Updated dependencies [65589d6]
- Updated dependencies [2c86fe3]
- Updated dependencies [e196c6a]
- Updated dependencies [4ab7523]
- Updated dependencies [19539b4]
- Updated dependencies [11b779e]
- Updated dependencies [739fe5b]
- Updated dependencies [4bfe1a5]
- Updated dependencies [2065e31]
- Updated dependencies [b69d0f5]
- Updated dependencies [4d47afe]
- Updated dependencies [e4e5c6e]
- Updated dependencies [9a56784]
- Updated dependencies [d00d2f6]
- Updated dependencies [df0c12d]
- Updated dependencies [d31785f]
- Updated dependencies [c308a4f]
- Updated dependencies [e2899f6]
- Updated dependencies [3851f87]
- Updated dependencies [2a29caa]
- Updated dependencies [09a6eee]
- Updated dependencies [1a7f907]
- Updated dependencies [cd455c8]
- Updated dependencies [30d3752]
- Updated dependencies [c80e7ae]
- Updated dependencies [09a9a8a]
- Updated dependencies [07026cf]
- Updated dependencies [5d4f3d5]
- Updated dependencies [4d80e8b]
- Updated dependencies [30b1c63]
- Updated dependencies [079b457]
- Updated dependencies [e43b211]
- Updated dependencies [890b38f]
- Updated dependencies [8bee54b]
- Updated dependencies [7a537ce]
- Updated dependencies [593c4bf]
- Updated dependencies [ff08691]
- Updated dependencies [60e0f90]
- Updated dependencies [90c5285]
- Updated dependencies [7901b2d]
- Updated dependencies [56bca91]
- Updated dependencies [79394d7]
- Updated dependencies [730fd9a]
- Updated dependencies [44bc51d]
- Updated dependencies [73cfddf]
- Updated dependencies [d634e66]
  - @objectstack/spec@17.1.0

## 17.0.0

### Minor Changes

- 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.

- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)

  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。

  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
  谁确认的、何时、在哪个姿态下问的),**之后不复问**。

  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
    元数据可以直接重试,不需要先卸载。
  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
    其中一条仍会在剩下的那条上停住。
  - 升级引入的**新**约束会被问,老的答案继续算数。
  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
    `os migrate plan` 的 advisory 形态覆盖。

  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。

  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
  逐条清单而不是一句 "Install failed (409)"。

  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。

  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
  `gen:schema && gen:docs` 再生成,未手改。

  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
  唯一约束**,故无可扫;这是核查结论,不是遗漏。

  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
  drift op 为零。

  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
  `unique: true` 一如既往合法。

- 840ee4b: fix(analytics,runtime,types): gate cube auto-inference on object existence; stop the dispatcher boundary returning raw SQL (#3867)

  Two independent defects on the `/analytics` surface, found while verifying #3770
  against a real server. On an authenticated CRM dev server, before this change:

  ```
  POST /api/v1/analytics/query {"cube":"sqlite_master","measures":["count"],"dimensions":["type"]}
  → 200 {"rows":[{"type":"index","count":262},{"type":"table","count":71},{"type":"view","count":1}],
         "sql":"SELECT type AS \"type\", COUNT(*) AS \"count\" FROM \"sqlite_master\" GROUP BY type"}
  ```

  That is SQLite's internal schema table — never a registered object — read
  successfully through the analytics endpoint. Not merely "the name reaches the
  driver and errors": **any table the connection can see was readable.**

  **① The cube name reached the driver as a table name.** `AnalyticsService.ensureCube`
  auto-infers a minimal Cube when none is registered, with `cube.sql = <the queried
name>`. That is the intended "metric over an object" path — an `object-metric` KPI
  widget queries `crm_account` with no authored Cube — but it accepted _any_ string,
  so the endpoint could aggregate over an arbitrary physical table. The
  analytics-side twin of the data-path gap #3770 closed, and it was not covered by
  that fix: #3770 gated the protocol's `analyticsQuery`, which is the _degraded
  fallback_; a deployment with `@objectstack/service-analytics` installed runs the
  real engine instead (`ctx.replaceService`).

  Inference is now gated on the same schema registry the data path consults, via a
  new optional `AnalyticsServiceConfig.isRegisteredObject` that `plugin.ts` wires
  from the `data` engine's `getObject`. Three-way rule: a registered Cube runs
  untouched (its `sql` is whatever it declares); an unregistered name that IS an
  object still auto-infers exactly as before; neither → `CUBE_NOT_FOUND` / 404
  raised before any SQL exists, naming both ways to make the request valid. With no
  probe configured the gate stands down and warns once — the same tiering #3770
  took for a missing registry. `generateSql` (`/analytics/sql`) is gated too.

  **② The dispatcher boundary returned `err.message` verbatim.** `errorResponseBase`
  is the single error exit for _every_ route the dispatcher plugin mounts —
  `/analytics`, `/packages`, `/i18n`, `/storage`, `/automation`, `/auth`,
  `/notifications`, `/mcp`. `@objectstack/rest` has guarded its data routes against
  driver dumps forever (`mapDataError`); this boundary guarded nothing, so any
  driver error on any of those routes shipped its SQL to the client. Unlike ①, this
  half is unconditional — it does not depend on the cube being invalid.

  The leak heuristic moved out of `rest-server.ts` into `@objectstack/types` as
  `looksLikeInternalErrorLeak` (both packages already depend on it) and is now
  applied at both boundaries — one predicate, one place to widen when a new
  dialect's phrasing shows up. `mapDataError`'s behaviour is unchanged. At the
  dispatcher it applies **only to 5xx**: a 4xx message is a deliberate
  business/validation answer and must reach the caller intact. Sanitising costs no
  diagnostics — the untouched error still reaches `errorReporter` through the
  existing `__obsRecordedError` side-channel.

  **Also fixed in the same function:** `errorResponseBase` read only
  `err.statusCode`, while domain errors across this codebase carry `status` (and
  `HttpDispatcher.errorFromThrown` already reads `status` first). Every deliberate
  4xx thrown through a dispatcher route — including #3770's `OBJECT_NOT_FOUND` on
  the analytics fallback path — was rendered as a **500**. It now reads `status`
  then `statusCode`.

  **Behaviour change.** `/analytics/query` and `/analytics/sql` return 404
  `CUBE_NOT_FOUND` for a cube that is neither registered nor a registered object;
  previously the name was passed to the driver. Dashboards and KPI widgets pointed
  at real objects or authored cubes are unaffected. A 5xx on a dispatcher route
  whose message looks like a driver dump now reads `Internal server error` — check
  server logs or your error reporter for the original.

- 64cd010: fix(runtime,types)!: `/analytics/query` no longer echoes RLS policy field names — the declared-server-fault withhold is shared by both HTTP boundaries (#5811)

  **Observable behaviour change — read this if you read, log, or assert on
  `error.message` from a dispatcher-plugin route.** An error that **declares a
  server fault** in the ADR-0112 envelope (`status >= 500` _and_ a non-empty
  `code`) now leaves `dispatcher-plugin.errorResponseBase` with its message
  replaced by `"Internal server error"`. It previously reached the caller verbatim
  unless it happened to _sound_ like a SQL/driver dump. This applies to every route
  that plugin mounts — `/analytics`, `/packages`, `/i18n`, `/automation`, `/auth`,
  `/notifications`, `/mcp`, … — not only the one that motivated it. Nothing a
  machine reads changed: the producer's `code` still arrives in the response
  (`error.code`, promoted there from `details` by the shared envelope builder,
  #3842), the status is untouched, and the full original text still goes to the
  server log and `errorReporter` via `__obsRecordedError`.

  ## What was wrong

  #5367 (maintainer ruling 2026-08-06) made `read-scope-sql.ts`'s ten fail-closed
  RLS lowering refusals `READ_SCOPE_COMPILE_FAILED` / 500 and taught
  `POST /analytics/dataset/query` to withhold their message, because those messages
  name the field names and comparands of an **administrator's** sharing rule:

  ```
  [read-scope-sql] unsafe field identifier "secret_policy_field" — refusing to
  build read scope (fail-closed).
  ```

  The caller never wrote that field name and must not be able to read it out of an
  error body. But the **sibling** analytics face was never closed.
  `compileScopedFilterToSql` runs on both `NativeSQLStrategy.applyReadScope` and
  `ObjectQLStrategy`'s echoed SQL, both of which serve `POST /analytics/query`,
  which exits through `dispatcher-plugin.errorResponseBase`. That exit's only
  message guard was `looksLikeInternalErrorLeak` — a heuristic over SQL/driver
  _phrasing_ — and all eleven read-scope message shapes return `false` from it.
  Measured at that boundary: **11 of 11 echoed verbatim**, at 500, with the policy
  content in `error.message`. A real reachable disclosure, not a theoretical one.

  ## What changed

  - **`@objectstack/types` gains `declaresServerFault(err)`**, exported from
    `error-leak.ts` beside `looksLikeInternalErrorLeak`. The heuristic asks whether
    a message _sounds_ internal; the declaration asks whether the producer _said
    so_. `error-leak.ts`'s own file header already states the principle — "do not
    ship driver internals to clients" is a property of the HTTP boundary, not of
    one router — and this is the second predicate that principle asks for.
  - **Both boundaries read it.** `dispatcher-plugin.errorResponseBase` gains the
    withhold (the fix); `rest-server.ts`'s `/analytics/dataset/query` catch drops
    its in-line copy of the same test in favour of the shared one. #5808 wrote that
    rule in-line on purpose — promoting a rule with one consumer is a speculative
    surface — and this is the second consumer, so it was promoted rather than
    duplicated (`#3843`/`#3867` paid for the two-implementations shape twice).
    The REST face's verdict is unchanged in every case: same `status >= 500` plus
    non-empty `code` test, over the same two fields.

  ## What deliberately did NOT change

  - ⛔ **This is not "withhold every 5xx".** #5667 kept **undeclared** 5xx errors
    legible on purpose: a bare `Error` from our own code ("no strategy can handle
    query …") is the operator's own bug report, names nothing tenant-sensitive, and
    still falls to `looksLikeInternalErrorLeak` alone. A 5xx carrying only half an
    envelope (a status with no code) is likewise still readable — inventing the
    withhold for it would be the consumer-side leniency Prime Directive #12 removes.
  - **4xx is untouched.** `declaresServerFault` requires `status >= 500`, so a
    deliberate business/validation answer can never be swallowed by it.
  - **`statusCode` is not accepted as a substitute for `status`.** `status` is the
    channel ADR-0112 declares; making a disclosure rule depend on which spelling a
    producer reached for would be the same leniency in a different place.
  - **The heuristic was not taught to recognise `[read-scope-sql]`.** That would be
    more prose sniffing — the mechanism #5352/#5367 exist to remove — and would only
    ever cover the family someone remembered to add.

  Coverage: `analytics-query-read-scope-withhold.test.ts` (runtime) drives six RLS
  policy shapes end-to-end through a **real** `AnalyticsService` on the real
  native-SQL path and the real mounted route, asserting the 500, that the whole
  serialized body contains no policy detail, that `error.code` still carries
  `READ_SCOPE_COMPILE_FAILED`, and that the full text is still on the
  `__obsRecordedError` side-channel — plus a positive control and both sides of the
  declared-vs-undeclared tiering. `error-leak.test.ts` (types) pins the predicate
  directly, including that all eleven read-scope shapes stay invisible to the
  heuristic. The REST face's existing `analytics-read-scope-refusal-envelope.test.ts`
  is green before and after, unchanged, which is the pin on the refactor.

- 9f5cc79: A bulk write's per-row `errors[].httpStatus` carries the status its producer declared, in any spelling (#8570)

  `toRowApiError` set the limb from `err.status` alone, so two well-defined client
  refusals shipped a batch row with no status at all: objectql's `ValidationError`
  (a 400 recognisable by shape, which deliberately declares no `status`) and
  `plugin-approvals`' record lock (a 409 spelled `statusCode`). Sibling rows in the
  same response did carry one — `rowRequiredIdError` → 400,
  `recordNotFoundError` → 404 — so a caller branching on `httpStatus` to tell "fix
  your input" from "the server broke" got an answer for some failure rows and
  silence for others, with nothing saying which. Same single-spelling defect #7525
  fixed at the HTTP door, one layer down.

  The limb now asks `resolveThrownHttpError` — the resolver the HTTP doors and the
  row's `message` limb already answer with — so a refusal declaring `.status`,
  `.statusCode` or the `VALIDATION_FAILED` shape reaches the row as the status it
  always meant. Rows whose throw declared nothing (a driver fault, a hook throwing
  a bare `Error`) still carry no `httpStatus`: the resolver's 500 there is the
  caller's fallback, not a producer's claim, and stamping it would add a field to
  the wire for those populations rather than restore a declared one. `code` reads
  the same resolution, so a row can no longer contradict itself.

  `ThrownHttpError` gains `declaredStatus` — the resolved status minus the
  fallback, absent when the throw declared none. `status` is unchanged, and every
  boundary that answers with the status itself keeps reading it; the new field is
  for sinks that mirror a status onto response DATA, where a fallback would be an
  invention.

- 2a37694: fix(plugin-dev,types): the production escape hatch stops being silent (#3900)

  `DevPlugin.init()` refuses to run under `NODE_ENV=production` (ADR-0115 D6), and
  `OS_ALLOW_DEV_PLUGIN` overrides that refusal. As shipped, the override returned
  early with **no output at all**: the process ran the development assembly while
  every log line and the ready banner read like an ordinary production start.

  That reproduces, one level up, the defect the guard exists to close. The guard's
  own precedent says so — `OS_ALLOW_DEGRADED_TENANCY` boots degraded _and brands
  it everywhere an operator looks_, and `OS_ALLOW_DRIVER_CONNECT_FAILURE`'s
  contract is "logged loudly at startup". An escape hatch that says nothing leaves
  the operator's only evidence of a degraded state in an env var they may not have
  set themselves.

  **The override now brands itself, twice.** A warning at `init()` — emitted
  before any assembly work, so it survives an assembly step that later throws —
  and a repeat on the ready banner, which is the surface an operator actually
  reads:

  ```
  ⚠ DEV ASSEMBLY UNDER NODE_ENV=production (OS_ALLOW_DEV_PLUGIN is set) — the boot
    guard was explicitly overridden. This process is running the DEVELOPMENT
    assembly, which is not hardened for production traffic (ADR-0115 D6).
      • Auth secret is the default published inside @objectstack/plugin-dev. It is
        public, so anyone can mint a session this stack accepts. Pass `authSecret`
        explicitly.
      • Data goes to the in-memory driver with persistence disabled — every record
        is lost when this process exits.
  ```

  Only hazards that are live for _that_ configuration are named: the secret line
  is suppressed when the operator passed their own `authSecret`, and the driver
  line when the `driver` toggle is off. The dev-admin seed is deliberately absent
  — `plugin-auth`'s `maybeSeedDevAdmin` is hard-gated to
  `NODE_ENV === 'development'` and cannot fire on this path, so warning about it
  would spend the attention the real hazards need.

  **New export — `resolveAllowDevPlugin()` (`@objectstack/types`).** The flag moves
  off a bare `process.env['OS_ALLOW_DEV_PLUGIN'] === '1'` and joins the
  `OS_ALLOW_*` family's shared truthy vocabulary, next to
  `resolveAllowDegradedTenancy` / `resolveAllowDriverConnectFailure`.

  FROM → TO for operators: `OS_ALLOW_DEV_PLUGIN=1` keeps working unchanged.
  `OS_ALLOW_DEV_PLUGIN=true` (and `on` / `yes`, case-insensitive, surrounding
  whitespace ignored) **now takes effect** where the strict comparison previously
  ignored it and failed the boot. That is a widening, in the direction an operator
  setting the flag already intended; falsy and unrecognised values still refuse to
  boot, and unset still means "fail fast". If you were relying on
  `OS_ALLOW_DEV_PLUGIN=true` being inert as a way to keep the guard armed, unset
  the variable instead.

  No change to the refusal path, which this issue re-verified end to end:
  `kernel.use()` only registers, `initPluginWithTimeout` does not catch,
  `bootstrap()` rethrows, and `os serve`'s outer handler prints the message and
  exits `1`. The `throw` is genuinely fatal here, so it needs none of the
  `process.exit(1)` the tenancy guard required for sitting inside a broad `catch`.

- b25a116: fix(verify): resolve the enterprise organizations package from the HOST APP (#4700)

  `bootStack(app, { multiTenant: true })` — and therefore `objectstack verify
--multi-tenant` — could never load `@objectstack/organizations`. Node ESM
  resolves a bare `import()` against the **importer's own realpath**, which for
  `packages/verify` is inside the framework workspace, while the enterprise
  package is cloud-private and only ever lives in the verified app's
  `node_modules`. Every real host app fell into the catch and was told to
  "Install/link it in this workspace" — about a package it had already installed.
  Same defect class as cloud#1013, which fixed `objectstack serve`; #4699 fixed
  that one call site and this issue tracked the two the sweep left behind.

  **New: `@objectstack/types/node`.** The host-app resolver (`createHostRequire` /
  `createHostImporter`) moved out of `packages/cli/src/utils/import-from-host.ts`
  — where `@objectstack/verify` and the dogfood suite could not import it without
  inverting the dependency direction — into a **node-only subpath export** of
  `@objectstack/types`. One behaviour, one source; the CLI now consumes it and its
  private copy is deleted.

  It is a subpath and **not** the root export because `@objectstack/types` is a
  dependency of `@objectstack/hono` ("edge-compatible REST API server for
  Cloudflare Workers, Deno, Bun, and Node") and of the plugin layer a `LiteKernel`
  boots on Workers. The root entry reaches zero `node:` builtins, and a Workers
  bundle breaks on `node:module` even when nothing calls it. `tsup` emits the two
  entries as separate self-contained bundles (`splitting: false`), and a test
  walks the root's import graph and fails on the first reachable `node:`
  specifier, so the isolation is enforced rather than merely intended. Same
  arrangement `@objectstack/metadata` already ships for its `./node` subpath.

  **New: `BootOptions.hostRoot`** (optional, defaults to `process.cwd()`) names
  the app whose `node_modules` supplies those optional packages — for a harness
  booting an app that is not the working directory.

  **The dogfood multi-org gates had never run.** Two suites probed availability
  with the same bare `import()` and so were **constant-false** — not "false
  because absent" but false by construction, in every environment including the
  cloud CI whose comment claimed it ran them. The #1994 cross-tenant RLS proof and
  the attachments cross-tenant isolation block had therefore never executed while
  the suite reported green (Prime Directive #10, test-suite edition). They now
  resolve like the runtime does, and `OS_TEST_MULTI_ORG_ENABLED=1` declares that a
  run is expected to ship the package — turning a silent skip into a loud failure,
  so a run can no longer pass by quietly not running the gates it exists for.

- 02dc076: feat(types,cli,verify)!: 只解析 host app 声明过的包 —— `NODE_PATH` 不再算数,ADR-0093 D5 那道墙从此与启动方式无关 (#4719)

  **问题:契约写下了,但从没被检查过。** `@objectstack/types/node` 的
  `createHostRequire` 返回一个 CJS `createRequire`,而 CJS 解析认 `NODE_PATH`
  (`Module.globalPaths`)。pnpm 生成的 bin shim 第一件事就是
  `export NODE_PATH=<workspace>/node_modules/.pnpm/node_modules`,于是任何被工作区里
  **任意一个包**传递依赖到的包都能"从 host app 解析成功" —— 跟这个 app 声明了什么毫无关系。

  实测(cloud `apps/objectos-ee`,当时未声明 `@objectstack/organizations`):
  `pnpm start`(经 shim)boot 成功、插件表里有 `Organizations`、ADR-0093 D5 一声不吭;
  `node node_modules/@objectstack/cli/bin/run.js serve`(不经 shim)则
  `✖ FATAL: tenancy posture 'isolated' was requested…` 并 exit 1。同一个 app、同一份
  `package.json`、同一个 posture,**只因为进程是怎么被拉起来的**,走出两种结果。
  而 D5 的报错一直在教 operator "declare it in the app's package.json" —— 那正是
  CLI 从来没检查过的那件事。

  **改法:声明即执行。** 解析前先读 `<hostRoot>/package.json`;只有包名出现在
  `dependencies` / `devDependencies` / `optionalDependencies` / `peerDependencies`
  的 **键**里,才去 host 的 `node_modules` 里查它。仅仅"能被解析到"不再算数 ——
  那正是让契约失效的那个偶然。未声明的包退回到 importing package 自身的解析
  (ESM,不认 `NODE_PATH`),框架自有的包加载路径不受影响。

  **两种失败从此分开报。** 今天它们都塌成同一条 `MODULE_NOT_FOUND`,补救办法却相反:

  - **未声明** —— 指向"在 app 的 `package.json` 里声明并安装",并说明为什么
    hoisting / `NODE_PATH` 不被接受;
  - **声明了但解析不到** —— 明确说这是**安装**问题(`pnpm install`、生产 prune
    砍掉了它、dist 没构建),别再让人回去重看那份已经写对的 `package.json`。

  分类经新导出的 `hostImportFailureKind(err)` 暴露给调用方;两种错误都仍带
  `code: 'MODULE_NOT_FOUND'`,`isModuleNotFoundError` 的既有判定不变。

  **BREAKING — 哪类部署会从假绿变红,以及怎么修。**

  1. **靠 hoisting 苟着的部署。** 一个 app 请求了 walled tenancy posture
     (`OS_TENANCY_POSTURE=group` / `isolated` 或 `OS_MULTI_ORG_ENABLED=1`)、
     却没在自己的 `package.json` 里声明 `@objectstack/organizations`,过去经 pnpm
     shim 启动能正常 boot —— 现在会命中 ADR-0093 D5 并 exit 1。
     **修法:在那个 app 的 `package.json` 里声明该依赖并安装。**
     这些部署本来就在未声明状态下运行,红的是一直存在的事实,不是新引入的故障:
     同一个 app 不经 shim 启动今天就已经是 exit 1。
     (同样适用于 `@objectstack/service-ai` / `@objectstack/service-ai-studio`,以及
     `bootStack({ multiTenant: true })`、dogfood 的 enterprise 门。)

  2. **`createHostImporter` 的签名变了**,因为它现在需要 host 的**根目录**才能读到
     那份 manifest,而一个 `NodeRequire` 无法被问出它锚在哪里:

     ```diff
     - createHostImporter(createHostRequire(hostRoot))
     + createHostImporter(hostRoot)                     // 省略参数 = process.cwd(),同旧默认
     ```

     `createHostRequire` 本身保持不变,仍然导出。

  新增导出(`@objectstack/types/node`):`HOST_DECLARATION_FIELDS`、
  `HostDeclarationField`、`HostDeclaration`、`readHostDeclaration`、
  `isDeclaredByHost`、`packageNameFromSpecifier`、`HostImportFailureKind`、
  `HOST_IMPORT_FAILURE_KIND`、`hostImportFailureKind`。

- 030125b: feat(objectql)!: `init()` refuses to boot when a data driver fails to connect (#3741)

  `ObjectQLEngine.init()` wrapped every driver's `connect()` in a try/catch, logged
  one error line, and carried on. A server whose database was unreachable therefore
  "started successfully" — health endpoints could even stay green — and then failed
  every request with an error that reads nothing like _the database is down_. The
  warning it printed (`Operations may recover via lazy reconnection or fail at query
time`) was half fiction: grep the repo and no reconnection exists in `driver-sql`
  or `driver-mongodb`, so only the "fail at query time" half was ever real. The
  caller made it worse — `ObjectQLPlugin.start()` runs `syncRegisteredSchemas()`
  immediately after `init()`, issuing DDL against a driver that isn't there.

  The structural half of the bug was worse than the operational one: the catch
  removed a driver's ability to **refuse startup at all**. Any fatal startup check —
  licence, server version, incompatible configuration, missing capability, not just
  an unreachable socket — is expressed by throwing from `connect()`, and every one
  of them was silently downgraded to a runtime error. That is why driver-mongodb's
  multi-tenancy guard (#3724 / #3734) had to be hoisted into its constructor.

  - `init()` now **throws** `DriverConnectError` (`code: 'ERR_DRIVER_CONNECT'`)
    when any boot-registered driver's `connect()` rejects, aborting kernel
    bootstrap. It still attempts every driver first, so one failed boot names all
    of them. The message is self-contained — each failed driver and its cause —
    because the CLI prints `error.message` alone; the first cause is also attached
    as `error.cause`. Exported from both `@objectstack/objectql` and
    `@objectstack/objectql/core`.
  - `connect()` is now a supported place for a driver to veto boot. Startup
    validation that needs a live connection (server version, capability probes)
    no longer has to be forced into a constructor.
  - The misleading "lazy reconnection" warning is gone.
  - New escape hatch `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`
    (`resolveAllowDriverConnectFailure()` in `@objectstack/types`) restores the old
    lenient boot, but loudly: a `DEGRADED BOOT` banner names the failed drivers and
    states that they are never retried or reconnected and that every query and
    schema sync routed to them will fail for the process lifetime. The banner goes
    to stderr as well as the logger, because `os serve` swallows all of stdout
    during boot and `Logger` routes `warn` there — logger-only, the one message
    that matters would be invisible in exactly the deployment the flag is for.
    Defaults off.

  **Migration.** No code or config change is needed for a correctly configured
  deployment — a driver that connected before still connects. A deployment that was
  _silently_ booting without its database now fails the boot instead, with the
  driver name and cause in the error; fix the datasource configuration (typically
  `OS_DATABASE_URL`, credentials, or network reachability). To keep booting without
  it — deliberately, and knowing every request that touches it will fail — set
  `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`.

- b4b2c7d: fix(rest,runtime,types): the direct-mount package door answers a coded refusal with its own status and code (#8016)

  **This changes HTTP status codes on a live surface.** Requests to
  `/api/v1/packages` that today come back `500 INTERNAL_ERROR` will come back as
  the refusal they always were — `409 DESTRUCTIVE_CHANGE` for an uninstall that
  would drop data, `400`/`403` for a coded refusal thrown from below. A client
  that keys on `500` to decide "the platform is down, retry later" for these
  routes must key on the `code` instead. No route, path, verb or success body
  changes.

  `/api/v1/packages` has two HTTP transports. The runtime dispatcher's
  (`packages/runtime/src/domains/packages.ts`) reads a thrown error's own
  `.status` and `.code` and answers with them. The direct-mount REST registrar
  (`packages/rest/src/package-routes.ts`) had **four** catch-alls that answered
  `sendError(res, 500, 'INTERNAL_ERROR', …)` regardless — and that registrar
  mounts _first_ in the production stack, so the status-blind answer was the one
  production actually returned. `packageService.publish`, `packageService.delete`
  and `protocol.deletePackage` all execute inside those blocks, and
  `@objectstack/metadata-protocol` throws coded, status-carrying refusals from
  that call path. So a caller who was **refused** was told the platform had
  **broken**: the wrong class of answer, a retry that cannot succeed, and the one
  field a client can branch on dropped.

  The four sites now leave through one shared exit. The mapping is not
  reimplemented here — that is how the two doors diverged in the first place. It
  moved to `resolveThrownHttpError` in **`@objectstack/types`** (alongside the
  `sendOk`/`sendError` envelope writer and `looksLikeInternalErrorLeak`, for the
  same reason: it is a property of the HTTP boundary, not of one router), and the
  dispatcher's `HttpDispatcher.errorFromThrown` is now its other caller. It could
  not live in `@objectstack/runtime`: that package depends on `@objectstack/rest`,
  so the import can only point one way.

  The rule, unchanged from what the dispatcher always applied:

  - **status** — the producer's `.status`, then `.statusCode` (both spellings are
    produced in this repo), then `400` for a record-validation failure, then the
    caller's fallback.
  - **code** — `VALIDATION_FAILED` for a validation failure, then the thrown
    `.code` **when it is a member of the declared ADR-0112 vocabulary**
    (`StandardErrorCode ∪ ERROR_CODE_LEDGER`), then the code the status derives.
    An unregistered code no longer reaches `error.code` on the dispatcher door
    either; it would have failed envelope parse, which is ADR-0112's closed
    vocabulary working rather than a dialect leaking onto the wire.
  - **the 500 survives** — a throw declaring neither status nor a registered code
    is a genuine fault and still answers `500 INTERNAL_ERROR`.

  `validation-failure.ts` moved from `@objectstack/runtime` to
  `@objectstack/types` for reachability and is re-exported from its old module
  path; every existing import site is unchanged.

  Unchanged and deliberately so: this REST door still ships a 5xx message
  verbatim, where the dispatcher withholds one that looks like an internal leak
  (`looksLikeInternalErrorLeak`, #3867). That asymmetry predates this fix and is
  filed separately.

- 91cefb8: refactor(types,rest,metadata,analytics): Postgres 的 `"x" of relation "y"` 短语收归一处，三个包不再各修一遍同一个超串洞（#6615）

  Postgres 把「关系内部某个子对象」的失败写成 `column "label" of relation "sys_team" does not exist`——里面**逐字包含**一句合法的「表不存在」短语 `relation "sys_team" does not exist`，含义却相反：关系正因为存在才被点名。任何对「这句话是不是在说表没了」的正则收紧都消不掉这个匹配，短语确实在里面；唯一的修法是**先问更具体的问题**。所以修的是**顺序**，不是模式。

  正因为如此，这个短语被分三次教给了这个仓库，分属三个包、三个 PR，其中两次是在别处已经踩过同一个洞之后：`@objectstack/rest` 的 `mapDataError`（#5352）、`@objectstack/service-analytics` 的缺列扣除（#6035 / PR #6346）、`@objectstack/metadata` 的 `MISSING_TABLE.excludes`（#6347 / PR #6613）。本次把它收进 `@objectstack/types`，与 `isUniqueViolationError`（#6250）和 `isModuleNotFoundError`（framework#3265）同一个理由与同一个位置。

  **两种宽度，故意保留成两个导出。** 三个消费者要的并不是同一条正则，差别也不是随手写的，而是**每个站点哪个方向的误差是安全的**：

  - `matchMissingColumnOfRelation(message)` —— 严格提取器，锚定 Postgres 的 errmsg 模板 `column "%s" of relation "%s" does not exist`，返回列名。`rest` 用它把 42703 答成 `400 INVALID_FIELD` 而不是 `404`；`service-analytics` 用它在分类前扣除缺列。这两处**过宽**会把真正缺失的表变成硬失败、回退 #5033 刻意保留的宽容，**漏匹配**只是让消息含糊一点——所以必须严格。
  - `isRelationSubObjectPhrase(message)` —— 宽检测器，丢掉 `column` / `[a-z0-9_]+` / `does not exist` 三个锚点：任意子对象、任意带引号标识符、任意判词。`metadata` 用它做排除。这一处**过宽**只会把良性判定变成响亮判定，**漏匹配**却会让 `event_seq` 从 1 重新开始、撞进一张已有行的历史表——方向正好相反。

  把两者合并成一条正则，无论哪种宽度胜出都会对其中一个调用方是错的；这是卡片记录在案的风险，两个导出即为此而设，理由是承重的而非风格的。仓库里第四份拷贝（`service-analytics` 测试内用于守护 fixture 的那条正则）同时收编：它本是为「两张面孔别对不上」而写，却把断言打在其中一面的私有复述上，因而正是它要防的漂移。

  行为逐字保持不变：搬进来的两条模式与原站点逐字节相同。`@objectstack/service-analytics` 因此新增一条对 `@objectstack/types` 的依赖边——这是本次唯一的依赖变化，构造上无环（`@objectstack/types` 只依赖 `@objectstack/spec`，后者无仓内依赖），且仓库 73 个包中已有 25 个、16 个 service 中已有 5 个携带同一条边。

- d5749d7: refactor(types,rest,services,plugin-sharing): one shared writer for the response envelope, and `error.code` is enforced at compile time (#3973)

  `BaseResponseSchema` declares one envelope for every REST body the platform
  emits. It declared it once; the code that _wrote_ it was copied per route
  module. After #3843 and #3983 converted the last drifting one, seven modules
  each carried their own two-line `sendOk` / `sendError` pair — so the envelope's
  shape lived in fourteen places rather than one.

  `pnpm check:route-envelope` proved those seven copies agreed, which is why this
  is a cleanup rather than a bug fix. But a guard proves agreement; it does not
  create it. An eighth module starts by copying the pair again — not
  hypothetically: `share-link-routes.ts` was found already drifting by the
  repo-wide scan, and its drift had broken `client.shareLinks.create()` and
  `.list()` through `unwrapResponse` (#3983).

  ## What moved

  `sendOk` / `sendError` now live once, in `@objectstack/types`
  (`response-envelope.ts`), and all seven modules import them:

  | Module                                |
  | ------------------------------------- |
  | `service-storage/storage-routes.ts`   |
  | `service-settings/settings-routes.ts` |
  | `service-datasource/admin-routes.ts`  |
  | `rest/external-datasource-routes.ts`  |
  | `rest/package-routes.ts`              |
  | `service-i18n/i18n-service-plugin.ts` |
  | `plugin-sharing/share-link-routes.ts` |

  Placement was the open question in #3973, not design. `packages/spec` is
  schemas-only (Prime Directive #2), and the callers span `rest`, four
  `services/*` and one `plugins/*`, which rules out anything depending on them.
  `@objectstack/types` depends on nothing but `@objectstack/spec`, so every caller
  can reach it, and it is already where the repo puts a helper the HTTP boundaries
  share — `looksLikeInternalErrorLeak` (#3867) sits one file over and made the
  same argument first.

  The builders take a structural `{ status(n), json(body) }`, so the package
  imports no HTTP contract at all: `IHttpResponse` satisfies it, and so does the
  `any`-typed `res` the older modules carry.

  ## `error.code` is now checked by the compiler

  All seven copies typed the parameter `code: string`. ADR-0112 (#3841) closed the
  vocabulary — `ErrorCode` is `StandardErrorCode ∪ ERROR_CODE_LEDGER` — but an
  invented code was still caught only at runtime, by a conformance suite parsing a
  driven body, i.e. only on routes some test happened to drive.

  The shared `sendError` types `code` as `ErrorCode`, so an unregistered code now
  fails to compile, at every call site at once:

  ```ts
  sendError(res, 400, "NOT_A_REGISTERED_CODE", "invented");
  // Argument of type '"NOT_A_REGISTERED_CODE"' is not assignable to parameter of type 'ErrorCode'.
  ```

  This cost no call-site churn: every code the seven modules emit was already
  registered.

  ## `extra` is closed at the same place

  `sendError`'s last parameter is `Pick<ApiError, 'category' | 'httpStatus' |
'details' | 'requestId'>` — exactly what `ApiErrorSchema` declares beside `code`
  and `message`.

  It was `Record<string, unknown>` while `settings-routes` still hung `namespace` /
  `key` / `reason` / `fields` beside `code`. Those bodies passed every gate anyway:
  `ApiErrorSchema` is a plain `z.object`, so unknown keys were STRIPPED rather than
  rejected, and `envelopeViolations` inspects only the body's top level —
  conformant _by stripping_ rather than by declaration. #4224 moved that module
  onto `details`, which is what lets the parameter close here. Closing it at the
  shared builder is the part that lasts: an undeclared sibling is now a compile
  error in every module at once, rather than a key that quietly evaporates in
  whichever module reintroduces it.

  ## Nothing changes on the wire

  The seven pairs were identical modulo the optional `status` and `extra`
  parameters this one unions, and each module's driven conformance suite still
  parses its real bodies against the real spec schemas. One internal call site was
  rewritten: `package-routes` passed `details` positionally and now passes
  `{ details }`, producing the same `error.details` it always did.

  ## The guard got stronger

  `scripts/check-route-envelope.mjs` counts response write sites per module. A
  module that routes everything through the shared pair builds **none** itself, so
  the seven now declare `0 / 0 / 0` where they used to declare `2 / 1 / 1`, and the
  shared pair is pinned separately at `2 / 1 / 1` so the invariant stays total for
  the surface rather than per-module. What the count asserts is no longer "your two
  builders are the enveloped ones" but "you have no builders" — and a new route
  that hand-rolls a body still moves it off zero and fails.

- 129b378: fix(types,rest): one named answer for "which column conflicted" — an index name is never returned as one (#6544)

  #6250 retired four private "is this a unique violation?" vocabularies into
  `isUniqueViolationError`. It left the harder half of the question behind: the
  import runner's `sanitizeRowError` still carried its own three-dialect regex
  chain, because it does **more** than answer yes/no — it names the offending
  column so the importer can say _"A record with this `email` already exists."_
  This lands that second answer as a shared export and migrates the last private
  copy onto it.

  **New — `uniqueViolationColumn(error)` in `@objectstack/types`** (`string |
undefined`), sibling to `isUniqueViolationError` and gated on it, reading the
  same channels one step down the same bounded `cause` chain, plus
  node-postgres' `detail` field.

  **Its contract, per the maintainer's 2026-08-08 ruling: a value comes back only
  when the identifier the driver printed is determinably a COLUMN.** When a
  dialect names an _index_ instead — MySQL's `Duplicate entry … for key
'idx_email_unique'`, Postgres' `violates unique constraint "sys_user_email_key"`,
  SQLite's `UNIQUE constraint failed: index 'x'` — the answer is `undefined`,
  never the index name. Callers render this into a form field, and an index name
  mistaken for a column points the user at a field that does not exist, whereas
  `undefined` degrades to generic copy. A **composite** key (`Key (tenant_id,
email)=(…)`) is `undefined` for the same reason: there is no single offending
  column, and naming the first is the same class of wrong answer.

  **⚠️ User-visible change on MySQL imports.** MySQL's duplicate-entry message
  names the index and never the column, so the importer no longer names a column
  there: rows that used to read _"A record with this `idx_email_unique` already
  exists."_ — or, on MySQL 8's table-qualified `for key 'sys_user.email'`, a
  plausible-looking _`email`_ that was still an index name — now read **"A record
  with this value already exists."** That is deliberate and is the accepted cost
  of the ruling. The conflict is still recognised as a conflict; only the naming
  narrowed.

  Three smaller import messages improve in the same move, all previously wrong
  rather than merely vague:

  - SQLite's expression/partial-index form used to render as _"A record with this
    **index** already exists."_
  - Postgres' expression index used to render the truncated fragment _"A record
    with this **lower(email** already exists."_
  - A Postgres conflict with no `DETAIL:` line used to fall through to the SQL
    backstop and echo the driver's own sentence — index name included — at the
    importer. It now gets the same generic conflict copy, which is also the exact
    wording `mapDataError` puts in the 409 `UNIQUE_VIOLATION` body, so the
    importer and the API say one thing about one condition.

  Not changed: the NOT NULL branch, the raw-SQL backstop, and every non-conflict
  message, which pass through exactly as before.

### Patch Changes

- a8940e4: The ADR-0114 D3 mapper (Zod issue codes → the closed `FieldErrorCode` catalog) is now
  `zodIssuesToFields`, exported from `@objectstack/spec` (`@objectstack/spec/api`), and it is
  the ONE implementation of D3's table in the repo (#8124).

  Why: `fields[].code` is declared as a closed catalog (`FieldErrorCode`, ADR-0114 D2), but
  `@objectstack/types`' `fieldsFromZodIssues` — the helper the runtime `/analytics`,
  `/notifications` and `/automation` entry refusals emit through — passed Zod's own issue
  codes through verbatim. A refusal carrying `unrecognized_keys` / `too_small` did not parse
  against the schema the protocol declares for it, and the same wire slot spoke two
  vocabularies depending on which route served it.

  What changed on the wire (all three runtime domain routes):

  - `fields[].code` values are now catalog members: `unrecognized_keys` → `unknown_field`,
    `too_small` → `min_length`/`min_value`/`min_items` (by origin), `too_big` → the `max_*`
    mirrors, enum misses → `invalid_option`, `custom` and any unmapped Zod code →
    `invalid_value`.
  - A rejection behind a `z.union` is expanded per #5014: the union's own entry is followed
    by the branch entries that explain it, so entry count is no longer issue count.
  - Two hand-spelled `unrecognized_keys` literals (the analytics `filters` hint and the
    automation toggle unknown-key refusal) now say `unknown_field`, the catalog member.

  `@objectstack/rest` re-exports the shared implementation from `rest-server.ts` and its
  behavior is unchanged (its own mapper tests pin that); `fieldsFromZodIssues` keeps its
  signature (plus an optional trailing `input` that upgrades a missing required property from
  `invalid_type` to `required`, per the D3 table) and keeps the `'(body)'` spelling for
  root-level failures.

- 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.

- 87aca93: fix(datasource)!: a declared datasource that objects bind to must connect, or the boot fails (#3758)

  `DatasourceConnectionService.handleFailure()` fail-fasted only for an `external`
  datasource with `validation.onMismatch: 'fail'`. Everything else degraded to one
  `warn` line — including the case the D2 auto-connect gate itself flags as having
  **no fallback path**: a datasource that objects bind to explicitly via
  `object.datasource`. Those objects never fall through to the `default` driver;
  `engine.getDriver` throws `Datasource 'x' is not registered` for them.

  So an app declaring `datasource: 'analytics'` with 20 objects bound to it, booted
  against a wrong `ANALYTICS_URL`, started clean and exited zero — and then failed
  every read and write of those 20 objects with an error that reads nothing like
  _the analytics database is unreachable_. The rest of the app worked, which made it
  **harder** to locate than a total outage: it looks like "some pages are broken",
  not like a misconfigured datasource. This is the same decision #3741/#3751 fixed
  one layer up in `ObjectQLEngine.init()`; the boundary here was still drawn in the
  old place.

  - **Fail-fast is now keyed on "no fallback path", not on `onMismatch` alone.** At
    the `declared-auto` (boot) trigger, a connect failure aborts the boot when the
    datasource is `external` + `onMismatch: 'fail'` **or** when ≥1 object binds to
    it explicitly. `autoConnect: true` with nothing bound stays lenient — that is
    "connect it if you can", and nothing declares a dependency on it. The
    runtime-admin create/update and boot-rehydration triggers are unchanged and
    still always degrade: a UI action must never brick a running server.
  - **Every failure mode counts**, not just an unreachable socket: an unresolvable
    `external.credentialsRef` (D3) and an unsupported `driver` leave the bound
    objects exactly as dead, so they take the same verdict.
  - **The error names the bound objects** (up to 10, then `+N more`) alongside the
    underlying cause, so the message points at the real problem instead of just the
    datasource name. The service already receives the list for post-connect
    `syncObjectSchema`.
  - **`connectDeclared()` attempts every gated datasource before throwing**, and
    aggregates, so one failed boot reports all the misconfigured ones rather than
    one per restart — the same shape as `ObjectQLEngine.init()`'s
    `DriverConnectError`.
  - **The escape hatch is shared with the engine guard**:
    `OS_ALLOW_DRIVER_CONNECT_FAILURE=1` now also covers this path (and covers
    `onMismatch: 'fail'`, which previously had no opt-out). The operator intent is
    identical — "I know the database is unreachable, boot anyway" — and two flags
    would only guarantee one of them gets missed. When set, boot continues and a
    `DEGRADED BOOT` banner goes to stderr as well as the logger, because `os serve`
    swallows stdout during boot. `emitDegradedBootBanner` moved to
    `@objectstack/types` so both call sites share one implementation;
    `@objectstack/objectql` re-exports it unchanged.

  ADR-0062 D5 is amended with the new criterion and the shared flag.

  **Migration.** No change for a correctly configured deployment — a datasource that
  connected before still connects. A deployment that was _silently_ booting with a
  dead, explicitly-bound datasource now fails the boot instead, naming the
  datasource, the cause, and the objects that depend on it; fix the datasource
  configuration. To keep booting without it — deliberately, knowing every request
  touching those objects will fail — set `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`.

- c20b875: **Correct the stale premise left behind by #4012: the degraded-boot stderr copy
  survives the operator's LOG LEVEL, not `os serve`'s boot-quiet window.**

  `emitDegradedBootBanner` writes the `OS_ALLOW_DRIVER_CONNECT_FAILURE` banner to
  stderr in addition to `logger.warn`, and every comment and test name explaining
  why cited the same reason: `os serve` swallowed all of stdout while the kernel
  booted, and `Logger` routes `warn` to stdout. #4012 fixed that — the boot window
  now buffers and replays `warn`-and-above — which retires the _stated_
  justification for a duplicate that is nonetheless still load-bearing:

  `Logger.write()` returns before touching a stream when the record is below
  `config.level`, so at `--log-level error`, `fatal` or `silent` the banner's
  `logger.warn` reaches **no** stream at all. A production host at `error` is
  exactly the deployment this escape hatch exists for, and exactly where a
  logger-only banner would vanish. Removing the stderr copy on the strength of
  #4012 would therefore have been a regression — so this documents the reason that
  is still true, in the places someone would read before deleting it:
  `degraded-boot.ts`, the engine's emit site, and all three parity tests
  (objectql, runtime, service-datasource), which are renamed off "which `os serve`
  boot-quiet cannot swallow" to "which the operator log level cannot filter away".

  The objectql parity test now proves the claim instead of asserting around it: it
  drives a **real** `ObjectLogger` at `level: 'error'` and requires the banner on
  stderr _and_ nothing on stdout. Set the level to `warn` and it fails — so the
  test is pinned to the level filter rather than passing for any reason.

  Also corrected in the same sweep, all comment-only, all previously overstating
  what #4012 had not yet fixed:

  - the automation wiring summary (`format.ts`, `serve.ts`, its test) claimed the
    boot window swallowed the engine's binding warnings. Its real justification is
    stronger and unchanged: a flow that silently fails to arm emits **no** log line
    at any level, so binding state has to be read off the live engine — absence of
    a warning was never evidence of a bound flow.
  - the seed summary (`seed-summary.ts`, `format.ts`, its test) and `AppPlugin`'s
    seed-outcome note attributed the silence to the boot window; the operative
    gate is that `SeedLoader`'s result logs are `info`, under the default `warn`.

  No behavior changes.

- 32d3800: fix(driver-sql): bound a connection attempt at 10s, and correct the "no reconnection" claim (#3769, #3759)

  Two related corrections, both from measuring what #3741/#3751/#3765 had only asserted.

  **The claim was wrong.** #3751 and #3765 shipped several statements that drivers
  never reconnect — "there is no lazy reconnection", "NOT retried and NOT
  reconnected", "stays disconnected for the process lifetime". Measured, both
  drivers recover on their own:

  - driver-mongodb: killing a real `mongod` and restarting it on the same port,
    the _same_ driver instance served the next write successfully (13ms), with no
    reconnect call from us — the official driver's topology monitor handles it.
  - driver-sql: a knex/pg pool is not poisoned by an outage. Its error tracks live
    server state (`ECONNREFUSED` while down → a handshake error once a listener is
    back → `ECONNREFUSED` again), i.e. every acquire opens a fresh connection.
    `storage-driver.ts` also configures `pool.min: 0`, so no stale idle
    connections are held.

  The original reasoning grepped this repo for `reconnect`, found nothing, and
  concluded recovery does not happen — but the recovery lives in the client
  libraries, not in our code. The claims are now corrected in `DriverConnectError`,
  the `DEGRADED BOOT` banner, `resolveAllowDriverConnectFailure`'s docs, and the
  drivers / self-hosting pages.

  **Fail-fast at boot is unchanged and still correct** — the reason is just
  different. It is not that the connection can never return; it is that the _boot
  sequence_ never re-runs. A driver that missed `init()` also missed
  `syncRegisteredSchemas()`, so its tables can simply not exist even after the
  database comes back. The banner now says that.

  **The real defect underneath.** `SqlDriver` passed its config to knex untouched,
  so a database endpoint that accepts TCP but never completes the handshake — an
  overloaded instance, a half-open firewall, a load balancer mid-failover — made
  every query wait out tarn's 30s default, then fail with `Timeout acquiring a
connection. The pool is probably full`, pointing an operator at pool sizing
  instead of the network. With a small `pool.max` a few such queries saturate the
  pool and everything else queues.

  `SqlDriver` now defaults `pool.createTimeoutMillis` to **10s**, matching
  driver-mongodb's existing `connectTimeoutMS ?? 10_000` so both drivers give up on
  an unreachable server at the same point. A host that sets its own
  `createTimeoutMillis` is left alone.

  **Migration.** None for a healthy datasource. A deployment that deliberately
  relies on connection establishment taking longer than 10s (a slow cross-region
  replica) should set `pool.createTimeoutMillis` explicitly on its `SqlDriver`
  config.

  Not fixed here, tracked in #3769: knex still reports the bounded wait as "the
  pool is probably full". An accurate message needs a dialect-specific connect
  timeout (pg's `connectionTimeoutMillis`), which changes the shape of `connection`
  and would regress the startup banner's URL display.

- f598aa8: Withhold the Postgres and bare-SQLite phrasings of a driver failure from HTTP error bodies

  `looksLikeInternalErrorLeak` recognised SQLite's `SQLITE_ERROR: no such table: sys_metadata`
  but not the Postgres phrasing of the same condition, `relation "sys_metadata" does not exist`.
  The result was that one failure disclosed a physical table name or not depending on which
  engine was underneath, from every boundary that applies the predicate — `HttpDispatcher.error`,
  the declarative endpoint executor, the dispatcher plugin, the direct-mount package door and the
  Hono auth-config route.

  The predicate now also recognises, for the engines this repo actually runs:

  - Postgres `relation "…" does not exist` and `column "…" does not exist` (42P01/42703), which
    covers the `… of relation "…"` sub-object family as a superstring;
  - Postgres `permission denied for table|relation|sequence|database …` (42501);
  - SQLite/libsql `no such table:` / `no such column:` in their bare, un-prefixed form.

  Each phrasing is anchored on the driver's own template — a quoted identifier, or the trailing
  colon — never on the bare tail, so ordinary business messages such as "user does not exist" are
  still returned to the caller unchanged. The predicate is applied only where the outcome is
  already a 5xx, and the full text still reaches the server log and the error reporter.

- 08f93bc: fix(auth): `organization/create` gates on the authoritative `OS_TENANCY_POSTURE`, not the demoted `OS_MULTI_ORG_ENABLED` (#5233)

  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
  `group`), legacy boolean unset — mounted the entire organization wall and still
  answered `403 Creating additional organizations is disabled on this deployment.`
  to `POST /api/v1/auth/organization/create`. Org-less users had no way to create
  their workspace, so the guided "Create your workspace" path was a dead end.

  ADR-0105 D1 made `OS_TENANCY_POSTURE` the canonical knob and demoted
  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
  Two sites in `AuthManager` kept reading the demoted boolean directly, so both
  reported "single-org" on a deployment that had asked for a wall and got one:

  - `organizationHooks.beforeCreateOrganization` — the 403 above. It now judges
    `postureEnforcesWall(resolveTenancyPosture())`, matching the knob `serve.ts`'s
    own ADR-0093 D5 boot guard keys on. Intent is unchanged (single-org still
    refuses); only the knob is corrected.
  - `/auth/config`'s `features.multiOrgEnabled` — its no-tenancy-service fallback
    read the same boolean. It now falls back to the resolved posture, so a lean
    embedding advertises the capability its own gate allows.

  **No configuration change is needed anywhere.** Deployments that set only
  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
  workaround people used to unblock themselves stays valid. Deployments that set
  only `OS_TENANCY_POSTURE` can now drop the redundant boolean.

  `resolveMultiOrgEnabled()`'s doc comment in `@objectstack/types` — which still
  instructed "the auth manager's `/auth/config` feature flag and org-create guard
  … MUST call this", written before the demotion — now says the opposite: ask the
  posture, and never gate on this boolean. Its behaviour is unchanged.

- 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.

- 39eb01b: fix(runtime,cli,types): `os migrate` and the dev runtime now share one `__search` companion schema view (#3955)

  On a zh-locale deployment the dev runtime provisions the hidden `__search`
  pinyin companion column (ADR-0098) on every eligible object, but the
  `os migrate plan`/`apply` boot went through `createStandaloneStack`, which
  never derived the locale-gated pinyin decision from the compiled artifact.
  Its metadata therefore lacked every companion column, and `migrate plan`
  reported each live `__search` column of a dev-created database as a
  destructive orphan — with `--allow-destructive` as the printed remediation,
  which would have dropped live feature columns.

  - `@objectstack/types`: new `collectConfiguredLocales(i18n)` and
    `stampSearchPinyinEnabled(i18n)` — the single resolve-and-stamp helper for
    `OS_SEARCH_PINYIN_ENABLED`. An explicit env value still wins; only a
    positive locale-derived decision is stamped.
  - `@objectstack/runtime`: `createStandaloneStack` stamps the decision from
    the artifact's `i18n` before any plugin constructs a `SchemaRegistry`, and
    surfaces `i18n` on its result like `requires`/`objects`/`manifest`.
  - `@objectstack/cli`: the `serve`/`dev` boot now stamps through the same
    shared helper (behaviour unchanged), so create/serve and plan/apply cannot
    compute different schema views of the same source tree.

  A fresh CLI-created database is now also born with the same `__search`
  columns the dev runtime would provision, instead of acquiring them on the
  next dev boot.

- 694c350: fix(drivers): a `conflictKeys` upsert with no backing unique index refuses legibly on **Postgres** too, not only SQLite (#8567)

  `SqlDriver.upsert` recognised "the `ON CONFLICT` target is not backed by a
  PRIMARY KEY or UNIQUE index" on **SQLite only** (#8445). `driver-sql` serves
  three dialects, so on Postgres the raw driver error still escaped: `mapDataError`
  fell through to its default branch and served the thrown message as the whole
  response body — and that message is the **statement**, with no `code` for any
  client to branch on.

  **What a Postgres caller got, and now gets.** Measured against a real
  PostgreSQL 16.13 through the same knex + `pg` path the driver uses:

  ```
  before:  code=42P10  status=undefined
           message=insert into "plain" ("email", "id", "title") values ($1, $2, $3)
                   on conflict ("email") do update set "title" = excluded."title"
                   - there is no unique or exclusion constraint matching the ON CONFLICT specification

  after:   code=VALIDATION_ERROR  status=400
           message=Cannot upsert into "plain" on conflict keys ("email"): no PRIMARY KEY or
                   UNIQUE index backs them, … Fix by declaring the column(s) "unique: true" …
  ```

  The accept/reject set does not move: the same upserts fail, they fail legibly.
  The server's own sentence is preserved on the error's `cause`, which no error
  mapper puts on the wire, so an operator debugging the table keeps the ground
  truth while the caller stops receiving SQL text.

  **One clause of the refusal wording changed, on both faces.** "…and SQLite
  refuses the statement" is now "…and **the database** refuses the statement".
  Once recognition covers Postgres, naming SQLite points a Postgres operator at
  the wrong engine. `driver-turso`'s remote-face copy moved in the same commit —
  the two are held word-for-word identical (#5240) by #8568's cross-face parity
  pin. No other sentence of the refusal changed.

  **Recognition is now a named, shared predicate.**
  `isUnbackedConflictTargetError` is exported from `@objectstack/types` beside
  `isUniqueViolationError`, carrying one measured message limb per dialect that
  can raise the condition. ⚠️ It is deliberately a **separate** predicate:
  `isUniqueViolationError` answers the opposite condition (an index exists and the
  row violated it), and a merged one would report a working constraint as a
  missing one.

  **MySQL is unaffected, by measurement rather than omission.** knex compiles
  `onConflict(...).merge(...)` on that dialect to `ON DUPLICATE KEY UPDATE`, which
  takes no conflict target — the named keys never leave the process, so the server
  is never asked to find an index for them and the condition cannot arise. The
  compiled statement is pinned; the live MySQL cell is reported as un-run rather
  than passing vacuously.

- 88f9d94: fix(types,rest): one named unique-violation predicate — a MySQL conflict is 409 UNIQUE_VIOLATION, not 500 (#6250)

  **On MySQL, every unique-constraint conflict came back as `500 INTERNAL_ERROR`.**
  The API contract registers `UNIQUE_VIOLATION` as a 409 code
  (`packages/spec/src/api/error-code-ledger.zod.ts`), so a front end had no way to
  tell "this email is already taken" from "the server fell over" — no retry advice,
  no field to point at, and a 5xx in the operator's dashboards for what is an
  ordinary client outcome. SQLite and Postgres deployments never saw it, which is
  why it survived: their conflict prose happens to contain the words the mapping
  looked for.

  **Cause: the conflict verdict was nested inside a leak heuristic.** REST's 409
  branch lived inside the true-branch of `looksLikeInternalErrorLeak()`, keyed on
  the substrings `unique constraint` / `unique violation`. MySQL says
  `ER_DUP_ENTRY: Duplicate entry '…' for key '…'`, which matches no limb of that
  heuristic, so the conflict never reached the `if` at all and fell out of the
  terminal `UNCLASSIFIED_FAULT`. Two unrelated questions — "is this a conflict?"
  and "would echoing this text leak internals?" — had been fused into one, and
  MySQL is where they disagree.

  Measured on the previous release, through the real error mapper:

  ```
  mysql,    bare message       500 INTERNAL_ERROR  →  409 UNIQUE_VIOLATION
  mysql,    knex-wrapped SQL   500 DATABASE_ERROR  →  409 UNIQUE_VIOLATION
  postgres, SQLSTATE only      500 INTERNAL_ERROR  →  409 UNIQUE_VIOLATION
  sqlite,   message            409 UNIQUE_VIOLATION   (unchanged)
  postgres, message            409 UNIQUE_VIOLATION   (unchanged)
  ```

  So the hole was never MySQL-only: the mapping read one of the two channels
  drivers use. A Postgres error carrying SQLSTATE `23505` with unremarkable prose
  was a 500 as well.

  **New: `isUniqueViolationError(error)`, exported from `@objectstack/types`.** One
  named predicate replaces the substring test, reading every channel a driver
  uses — `code` (`23505` / `ER_DUP_ENTRY` / `SQLITE_CONSTRAINT_UNIQUE`), `errno`
  (`1062`), the message, and one step down the `cause` chain that pool and
  query-builder layers wrap with. Its vocabulary is the union of the four
  hand-written copies the repo already carried, so routing REST through it cannot
  narrow any verdict clients rely on today; an unrecognised error is never a
  conflict, because a false 409 tells an SDK not to retry and points the user at a
  value that is fine.

  **The internal-leak classifier is byte-identical.** The fix hoists the conflict
  question out of it rather than widening its criteria, so nothing else it guards
  is reclassified as safe-to-expose. And the 409 body is fixed text: MySQL embeds
  the offending user data in its message (`Duplicate entry 'a@b.com' …`) and
  Postgres the index and column names, none of which reaches the client. The full
  driver text still reaches the server log.

  No action needed. Clients that already handled `409 UNIQUE_VIOLATION` on SQLite
  and Postgres now receive it on MySQL too.

- Updated dependencies [50616d9]
- Updated dependencies [430dcc2]
- Updated dependencies [6a67d7a]
- Updated dependencies [333a374]
- Updated dependencies [9fe9c1d]
- Updated dependencies [3d5c090]
- Updated dependencies [e5bd768]
- Updated dependencies [08b5a3d]
- Updated dependencies [e027b3e]
- Updated dependencies [e6ac4bd]
- Updated dependencies [c2429b0]
- Updated dependencies [445a0c2]
- Updated dependencies [d99aeb3]
- Updated dependencies [f6609e6]
- Updated dependencies [4727eb8]
- Updated dependencies [a70358a]
- Updated dependencies [0ecc656]
- Updated dependencies [06772eb]
- Updated dependencies [d4e0809]
- Updated dependencies [80334c7]
- Updated dependencies [f63cd09]
- Updated dependencies [97e7e3c]
- Updated dependencies [ce5242c]
- Updated dependencies [a7163ea]
- Updated dependencies [e6e9379]
- Updated dependencies [5823d59]
- Updated dependencies [3140f9c]
- Updated dependencies [9500ba4]
- Updated dependencies [fa3d0cf]
- Updated dependencies [af5a224]
- Updated dependencies [71f76e1]
- Updated dependencies [37b1346]
- Updated dependencies [99736a0]
- Updated dependencies [fe67e34]
- Updated dependencies [fdb4f50]
- Updated dependencies [270650f]
- Updated dependencies [3aef718]
- Updated dependencies [1bd5652]
- Updated dependencies [14252d3]
- Updated dependencies [7fb436c]
- Updated dependencies [879ea13]
- Updated dependencies [8828b9e]
- Updated dependencies [1ea6bce]
- Updated dependencies [c1dcacd]
- Updated dependencies [ad303ed]
- Updated dependencies [32ccb23]
- Updated dependencies [f5a4ef0]
- Updated dependencies [2d3e255]
- Updated dependencies [a8940e4]
- Updated dependencies [7d7521f]
- Updated dependencies [5dc4d02]
- Updated dependencies [f724f69]
- Updated dependencies [98877c9]
- Updated dependencies [98877c9]
- Updated dependencies [53068c1]
- Updated dependencies [ee58392]
- Updated dependencies [f16e54e]
- Updated dependencies [06be54e]
- Updated dependencies [28ad90e]
- Updated dependencies [76d74ec]
- Updated dependencies [201b31f]
- Updated dependencies [e6b1b69]
- Updated dependencies [259459d]
- Updated dependencies [3f7f14e]
- Updated dependencies [e2616e0]
- Updated dependencies [6fdc5c6]
- Updated dependencies [8b9d71e]
- Updated dependencies [05154a1]
- Updated dependencies [33f5e23]
- Updated dependencies [259af21]
- Updated dependencies [f8644c7]
- Updated dependencies [306ca50]
- Updated dependencies [978fed2]
- Updated dependencies [cfc293f]
- Updated dependencies [587fc91]
- Updated dependencies [de70b42]
- Updated dependencies [9b6fe7c]
- Updated dependencies [fb3d99b]
- Updated dependencies [1986594]
- Updated dependencies [6968885]
- Updated dependencies [eaed61f]
- Updated dependencies [cdfbee2]
- Updated dependencies [ad4af62]
- Updated dependencies [debe2f6]
- Updated dependencies [d44dbfa]
- Updated dependencies [29c6c9d]
- Updated dependencies [d21c001]
- Updated dependencies [ad047d2]
- Updated dependencies [8c711fb]
- Updated dependencies [f1cc3a3]
- Updated dependencies [09e4547]
- Updated dependencies [97b0798]
- Updated dependencies [474fe39]
- Updated dependencies [0bc685a]
- Updated dependencies [b949059]
- Updated dependencies [2826d1e]
- Updated dependencies [be1c52c]
- Updated dependencies [c5ff96d]
- Updated dependencies [5a84d41]
- Updated dependencies [84e7be9]
- Updated dependencies [91f4c78]
- Updated dependencies [ddc2527]
- Updated dependencies [820eff9]
- Updated dependencies [a6c3f38]
- Updated dependencies [debc23a]
- Updated dependencies [0f8ad09]
- Updated dependencies [553a47f]
- Updated dependencies [43a7a8d]
- Updated dependencies [a98085f]
- Updated dependencies [20b1a9e]
- Updated dependencies [344a22a]
- Updated dependencies [4827e91]
- Updated dependencies [8d895ff]
- Updated dependencies [86f7a20]
- Updated dependencies [a3a884d]
- Updated dependencies [cfed092]
- Updated dependencies [203a449]
- Updated dependencies [8f9689f]
- Updated dependencies [73f69dc]
- Updated dependencies [04c56aa]
- Updated dependencies [f6472d7]
- Updated dependencies [57a3bb3]
- Updated dependencies [b3efeb7]
- Updated dependencies [ddd075a]
- Updated dependencies [88154be]
- Updated dependencies [e8dc61e]
- Updated dependencies [9c82146]
- Updated dependencies [5f9a987]
- Updated dependencies [744b8f5]
- Updated dependencies [ac37fc6]
- Updated dependencies [2f3e793]
- Updated dependencies [4820f55]
- Updated dependencies [462d9c4]
- Updated dependencies [78caf51]
- Updated dependencies [7d21581]
- Updated dependencies [37785ed]
- Updated dependencies [62a789b]
- Updated dependencies [2e284b2]
- Updated dependencies [d8e8d9c]
- Updated dependencies [789ad63]
- Updated dependencies [f2445c9]
- Updated dependencies [94e749b]
- Updated dependencies [ea1d916]
- Updated dependencies [2af1988]
- Updated dependencies [1b49eaf]
- Updated dependencies [ae31a19]
- Updated dependencies [e0f300b]
- Updated dependencies [0161c7f]
- Updated dependencies [e900015]
- Updated dependencies [db02d47]
- Updated dependencies [b5bdf48]
- Updated dependencies [23338c3]
- Updated dependencies [12a19a8]
- Updated dependencies [5b843fb]
- Updated dependencies [62b6a2f]
- Updated dependencies [7e5af5c]
- Updated dependencies [5b4780b]
- Updated dependencies [a933452]
- Updated dependencies [9d1d9c7]
- Updated dependencies [8140915]
- Updated dependencies [a019e52]
- Updated dependencies [e8f8f6c]
- Updated dependencies [41dcda3]
- Updated dependencies [7b48cf9]
- Updated dependencies [b5404f4]
- Updated dependencies [64fc6d5]
- Updated dependencies [b4487aa]
- Updated dependencies [1007379]
- Updated dependencies [65ca83a]
- Updated dependencies [0bfdf46]
- Updated dependencies [947d4f9]
- Updated dependencies [f764691]
- Updated dependencies [e120a5a]
- Updated dependencies [e5bd2f6]
- Updated dependencies [e650d67]
- Updated dependencies [04476e7]
- Updated dependencies [67bf2e2]
- Updated dependencies [eaaf03c]
- Updated dependencies [d17df80]
- Updated dependencies [7d0e7b5]
- Updated dependencies [c6d1cb4]
- Updated dependencies [6513c17]
- Updated dependencies [36030ff]
- Updated dependencies [79228cd]
- Updated dependencies [6117f7b]
- Updated dependencies [e533b0b]
- Updated dependencies [cdf4d9a]
- Updated dependencies [aee1806]
- Updated dependencies [c13350b]
- Updated dependencies [c13350b]
- Updated dependencies [2c1988c]
- Updated dependencies [9ca2d85]
- Updated dependencies [c13350b]
- Updated dependencies [891d345]
- Updated dependencies [c8124e5]
- Updated dependencies [a52e2ef]
- Updated dependencies [5293114]
- Updated dependencies [376a061]
- Updated dependencies [c142ced]
- Updated dependencies [211abdb]
- Updated dependencies [b3363e9]
- Updated dependencies [eda599e]
- Updated dependencies [a1a4140]
- Updated dependencies [7c7e246]
- Updated dependencies [2ef1807]
- Updated dependencies [f35cdc5]
- Updated dependencies [d03fe25]
- Updated dependencies [217e2e6]
- Updated dependencies [2672f85]
- Updated dependencies [20bc357]
- Updated dependencies [11066f6]
- Updated dependencies [916af17]
- Updated dependencies [84c86fb]
- Updated dependencies [2a2a9fb]
- Updated dependencies [86a71d1]
- Updated dependencies [c001422]
- Updated dependencies [77022a9]
- Updated dependencies [d5c75e2]
- Updated dependencies [03d26f7]
- Updated dependencies [5966c2a]
- Updated dependencies [2382580]
- Updated dependencies [9ea2bc5]
- Updated dependencies [a2e157c]
- Updated dependencies [95c4227]
- Updated dependencies [2a61116]
- Updated dependencies [52760bf]
- Updated dependencies [5543020]
- Updated dependencies [880d343]
- Updated dependencies [6e82972]
- Updated dependencies [d4df105]
- Updated dependencies [4615a18]
- Updated dependencies [f505689]
- Updated dependencies [d9fa683]
- Updated dependencies [606d577]
- Updated dependencies [4384921]
- Updated dependencies [e2798fa]
- Updated dependencies [3c628ce]
- Updated dependencies [c2d9098]
- Updated dependencies [0fd8556]
- Updated dependencies [3c7bcc0]
- Updated dependencies [4b6cac7]
- Updated dependencies [7631964]
- Updated dependencies [ac471a0]
- Updated dependencies [60ae58e]
- Updated dependencies [7f62706]
- Updated dependencies [667fa44]
- Updated dependencies [37e38d1]
- Updated dependencies [e906126]
- Updated dependencies [ce92674]
- Updated dependencies [08363a0]
- Updated dependencies [444de5b]
- Updated dependencies [a227ed7]
- Updated dependencies [7cb922e]
- Updated dependencies [1d22114]
- Updated dependencies [1eb13a0]
- Updated dependencies [c52e608]
- Updated dependencies [9613396]
- Updated dependencies [3f7b4ff]
- Updated dependencies [74155c7]
- Updated dependencies [b5f9397]
- Updated dependencies [ed77493]
- Updated dependencies [6908830]
- Updated dependencies [8b06bba]
- Updated dependencies [58a03d2]
- Updated dependencies [2bacd1a]
- Updated dependencies [e47b342]
- Updated dependencies [4c54037]
- Updated dependencies [dc530b4]
- Updated dependencies [9f601e8]
- Updated dependencies [6a9dec6]
- Updated dependencies [0f7157b]
- Updated dependencies [4dc1c7d]
- Updated dependencies [d9bef45]
- Updated dependencies [4dfd002]
- Updated dependencies [f549a0d]
- Updated dependencies [51c5227]
- Updated dependencies [82da264]
- Updated dependencies [77be690]
- Updated dependencies [4ed7ed4]
- Updated dependencies [9b9b70f]
- Updated dependencies [f5a9bc2]
- Updated dependencies [e59786e]
- Updated dependencies [2fa4ca1]
- Updated dependencies [bcf1112]
- Updated dependencies [baeb4f0]
- Updated dependencies [29488cc]
- Updated dependencies [881a3cc]
- Updated dependencies [f5a2320]
- Updated dependencies [ad6317b]
- Updated dependencies [811c30c]
- Updated dependencies [a4a85c8]
- Updated dependencies [859cb83]
- Updated dependencies [07a4e26]
- Updated dependencies [9774b78]
- Updated dependencies [8a88885]
- Updated dependencies [deb538f]
- Updated dependencies [b49ccfd]
- Updated dependencies [5b89711]
- Updated dependencies [85d95e7]
- Updated dependencies [08cd163]
- Updated dependencies [0c8a22f]
- Updated dependencies [5f7669e]
- Updated dependencies [becbe53]
- Updated dependencies [b127c8b]
- Updated dependencies [763931e]
- Updated dependencies [ec975f1]
- Updated dependencies [168f60f]
- Updated dependencies [b07d829]
- Updated dependencies [de9af8a]
- Updated dependencies [eb4204b]
- Updated dependencies [a80302a]
- Updated dependencies [a648e96]
- Updated dependencies [a47ac06]
- Updated dependencies [e4c61a7]
- Updated dependencies [cc60165]
- Updated dependencies [474f131]
- Updated dependencies [081aa6f]
- Updated dependencies [91f4c78]
- Updated dependencies [050cd82]
- Updated dependencies [4d552af]
- Updated dependencies [44d677c]
- Updated dependencies [c32944d]
- Updated dependencies [1dd780f]
- Updated dependencies [e8d0c21]
- Updated dependencies [244ca86]
- Updated dependencies [546ab3c]
- Updated dependencies [c4df271]
- Updated dependencies [c8d6f6e]
- Updated dependencies [0b51bb6]
- Updated dependencies [d9971d3]
- Updated dependencies [7dc1067]
- Updated dependencies [4f13be2]
- Updated dependencies [a41ba5c]
- Updated dependencies [189854c]
- Updated dependencies [0e3a226]
- Updated dependencies [92a67f2]
- Updated dependencies [9136327]
- Updated dependencies [bf0ae99]
- Updated dependencies [abeb375]
- Updated dependencies [cb3b6cd]
- Updated dependencies [73b7234]
- Updated dependencies [d2b97c3]
- Updated dependencies [61cc079]
- Updated dependencies [0e96e46]
- Updated dependencies [c1d44f7]
- Updated dependencies [59b794f]
- Updated dependencies [ef4efa8]
- Updated dependencies [cbb6a5c]
- Updated dependencies [fc3a36a]
- Updated dependencies [ab9fb5c]
- Updated dependencies [69787f0]
- Updated dependencies [5d022a1]
- Updated dependencies [042b9ee]
- Updated dependencies [f985b3f]
- Updated dependencies [795b6e1]
- Updated dependencies [d52d4fe]
- Updated dependencies [742cebb]
- Updated dependencies [175d789]
- Updated dependencies [f549a0d]
- Updated dependencies [427344c]
- Updated dependencies [8af76ae]
- Updated dependencies [1d4756e]
- Updated dependencies [720c5ad]
- Updated dependencies [a8d1e24]
- Updated dependencies [b85cc54]
- Updated dependencies [a36db28]
- Updated dependencies [7a8476f]
- Updated dependencies [518ca7a]
- Updated dependencies [41642b0]
- Updated dependencies [4cca74c]
- Updated dependencies [88ef03e]
- Updated dependencies [9a4932a]
- Updated dependencies [3f8817a]
- Updated dependencies [a2443e3]
- Updated dependencies [e1554b1]
- Updated dependencies [9e2caf3]
- Updated dependencies [4856789]
- Updated dependencies [81ce41a]
- Updated dependencies [85e1e4e]
- Updated dependencies [c3f4916]
- Updated dependencies [55dbbba]
- Updated dependencies [33e0385]
- Updated dependencies [dac6a08]
- Updated dependencies [72c3c86]
- Updated dependencies [2d8dba3]
- Updated dependencies [7f1a635]
- Updated dependencies [2205363]
- Updated dependencies [09fe58d]
- Updated dependencies [f9fc874]
- Updated dependencies [d62f8eb]
- Updated dependencies [d0a5ceb]
- Updated dependencies [a7586cd]
- Updated dependencies [4c5e80e]
- Updated dependencies [4b5702a]
- Updated dependencies [011b386]
- Updated dependencies [e18a162]
- Updated dependencies [394b7a1]
- Updated dependencies [ce92674]
- Updated dependencies [cf2c9b7]
- Updated dependencies [d127ff0]
- Updated dependencies [36d90fc]
- Updated dependencies [7777e8f]
- Updated dependencies [9b86cf6]
- Updated dependencies [d063a96]
- Updated dependencies [8825a06]
- Updated dependencies [5087ac6]
- Updated dependencies [677b591]
- Updated dependencies [cf7c694]
- Updated dependencies [ddd0f06]
- Updated dependencies [d77d1b7]
- Updated dependencies [0f9faa2]
- Updated dependencies [2d1ddf0]
- Updated dependencies [354b00f]
- Updated dependencies [3de535b]
- Updated dependencies [fe2e15a]
- Updated dependencies [5b79a34]
- Updated dependencies [502564d]
- Updated dependencies [603cab8]
- Updated dependencies [c757854]
- Updated dependencies [471839d]
- Updated dependencies [507b92a]
- Updated dependencies [b508244]
- Updated dependencies [df95346]
- Updated dependencies [3dede58]
- Updated dependencies [c6b6bb4]
- Updated dependencies [594508e]
- Updated dependencies [7cf42fe]
- Updated dependencies [5966c2a]
- Updated dependencies [0045682]
- Updated dependencies [7309c81]
- Updated dependencies [2f59da0]
- Updated dependencies [d56012f]
- Updated dependencies [f78dd83]
- Updated dependencies [a2cd18a]
- Updated dependencies [9051802]
- Updated dependencies [20bc1ec]
- Updated dependencies [1c625ca]
- Updated dependencies [2f8328c]
- Updated dependencies [2a6c279]
- Updated dependencies [8c8f0df]
- Updated dependencies [8ad609c]
- Updated dependencies [bbee302]
- Updated dependencies [90c2b15]
- Updated dependencies [4638aaa]
- Updated dependencies [0222d3c]
- Updated dependencies [08863dd]
- Updated dependencies [f293d45]
- Updated dependencies [56664f5]
- Updated dependencies [71f205d]
- Updated dependencies [f067930]
- Updated dependencies [414395b]
- Updated dependencies [42eeb7d]
- Updated dependencies [31cbe90]
- Updated dependencies [6b7129a]
- Updated dependencies [97ace2a]
- Updated dependencies [26e1029]
- Updated dependencies [0a936ea]
- Updated dependencies [90bbf25]
- Updated dependencies [023c00b]
- Updated dependencies [eb91eba]
- Updated dependencies [42da73d]
- Updated dependencies [01e124d]
- Updated dependencies [ef7b5ef]
- Updated dependencies [9514767]
- Updated dependencies [8f20201]
- Updated dependencies [155507e]
- Updated dependencies [643b7c7]
- Updated dependencies [7bba90b]
- Updated dependencies [8813b90]
- Updated dependencies [108ba8d]
- Updated dependencies [2a5f04a]
- Updated dependencies [4f740b0]
- Updated dependencies [7ce02eb]
- Updated dependencies [b4ad984]
- Updated dependencies [a9f32df]
- Updated dependencies [aeb9b27]
- Updated dependencies [7d27da0]
- Updated dependencies [1a15893]
- Updated dependencies [b70e534]
- Updated dependencies [7e05d8e]
- Updated dependencies [8f1851e]
- Updated dependencies [61ea810]
- Updated dependencies [2233a85]
- Updated dependencies [67452d1]
- Updated dependencies [089767f]
- Updated dependencies [a13827e]
- Updated dependencies [66d99ec]
- Updated dependencies [cb43296]
- Updated dependencies [b61afc1]
- Updated dependencies [79021fc]
- Updated dependencies [7733604]
- Updated dependencies [40e420f]
- Updated dependencies [62dd69a]
- Updated dependencies [d13004a]
- Updated dependencies [e15e679]
- Updated dependencies [2ab1257]
- Updated dependencies [0fc6219]
- Updated dependencies [061406d]
- Updated dependencies [e4c8b6c]
- Updated dependencies [acb10f6]
- 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 [4cc4fb7]
- Updated dependencies [97b6658]
- Updated dependencies [2c26040]
- Updated dependencies [f758cec]
- Updated dependencies [5b47ab5]
- Updated dependencies [b09d8d9]
- Updated dependencies [b09d8d9]
- Updated dependencies [8675db6]
- Updated dependencies [b09d8d9]
- Updated dependencies [27358d5]
- Updated dependencies [1c3da1f]
- Updated dependencies [c1f344b]
- Updated dependencies [3eb1b2b]
- Updated dependencies [9c93465]
- Updated dependencies [a34fd2e]
- Updated dependencies [ebb209c]
- Updated dependencies [76bcb83]
- Updated dependencies [59b85c0]
- Updated dependencies [889ae47]
- Updated dependencies [4f4c3fb]
- Updated dependencies [78f0be8]
- Updated dependencies [6e357ed]
- Updated dependencies [d6938bf]
- Updated dependencies [35f7fb4]
- Updated dependencies [0410522]
- Updated dependencies [63b33e6]
- Updated dependencies [f163028]
- Updated dependencies [814db6d]
- Updated dependencies [a5302c7]
- Updated dependencies [31e0be9]
- Updated dependencies [4bfd455]
- Updated dependencies [ffd2ce2]
- Updated dependencies [2a44c1d]
- Updated dependencies [7084313]
- Updated dependencies [f07808c]
- Updated dependencies [7ffc3d3]
- Updated dependencies [88346ba]
- Updated dependencies [4631592]
- Updated dependencies [62f8017]
- Updated dependencies [32ff033]
- Updated dependencies [a831df1]
- Updated dependencies [f752ee3]
- Updated dependencies [a1b61e0]
- Updated dependencies [cd6b9f2]
- Updated dependencies [2cb6d3c]
- Updated dependencies [af2a095]
- Updated dependencies [5ac93d4]
- Updated dependencies [695cfbd]
- Updated dependencies [0e043d8]
- Updated dependencies [93f267f]
- Updated dependencies [7445149]
- Updated dependencies [ec796d5]
- Updated dependencies [071d0dc]
- Updated dependencies [0024abf]
- Updated dependencies [8dd98bf]
- Updated dependencies [e87fea1]
- Updated dependencies [c65e529]
- Updated dependencies [0848bea]
- Updated dependencies [d51bed2]
- Updated dependencies [dadd1ad]
- Updated dependencies [acbf364]
- Updated dependencies [3ca34c1]
- Updated dependencies [7adc841]
- Updated dependencies [239c3a3]
- Updated dependencies [b8b3c64]
- Updated dependencies [2f2e63c]
- Updated dependencies [4845f85]
- Updated dependencies [486d526]
- Updated dependencies [94a0bbc]
- Updated dependencies [d6bfb3d]
- Updated dependencies [8a9c079]
- Updated dependencies [7b005b4]
- Updated dependencies [cc3555e]
- Updated dependencies [a2266a6]
- Updated dependencies [d25a0ec]
- Updated dependencies [89d7b35]
- Updated dependencies [94f7b6a]
- Updated dependencies [5c94f83]
- Updated dependencies [ea936f3]
- Updated dependencies [0c0fbd9]
- Updated dependencies [667b83e]
- Updated dependencies [f3141d8]
- Updated dependencies [7687f7b]
- Updated dependencies [5a84d41]
- Updated dependencies [fd3013a]
- Updated dependencies [85ec26d]
- Updated dependencies [73e576f]
- Updated dependencies [f6476fc]
- Updated dependencies [69ac82c]
- Updated dependencies [4ac12ef]
- Updated dependencies [833ed84]
- Updated dependencies [a18abf3]
- Updated dependencies [c6a4eeb]
- Updated dependencies [1659072]
- Updated dependencies [f450ae7]
- Updated dependencies [abceb0d]
- Updated dependencies [627b188]
- Updated dependencies [8d4eae7]
- Updated dependencies [c5a5996]
- Updated dependencies [0c302a7]
- Updated dependencies [b88f5e8]
- Updated dependencies [65a3a84]
- Updated dependencies [6633337]
- Updated dependencies [21676eb]
- Updated dependencies [e9cb9ab]
- Updated dependencies [42cc219]
- Updated dependencies [d7e0b42]
- Updated dependencies [3510e4a]
- Updated dependencies [f00d8d4]
- Updated dependencies [5326b36]
- Updated dependencies [aa4b90d]
- Updated dependencies [ccd9397]
- Updated dependencies [503be86]
- Updated dependencies [54299ca]
- Updated dependencies [ae490ef]
- Updated dependencies [e124711]
- Updated dependencies [dc61def]
- Updated dependencies [bca935b]
- Updated dependencies [c54c822]
- Updated dependencies [8dcc0f5]
- Updated dependencies [75b9e51]
- Updated dependencies [f61c8cf]
- Updated dependencies [e3ef52b]
- Updated dependencies [0a2f233]
- Updated dependencies [8621cdd]
- Updated dependencies [251e888]
- Updated dependencies [07f1822]
- Updated dependencies [e336549]
- Updated dependencies [3bb9340]
- Updated dependencies [1e604c4]
- Updated dependencies [04fab5e]
- Updated dependencies [183b4c4]
- Updated dependencies [7f713b6]
- Updated dependencies [d40f43a]
- Updated dependencies [2fdb36e]
- Updated dependencies [6f23667]
- Updated dependencies [cde1975]
- Updated dependencies [0bc685a]
- Updated dependencies [20526f5]
- Updated dependencies [efedd28]
- Updated dependencies [5d21a48]
- Updated dependencies [5278e11]
- Updated dependencies [c5eef1d]
- Updated dependencies [e5e7ee0]
- Updated dependencies [23dba62]
- Updated dependencies [e0f300b]
- Updated dependencies [761a0ba]
- Updated dependencies [c960170]
- Updated dependencies [19365b7]
- Updated dependencies [ba98e26]
- Updated dependencies [b7ed26d]
- Updated dependencies [a2ebea2]
- Updated dependencies [800bdb0]
- Updated dependencies [9d4dfc4]
- Updated dependencies [1059965]
- Updated dependencies [def5919]
- Updated dependencies [60b672e]
- Updated dependencies [6b441a8]
- Updated dependencies [ce0cfe9]
- Updated dependencies [04f1182]
- Updated dependencies [be87153]
- Updated dependencies [dd0f681]
- Updated dependencies [60f0dd8]
- Updated dependencies [a87c5cd]
- Updated dependencies [a47f338]
- Updated dependencies [b3a3d83]
- Updated dependencies [7a55913]
- Updated dependencies [35accbf]
- Updated dependencies [6038de7]
- Updated dependencies [fc5f536]
- Updated dependencies [5647006]
- Updated dependencies [e654bfd]
- Updated dependencies [01a7337]
- Updated dependencies [b45c71e]
- Updated dependencies [f8cfbb4]
- Updated dependencies [6e6c872]
- Updated dependencies [2598216]
- Updated dependencies [11949fc]
- Updated dependencies [2c7e62d]
- Updated dependencies [eb95d97]
- Updated dependencies [b098b0e]
- Updated dependencies [4d00b13]
- Updated dependencies [1363084]
- Updated dependencies [fa5758e]
- Updated dependencies [38f7e4f]
- Updated dependencies [eb7613c]
- Updated dependencies [c57f3cf]
- Updated dependencies [ecc9110]
- Updated dependencies [e4c2dc8]
- Updated dependencies [97faca3]
- Updated dependencies [57bab76]
- Updated dependencies [c89d18c]
- Updated dependencies [1bd2795]
- Updated dependencies [f7bd4e2]
- Updated dependencies [361bd5b]
- Updated dependencies [aac90a5]
- Updated dependencies [3da3da5]
- Updated dependencies [1e6ab15]
- Updated dependencies [b90086a]
- Updated dependencies [8186a70]
- Updated dependencies [a329cca]
- Updated dependencies [c87ef70]
- Updated dependencies [3cb0618]
- Updated dependencies [32a0874]
- Updated dependencies [6eec18c]
- Updated dependencies [4d7bebf]
- Updated dependencies [821ac7a]
- Updated dependencies [8f81731]
- Updated dependencies [7055c22]
- Updated dependencies [785a748]
- Updated dependencies [3af0354]
- Updated dependencies [866ff16]
- Updated dependencies [5a85e67]
- Updated dependencies [8b50cb3]
- Updated dependencies [a0fdc56]
- Updated dependencies [b95577a]
- Updated dependencies [0dcbc11]
- Updated dependencies [d88f3e9]
- Updated dependencies [ad5fe25]
- Updated dependencies [c183a12]
- Updated dependencies [83c161f]
- Updated dependencies [d8c4957]
- Updated dependencies [b9f930b]
- Updated dependencies [f24cb83]
- Updated dependencies [5dbbb92]
- Updated dependencies [ea90179]
- Updated dependencies [1818998]
- Updated dependencies [ce92674]
- Updated dependencies [5ef0b5b]
- Updated dependencies [8c2db68]
- Updated dependencies [22b5e54]
- Updated dependencies [0166bd5]
- Updated dependencies [8064b07]
- Updated dependencies [09ee21c]
- Updated dependencies [4a56dbd]
- Updated dependencies [289d04a]
- Updated dependencies [f549a0d]
- Updated dependencies [48fbacb]
- Updated dependencies [06df4fa]
- Updated dependencies [3fc2e48]
- Updated dependencies [c9b809f]
- Updated dependencies [e8f435c]
- Updated dependencies [32386f8]
- Updated dependencies [9b702dc]
- Updated dependencies [ab16331]
- Updated dependencies [41610f6]
- Updated dependencies [69f1dfd]
- Updated dependencies [bbe05de]
- Updated dependencies [355e951]
- Updated dependencies [a1dd1e4]
- Updated dependencies [dadb43f]
  - @objectstack/spec@17.0.0

## 17.0.0-rc.6

### Minor Changes

- 91cefb8: refactor(types,rest,metadata,analytics): Postgres 的 `"x" of relation "y"` 短语收归一处，三个包不再各修一遍同一个超串洞（#6615）

  Postgres 把「关系内部某个子对象」的失败写成 `column "label" of relation "sys_team" does not exist`——里面**逐字包含**一句合法的「表不存在」短语 `relation "sys_team" does not exist`，含义却相反：关系正因为存在才被点名。任何对「这句话是不是在说表没了」的正则收紧都消不掉这个匹配，短语确实在里面；唯一的修法是**先问更具体的问题**。所以修的是**顺序**，不是模式。

  正因为如此，这个短语被分三次教给了这个仓库，分属三个包、三个 PR，其中两次是在别处已经踩过同一个洞之后：`@objectstack/rest` 的 `mapDataError`（#5352）、`@objectstack/service-analytics` 的缺列扣除（#6035 / PR #6346）、`@objectstack/metadata` 的 `MISSING_TABLE.excludes`（#6347 / PR #6613）。本次把它收进 `@objectstack/types`，与 `isUniqueViolationError`（#6250）和 `isModuleNotFoundError`（framework#3265）同一个理由与同一个位置。

  **两种宽度，故意保留成两个导出。** 三个消费者要的并不是同一条正则，差别也不是随手写的，而是**每个站点哪个方向的误差是安全的**：

  - `matchMissingColumnOfRelation(message)` —— 严格提取器，锚定 Postgres 的 errmsg 模板 `column "%s" of relation "%s" does not exist`，返回列名。`rest` 用它把 42703 答成 `400 INVALID_FIELD` 而不是 `404`；`service-analytics` 用它在分类前扣除缺列。这两处**过宽**会把真正缺失的表变成硬失败、回退 #5033 刻意保留的宽容，**漏匹配**只是让消息含糊一点——所以必须严格。
  - `isRelationSubObjectPhrase(message)` —— 宽检测器，丢掉 `column` / `[a-z0-9_]+` / `does not exist` 三个锚点：任意子对象、任意带引号标识符、任意判词。`metadata` 用它做排除。这一处**过宽**只会把良性判定变成响亮判定，**漏匹配**却会让 `event_seq` 从 1 重新开始、撞进一张已有行的历史表——方向正好相反。

  把两者合并成一条正则，无论哪种宽度胜出都会对其中一个调用方是错的；这是卡片记录在案的风险，两个导出即为此而设，理由是承重的而非风格的。仓库里第四份拷贝（`service-analytics` 测试内用于守护 fixture 的那条正则）同时收编：它本是为「两张面孔别对不上」而写，却把断言打在其中一面的私有复述上，因而正是它要防的漂移。

  行为逐字保持不变：搬进来的两条模式与原站点逐字节相同。`@objectstack/service-analytics` 因此新增一条对 `@objectstack/types` 的依赖边——这是本次唯一的依赖变化，构造上无环（`@objectstack/types` 只依赖 `@objectstack/spec`，后者无仓内依赖），且仓库 73 个包中已有 25 个、16 个 service 中已有 5 个携带同一条边。

- 129b378: fix(types,rest): one named answer for "which column conflicted" — an index name is never returned as one (#6544)

  #6250 retired four private "is this a unique violation?" vocabularies into
  `isUniqueViolationError`. It left the harder half of the question behind: the
  import runner's `sanitizeRowError` still carried its own three-dialect regex
  chain, because it does **more** than answer yes/no — it names the offending
  column so the importer can say _"A record with this `email` already exists."_
  This lands that second answer as a shared export and migrates the last private
  copy onto it.

  **New — `uniqueViolationColumn(error)` in `@objectstack/types`** (`string |
undefined`), sibling to `isUniqueViolationError` and gated on it, reading the
  same channels one step down the same bounded `cause` chain, plus
  node-postgres' `detail` field.

  **Its contract, per the maintainer's 2026-08-08 ruling: a value comes back only
  when the identifier the driver printed is determinably a COLUMN.** When a
  dialect names an _index_ instead — MySQL's `Duplicate entry … for key
'idx_email_unique'`, Postgres' `violates unique constraint "sys_user_email_key"`,
  SQLite's `UNIQUE constraint failed: index 'x'` — the answer is `undefined`,
  never the index name. Callers render this into a form field, and an index name
  mistaken for a column points the user at a field that does not exist, whereas
  `undefined` degrades to generic copy. A **composite** key (`Key (tenant_id,
email)=(…)`) is `undefined` for the same reason: there is no single offending
  column, and naming the first is the same class of wrong answer.

  **⚠️ User-visible change on MySQL imports.** MySQL's duplicate-entry message
  names the index and never the column, so the importer no longer names a column
  there: rows that used to read _"A record with this `idx_email_unique` already
  exists."_ — or, on MySQL 8's table-qualified `for key 'sys_user.email'`, a
  plausible-looking _`email`_ that was still an index name — now read **"A record
  with this value already exists."** That is deliberate and is the accepted cost
  of the ruling. The conflict is still recognised as a conflict; only the naming
  narrowed.

  Three smaller import messages improve in the same move, all previously wrong
  rather than merely vague:

  - SQLite's expression/partial-index form used to render as _"A record with this
    **index** already exists."_
  - Postgres' expression index used to render the truncated fragment _"A record
    with this **lower(email** already exists."_
  - A Postgres conflict with no `DETAIL:` line used to fall through to the SQL
    backstop and echo the driver's own sentence — index name included — at the
    importer. It now gets the same generic conflict copy, which is also the exact
    wording `mapDataError` puts in the 409 `UNIQUE_VIOLATION` body, so the
    importer and the API say one thing about one condition.

  Not changed: the NOT NULL branch, the raw-SQL backstop, and every non-conflict
  message, which pass through exactly as before.

### Patch Changes

- 88f9d94: fix(types,rest): one named unique-violation predicate — a MySQL conflict is 409 UNIQUE_VIOLATION, not 500 (#6250)

  **On MySQL, every unique-constraint conflict came back as `500 INTERNAL_ERROR`.**
  The API contract registers `UNIQUE_VIOLATION` as a 409 code
  (`packages/spec/src/api/error-code-ledger.zod.ts`), so a front end had no way to
  tell "this email is already taken" from "the server fell over" — no retry advice,
  no field to point at, and a 5xx in the operator's dashboards for what is an
  ordinary client outcome. SQLite and Postgres deployments never saw it, which is
  why it survived: their conflict prose happens to contain the words the mapping
  looked for.

  **Cause: the conflict verdict was nested inside a leak heuristic.** REST's 409
  branch lived inside the true-branch of `looksLikeInternalErrorLeak()`, keyed on
  the substrings `unique constraint` / `unique violation`. MySQL says
  `ER_DUP_ENTRY: Duplicate entry '…' for key '…'`, which matches no limb of that
  heuristic, so the conflict never reached the `if` at all and fell out of the
  terminal `UNCLASSIFIED_FAULT`. Two unrelated questions — "is this a conflict?"
  and "would echoing this text leak internals?" — had been fused into one, and
  MySQL is where they disagree.

  Measured on the previous release, through the real error mapper:

  ```
  mysql,    bare message       500 INTERNAL_ERROR  →  409 UNIQUE_VIOLATION
  mysql,    knex-wrapped SQL   500 DATABASE_ERROR  →  409 UNIQUE_VIOLATION
  postgres, SQLSTATE only      500 INTERNAL_ERROR  →  409 UNIQUE_VIOLATION
  sqlite,   message            409 UNIQUE_VIOLATION   (unchanged)
  postgres, message            409 UNIQUE_VIOLATION   (unchanged)
  ```

  So the hole was never MySQL-only: the mapping read one of the two channels
  drivers use. A Postgres error carrying SQLSTATE `23505` with unremarkable prose
  was a 500 as well.

  **New: `isUniqueViolationError(error)`, exported from `@objectstack/types`.** One
  named predicate replaces the substring test, reading every channel a driver
  uses — `code` (`23505` / `ER_DUP_ENTRY` / `SQLITE_CONSTRAINT_UNIQUE`), `errno`
  (`1062`), the message, and one step down the `cause` chain that pool and
  query-builder layers wrap with. Its vocabulary is the union of the four
  hand-written copies the repo already carried, so routing REST through it cannot
  narrow any verdict clients rely on today; an unrecognised error is never a
  conflict, because a false 409 tells an SDK not to retry and points the user at a
  value that is fine.

  **The internal-leak classifier is byte-identical.** The fix hoists the conflict
  question out of it rather than widening its criteria, so nothing else it guards
  is reclassified as safe-to-expose. And the 409 body is fixed text: MySQL embeds
  the offending user data in its message (`Duplicate entry 'a@b.com' …`) and
  Postgres the index and column names, none of which reaches the client. The full
  driver text still reaches the server log.

  No action needed. Clients that already handled `409 UNIQUE_VIOLATION` on SQLite
  and Postgres now receive it on MySQL too.

- Updated dependencies [3d5c090]
- Updated dependencies [e5bd768]
- Updated dependencies [e027b3e]
- Updated dependencies [c2429b0]
- Updated dependencies [445a0c2]
- Updated dependencies [f6609e6]
- Updated dependencies [a70358a]
- Updated dependencies [97e7e3c]
- Updated dependencies [8828b9e]
- Updated dependencies [53068c1]
- Updated dependencies [ee58392]
- Updated dependencies [f16e54e]
- Updated dependencies [06be54e]
- Updated dependencies [259459d]
- Updated dependencies [3f7f14e]
- Updated dependencies [6968885]
- Updated dependencies [eaed61f]
- Updated dependencies [debe2f6]
- Updated dependencies [97b0798]
- Updated dependencies [43a7a8d]
- Updated dependencies [73f69dc]
- Updated dependencies [04c56aa]
- Updated dependencies [b3efeb7]
- Updated dependencies [ddd075a]
- Updated dependencies [88154be]
- Updated dependencies [e8dc61e]
- Updated dependencies [2f3e793]
- Updated dependencies [d8e8d9c]
- Updated dependencies [94e749b]
- Updated dependencies [ea1d916]
- Updated dependencies [ae31a19]
- Updated dependencies [e0f300b]
- Updated dependencies [62b6a2f]
- Updated dependencies [5b4780b]
- Updated dependencies [a933452]
- Updated dependencies [8140915]
- Updated dependencies [7b48cf9]
- Updated dependencies [b5404f4]
- Updated dependencies [f764691]
- Updated dependencies [e120a5a]
- Updated dependencies [e650d67]
- Updated dependencies [04476e7]
- Updated dependencies [79228cd]
- Updated dependencies [b3363e9]
- Updated dependencies [2ef1807]
- Updated dependencies [d03fe25]
- Updated dependencies [2672f85]
- Updated dependencies [11066f6]
- Updated dependencies [916af17]
- Updated dependencies [84c86fb]
- Updated dependencies [2a2a9fb]
- Updated dependencies [a2e157c]
- Updated dependencies [95c4227]
- Updated dependencies [2a61116]
- Updated dependencies [d4df105]
- Updated dependencies [e2798fa]
- Updated dependencies [0fd8556]
- Updated dependencies [74155c7]
- Updated dependencies [6908830]
- Updated dependencies [8b06bba]
- Updated dependencies [4c54037]
- Updated dependencies [0f7157b]
- Updated dependencies [d9bef45]
- Updated dependencies [f549a0d]
- Updated dependencies [82da264]
- Updated dependencies [9b9b70f]
- Updated dependencies [f5a9bc2]
- Updated dependencies [881a3cc]
- Updated dependencies [ad6317b]
- Updated dependencies [8a88885]
- Updated dependencies [5f7669e]
- Updated dependencies [becbe53]
- Updated dependencies [b127c8b]
- Updated dependencies [a80302a]
- Updated dependencies [474f131]
- Updated dependencies [050cd82]
- Updated dependencies [4d552af]
- Updated dependencies [44d677c]
- Updated dependencies [c32944d]
- Updated dependencies [1dd780f]
- Updated dependencies [c8d6f6e]
- Updated dependencies [92a67f2]
- Updated dependencies [9136327]
- Updated dependencies [bf0ae99]
- Updated dependencies [cb3b6cd]
- Updated dependencies [73b7234]
- Updated dependencies [d2b97c3]
- Updated dependencies [59b794f]
- Updated dependencies [fc3a36a]
- Updated dependencies [69787f0]
- Updated dependencies [5d022a1]
- Updated dependencies [042b9ee]
- Updated dependencies [f549a0d]
- Updated dependencies [a36db28]
- Updated dependencies [3f8817a]
- Updated dependencies [a2443e3]
- Updated dependencies [e1554b1]
- Updated dependencies [4856789]
- Updated dependencies [c3f4916]
- Updated dependencies [33e0385]
- Updated dependencies [2205363]
- Updated dependencies [09fe58d]
- Updated dependencies [d0a5ceb]
- Updated dependencies [e18a162]
- Updated dependencies [d127ff0]
- Updated dependencies [9b86cf6]
- Updated dependencies [8825a06]
- Updated dependencies [5087ac6]
- Updated dependencies [2d1ddf0]
- Updated dependencies [354b00f]
- Updated dependencies [3de535b]
- Updated dependencies [fe2e15a]
- Updated dependencies [c6b6bb4]
- Updated dependencies [2f59da0]
- Updated dependencies [8ad609c]
- Updated dependencies [bbee302]
- Updated dependencies [08863dd]
- Updated dependencies [56664f5]
- Updated dependencies [31cbe90]
- Updated dependencies [90bbf25]
- Updated dependencies [eb91eba]
- Updated dependencies [42da73d]
- Updated dependencies [643b7c7]
- Updated dependencies [1a15893]
- Updated dependencies [b70e534]
- Updated dependencies [2233a85]
- Updated dependencies [62dd69a]
- Updated dependencies [e15e679]
- Updated dependencies [2ab1257]
- Updated dependencies [4cc4fb7]
- Updated dependencies [2c26040]
- Updated dependencies [f758cec]
- Updated dependencies [78f0be8]
- Updated dependencies [35f7fb4]
- Updated dependencies [a5302c7]
- Updated dependencies [7084313]
- Updated dependencies [0e043d8]
- Updated dependencies [dadd1ad]
- Updated dependencies [2f2e63c]
- Updated dependencies [486d526]
- Updated dependencies [89d7b35]
- Updated dependencies [85ec26d]
- Updated dependencies [f6476fc]
- Updated dependencies [4ac12ef]
- Updated dependencies [b88f5e8]
- Updated dependencies [42cc219]
- Updated dependencies [d7e0b42]
- Updated dependencies [3510e4a]
- Updated dependencies [aa4b90d]
- Updated dependencies [54299ca]
- Updated dependencies [dc61def]
- Updated dependencies [251e888]
- Updated dependencies [183b4c4]
- Updated dependencies [2fdb36e]
- Updated dependencies [20526f5]
- Updated dependencies [c5eef1d]
- Updated dependencies [e0f300b]
- Updated dependencies [761a0ba]
- Updated dependencies [be87153]
- Updated dependencies [60f0dd8]
- Updated dependencies [a87c5cd]
- Updated dependencies [a47f338]
- Updated dependencies [2598216]
- Updated dependencies [2c7e62d]
- Updated dependencies [eb7613c]
- Updated dependencies [ecc9110]
- Updated dependencies [f7bd4e2]
- Updated dependencies [361bd5b]
- Updated dependencies [1818998]
- Updated dependencies [09ee21c]
- Updated dependencies [f549a0d]
- Updated dependencies [3fc2e48]
- Updated dependencies [e8f435c]
- Updated dependencies [41610f6]
  - @objectstack/spec@17.0.0-rc.6

## 17.0.0-rc.5

### Patch Changes

- Updated dependencies [e8f8f6c]
- Updated dependencies [7f713b6]
- Updated dependencies [c960170]
- Updated dependencies [def5919]
- Updated dependencies [ce0cfe9]
- Updated dependencies [1363084]
  - @objectstack/spec@17.0.0-rc.5

## 17.0.0-rc.4

### Minor Changes

- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)

  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。

  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
  谁确认的、何时、在哪个姿态下问的),**之后不复问**。

  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
    元数据可以直接重试,不需要先卸载。
  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
    其中一条仍会在剩下的那条上停住。
  - 升级引入的**新**约束会被问,老的答案继续算数。
  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
    `os migrate plan` 的 advisory 形态覆盖。

  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。

  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
  逐条清单而不是一句 "Install failed (409)"。

  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。

  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
  `gen:schema && gen:docs` 再生成,未手改。

  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
  唯一约束**,故无可扫;这是核查结论,不是遗漏。

  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
  drift op 为零。

  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
  `unique: true` 一如既往合法。

- 64cd010: fix(runtime,types)!: `/analytics/query` no longer echoes RLS policy field names — the declared-server-fault withhold is shared by both HTTP boundaries (#5811)

  **Observable behaviour change — read this if you read, log, or assert on
  `error.message` from a dispatcher-plugin route.** An error that **declares a
  server fault** in the ADR-0112 envelope (`status >= 500` _and_ a non-empty
  `code`) now leaves `dispatcher-plugin.errorResponseBase` with its message
  replaced by `"Internal server error"`. It previously reached the caller verbatim
  unless it happened to _sound_ like a SQL/driver dump. This applies to every route
  that plugin mounts — `/analytics`, `/packages`, `/i18n`, `/automation`, `/auth`,
  `/notifications`, `/mcp`, … — not only the one that motivated it. Nothing a
  machine reads changed: the producer's `code` still arrives in the response
  (`error.code`, promoted there from `details` by the shared envelope builder,
  #3842), the status is untouched, and the full original text still goes to the
  server log and `errorReporter` via `__obsRecordedError`.

  ## What was wrong

  #5367 (maintainer ruling 2026-08-06) made `read-scope-sql.ts`'s ten fail-closed
  RLS lowering refusals `READ_SCOPE_COMPILE_FAILED` / 500 and taught
  `POST /analytics/dataset/query` to withhold their message, because those messages
  name the field names and comparands of an **administrator's** sharing rule:

  ```
  [read-scope-sql] unsafe field identifier "secret_policy_field" — refusing to
  build read scope (fail-closed).
  ```

  The caller never wrote that field name and must not be able to read it out of an
  error body. But the **sibling** analytics face was never closed.
  `compileScopedFilterToSql` runs on both `NativeSQLStrategy.applyReadScope` and
  `ObjectQLStrategy`'s echoed SQL, both of which serve `POST /analytics/query`,
  which exits through `dispatcher-plugin.errorResponseBase`. That exit's only
  message guard was `looksLikeInternalErrorLeak` — a heuristic over SQL/driver
  _phrasing_ — and all eleven read-scope message shapes return `false` from it.
  Measured at that boundary: **11 of 11 echoed verbatim**, at 500, with the policy
  content in `error.message`. A real reachable disclosure, not a theoretical one.

  ## What changed

  - **`@objectstack/types` gains `declaresServerFault(err)`**, exported from
    `error-leak.ts` beside `looksLikeInternalErrorLeak`. The heuristic asks whether
    a message _sounds_ internal; the declaration asks whether the producer _said
    so_. `error-leak.ts`'s own file header already states the principle — "do not
    ship driver internals to clients" is a property of the HTTP boundary, not of
    one router — and this is the second predicate that principle asks for.
  - **Both boundaries read it.** `dispatcher-plugin.errorResponseBase` gains the
    withhold (the fix); `rest-server.ts`'s `/analytics/dataset/query` catch drops
    its in-line copy of the same test in favour of the shared one. #5808 wrote that
    rule in-line on purpose — promoting a rule with one consumer is a speculative
    surface — and this is the second consumer, so it was promoted rather than
    duplicated (`#3843`/`#3867` paid for the two-implementations shape twice).
    The REST face's verdict is unchanged in every case: same `status >= 500` plus
    non-empty `code` test, over the same two fields.

  ## What deliberately did NOT change

  - ⛔ **This is not "withhold every 5xx".** #5667 kept **undeclared** 5xx errors
    legible on purpose: a bare `Error` from our own code ("no strategy can handle
    query …") is the operator's own bug report, names nothing tenant-sensitive, and
    still falls to `looksLikeInternalErrorLeak` alone. A 5xx carrying only half an
    envelope (a status with no code) is likewise still readable — inventing the
    withhold for it would be the consumer-side leniency Prime Directive #12 removes.
  - **4xx is untouched.** `declaresServerFault` requires `status >= 500`, so a
    deliberate business/validation answer can never be swallowed by it.
  - **`statusCode` is not accepted as a substitute for `status`.** `status` is the
    channel ADR-0112 declares; making a disclosure rule depend on which spelling a
    producer reached for would be the same leniency in a different place.
  - **The heuristic was not taught to recognise `[read-scope-sql]`.** That would be
    more prose sniffing — the mechanism #5352/#5367 exist to remove — and would only
    ever cover the family someone remembered to add.

  Coverage: `analytics-query-read-scope-withhold.test.ts` (runtime) drives six RLS
  policy shapes end-to-end through a **real** `AnalyticsService` on the real
  native-SQL path and the real mounted route, asserting the 500, that the whole
  serialized body contains no policy detail, that `error.code` still carries
  `READ_SCOPE_COMPILE_FAILED`, and that the full text is still on the
  `__obsRecordedError` side-channel — plus a positive control and both sides of the
  declared-vs-undeclared tiering. `error-leak.test.ts` (types) pins the predicate
  directly, including that all eleven read-scope shapes stay invisible to the
  heuristic. The REST face's existing `analytics-read-scope-refusal-envelope.test.ts`
  is green before and after, unchanged, which is the pin on the refactor.

- 02dc076: feat(types,cli,verify)!: 只解析 host app 声明过的包 —— `NODE_PATH` 不再算数,ADR-0093 D5 那道墙从此与启动方式无关 (#4719)

  **问题:契约写下了,但从没被检查过。** `@objectstack/types/node` 的
  `createHostRequire` 返回一个 CJS `createRequire`,而 CJS 解析认 `NODE_PATH`
  (`Module.globalPaths`)。pnpm 生成的 bin shim 第一件事就是
  `export NODE_PATH=<workspace>/node_modules/.pnpm/node_modules`,于是任何被工作区里
  **任意一个包**传递依赖到的包都能"从 host app 解析成功" —— 跟这个 app 声明了什么毫无关系。

  实测(cloud `apps/objectos-ee`,当时未声明 `@objectstack/organizations`):
  `pnpm start`(经 shim)boot 成功、插件表里有 `Organizations`、ADR-0093 D5 一声不吭;
  `node node_modules/@objectstack/cli/bin/run.js serve`(不经 shim)则
  `✖ FATAL: tenancy posture 'isolated' was requested…` 并 exit 1。同一个 app、同一份
  `package.json`、同一个 posture,**只因为进程是怎么被拉起来的**,走出两种结果。
  而 D5 的报错一直在教 operator "declare it in the app's package.json" —— 那正是
  CLI 从来没检查过的那件事。

  **改法:声明即执行。** 解析前先读 `<hostRoot>/package.json`;只有包名出现在
  `dependencies` / `devDependencies` / `optionalDependencies` / `peerDependencies`
  的 **键**里,才去 host 的 `node_modules` 里查它。仅仅"能被解析到"不再算数 ——
  那正是让契约失效的那个偶然。未声明的包退回到 importing package 自身的解析
  (ESM,不认 `NODE_PATH`),框架自有的包加载路径不受影响。

  **两种失败从此分开报。** 今天它们都塌成同一条 `MODULE_NOT_FOUND`,补救办法却相反:

  - **未声明** —— 指向"在 app 的 `package.json` 里声明并安装",并说明为什么
    hoisting / `NODE_PATH` 不被接受;
  - **声明了但解析不到** —— 明确说这是**安装**问题(`pnpm install`、生产 prune
    砍掉了它、dist 没构建),别再让人回去重看那份已经写对的 `package.json`。

  分类经新导出的 `hostImportFailureKind(err)` 暴露给调用方;两种错误都仍带
  `code: 'MODULE_NOT_FOUND'`,`isModuleNotFoundError` 的既有判定不变。

  **BREAKING — 哪类部署会从假绿变红,以及怎么修。**

  1. **靠 hoisting 苟着的部署。** 一个 app 请求了 walled tenancy posture
     (`OS_TENANCY_POSTURE=group` / `isolated` 或 `OS_MULTI_ORG_ENABLED=1`)、
     却没在自己的 `package.json` 里声明 `@objectstack/organizations`,过去经 pnpm
     shim 启动能正常 boot —— 现在会命中 ADR-0093 D5 并 exit 1。
     **修法:在那个 app 的 `package.json` 里声明该依赖并安装。**
     这些部署本来就在未声明状态下运行,红的是一直存在的事实,不是新引入的故障:
     同一个 app 不经 shim 启动今天就已经是 exit 1。
     (同样适用于 `@objectstack/service-ai` / `@objectstack/service-ai-studio`,以及
     `bootStack({ multiTenant: true })`、dogfood 的 enterprise 门。)

  2. **`createHostImporter` 的签名变了**,因为它现在需要 host 的**根目录**才能读到
     那份 manifest,而一个 `NodeRequire` 无法被问出它锚在哪里:

     ```diff
     - createHostImporter(createHostRequire(hostRoot))
     + createHostImporter(hostRoot)                     // 省略参数 = process.cwd(),同旧默认
     ```

     `createHostRequire` 本身保持不变,仍然导出。

  新增导出(`@objectstack/types/node`):`HOST_DECLARATION_FIELDS`、
  `HostDeclarationField`、`HostDeclaration`、`readHostDeclaration`、
  `isDeclaredByHost`、`packageNameFromSpecifier`、`HostImportFailureKind`、
  `HOST_IMPORT_FAILURE_KIND`、`hostImportFailureKind`。

### Patch Changes

- 08f93bc: fix(auth): `organization/create` gates on the authoritative `OS_TENANCY_POSTURE`, not the demoted `OS_MULTI_ORG_ENABLED` (#5233)

  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
  `group`), legacy boolean unset — mounted the entire organization wall and still
  answered `403 Creating additional organizations is disabled on this deployment.`
  to `POST /api/v1/auth/organization/create`. Org-less users had no way to create
  their workspace, so the guided "Create your workspace" path was a dead end.

  ADR-0105 D1 made `OS_TENANCY_POSTURE` the canonical knob and demoted
  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
  Two sites in `AuthManager` kept reading the demoted boolean directly, so both
  reported "single-org" on a deployment that had asked for a wall and got one:

  - `organizationHooks.beforeCreateOrganization` — the 403 above. It now judges
    `postureEnforcesWall(resolveTenancyPosture())`, matching the knob `serve.ts`'s
    own ADR-0093 D5 boot guard keys on. Intent is unchanged (single-org still
    refuses); only the knob is corrected.
  - `/auth/config`'s `features.multiOrgEnabled` — its no-tenancy-service fallback
    read the same boolean. It now falls back to the resolved posture, so a lean
    embedding advertises the capability its own gate allows.

  **No configuration change is needed anywhere.** Deployments that set only
  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
  workaround people used to unblock themselves stays valid. Deployments that set
  only `OS_TENANCY_POSTURE` can now drop the redundant boolean.

  `resolveMultiOrgEnabled()`'s doc comment in `@objectstack/types` — which still
  instructed "the auth manager's `/auth/config` feature flag and org-create guard
  … MUST call this", written before the demotion — now says the opposite: ask the
  posture, and never gate on this boolean. Its behaviour is unchanged.

- Updated dependencies [9fe9c1d]
- Updated dependencies [d4e0809]
- Updated dependencies [f724f69]
- Updated dependencies [28ad90e]
- Updated dependencies [f8644c7]
- Updated dependencies [306ca50]
- Updated dependencies [978fed2]
- Updated dependencies [cfc293f]
- Updated dependencies [de70b42]
- Updated dependencies [fb3d99b]
- Updated dependencies [cdfbee2]
- Updated dependencies [29c6c9d]
- Updated dependencies [d21c001]
- Updated dependencies [f1cc3a3]
- Updated dependencies [ddc2527]
- Updated dependencies [553a47f]
- Updated dependencies [a3a884d]
- Updated dependencies [cfed092]
- Updated dependencies [2e284b2]
- Updated dependencies [1b49eaf]
- Updated dependencies [0161c7f]
- Updated dependencies [e900015]
- Updated dependencies [b5bdf48]
- Updated dependencies [a019e52]
- Updated dependencies [64fc6d5]
- Updated dependencies [947d4f9]
- Updated dependencies [eaaf03c]
- Updated dependencies [d17df80]
- Updated dependencies [7d0e7b5]
- Updated dependencies [6513c17]
- Updated dependencies [c142ced]
- Updated dependencies [eda599e]
- Updated dependencies [c001422]
- Updated dependencies [77022a9]
- Updated dependencies [52760bf]
- Updated dependencies [5543020]
- Updated dependencies [880d343]
- Updated dependencies [6e82972]
- Updated dependencies [4615a18]
- Updated dependencies [7f62706]
- Updated dependencies [667fa44]
- Updated dependencies [37e38d1]
- Updated dependencies [1eb13a0]
- Updated dependencies [c52e608]
- Updated dependencies [4dfd002]
- Updated dependencies [77be690]
- Updated dependencies [811c30c]
- Updated dependencies [b49ccfd]
- Updated dependencies [85d95e7]
- Updated dependencies [168f60f]
- Updated dependencies [244ca86]
- Updated dependencies [546ab3c]
- Updated dependencies [0b51bb6]
- Updated dependencies [d9971d3]
- Updated dependencies [abeb375]
- Updated dependencies [ef4efa8]
- Updated dependencies [cbb6a5c]
- Updated dependencies [795b6e1]
- Updated dependencies [175d789]
- Updated dependencies [55dbbba]
- Updated dependencies [72c3c86]
- Updated dependencies [7f1a635]
- Updated dependencies [502564d]
- Updated dependencies [471839d]
- Updated dependencies [b508244]
- Updated dependencies [594508e]
- Updated dependencies [1c625ca]
- Updated dependencies [71f205d]
- Updated dependencies [414395b]
- Updated dependencies [26e1029]
- Updated dependencies [108ba8d]
- Updated dependencies [b4ad984]
- Updated dependencies [a9f32df]
- Updated dependencies [aeb9b27]
- Updated dependencies [7d27da0]
- Updated dependencies [089767f]
- Updated dependencies [e4c8b6c]
- Updated dependencies [acb10f6]
- Updated dependencies [1c3da1f]
- Updated dependencies [a34fd2e]
- Updated dependencies [889ae47]
- Updated dependencies [4f4c3fb]
- Updated dependencies [7adc841]
- Updated dependencies [4845f85]
- Updated dependencies [7b005b4]
- Updated dependencies [94f7b6a]
- Updated dependencies [5c94f83]
- Updated dependencies [73e576f]
- Updated dependencies [c5a5996]
- Updated dependencies [ae490ef]
- Updated dependencies [f61c8cf]
- Updated dependencies [e3ef52b]
- Updated dependencies [07f1822]
- Updated dependencies [04fab5e]
- Updated dependencies [efedd28]
- Updated dependencies [5278e11]
- Updated dependencies [23dba62]
- Updated dependencies [ba98e26]
- Updated dependencies [fc5f536]
- Updated dependencies [f8cfbb4]
- Updated dependencies [c89d18c]
- Updated dependencies [aac90a5]
- Updated dependencies [1e6ab15]
- Updated dependencies [c87ef70]
- Updated dependencies [3cb0618]
- Updated dependencies [32a0874]
- Updated dependencies [7055c22]
- Updated dependencies [785a748]
- Updated dependencies [3af0354]
- Updated dependencies [866ff16]
- Updated dependencies [5a85e67]
- Updated dependencies [c183a12]
- Updated dependencies [8064b07]
- Updated dependencies [4a56dbd]
- Updated dependencies [06df4fa]
  - @objectstack/spec@17.0.0-rc.4

## 17.0.0-rc.2

### Minor Changes

- b25a116: fix(verify): resolve the enterprise organizations package from the HOST APP (#4700)

  `bootStack(app, { multiTenant: true })` — and therefore `objectstack verify
--multi-tenant` — could never load `@objectstack/organizations`. Node ESM
  resolves a bare `import()` against the **importer's own realpath**, which for
  `packages/verify` is inside the framework workspace, while the enterprise
  package is cloud-private and only ever lives in the verified app's
  `node_modules`. Every real host app fell into the catch and was told to
  "Install/link it in this workspace" — about a package it had already installed.
  Same defect class as cloud#1013, which fixed `objectstack serve`; #4699 fixed
  that one call site and this issue tracked the two the sweep left behind.

  **New: `@objectstack/types/node`.** The host-app resolver (`createHostRequire` /
  `createHostImporter`) moved out of `packages/cli/src/utils/import-from-host.ts`
  — where `@objectstack/verify` and the dogfood suite could not import it without
  inverting the dependency direction — into a **node-only subpath export** of
  `@objectstack/types`. One behaviour, one source; the CLI now consumes it and its
  private copy is deleted.

  It is a subpath and **not** the root export because `@objectstack/types` is a
  dependency of `@objectstack/hono` ("edge-compatible REST API server for
  Cloudflare Workers, Deno, Bun, and Node") and of the plugin layer a `LiteKernel`
  boots on Workers. The root entry reaches zero `node:` builtins, and a Workers
  bundle breaks on `node:module` even when nothing calls it. `tsup` emits the two
  entries as separate self-contained bundles (`splitting: false`), and a test
  walks the root's import graph and fails on the first reachable `node:`
  specifier, so the isolation is enforced rather than merely intended. Same
  arrangement `@objectstack/metadata` already ships for its `./node` subpath.

  **New: `BootOptions.hostRoot`** (optional, defaults to `process.cwd()`) names
  the app whose `node_modules` supplies those optional packages — for a harness
  booting an app that is not the working directory.

  **The dogfood multi-org gates had never run.** Two suites probed availability
  with the same bare `import()` and so were **constant-false** — not "false
  because absent" but false by construction, in every environment including the
  cloud CI whose comment claimed it ran them. The #1994 cross-tenant RLS proof and
  the attachments cross-tenant isolation block had therefore never executed while
  the suite reported green (Prime Directive #10, test-suite edition). They now
  resolve like the runtime does, and `OS_TEST_MULTI_ORG_ENABLED=1` declares that a
  run is expected to ship the package — turning a silent skip into a loud failure,
  so a run can no longer pass by quietly not running the gates it exists for.

### Patch Changes

- Updated dependencies [430dcc2]
- Updated dependencies [e6ac4bd]
- Updated dependencies [80334c7]
- Updated dependencies [ce5242c]
- Updated dependencies [a7163ea]
- Updated dependencies [e6e9379]
- Updated dependencies [98877c9]
- Updated dependencies [98877c9]
- Updated dependencies [e6b1b69]
- Updated dependencies [ad047d2]
- Updated dependencies [2826d1e]
- Updated dependencies [5a84d41]
- Updated dependencies [20b1a9e]
- Updated dependencies [203a449]
- Updated dependencies [ac37fc6]
- Updated dependencies [4820f55]
- Updated dependencies [462d9c4]
- Updated dependencies [7d21581]
- Updated dependencies [f2445c9]
- Updated dependencies [23338c3]
- Updated dependencies [5b843fb]
- Updated dependencies [b4487aa]
- Updated dependencies [65ca83a]
- Updated dependencies [67bf2e2]
- Updated dependencies [c6d1cb4]
- Updated dependencies [36030ff]
- Updated dependencies [6117f7b]
- Updated dependencies [e533b0b]
- Updated dependencies [cdf4d9a]
- Updated dependencies [aee1806]
- Updated dependencies [c13350b]
- Updated dependencies [c13350b]
- Updated dependencies [9ca2d85]
- Updated dependencies [c13350b]
- Updated dependencies [891d345]
- Updated dependencies [a52e2ef]
- Updated dependencies [5293114]
- Updated dependencies [20bc357]
- Updated dependencies [5966c2a]
- Updated dependencies [2382580]
- Updated dependencies [d9fa683]
- Updated dependencies [3c7bcc0]
- Updated dependencies [4b6cac7]
- Updated dependencies [7631964]
- Updated dependencies [ac471a0]
- Updated dependencies [60ae58e]
- Updated dependencies [ce92674]
- Updated dependencies [9f601e8]
- Updated dependencies [51c5227]
- Updated dependencies [a4a85c8]
- Updated dependencies [07a4e26]
- Updated dependencies [ec975f1]
- Updated dependencies [eb4204b]
- Updated dependencies [4f13be2]
- Updated dependencies [61cc079]
- Updated dependencies [0e96e46]
- Updated dependencies [d52d4fe]
- Updated dependencies [742cebb]
- Updated dependencies [ce92674]
- Updated dependencies [cf2c9b7]
- Updated dependencies [0f9faa2]
- Updated dependencies [7cf42fe]
- Updated dependencies [5966c2a]
- Updated dependencies [f78dd83]
- Updated dependencies [a2cd18a]
- Updated dependencies [4638aaa]
- Updated dependencies [0222d3c]
- Updated dependencies [0a936ea]
- Updated dependencies [023c00b]
- Updated dependencies [155507e]
- Updated dependencies [7bba90b]
- Updated dependencies [7e05d8e]
- Updated dependencies [061406d]
- Updated dependencies [c1f344b]
- Updated dependencies [9c93465]
- Updated dependencies [ebb209c]
- Updated dependencies [63b33e6]
- Updated dependencies [2a44c1d]
- Updated dependencies [695cfbd]
- Updated dependencies [7445149]
- Updated dependencies [071d0dc]
- Updated dependencies [0848bea]
- Updated dependencies [d51bed2]
- Updated dependencies [b8b3c64]
- Updated dependencies [0c0fbd9]
- Updated dependencies [f3141d8]
- Updated dependencies [5a84d41]
- Updated dependencies [fd3013a]
- Updated dependencies [21676eb]
- Updated dependencies [e336549]
- Updated dependencies [d40f43a]
- Updated dependencies [e5e7ee0]
- Updated dependencies [a2ebea2]
- Updated dependencies [800bdb0]
- Updated dependencies [04f1182]
- Updated dependencies [5647006]
- Updated dependencies [38f7e4f]
- Updated dependencies [c57f3cf]
- Updated dependencies [97faca3]
- Updated dependencies [ad5fe25]
- Updated dependencies [ea90179]
- Updated dependencies [ce92674]
- Updated dependencies [5ef0b5b]
- Updated dependencies [48fbacb]
- Updated dependencies [355e951]
- Updated dependencies [dadb43f]
  - @objectstack/spec@17.0.0-rc.2

## 17.0.0-rc.1

### Minor Changes

- 2a37694: fix(plugin-dev,types): the production escape hatch stops being silent (#3900)

  `DevPlugin.init()` refuses to run under `NODE_ENV=production` (ADR-0115 D6), and
  `OS_ALLOW_DEV_PLUGIN` overrides that refusal. As shipped, the override returned
  early with **no output at all**: the process ran the development assembly while
  every log line and the ready banner read like an ordinary production start.

  That reproduces, one level up, the defect the guard exists to close. The guard's
  own precedent says so — `OS_ALLOW_DEGRADED_TENANCY` boots degraded _and brands
  it everywhere an operator looks_, and `OS_ALLOW_DRIVER_CONNECT_FAILURE`'s
  contract is "logged loudly at startup". An escape hatch that says nothing leaves
  the operator's only evidence of a degraded state in an env var they may not have
  set themselves.

  **The override now brands itself, twice.** A warning at `init()` — emitted
  before any assembly work, so it survives an assembly step that later throws —
  and a repeat on the ready banner, which is the surface an operator actually
  reads:

  ```
  ⚠ DEV ASSEMBLY UNDER NODE_ENV=production (OS_ALLOW_DEV_PLUGIN is set) — the boot
    guard was explicitly overridden. This process is running the DEVELOPMENT
    assembly, which is not hardened for production traffic (ADR-0115 D6).
      • Auth secret is the default published inside @objectstack/plugin-dev. It is
        public, so anyone can mint a session this stack accepts. Pass `authSecret`
        explicitly.
      • Data goes to the in-memory driver with persistence disabled — every record
        is lost when this process exits.
  ```

  Only hazards that are live for _that_ configuration are named: the secret line
  is suppressed when the operator passed their own `authSecret`, and the driver
  line when the `driver` toggle is off. The dev-admin seed is deliberately absent
  — `plugin-auth`'s `maybeSeedDevAdmin` is hard-gated to
  `NODE_ENV === 'development'` and cannot fire on this path, so warning about it
  would spend the attention the real hazards need.

  **New export — `resolveAllowDevPlugin()` (`@objectstack/types`).** The flag moves
  off a bare `process.env['OS_ALLOW_DEV_PLUGIN'] === '1'` and joins the
  `OS_ALLOW_*` family's shared truthy vocabulary, next to
  `resolveAllowDegradedTenancy` / `resolveAllowDriverConnectFailure`.

  FROM → TO for operators: `OS_ALLOW_DEV_PLUGIN=1` keeps working unchanged.
  `OS_ALLOW_DEV_PLUGIN=true` (and `on` / `yes`, case-insensitive, surrounding
  whitespace ignored) **now takes effect** where the strict comparison previously
  ignored it and failed the boot. That is a widening, in the direction an operator
  setting the flag already intended; falsy and unrecognised values still refuse to
  boot, and unset still means "fail fast". If you were relying on
  `OS_ALLOW_DEV_PLUGIN=true` being inert as a way to keep the guard armed, unset
  the variable instead.

  No change to the refusal path, which this issue re-verified end to end:
  `kernel.use()` only registers, `initPluginWithTimeout` does not catch,
  `bootstrap()` rethrows, and `os serve`'s outer handler prints the message and
  exits `1`. The `throw` is genuinely fatal here, so it needs none of the
  `process.exit(1)` the tenancy guard required for sitting inside a broad `catch`.

- d5749d7: refactor(types,rest,services,plugin-sharing): one shared writer for the response envelope, and `error.code` is enforced at compile time (#3973)

  `BaseResponseSchema` declares one envelope for every REST body the platform
  emits. It declared it once; the code that _wrote_ it was copied per route
  module. After #3843 and #3983 converted the last drifting one, seven modules
  each carried their own two-line `sendOk` / `sendError` pair — so the envelope's
  shape lived in fourteen places rather than one.

  `pnpm check:route-envelope` proved those seven copies agreed, which is why this
  is a cleanup rather than a bug fix. But a guard proves agreement; it does not
  create it. An eighth module starts by copying the pair again — not
  hypothetically: `share-link-routes.ts` was found already drifting by the
  repo-wide scan, and its drift had broken `client.shareLinks.create()` and
  `.list()` through `unwrapResponse` (#3983).

  ## What moved

  `sendOk` / `sendError` now live once, in `@objectstack/types`
  (`response-envelope.ts`), and all seven modules import them:

  | Module                                |
  | ------------------------------------- |
  | `service-storage/storage-routes.ts`   |
  | `service-settings/settings-routes.ts` |
  | `service-datasource/admin-routes.ts`  |
  | `rest/external-datasource-routes.ts`  |
  | `rest/package-routes.ts`              |
  | `service-i18n/i18n-service-plugin.ts` |
  | `plugin-sharing/share-link-routes.ts` |

  Placement was the open question in #3973, not design. `packages/spec` is
  schemas-only (Prime Directive #2), and the callers span `rest`, four
  `services/*` and one `plugins/*`, which rules out anything depending on them.
  `@objectstack/types` depends on nothing but `@objectstack/spec`, so every caller
  can reach it, and it is already where the repo puts a helper the HTTP boundaries
  share — `looksLikeInternalErrorLeak` (#3867) sits one file over and made the
  same argument first.

  The builders take a structural `{ status(n), json(body) }`, so the package
  imports no HTTP contract at all: `IHttpResponse` satisfies it, and so does the
  `any`-typed `res` the older modules carry.

  ## `error.code` is now checked by the compiler

  All seven copies typed the parameter `code: string`. ADR-0112 (#3841) closed the
  vocabulary — `ErrorCode` is `StandardErrorCode ∪ ERROR_CODE_LEDGER` — but an
  invented code was still caught only at runtime, by a conformance suite parsing a
  driven body, i.e. only on routes some test happened to drive.

  The shared `sendError` types `code` as `ErrorCode`, so an unregistered code now
  fails to compile, at every call site at once:

  ```ts
  sendError(res, 400, "NOT_A_REGISTERED_CODE", "invented");
  // Argument of type '"NOT_A_REGISTERED_CODE"' is not assignable to parameter of type 'ErrorCode'.
  ```

  This cost no call-site churn: every code the seven modules emit was already
  registered.

  ## `extra` is closed at the same place

  `sendError`'s last parameter is `Pick<ApiError, 'category' | 'httpStatus' |
'details' | 'requestId'>` — exactly what `ApiErrorSchema` declares beside `code`
  and `message`.

  It was `Record<string, unknown>` while `settings-routes` still hung `namespace` /
  `key` / `reason` / `fields` beside `code`. Those bodies passed every gate anyway:
  `ApiErrorSchema` is a plain `z.object`, so unknown keys were STRIPPED rather than
  rejected, and `envelopeViolations` inspects only the body's top level —
  conformant _by stripping_ rather than by declaration. #4224 moved that module
  onto `details`, which is what lets the parameter close here. Closing it at the
  shared builder is the part that lasts: an undeclared sibling is now a compile
  error in every module at once, rather than a key that quietly evaporates in
  whichever module reintroduces it.

  ## Nothing changes on the wire

  The seven pairs were identical modulo the optional `status` and `extra`
  parameters this one unions, and each module's driven conformance suite still
  parses its real bodies against the real spec schemas. One internal call site was
  rewritten: `package-routes` passed `details` positionally and now passes
  `{ details }`, producing the same `error.details` it always did.

  ## The guard got stronger

  `scripts/check-route-envelope.mjs` counts response write sites per module. A
  module that routes everything through the shared pair builds **none** itself, so
  the seven now declare `0 / 0 / 0` where they used to declare `2 / 1 / 1`, and the
  shared pair is pinned separately at `2 / 1 / 1` so the invariant stays total for
  the surface rather than per-module. What the count asserts is no longer "your two
  builders are the enveloped ones" but "you have no builders" — and a new route
  that hand-rolls a body still moves it off zero and fails.

### Patch Changes

- 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.

- c20b875: **Correct the stale premise left behind by #4012: the degraded-boot stderr copy
  survives the operator's LOG LEVEL, not `os serve`'s boot-quiet window.**

  `emitDegradedBootBanner` writes the `OS_ALLOW_DRIVER_CONNECT_FAILURE` banner to
  stderr in addition to `logger.warn`, and every comment and test name explaining
  why cited the same reason: `os serve` swallowed all of stdout while the kernel
  booted, and `Logger` routes `warn` to stdout. #4012 fixed that — the boot window
  now buffers and replays `warn`-and-above — which retires the _stated_
  justification for a duplicate that is nonetheless still load-bearing:

  `Logger.write()` returns before touching a stream when the record is below
  `config.level`, so at `--log-level error`, `fatal` or `silent` the banner's
  `logger.warn` reaches **no** stream at all. A production host at `error` is
  exactly the deployment this escape hatch exists for, and exactly where a
  logger-only banner would vanish. Removing the stderr copy on the strength of
  #4012 would therefore have been a regression — so this documents the reason that
  is still true, in the places someone would read before deleting it:
  `degraded-boot.ts`, the engine's emit site, and all three parity tests
  (objectql, runtime, service-datasource), which are renamed off "which `os serve`
  boot-quiet cannot swallow" to "which the operator log level cannot filter away".

  The objectql parity test now proves the claim instead of asserting around it: it
  drives a **real** `ObjectLogger` at `level: 'error'` and requires the banner on
  stderr _and_ nothing on stdout. Set the level to `warn` and it fails — so the
  test is pinned to the level filter rather than passing for any reason.

  Also corrected in the same sweep, all comment-only, all previously overstating
  what #4012 had not yet fixed:

  - the automation wiring summary (`format.ts`, `serve.ts`, its test) claimed the
    boot window swallowed the engine's binding warnings. Its real justification is
    stronger and unchanged: a flow that silently fails to arm emits **no** log line
    at any level, so binding state has to be read off the live engine — absence of
    a warning was never evidence of a bound flow.
  - the seed summary (`seed-summary.ts`, `format.ts`, its test) and `AppPlugin`'s
    seed-outcome note attributed the silence to the boot window; the operative
    gate is that `SeedLoader`'s result logs are `info`, under the default `warn`.

  No behavior changes.

- 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.

- 39eb01b: fix(runtime,cli,types): `os migrate` and the dev runtime now share one `__search` companion schema view (#3955)

  On a zh-locale deployment the dev runtime provisions the hidden `__search`
  pinyin companion column (ADR-0098) on every eligible object, but the
  `os migrate plan`/`apply` boot went through `createStandaloneStack`, which
  never derived the locale-gated pinyin decision from the compiled artifact.
  Its metadata therefore lacked every companion column, and `migrate plan`
  reported each live `__search` column of a dev-created database as a
  destructive orphan — with `--allow-destructive` as the printed remediation,
  which would have dropped live feature columns.

  - `@objectstack/types`: new `collectConfiguredLocales(i18n)` and
    `stampSearchPinyinEnabled(i18n)` — the single resolve-and-stamp helper for
    `OS_SEARCH_PINYIN_ENABLED`. An explicit env value still wins; only a
    positive locale-derived decision is stamped.
  - `@objectstack/runtime`: `createStandaloneStack` stamps the decision from
    the artifact's `i18n` before any plugin constructs a `SchemaRegistry`, and
    surfaces `i18n` on its result like `requires`/`objects`/`manifest`.
  - `@objectstack/cli`: the `serve`/`dev` boot now stamps through the same
    shared helper (behaviour unchanged), so create/serve and plan/apply cannot
    compute different schema views of the same source tree.

  A fresh CLI-created database is now also born with the same `__search`
  columns the dev runtime would provision, instead of acquiring them on the
  next dev boot.

- 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 [12a19a8]
- Updated dependencies [41dcda3]
- Updated dependencies [c8124e5]
- Updated dependencies [a1a4140]
- 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 [c1d44f7]
- Updated dependencies [ab9fb5c]
- Updated dependencies [f985b3f]
- Updated dependencies [9a4932a]
- Updated dependencies [f9fc874]
- Updated dependencies [011b386]
- Updated dependencies [7777e8f]
- Updated dependencies [507b92a]
- Updated dependencies [7309c81]
- Updated dependencies [20bc1ec]
- Updated dependencies [90c2b15]
- Updated dependencies [42eeb7d]
- Updated dependencies [01e124d]
- Updated dependencies [7ce02eb]
- Updated dependencies [a13827e]
- Updated dependencies [7733604]
- Updated dependencies [40e420f]
- Updated dependencies [d13004a]
- 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 [65a3a84]
- Updated dependencies [ccd9397]
- Updated dependencies [bca935b]
- 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 [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 [8b50cb3]
- Updated dependencies [8c2db68]
- Updated dependencies [22b5e54]
- Updated dependencies [0166bd5]
- Updated dependencies [9b702dc]
- Updated dependencies [ab16331]
  - @objectstack/spec@17.0.0-rc.1

## 17.0.0-rc.0

### Minor Changes

- 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.

- 840ee4b: fix(analytics,runtime,types): gate cube auto-inference on object existence; stop the dispatcher boundary returning raw SQL (#3867)

  Two independent defects on the `/analytics` surface, found while verifying #3770
  against a real server. On an authenticated CRM dev server, before this change:

  ```
  POST /api/v1/analytics/query {"cube":"sqlite_master","measures":["count"],"dimensions":["type"]}
  → 200 {"rows":[{"type":"index","count":262},{"type":"table","count":71},{"type":"view","count":1}],
         "sql":"SELECT type AS \"type\", COUNT(*) AS \"count\" FROM \"sqlite_master\" GROUP BY type"}
  ```

  That is SQLite's internal schema table — never a registered object — read
  successfully through the analytics endpoint. Not merely "the name reaches the
  driver and errors": **any table the connection can see was readable.**

  **① The cube name reached the driver as a table name.** `AnalyticsService.ensureCube`
  auto-infers a minimal Cube when none is registered, with `cube.sql = <the queried
name>`. That is the intended "metric over an object" path — an `object-metric` KPI
  widget queries `crm_account` with no authored Cube — but it accepted _any_ string,
  so the endpoint could aggregate over an arbitrary physical table. The
  analytics-side twin of the data-path gap #3770 closed, and it was not covered by
  that fix: #3770 gated the protocol's `analyticsQuery`, which is the _degraded
  fallback_; a deployment with `@objectstack/service-analytics` installed runs the
  real engine instead (`ctx.replaceService`).

  Inference is now gated on the same schema registry the data path consults, via a
  new optional `AnalyticsServiceConfig.isRegisteredObject` that `plugin.ts` wires
  from the `data` engine's `getObject`. Three-way rule: a registered Cube runs
  untouched (its `sql` is whatever it declares); an unregistered name that IS an
  object still auto-infers exactly as before; neither → `CUBE_NOT_FOUND` / 404
  raised before any SQL exists, naming both ways to make the request valid. With no
  probe configured the gate stands down and warns once — the same tiering #3770
  took for a missing registry. `generateSql` (`/analytics/sql`) is gated too.

  **② The dispatcher boundary returned `err.message` verbatim.** `errorResponseBase`
  is the single error exit for _every_ route the dispatcher plugin mounts —
  `/analytics`, `/packages`, `/i18n`, `/storage`, `/automation`, `/auth`,
  `/notifications`, `/mcp`. `@objectstack/rest` has guarded its data routes against
  driver dumps forever (`mapDataError`); this boundary guarded nothing, so any
  driver error on any of those routes shipped its SQL to the client. Unlike ①, this
  half is unconditional — it does not depend on the cube being invalid.

  The leak heuristic moved out of `rest-server.ts` into `@objectstack/types` as
  `looksLikeInternalErrorLeak` (both packages already depend on it) and is now
  applied at both boundaries — one predicate, one place to widen when a new
  dialect's phrasing shows up. `mapDataError`'s behaviour is unchanged. At the
  dispatcher it applies **only to 5xx**: a 4xx message is a deliberate
  business/validation answer and must reach the caller intact. Sanitising costs no
  diagnostics — the untouched error still reaches `errorReporter` through the
  existing `__obsRecordedError` side-channel.

  **Also fixed in the same function:** `errorResponseBase` read only
  `err.statusCode`, while domain errors across this codebase carry `status` (and
  `HttpDispatcher.errorFromThrown` already reads `status` first). Every deliberate
  4xx thrown through a dispatcher route — including #3770's `OBJECT_NOT_FOUND` on
  the analytics fallback path — was rendered as a **500**. It now reads `status`
  then `statusCode`.

  **Behaviour change.** `/analytics/query` and `/analytics/sql` return 404
  `CUBE_NOT_FOUND` for a cube that is neither registered nor a registered object;
  previously the name was passed to the driver. Dashboards and KPI widgets pointed
  at real objects or authored cubes are unaffected. A 5xx on a dispatcher route
  whose message looks like a driver dump now reads `Internal server error` — check
  server logs or your error reporter for the original.

- 030125b: feat(objectql)!: `init()` refuses to boot when a data driver fails to connect (#3741)

  `ObjectQLEngine.init()` wrapped every driver's `connect()` in a try/catch, logged
  one error line, and carried on. A server whose database was unreachable therefore
  "started successfully" — health endpoints could even stay green — and then failed
  every request with an error that reads nothing like _the database is down_. The
  warning it printed (`Operations may recover via lazy reconnection or fail at query
time`) was half fiction: grep the repo and no reconnection exists in `driver-sql`
  or `driver-mongodb`, so only the "fail at query time" half was ever real. The
  caller made it worse — `ObjectQLPlugin.start()` runs `syncRegisteredSchemas()`
  immediately after `init()`, issuing DDL against a driver that isn't there.

  The structural half of the bug was worse than the operational one: the catch
  removed a driver's ability to **refuse startup at all**. Any fatal startup check —
  licence, server version, incompatible configuration, missing capability, not just
  an unreachable socket — is expressed by throwing from `connect()`, and every one
  of them was silently downgraded to a runtime error. That is why driver-mongodb's
  multi-tenancy guard (#3724 / #3734) had to be hoisted into its constructor.

  - `init()` now **throws** `DriverConnectError` (`code: 'ERR_DRIVER_CONNECT'`)
    when any boot-registered driver's `connect()` rejects, aborting kernel
    bootstrap. It still attempts every driver first, so one failed boot names all
    of them. The message is self-contained — each failed driver and its cause —
    because the CLI prints `error.message` alone; the first cause is also attached
    as `error.cause`. Exported from both `@objectstack/objectql` and
    `@objectstack/objectql/core`.
  - `connect()` is now a supported place for a driver to veto boot. Startup
    validation that needs a live connection (server version, capability probes)
    no longer has to be forced into a constructor.
  - The misleading "lazy reconnection" warning is gone.
  - New escape hatch `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`
    (`resolveAllowDriverConnectFailure()` in `@objectstack/types`) restores the old
    lenient boot, but loudly: a `DEGRADED BOOT` banner names the failed drivers and
    states that they are never retried or reconnected and that every query and
    schema sync routed to them will fail for the process lifetime. The banner goes
    to stderr as well as the logger, because `os serve` swallows all of stdout
    during boot and `Logger` routes `warn` there — logger-only, the one message
    that matters would be invisible in exactly the deployment the flag is for.
    Defaults off.

  **Migration.** No code or config change is needed for a correctly configured
  deployment — a driver that connected before still connects. A deployment that was
  _silently_ booting without its database now fails the boot instead, with the
  driver name and cause in the error; fix the datasource configuration (typically
  `OS_DATABASE_URL`, credentials, or network reachability). To keep booting without
  it — deliberately, and knowing every request that touches it will fail — set
  `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`.

### Patch Changes

- 87aca93: fix(datasource)!: a declared datasource that objects bind to must connect, or the boot fails (#3758)

  `DatasourceConnectionService.handleFailure()` fail-fasted only for an `external`
  datasource with `validation.onMismatch: 'fail'`. Everything else degraded to one
  `warn` line — including the case the D2 auto-connect gate itself flags as having
  **no fallback path**: a datasource that objects bind to explicitly via
  `object.datasource`. Those objects never fall through to the `default` driver;
  `engine.getDriver` throws `Datasource 'x' is not registered` for them.

  So an app declaring `datasource: 'analytics'` with 20 objects bound to it, booted
  against a wrong `ANALYTICS_URL`, started clean and exited zero — and then failed
  every read and write of those 20 objects with an error that reads nothing like
  _the analytics database is unreachable_. The rest of the app worked, which made it
  **harder** to locate than a total outage: it looks like "some pages are broken",
  not like a misconfigured datasource. This is the same decision #3741/#3751 fixed
  one layer up in `ObjectQLEngine.init()`; the boundary here was still drawn in the
  old place.

  - **Fail-fast is now keyed on "no fallback path", not on `onMismatch` alone.** At
    the `declared-auto` (boot) trigger, a connect failure aborts the boot when the
    datasource is `external` + `onMismatch: 'fail'` **or** when ≥1 object binds to
    it explicitly. `autoConnect: true` with nothing bound stays lenient — that is
    "connect it if you can", and nothing declares a dependency on it. The
    runtime-admin create/update and boot-rehydration triggers are unchanged and
    still always degrade: a UI action must never brick a running server.
  - **Every failure mode counts**, not just an unreachable socket: an unresolvable
    `external.credentialsRef` (D3) and an unsupported `driver` leave the bound
    objects exactly as dead, so they take the same verdict.
  - **The error names the bound objects** (up to 10, then `+N more`) alongside the
    underlying cause, so the message points at the real problem instead of just the
    datasource name. The service already receives the list for post-connect
    `syncObjectSchema`.
  - **`connectDeclared()` attempts every gated datasource before throwing**, and
    aggregates, so one failed boot reports all the misconfigured ones rather than
    one per restart — the same shape as `ObjectQLEngine.init()`'s
    `DriverConnectError`.
  - **The escape hatch is shared with the engine guard**:
    `OS_ALLOW_DRIVER_CONNECT_FAILURE=1` now also covers this path (and covers
    `onMismatch: 'fail'`, which previously had no opt-out). The operator intent is
    identical — "I know the database is unreachable, boot anyway" — and two flags
    would only guarantee one of them gets missed. When set, boot continues and a
    `DEGRADED BOOT` banner goes to stderr as well as the logger, because `os serve`
    swallows stdout during boot. `emitDegradedBootBanner` moved to
    `@objectstack/types` so both call sites share one implementation;
    `@objectstack/objectql` re-exports it unchanged.

  ADR-0062 D5 is amended with the new criterion and the shared flag.

  **Migration.** No change for a correctly configured deployment — a datasource that
  connected before still connects. A deployment that was _silently_ booting with a
  dead, explicitly-bound datasource now fails the boot instead, naming the
  datasource, the cause, and the objects that depend on it; fix the datasource
  configuration. To keep booting without it — deliberately, knowing every request
  touching those objects will fail — set `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`.

- 32d3800: fix(driver-sql): bound a connection attempt at 10s, and correct the "no reconnection" claim (#3769, #3759)

  Two related corrections, both from measuring what #3741/#3751/#3765 had only asserted.

  **The claim was wrong.** #3751 and #3765 shipped several statements that drivers
  never reconnect — "there is no lazy reconnection", "NOT retried and NOT
  reconnected", "stays disconnected for the process lifetime". Measured, both
  drivers recover on their own:

  - driver-mongodb: killing a real `mongod` and restarting it on the same port,
    the _same_ driver instance served the next write successfully (13ms), with no
    reconnect call from us — the official driver's topology monitor handles it.
  - driver-sql: a knex/pg pool is not poisoned by an outage. Its error tracks live
    server state (`ECONNREFUSED` while down → a handshake error once a listener is
    back → `ECONNREFUSED` again), i.e. every acquire opens a fresh connection.
    `storage-driver.ts` also configures `pool.min: 0`, so no stale idle
    connections are held.

  The original reasoning grepped this repo for `reconnect`, found nothing, and
  concluded recovery does not happen — but the recovery lives in the client
  libraries, not in our code. The claims are now corrected in `DriverConnectError`,
  the `DEGRADED BOOT` banner, `resolveAllowDriverConnectFailure`'s docs, and the
  drivers / self-hosting pages.

  **Fail-fast at boot is unchanged and still correct** — the reason is just
  different. It is not that the connection can never return; it is that the _boot
  sequence_ never re-runs. A driver that missed `init()` also missed
  `syncRegisteredSchemas()`, so its tables can simply not exist even after the
  database comes back. The banner now says that.

  **The real defect underneath.** `SqlDriver` passed its config to knex untouched,
  so a database endpoint that accepts TCP but never completes the handshake — an
  overloaded instance, a half-open firewall, a load balancer mid-failover — made
  every query wait out tarn's 30s default, then fail with `Timeout acquiring a
connection. The pool is probably full`, pointing an operator at pool sizing
  instead of the network. With a small `pool.max` a few such queries saturate the
  pool and everything else queues.

  `SqlDriver` now defaults `pool.createTimeoutMillis` to **10s**, matching
  driver-mongodb's existing `connectTimeoutMS ?? 10_000` so both drivers give up on
  an unreachable server at the same point. A host that sets its own
  `createTimeoutMillis` is left alone.

  **Migration.** None for a healthy datasource. A deployment that deliberately
  relies on connection establishment taking longer than 10s (a slow cross-region
  replica) should set `pool.createTimeoutMillis` explicitly on its `SqlDriver`
  config.

  Not fixed here, tracked in #3769: knex still reports the bounded wait as "the
  pool is probably full". An accurate message needs a dialect-specific connect
  timeout (pg's `connectionTimeoutMillis`), which changes the shape of `connection`
  and would regress the startup banner's URL display.

- 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 [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 [1d4756e]
- Updated dependencies [720c5ad]
- Updated dependencies [a8d1e24]
- 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 [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 [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 [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 [11949fc]
- Updated dependencies [b098b0e]
- Updated dependencies [4d00b13]
- 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

## 16.1.0

### Patch Changes

- Updated dependencies [9e45b63]
  - @objectstack/spec@16.1.0

## 16.0.0

### Minor Changes

- 83e8f7d: feat(mcp): decouple the stdio auto-start switch from the HTTP surface + surface the MCP endpoint on `os dev` boot (#3167)

  The MCP HTTP surface (`/api/v1/mcp`) and the long-lived stdio transport used to
  share one env var: `OS_MCP_SERVER_ENABLED=true` turned the HTTP surface on **and**
  silently auto-started the stdio transport — which bridges the raw metadata service

  - data engine with no per-request principal (unscoped). An operator setting it to
    "make sure MCP is on" got an unscoped transport as a side effect.

  * **`@objectstack/types`** — new `resolveMcpStdioAutoStart()`. Stdio auto-start is
    now its own switch, `OS_MCP_STDIO_ENABLED` (default off); `OS_MCP_SERVER_ENABLED`
    governs only the HTTP surface. The legacy `OS_MCP_SERVER_ENABLED=true` trigger
    still starts stdio for one release, flagged as deprecated. `=false` is unchanged
    (it only ever gated HTTP).
  * **`@objectstack/mcp`** — `MCPServerPlugin.start()` gates stdio on the new switch
    and logs a one-time deprecation warning when started via the legacy alias.
  * **`@objectstack/cli`** — `os dev` now prints the MCP endpoint, the agent-skill
    URL, and a ready-to-paste `claude mcp add` command on boot (gated on the HTTP
    surface being on), so the "an agent operates the app it's building" loop is
    discoverable at dev time.
  * **`create-objectstack`** — the blank scaffold README documents that the app is
    itself an MCP server (the serve side), distinct from the consume-side connector.

- 92f5f19: feat(runtime): sandbox budget is script CPU-time, not wall clock (ADR-0102 D1, #3295)

  The QuickJS sandbox now meters each hook/action invocation against how much
  **VM-active (CPU) time** the body burns, not wall clock. Idle host-await time and
  a nested hook's own execution (which runs host-side while the caller's VM is
  parked) are no longer charged to the caller — so a slow/loaded host or a deep
  nested-write chain can't trip the budget while a script is merely waiting (the
  root cause of the #3259 CI flake). A separate, generous **wall-clock ceiling**
  (default 30s, `max(ceiling, cpuBudget)`) remains as the backstop for a body stuck
  on a host call that never settles.

  What changes for consumers (behaviour, not API signatures):

  - **Meaning of the timeout knobs.** `body.timeoutMs`, the `hookTimeoutMs` /
    `actionTimeoutMs` runner options, and `OS_SANDBOX_HOOK_TIMEOUT_MS` /
    `OS_SANDBOX_ACTION_TIMEOUT_MS` keep their **names, defaults (250ms / 5000ms),
    and precedence** — but now bound CPU-time instead of wall-clock. In practice
    this only _loosens_ legitimate slow/nested work; a runaway synchronous script
    is still cut at the same budget.
  - **Error messages.** `exceeded timeout of Nms` → either `exceeded CPU budget of
Nms` (script burned its CPU budget) or `exceeded wall-clock ceiling of Nms
while awaiting host calls` (stuck on a never-settling host call). Update any
    code/tests matching the old string.

  New knobs (additive):

  - `QuickJSScriptRunner` option `wallCeilingMs` and env `OS_SANDBOX_WALL_CEILING_MS`
    — tune the wall ceiling (explicit option › env › 30s).
  - `resolveSandboxTimeoutMs` (`@objectstack/types`) gains a `'wallCeiling'` kind.

  Also fixes a latent init bug in the new accounting where the interrupt handler
  could fire during `installCtx` and corrupt ctx marshalling. The nested-write
  integration suites now run at the stock 250ms budget (previously forced to 10s),
  which is itself the regression guard for the nested-charging fix.

- 32899e6: feat(runtime): env-overridable sandbox hook/action timeout default (#3259)

  The QuickJS sandbox enforces a wall-clock deadline on every hook/action
  invocation (250ms hooks / 5000ms actions). Each invocation compiles a fresh
  WASM module, and a nested hook compiles ANOTHER one inside the parent's budget,
  so on a heavily loaded or slow host — an oversubscribed CI runner, constrained
  production hardware — that fixed VM-creation cost alone can trip the hook
  default even while the VM is still making progress. On CI this surfaced as an
  intermittent `hook '…' exceeded timeout of 250ms` flake on PRs that never
  touched the sandbox path.

  The per-invocation timeout DEFAULT is now resolvable from the environment via
  `resolveSandboxTimeoutMs` (`@objectstack/types`), which `QuickJSScriptRunner`
  consults, so an operator can raise the floor once, deployment-wide, instead of
  re-tuning every call site:

  - `OS_SANDBOX_HOOK_TIMEOUT_MS` — default hook budget (ms)
  - `OS_SANDBOX_ACTION_TIMEOUT_MS` — default action budget (ms)

  Precedence is unchanged: an explicit `hookTimeoutMs` / `actionTimeoutMs` passed
  to the runner still wins over the env var, and a body's own declared `timeoutMs`
  still wins over the resolved default (the smaller of the explicit values). Only
  a positive integer is honored; unset / empty / non-numeric / non-positive keeps
  the built-in 250ms / 5000ms defaults, so behaviour is byte-for-byte unchanged
  when the vars are absent — production is unaffected unless it opts in.

  CI's Test Core now sets `OS_SANDBOX_HOOK_TIMEOUT_MS=10000` so the shared-runner
  load flake can't recur; genuine hangs stay bounded by each test's own timeout.

### Patch Changes

- Updated dependencies [f972574]
- Updated dependencies [6289ec3]
- Updated dependencies [22013aa]
- Updated dependencies [3ad3dd5]
- Updated dependencies [8efa395]
- Updated dependencies [3a18b60]
- Updated dependencies [a8aa34c]
- Updated dependencies [a3823b2]
- Updated dependencies [43a3efb]
- Updated dependencies [524696a]
- Updated dependencies [bfa3c3f]
- Updated dependencies [5e3301d]
- Updated dependencies [46e876c]
- Updated dependencies [158aa14]
- Updated dependencies [62a2117]
- Updated dependencies [d2723e2]
- Updated dependencies [fefcd54]
- Updated dependencies [beaf2de]
- Updated dependencies [369eb6e]
- Updated dependencies [06ff734]
- Updated dependencies [b659111]
- Updated dependencies [5754a23]
- Updated dependencies [6c270a6]
- Updated dependencies [668dd17]
- Updated dependencies [8abf133]
- Updated dependencies [e0859b1]
- Updated dependencies [04ecd4e]
- Updated dependencies [4d5a892]
- Updated dependencies [16cebeb]
- Updated dependencies [86d30af]
- Updated dependencies [8923843]
- Updated dependencies [a2795f6]
- Updated dependencies [f16b492]
- Updated dependencies [4b6fde8]
- Updated dependencies [2018df9]
- Updated dependencies [fc5a3a2]
- Updated dependencies [8ff9210]
  - @objectstack/spec@16.0.0

## 16.0.0-rc.1

### Patch Changes

- Updated dependencies [6289ec3]
- Updated dependencies [8efa395]
- Updated dependencies [bfa3c3f]
- Updated dependencies [62a2117]
- Updated dependencies [06ff734]
  - @objectstack/spec@16.0.0-rc.1

## 16.0.0-rc.0

### Minor Changes

- 83e8f7d: feat(mcp): decouple the stdio auto-start switch from the HTTP surface + surface the MCP endpoint on `os dev` boot (#3167)

  The MCP HTTP surface (`/api/v1/mcp`) and the long-lived stdio transport used to
  share one env var: `OS_MCP_SERVER_ENABLED=true` turned the HTTP surface on **and**
  silently auto-started the stdio transport — which bridges the raw metadata service

  - data engine with no per-request principal (unscoped). An operator setting it to
    "make sure MCP is on" got an unscoped transport as a side effect.

  * **`@objectstack/types`** — new `resolveMcpStdioAutoStart()`. Stdio auto-start is
    now its own switch, `OS_MCP_STDIO_ENABLED` (default off); `OS_MCP_SERVER_ENABLED`
    governs only the HTTP surface. The legacy `OS_MCP_SERVER_ENABLED=true` trigger
    still starts stdio for one release, flagged as deprecated. `=false` is unchanged
    (it only ever gated HTTP).
  * **`@objectstack/mcp`** — `MCPServerPlugin.start()` gates stdio on the new switch
    and logs a one-time deprecation warning when started via the legacy alias.
  * **`@objectstack/cli`** — `os dev` now prints the MCP endpoint, the agent-skill
    URL, and a ready-to-paste `claude mcp add` command on boot (gated on the HTTP
    surface being on), so the "an agent operates the app it's building" loop is
    discoverable at dev time.
  * **`create-objectstack`** — the blank scaffold README documents that the app is
    itself an MCP server (the serve side), distinct from the consume-side connector.

- 92f5f19: feat(runtime): sandbox budget is script CPU-time, not wall clock (ADR-0102 D1, #3295)

  The QuickJS sandbox now meters each hook/action invocation against how much
  **VM-active (CPU) time** the body burns, not wall clock. Idle host-await time and
  a nested hook's own execution (which runs host-side while the caller's VM is
  parked) are no longer charged to the caller — so a slow/loaded host or a deep
  nested-write chain can't trip the budget while a script is merely waiting (the
  root cause of the #3259 CI flake). A separate, generous **wall-clock ceiling**
  (default 30s, `max(ceiling, cpuBudget)`) remains as the backstop for a body stuck
  on a host call that never settles.

  What changes for consumers (behaviour, not API signatures):

  - **Meaning of the timeout knobs.** `body.timeoutMs`, the `hookTimeoutMs` /
    `actionTimeoutMs` runner options, and `OS_SANDBOX_HOOK_TIMEOUT_MS` /
    `OS_SANDBOX_ACTION_TIMEOUT_MS` keep their **names, defaults (250ms / 5000ms),
    and precedence** — but now bound CPU-time instead of wall-clock. In practice
    this only _loosens_ legitimate slow/nested work; a runaway synchronous script
    is still cut at the same budget.
  - **Error messages.** `exceeded timeout of Nms` → either `exceeded CPU budget of
Nms` (script burned its CPU budget) or `exceeded wall-clock ceiling of Nms
while awaiting host calls` (stuck on a never-settling host call). Update any
    code/tests matching the old string.

  New knobs (additive):

  - `QuickJSScriptRunner` option `wallCeilingMs` and env `OS_SANDBOX_WALL_CEILING_MS`
    — tune the wall ceiling (explicit option › env › 30s).
  - `resolveSandboxTimeoutMs` (`@objectstack/types`) gains a `'wallCeiling'` kind.

  Also fixes a latent init bug in the new accounting where the interrupt handler
  could fire during `installCtx` and corrupt ctx marshalling. The nested-write
  integration suites now run at the stock 250ms budget (previously forced to 10s),
  which is itself the regression guard for the nested-charging fix.

- 32899e6: feat(runtime): env-overridable sandbox hook/action timeout default (#3259)

  The QuickJS sandbox enforces a wall-clock deadline on every hook/action
  invocation (250ms hooks / 5000ms actions). Each invocation compiles a fresh
  WASM module, and a nested hook compiles ANOTHER one inside the parent's budget,
  so on a heavily loaded or slow host — an oversubscribed CI runner, constrained
  production hardware — that fixed VM-creation cost alone can trip the hook
  default even while the VM is still making progress. On CI this surfaced as an
  intermittent `hook '…' exceeded timeout of 250ms` flake on PRs that never
  touched the sandbox path.

  The per-invocation timeout DEFAULT is now resolvable from the environment via
  `resolveSandboxTimeoutMs` (`@objectstack/types`), which `QuickJSScriptRunner`
  consults, so an operator can raise the floor once, deployment-wide, instead of
  re-tuning every call site:

  - `OS_SANDBOX_HOOK_TIMEOUT_MS` — default hook budget (ms)
  - `OS_SANDBOX_ACTION_TIMEOUT_MS` — default action budget (ms)

  Precedence is unchanged: an explicit `hookTimeoutMs` / `actionTimeoutMs` passed
  to the runner still wins over the env var, and a body's own declared `timeoutMs`
  still wins over the resolved default (the smaller of the explicit values). Only
  a positive integer is honored; unset / empty / non-numeric / non-positive keeps
  the built-in 250ms / 5000ms defaults, so behaviour is byte-for-byte unchanged
  when the vars are absent — production is unaffected unless it opts in.

  CI's Test Core now sets `OS_SANDBOX_HOOK_TIMEOUT_MS=10000` so the shared-runner
  load flake can't recur; genuine hangs stay bounded by each test's own timeout.

### Patch Changes

- Updated dependencies [f972574]
- Updated dependencies [22013aa]
- Updated dependencies [3ad3dd5]
- Updated dependencies [3a18b60]
- Updated dependencies [a8aa34c]
- Updated dependencies [a3823b2]
- Updated dependencies [43a3efb]
- Updated dependencies [524696a]
- Updated dependencies [5e3301d]
- Updated dependencies [46e876c]
- Updated dependencies [158aa14]
- Updated dependencies [d2723e2]
- Updated dependencies [fefcd54]
- Updated dependencies [beaf2de]
- Updated dependencies [369eb6e]
- Updated dependencies [b659111]
- Updated dependencies [5754a23]
- Updated dependencies [6c270a6]
- Updated dependencies [668dd17]
- Updated dependencies [8abf133]
- Updated dependencies [e0859b1]
- Updated dependencies [04ecd4e]
- Updated dependencies [4d5a892]
- Updated dependencies [16cebeb]
- Updated dependencies [86d30af]
- Updated dependencies [8923843]
- Updated dependencies [a2795f6]
- Updated dependencies [f16b492]
- Updated dependencies [4b6fde8]
- Updated dependencies [2018df9]
- Updated dependencies [fc5a3a2]
  - @objectstack/spec@16.0.0-rc.0

## 15.1.1

### Patch Changes

- @objectstack/spec@15.1.1

## 15.1.0

### Minor Changes

- f531a26: Generic pinyin search recall (#2486, ADR-0098): a locale-gated
  `OS_SEARCH_PINYIN_ENABLED` switch (auto-on when the stack configures any
  `zh-*` locale) provisions a hidden `__search` companion column for each
  object's display/name field at compile time, the new
  `@objectstack/plugin-pinyin-search` fills it with full pinyin + initials
  ("张伟" → "zhangwei zw") on before-save (plus boot backfill and a
  `rebuildSearchCompanion` reconcile entry), and `$search` ORs the column in at
  query time — so lookup pickers, list quick-search and ⌘K transparently match
  `zhangwei` / `zw` against CJK names. Purely additive: `resolveSearchFields`,
  `searchableFields`, drivers and non-Chinese deployments are untouched; FLS
  restricted / secret / PII fields never feed the companion.

### Patch Changes

- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [3fe9df1]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [4109153]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [627f225]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
- Updated dependencies [f531a26]
  - @objectstack/spec@15.1.0

## 15.0.0

### Patch Changes

- Updated dependencies [28b7c28]
- Updated dependencies [13749ec]
- Updated dependencies [e62c233]
- Updated dependencies [ed61c9b]
- Updated dependencies [31d04d4]
  - @objectstack/spec@15.0.0

## 14.8.0

### Patch Changes

- Updated dependencies [16b4bf6]
- Updated dependencies [16b4bf6]
- Updated dependencies [10e8983]
- Updated dependencies [607aaf4]
- Updated dependencies [bb71321]
  - @objectstack/spec@14.8.0

## 14.7.0

### Minor Changes

- 824a395: Tenancy mode as a first-class capability + a single owner for the user→membership
  lifecycle (ADR-0093, Phases 1–3).

  **Tenancy service (`@objectstack/types`, `@objectstack/plugin-auth`).** plugin-auth
  registers a `tenancy` service — the single source of truth for tenancy mode
  (`mode`, `isolationActive`, `requested`, `degraded`, `defaultOrgId()`). It derives
  `isolationActive` from the presence of the `org-scoping` service, so the
  enterprise `@objectstack/organizations` package lights it up with no change.
  SecurityPlugin's RLS-strip gate and `/auth/config` (`features.multiOrgEnabled`,
  new `features.degradedTenancy`) now consume it instead of re-deriving the fact.

  **Fail-fast on degraded tenancy (`@objectstack/cli`, ADR-0093 D5).**
  `OS_MULTI_ORG_ENABLED=true` without a working `@objectstack/organizations` now
  **refuses to boot** — a deployment that requested tenant isolation must not serve
  traffic without it (tenant RLS would be silently stripped). Escape hatch:
  `OS_ALLOW_DEGRADED_TENANCY=1` boots in an explicitly branded degraded state
  (`features.degradedTenancy`). **This may halt upgrades for deployments that were
  silently degraded — intentionally; install the enterprise package or set the
  escape hatch.**

  **Membership reconciler (`@objectstack/plugin-auth`, ADR-0093 D1–D3, D6).** A
  single reconciler composed into better-auth's `user.create.after` hook owns the
  "every new user gets a membership" invariant across all creation paths (signup,
  admin create-user, import, SSO JIT). It yields to any existing membership (host
  hooks win), honors a new `membershipPolicy: 'auto' | 'invite-only'` auth option
  (default `auto`), and binds only to an unambiguous target org (single-org default;
  multi-org binds nothing). A bounded, idempotent `kernel:ready` backfill covers
  pre-existing member-less users in single-org/auto deployments
  (`OS_SKIP_MEMBERSHIP_BACKFILL=1` to opt out). The endpoint-level create-user bind
  from #2882 now delegates to this shared reconciler.

  New env vars: `OS_ALLOW_DEGRADED_TENANCY`, `OS_SKIP_MEMBERSHIP_BACKFILL`. New docs:
  Deployment → Tenancy Modes & Membership.

### Patch Changes

- Updated dependencies [d6a72eb]
  - @objectstack/spec@14.7.0

## 14.6.0

### Patch Changes

- Updated dependencies [609cb13]
- Updated dependencies [ce6d151]
  - @objectstack/spec@14.6.0

## 14.5.0

### Patch Changes

- Updated dependencies [526805e]
- Updated dependencies [d79ca07]
- Updated dependencies [33ebd34]
- Updated dependencies [c044f08]
- Updated dependencies [01274eb]
  - @objectstack/spec@14.5.0

## 14.4.0

### Patch Changes

- Updated dependencies [7953832]
- Updated dependencies [82e745e]
- Updated dependencies [f3035bd]
- Updated dependencies [82c0d94]
- Updated dependencies [7449476]
  - @objectstack/spec@14.4.0

## 14.3.0

### Patch Changes

- Updated dependencies [2a71f48]
- Updated dependencies [02f6af4]
- Updated dependencies [c1064f1]
  - @objectstack/spec@14.3.0

## 14.2.0

### Patch Changes

- Updated dependencies [ac8f029]
- Updated dependencies [4ab9958]
  - @objectstack/spec@14.2.0

## 14.1.0

### Patch Changes

- Updated dependencies [5a8465f]
- Updated dependencies [7f8620b]
- Updated dependencies [82ba3a6]
  - @objectstack/spec@14.1.0

## 14.0.0

### Patch Changes

- Updated dependencies [0a8e685]
- Updated dependencies [afa8115]
- Updated dependencies [80f12ca]
- Updated dependencies [e2fa074]
- Updated dependencies [23c8668]
- Updated dependencies [29f017d]
- Updated dependencies [216fa9a]
- Updated dependencies [6c22b12]
  - @objectstack/spec@14.0.0

## 13.0.0

### Minor Changes

- 57b89b4: feat(mcp): the MCP surface is now **default-on** — a core platform capability (#2698)

  `/api/v1/mcp` is served (and advertised in `/discovery`) out of the box; the
  OAuth 2.1 authorization track and Dynamic Client Registration follow it, so a
  fresh deployment is connectable by any MCP client with zero configuration.
  Operators opt OUT with `OS_MCP_SERVER_ENABLED=false`.

  - New single decision point `isMcpServerEnabled()` in `@objectstack/types`
    (default on; explicit `false`/`0`/`off`/`no` disables). The runtime
    dispatcher's `/mcp` route gate, the CLI's MCP plugin auto-load, the REST
    `/discovery` advertisement, and the auth service's OAuth/DCR follow-defaults
    all delegate to it — the served route, the advertised route, and the
    authorization track can never disagree.
  - The env var is now effectively tri-state: unset → HTTP surface on;
    explicit `true` → additionally auto-start the long-lived **stdio** transport
    at boot (unchanged, still opt-in — a default must not claim the process's
    stdin/stdout); explicit `false` → everything off, fail-closed (404, no
    metadata, no DCR).
  - The OAuth 2.1 TLS rule is unaffected: on a plain-HTTP non-loopback origin
    the OAuth track stays dark and the default-on surface remains API-key-only.

### Patch Changes

- Updated dependencies [6d83431]
- Updated dependencies [01917c2]
- Updated dependencies [b271691]
- Updated dependencies [a5a1e41]
- Updated dependencies [466adf6]
- Updated dependencies [5be00c3]
- Updated dependencies [466adf6]
- Updated dependencies [2bee609]
- Updated dependencies [fc7e7f7]
  - @objectstack/spec@13.0.0

## 12.6.0

### Patch Changes

- Updated dependencies [6cebf22]
  - @objectstack/spec@12.6.0

## 12.5.0

### Patch Changes

- Updated dependencies [8b3d363]
  - @objectstack/spec@12.5.0

## 12.4.0

### Patch Changes

- Updated dependencies [60dc3ba]
  - @objectstack/spec@12.4.0

## 12.3.0

### Patch Changes

- Updated dependencies [e7eceec]
  - @objectstack/spec@12.3.0

## 12.2.0

### Patch Changes

- Updated dependencies [fce8ff4]
- Updated dependencies [3962023]
- Updated dependencies [2bb193d]
- Updated dependencies [0426d27]
- Updated dependencies [da807f7]
  - @objectstack/spec@12.2.0

## 12.1.0

### Patch Changes

- Updated dependencies [93e6d02]
  - @objectstack/spec@12.1.0

## 12.0.0

### Patch Changes

- Updated dependencies [a8df396]
- Updated dependencies [e695fe0]
- Updated dependencies [7c09621]
- Updated dependencies [7709db4]
- Updated dependencies [2082109]
- Updated dependencies [7c09621]
- Updated dependencies [9860de4]
- Updated dependencies [069c205]
  - @objectstack/spec@12.0.0

## 11.10.0

### Patch Changes

- Updated dependencies [6a9397e]
- Updated dependencies [c0efe5d]
  - @objectstack/spec@11.10.0

## 11.9.0

### Patch Changes

- Updated dependencies [d3595d9]
  - @objectstack/spec@11.9.0

## 11.8.0

### Patch Changes

- @objectstack/spec@11.8.0

## 11.7.0

### Patch Changes

- Updated dependencies [5178906]
  - @objectstack/spec@11.7.0

## 11.6.0

### Patch Changes

- @objectstack/spec@11.6.0

## 11.5.0

### Patch Changes

- Updated dependencies [6ee4f04]
- Updated dependencies [c1e3a65]
  - @objectstack/spec@11.5.0

## 11.4.0

### Patch Changes

- Updated dependencies [5821c51]
- Updated dependencies [a0fce3f]
  - @objectstack/spec@11.4.0

## 11.3.0

### Patch Changes

- Updated dependencies [58e8e31]
- Updated dependencies [b4a5df0]
  - @objectstack/spec@11.3.0

## 11.2.0

### Patch Changes

- Updated dependencies [d0f4b13]
- Updated dependencies [302bdab]
  - @objectstack/spec@11.2.0

## 11.1.0

### Minor Changes

- fdb41c0: Remove ObjectStack's own legacy env-var aliases (11.0); ecosystem-standard names stay.

  The framework's renamed env vars no longer accept their old ObjectStack names —
  rename them:

  | removed legacy name                 | use                    |
  | ----------------------------------- | ---------------------- |
  | `OS_MULTI_TENANT`                   | `OS_MULTI_ORG_ENABLED` |
  | `OBJECTSTACK_METADATA_WRITABLE`     | `OS_METADATA_WRITABLE` |
  | `OS_AUTH_BASE_URL`, `AUTH_BASE_URL` | `OS_AUTH_URL`          |

  **Ecosystem-standard names are NOT removed** — they remain accepted (and no longer
  emit a deprecation warning, since they are permanent conventions, not legacy):
  `DATABASE_URL`, `AUTH_SECRET`, `BETTER_AUTH_SECRET`, `BETTER_AUTH_URL`, `PORT`,
  `CORS_*`, `LOG_LEVEL`, `ROOT_DOMAIN`, `MCP_SERVER_*`. The generic
  `readEnvWithDeprecation` helper is unchanged.

### Patch Changes

- Updated dependencies [ecf193f]
- Updated dependencies [51bec81]
- Updated dependencies [3e593a7]
- Updated dependencies [63d5403]
  - @objectstack/spec@11.1.0

## 11.0.0

### Patch Changes

- 795b6d1: refactor: single-source the multi-org (`OS_MULTI_ORG_ENABLED`) flag resolution

  "Is this deployment multi-org?" was resolved in 10 places across 8 packages
  with three subtly different inline expressions:

  - the canonical `String(readEnvWithDeprecation('OS_MULTI_ORG_ENABLED',
'OS_MULTI_TENANT') ?? 'false').toLowerCase() !== 'false'` (objectql registry,
    plugin-dev, runtime app-plugin, cli serve/verify, cloud-connection),
  - a redundant `env.OS_MULTI_ORG_ENABLED !== undefined ? … : …` variant in
    plugin-auth (auth-manager `/auth/config` features + `beforeCreateOrganization`
    guard),
  - and a bare `process.env.OS_MULTI_ORG_ENABLED ?? process.env.OS_MULTI_TENANT`
    read in the SQL driver's `isMultiTenantMode()` — which skipped the
    `OS_MULTI_TENANT` deprecation warning every other site emits.

  Because the SQL driver computed the mode independently of the auth/security
  layer, the driver's tenant-audit gate and the rest of the system could in
  principle disagree about whether tenant isolation is active.

  Introduces `resolveMultiOrgEnabled()` in `@objectstack/types` (next to
  `readEnvWithDeprecation`, the natural leaf dependency) as the single source of
  truth, and routes all 10 sites through it. `@objectstack/driver-sql` gains a
  direct `@objectstack/types` dependency (previously it read `process.env`
  directly).

  Behaviour is unchanged everywhere except the SQL driver, which now also emits
  the one-shot `OS_MULTI_TENANT`-is-deprecated warning — consistent with every
  other site. This mirrors the `resolveAuthzContext` single-source pattern in
  `@objectstack/core`. Follow-up (not in this change): a lint gate forbidding new
  inline reads of these env vars outside the helper.

- Updated dependencies [ab5718a]
- Updated dependencies [4845c12]
- Updated dependencies [c1a754a]
- Updated dependencies [6fbe91f]
- Updated dependencies [715d667]
- Updated dependencies [5eef4cf]
- Updated dependencies [72759e1]
- Updated dependencies [6c4fbd9]
- Updated dependencies [ef3ed67]
- Updated dependencies [cd51229]
- Updated dependencies [7697a0e]
- Updated dependencies [e7e04f1]
- Updated dependencies [cfd5ac4]
- Updated dependencies [2be5c1f]
- Updated dependencies [ad143ce]
- Updated dependencies [5c4a8c8]
- Updated dependencies [3afaeed]
- Updated dependencies [8801c02]
- Updated dependencies [3d04e06]
- Updated dependencies [4a84c98]
- Updated dependencies [d980f0d]
- Updated dependencies [a658523]
- Updated dependencies [82ff91c]
- Updated dependencies [638f472]
  - @objectstack/spec@11.0.0

## 10.3.0

### Patch Changes

- @objectstack/spec@10.3.0

## 10.2.0

### Patch Changes

- Updated dependencies [b496498]
  - @objectstack/spec@10.2.0

## 10.1.0

### Patch Changes

- Updated dependencies [49da36e]
- Updated dependencies [ac79f16]
  - @objectstack/spec@10.1.0

## 10.0.0

### Patch Changes

- Updated dependencies [d7ff626]
- Updated dependencies [2a1b16b]
- Updated dependencies [e16f2a8]
- Updated dependencies [e411a82]
- Updated dependencies [a581385]
- Updated dependencies [220ce5b]
- Updated dependencies [3efe334]
- Updated dependencies [feead7e]
- Updated dependencies [6ca20b3]
- Updated dependencies [5f875fe]
- Updated dependencies [b469950]
  - @objectstack/spec@10.0.0

## 9.11.0

### Patch Changes

- Updated dependencies [e7f6539]
- Updated dependencies [2365d07]
- Updated dependencies [6595b53]
- Updated dependencies [fa8964d]
- Updated dependencies [36138c7]
- Updated dependencies [a8e4f3b]
- Updated dependencies [4c213c2]
- Updated dependencies [2afb612]
  - @objectstack/spec@9.11.0

## 9.10.0

### Patch Changes

- Updated dependencies [db02bd5]
- Updated dependencies [641675d]
- Updated dependencies [94e9040]
- Updated dependencies [1f88fd9]
- Updated dependencies [1f88fd9]
  - @objectstack/spec@9.10.0

## 9.9.1

### Patch Changes

- @objectstack/spec@9.9.1

## 9.9.0

### Patch Changes

- Updated dependencies [84249a4]
- Updated dependencies [11af299]
- Updated dependencies [d5774b5]
- Updated dependencies [134043a]
- Updated dependencies [90108e0]
- Updated dependencies [9afeb2d]
- Updated dependencies [6bec07e]
- Updated dependencies [601cc11]
- Updated dependencies [575448d]
  - @objectstack/spec@9.9.0

## 9.8.0

### Patch Changes

- Updated dependencies [97c55b3]
- Updated dependencies [1b1f490]
  - @objectstack/spec@9.8.0

## 9.7.0

### Patch Changes

- @objectstack/spec@9.7.0

## 9.6.0

### Patch Changes

- Updated dependencies [d1e930a]
- Updated dependencies [71578f2]
- Updated dependencies [5e3a301]
- Updated dependencies [5db2742]
  - @objectstack/spec@9.6.0

## 9.5.1

### Patch Changes

- Updated dependencies [ee72aae]
  - @objectstack/spec@9.5.1

## 9.5.0

### Patch Changes

- Updated dependencies [d08551c]
- Updated dependencies [707aeed]
- Updated dependencies [7a103d4]
- Updated dependencies [4b01250]
  - @objectstack/spec@9.5.0

## 9.4.0

### Patch Changes

- Updated dependencies [060467a]
- Updated dependencies [0856476]
- Updated dependencies [b678d8c]
- Updated dependencies [b678d8c]
- Updated dependencies [b678d8c]
  - @objectstack/spec@9.4.0

## 9.3.0

### Patch Changes

- Updated dependencies [1ada658]
- Updated dependencies [3219191]
- Updated dependencies [290f631]
- Updated dependencies [50b7b47]
- Updated dependencies [f15d6f6]
- Updated dependencies [f8684ea]
- Updated dependencies [b4765be]
  - @objectstack/spec@9.3.0

## 9.2.0

### Patch Changes

- Updated dependencies [2f57b75]
- Updated dependencies [2f57b75]
  - @objectstack/spec@9.2.0

## 9.1.0

### Patch Changes

- Updated dependencies [b9062c9]
  - @objectstack/spec@9.1.0

## 9.0.1

### Patch Changes

- Updated dependencies [1817845]
  - @objectstack/spec@9.0.1

## 9.0.0

### Patch Changes

- Updated dependencies [4c3f693]
- Updated dependencies [0bf39f1]
- Updated dependencies [f533f42]
- Updated dependencies [1c83ee8]
  - @objectstack/spec@9.0.0

## 8.0.1

### Patch Changes

- @objectstack/spec@8.0.1

## 8.0.0

### Patch Changes

- Updated dependencies [a46c017]
- Updated dependencies [b990b89]
- Updated dependencies [99111ec]
- Updated dependencies [d5a8161]
- Updated dependencies [5cf1f1b]
- Updated dependencies [9ef89d4]
- Updated dependencies [3306d2f]
- Updated dependencies [bc44195]
- Updated dependencies [9e2e229]
  - @objectstack/spec@8.0.0

## 7.9.0

### Patch Changes

- @objectstack/spec@7.9.0

## 7.8.0

### Patch Changes

- Updated dependencies [06f2bbb]
- Updated dependencies [36719db]
- Updated dependencies [424ab26]
  - @objectstack/spec@7.8.0

## 7.7.0

### Patch Changes

- Updated dependencies [b391955]
- Updated dependencies [f06b64e]
- Updated dependencies [023bf93]
  - @objectstack/spec@7.7.0

## 7.6.0

### Patch Changes

- Updated dependencies [955d4c8]
- Updated dependencies [c4a4cbd]
- Updated dependencies [b046ec2]
- Updated dependencies [2170ad9]
- Updated dependencies [02d6359]
- Updated dependencies [7648242]
- Updated dependencies [8fa1e7f]
- Updated dependencies [55866f5]
- Updated dependencies [60f9c45]
  - @objectstack/spec@7.6.0

## 7.5.0

### Patch Changes

- @objectstack/spec@7.5.0

## 7.4.1

### Patch Changes

- @objectstack/spec@7.4.1

## 7.4.0

### Patch Changes

- Updated dependencies [23c7107]
- Updated dependencies [c72daad]
- Updated dependencies [f115182]
- Updated dependencies [2faf9f2]
- Updated dependencies [2faf9f2]
- Updated dependencies [2faf9f2]
- Updated dependencies [58b450b]
- Updated dependencies [82eb6cf]
- Updated dependencies [13d8653]
- Updated dependencies [ff3d006]
- Updated dependencies [5e831de]
  - @objectstack/spec@7.4.0

## 7.3.0

### Patch Changes

- Updated dependencies [5e7c554]
  - @objectstack/spec@7.3.0

## 7.2.1

### Patch Changes

- 9096dfe: **`OS_` env-var prefix migration** (issue #1382).

  All ObjectStack-owned environment variables now use the `OS_` prefix. Legacy
  names still work for one release and emit a one-shot deprecation warning via
  the new `readEnvWithDeprecation()` helper in `@objectstack/types`.

  **Renamed (with legacy fallback):**

  | New                       | Legacy (deprecated)                                    |
  | :------------------------ | :----------------------------------------------------- |
  | `OS_AUTH_SECRET`          | `AUTH_SECRET`, `BETTER_AUTH_SECRET`                    |
  | `OS_AUTH_URL`             | `AUTH_BASE_URL`, `BETTER_AUTH_URL`, `OS_AUTH_BASE_URL` |
  | `OS_PORT`                 | `PORT`                                                 |
  | `OS_DATABASE_URL`         | `DATABASE_URL`                                         |
  | `OS_ROOT_DOMAIN`          | `ROOT_DOMAIN`                                          |
  | `OS_MULTI_ORG_ENABLED`    | `OS_MULTI_TENANT`                                      |
  | `OS_CORS_ENABLED`         | `CORS_ENABLED`                                         |
  | `OS_CORS_ORIGIN`          | `CORS_ORIGIN`                                          |
  | `OS_CORS_CREDENTIALS`     | `CORS_CREDENTIALS`                                     |
  | `OS_CORS_MAX_AGE`         | `CORS_MAX_AGE`                                         |
  | `OS_AI_MODEL`             | `AI_MODEL`                                             |
  | `OS_MCP_SERVER_ENABLED`   | `MCP_SERVER_ENABLED`                                   |
  | `OS_MCP_SERVER_NAME`      | `MCP_SERVER_NAME`                                      |
  | `OS_MCP_SERVER_TRANSPORT` | `MCP_SERVER_TRANSPORT`                                 |
  | `OS_NODE_ID`              | `OBJECTSTACK_NODE_ID`                                  |
  | `OS_METADATA_WRITABLE`    | `OBJECTSTACK_METADATA_WRITABLE`                        |
  | `OS_DEV_CRYPTO_KEY`       | `OBJECTSTACK_DEV_CRYPTO_KEY`                           |
  | `OS_HOME`                 | `OBJECTSTACK_HOME`                                     |

  **Migration:** rename in your `.env`. Legacy names continue to work this
  release and will be removed in a future major. Industry-standard names
  (`NODE_ENV`, `HOME`, `OPENAI_API_KEY`, `TURSO_*`, OAuth
  `*_CLIENT_ID/SECRET`, `RESEND_API_KEY`, `POSTMARK_TOKEN`,
  `AI_GATEWAY_*`, `SMTP_*`) are NOT renamed.

  - @objectstack/spec@7.2.1

## 7.2.0

### Patch Changes

- @objectstack/spec@7.2.0

## 7.1.0

### Patch Changes

- Updated dependencies [47a92f4]
  - @objectstack/spec@7.1.0

## 7.0.0

### Patch Changes

- Updated dependencies [74470ad]
- Updated dependencies [d29617e]
- Updated dependencies [dc72172]
  - @objectstack/spec@7.0.0

## 6.9.0

### Patch Changes

- @objectstack/spec@6.9.0

## 6.8.1

### Patch Changes

- @objectstack/spec@6.8.1

## 6.8.0

### Patch Changes

- Updated dependencies [6e88f77]
- Updated dependencies [c8b9f57]
  - @objectstack/spec@6.8.0

## 6.7.1

### Patch Changes

- @objectstack/spec@6.7.1

## 6.7.0

### Patch Changes

- Updated dependencies [430067b]
- Updated dependencies [4f9e9d4]
  - @objectstack/spec@6.7.0

## 6.6.0

### Patch Changes

- Updated dependencies [a49cfc2]
  - @objectstack/spec@6.6.0

## 6.5.1

### Patch Changes

- @objectstack/spec@6.5.1

## 6.5.0

### Patch Changes

- @objectstack/spec@6.5.0

## 6.4.0

### Patch Changes

- Updated dependencies [f8651cc]
- Updated dependencies [f8651cc]
- Updated dependencies [0bf6f9a]
  - @objectstack/spec@6.4.0

## 6.3.0

### Patch Changes

- @objectstack/spec@6.3.0

## 6.2.0

### Patch Changes

- Updated dependencies [b4c74a9]
  - @objectstack/spec@6.2.0

## 6.1.1

### Patch Changes

- @objectstack/spec@6.1.1

## 6.1.0

### Patch Changes

- Updated dependencies [93c0589]
  - @objectstack/spec@6.1.0

## 6.0.0

### Patch Changes

- Updated dependencies [629a716]
- Updated dependencies [dbc4f7d]
- Updated dependencies [944f187]
  - @objectstack/spec@6.0.0

## 5.2.0

### Patch Changes

- Updated dependencies [bab2b20]
- Updated dependencies [fa011d8]
- Updated dependencies [b806f58]
  - @objectstack/spec@5.2.0

## 5.1.0

### Patch Changes

- Updated dependencies [75f4ee6]
- Updated dependencies [823d559]
  - @objectstack/spec@5.1.0

## 5.0.0

### Patch Changes

- Updated dependencies [2f9073a]
  - @objectstack/spec@5.0.0

## 4.2.0

### Patch Changes

- Updated dependencies [2869891]
  - @objectstack/spec@4.2.0

## 4.1.1

### Patch Changes

- @objectstack/spec@4.1.1

## 4.1.0

### Patch Changes

- Updated dependencies [2108c30]
- Updated dependencies [23db640]
  - @objectstack/spec@4.1.0

## 4.0.5

### Patch Changes

- 15e0df6: chore: unify all package versions to a single patch release
- Updated dependencies [15e0df6]
  - @objectstack/spec@4.0.5

## 4.0.4

### Patch Changes

- Updated dependencies [326b66b]
  - @objectstack/spec@4.0.4

## 4.0.3

### Patch Changes

- @objectstack/spec@4.0.3

## 4.0.2

### Patch Changes

- Updated dependencies [5f659e9]
  - @objectstack/spec@4.0.2

## 4.0.0

### Patch Changes

- Updated dependencies [f08ffc3]
- Updated dependencies [e0b0a78]
  - @objectstack/spec@4.0.0

## 3.3.1

### Patch Changes

- @objectstack/spec@3.3.1

## 3.3.0

### Patch Changes

- @objectstack/spec@3.3.0

## 3.2.9

### Patch Changes

- @objectstack/spec@3.2.9

## 3.2.8

### Patch Changes

- @objectstack/spec@3.2.8

## 3.2.7

### Patch Changes

- @objectstack/spec@3.2.7

## 3.2.6

### Patch Changes

- @objectstack/spec@3.2.6

## 3.2.5

### Patch Changes

- @objectstack/spec@3.2.5

## 3.2.4

### Patch Changes

- @objectstack/spec@3.2.4

## 3.2.3

### Patch Changes

- @objectstack/spec@3.2.3

## 3.2.2

### Patch Changes

- Updated dependencies [46defbb]
  - @objectstack/spec@3.2.2

## 3.2.1

### Patch Changes

- Updated dependencies [850b546]
  - @objectstack/spec@3.2.1

## 3.2.0

### Patch Changes

- Updated dependencies [5901c29]
  - @objectstack/spec@3.2.0

## 3.1.1

### Patch Changes

- Updated dependencies [953d667]
  - @objectstack/spec@3.1.1

## 3.1.0

### Patch Changes

- Updated dependencies [0088830]
  - @objectstack/spec@3.1.0

## 3.0.11

### Patch Changes

- Updated dependencies [92d9d99]
  - @objectstack/spec@3.0.11

## 3.0.10

### Patch Changes

- Updated dependencies [d1e5d31]
  - @objectstack/spec@3.0.10

## 3.0.9

### Patch Changes

- Updated dependencies [15e0df6]
  - @objectstack/spec@3.0.9

## 3.0.8

### Patch Changes

- Updated dependencies [5a968a2]
  - @objectstack/spec@3.0.8

## 3.0.7

### Patch Changes

- Updated dependencies [0119bd7]
- Updated dependencies [5426bdf]
  - @objectstack/spec@3.0.7

## 3.0.6

### Patch Changes

- Updated dependencies [5df254c]
  - @objectstack/spec@3.0.6

## 3.0.5

### Patch Changes

- Updated dependencies [23a4a68]
  - @objectstack/spec@3.0.5

## 3.0.4

### Patch Changes

- Updated dependencies [d738987]
  - @objectstack/spec@3.0.4

## 3.0.3

### Patch Changes

- c7267f6: Patch release for maintenance updates and improvements.
- Updated dependencies [c7267f6]
  - @objectstack/spec@3.0.3

## 3.0.2

### Patch Changes

- Updated dependencies [28985f5]
  - @objectstack/spec@3.0.2

## 3.0.1

### Patch Changes

- Updated dependencies [389725a]
  - @objectstack/spec@3.0.1

## 3.0.0

### Major Changes

- Release v3.0.0 — unified version bump for all ObjectStack packages.

### Patch Changes

- Updated dependencies
  - @objectstack/spec@3.0.0

## 2.0.7

### Patch Changes

- Updated dependencies
  - @objectstack/spec@2.0.7

## 2.0.6

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@2.0.6

## 2.0.5

### Patch Changes

- Updated dependencies
  - @objectstack/spec@2.0.5

## 2.0.4

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@2.0.4

## 2.0.3

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@2.0.3

## 2.0.2

### Patch Changes

- Updated dependencies [1db8559]
  - @objectstack/spec@2.0.2

## 2.0.1

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@2.0.1

## 2.0.0

### Patch Changes

- Updated dependencies [38e5dd5]
- Updated dependencies [38e5dd5]
  - @objectstack/spec@2.0.0

## 1.0.12

### Patch Changes

- Updated dependencies
  - @objectstack/spec@1.0.12

## 1.0.11

### Patch Changes

- @objectstack/spec@1.0.11

## 1.0.10

### Patch Changes

- @objectstack/spec@1.0.10

## 1.0.9

### Patch Changes

- @objectstack/spec@1.0.9

## 1.0.8

### Patch Changes

- @objectstack/spec@1.0.8

## 1.0.7

### Patch Changes

- @objectstack/spec@1.0.7

## 1.0.6

### Patch Changes

- Updated dependencies [a7f7b9d]
  - @objectstack/spec@1.0.6

## 1.0.5

### Patch Changes

- b1d24bd: refactor: migrate build system from tsc to tsup for faster builds
  - Replaced `tsc` with `tsup` (using esbuild) across all packages
  - Added shared `tsup.config.ts` in workspace root
  - Added `tsup` as workspace dev dependency
  - significantly improved build performance
- Updated dependencies [b1d24bd]
  - @objectstack/spec@1.0.5

## 1.0.4

### Patch Changes

- @objectstack/spec@1.0.4

## 1.0.3

### Patch Changes

- @objectstack/spec@1.0.3

## 1.0.2

### Patch Changes

- a0a6c85: Infrastructure and development tooling improvements

  - Add changeset configuration for automated version management
  - Add comprehensive GitHub Actions workflows (CI, CodeQL, linting, releases)
  - Add development configuration files (.cursorrules, .github/prompts)
  - Add documentation files (ARCHITECTURE.md, CONTRIBUTING.md, workflows docs)
  - Update test script configuration in package.json
  - Add @objectstack/cli to devDependencies for better development experience

- 109fc5b: Unified patch release to align all package versions.
- Updated dependencies [a0a6c85]
- Updated dependencies [109fc5b]
  - @objectstack/spec@1.0.2

## 1.0.1

### Patch Changes

- @objectstack/spec@1.0.1

## 1.0.0

### Major Changes

- Major version release for ObjectStack Protocol v1.0.
  - Stabilized Protocol Definitions
  - Enhanced Runtime Plugin Support
  - Fixed Type Compliance across Monorepo

### Patch Changes

- Updated dependencies
  - @objectstack/spec@1.0.0

## 0.9.2

### Patch Changes

- Updated dependencies
  - @objectstack/spec@0.9.2

## 0.9.1

### Patch Changes

- Patch release for maintenance and stability improvements. All packages updated with unified versioning.
- Updated dependencies
  - @objectstack/spec@0.9.1

## 0.8.2

### Patch Changes

- Updated dependencies [555e6a7]
  - @objectstack/spec@0.8.2

## 0.8.1

### Patch Changes

- @objectstack/spec@0.8.1

## 1.0.0

### Minor Changes

- # Upgrade to Zod v4 and Protocol Improvements

  This release includes a major upgrade to the core validation engine (Zod v4) and aligns all protocol definitions with stricter type safety.

### Patch Changes

- Updated dependencies
  - @objectstack/spec@1.0.0

## 0.7.2

### Patch Changes

- fb41cc0: Patch release: Updated documentation and JSON schemas
- Updated dependencies [fb41cc0]
  - @objectstack/spec@0.7.2

## 0.7.1

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@0.7.1

## 0.6.1

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@0.6.1

## 0.6.0

### Minor Changes

- b2df5f7: Unified version bump to 0.5.0

  - Standardized all package versions to 0.5.0 across the monorepo
  - Fixed driver-memory package.json paths for proper module resolution
  - Ensured all packages are in sync for the 0.5.0 release

### Patch Changes

- Updated dependencies [b2df5f7]
  - @objectstack/spec@0.6.0

## 0.4.2

### Patch Changes

- Unify all package versions to 0.4.2
- Updated dependencies
  - @objectstack/spec@0.4.2

## 0.4.1

### Patch Changes

- Version synchronization and dependency updates

  - Synchronized plugin-msw version to 0.4.1
  - Updated runtime peer dependency versions to ^0.4.1
  - Fixed internal dependency version mismatches

- Updated dependencies
  - @objectstack/spec@0.4.1

## 0.4.0

### Minor Changes

- Release version 0.4.0

## 0.3.3

### Patch Changes

- Workflow and configuration improvements

  - Enhanced GitHub workflows for CI, release, and PR automation
  - Added comprehensive prompt templates for different protocol areas
  - Improved project documentation and automation guides
  - Updated changeset configuration
  - Added cursor rules for better development experience

- Updated dependencies
  - @objectstack/spec@0.3.3

## 0.3.2

### Patch Changes

- Patch release for maintenance and stability improvements
- Updated dependencies
  - @objectstack/spec@0.3.2

## 0.3.1

### Patch Changes

- @objectstack/spec@0.3.1

## 0.3.0

### Patch Changes

- Updated dependencies
  - @objectstack/spec@1.0.0

## 0.2.0

### Minor Changes

- Initial release of ObjectStack Protocol & Specification packages

  This is the first public release of the ObjectStack ecosystem, providing:

  - Core protocol definitions and TypeScript types
  - ObjectQL query language and runtime
  - Memory driver for in-memory data storage
  - Client library for interacting with ObjectStack
  - Hono server plugin for REST API endpoints
  - Complete JSON schema generation for all specifications

### Patch Changes

- Updated dependencies
  - @objectstack/spec@0.2.0

## 0.1.1

### Patch Changes

- Remove debug logs from registry and protocol modules
- Updated dependencies
  - @objectstack/spec@0.1.2