@objectstack/metadata 17.2.0 → 17.4.0

package/CHANGELOG.md

@@ -1,5 +1,1972 @@
 # @objectstack/metadata
 
+## 17.4.0
+
+### Minor Changes
+
+- a56baa2: feat(metadata,objectql): a keyed plural read on `MetadataManager`, `listNames` fault parity, and an action audit that answers from the same identity and sources as the router
+  
+  Two plural reads of one metadata plane could disagree with a by-name read of
+  that same plane, and the ADR-0110 D5 action-governance audit stood on the
+  disagreement — reporting `registered handler with NO declaration … REFUSED at
+  dispatch` about a route the router was resolving and dispatching in the same
+  boot.
+  
+  **`MetadataManager.listNames` gains the per-loader `try`/`catch` that
+  `loadMany` and `list()` have carried since #5108.** One loader fault used to
+  produce two different facts depending only on which plural read a caller
+  reached for: `loadMany` swallowed it and answered short, `listNames` threw. It
+  now degrades the same way, through the same `reportLoaderReadFailure` /
+  `reportLoaderReadRecovered` helpers — one outage, one line, one vocabulary.
+  Callers that relied on `listNames` throwing to detect an outage should read
+  `listDiagnosed()`, which reports `degraded` explicitly.
+  
+  **New: `MetadataManager.loadManyKeyed(type, options?)`** — `loadMany` read under
+  the identity the STORE holds each item by, returning `{ name, data }` pairs. It
+  delegates to a loader's own `loadManyKeyed` where one is offered (on
+  `DatabaseLoader` that shares `loadMany`'s single query, so it costs nothing
+  extra) and otherwise falls back to that loader's `list()` + per-name `load()`.
+  ⛔ **`loadMany`'s published return shape does not change**, and no existing
+  consumer is touched: the key travels *beside* the body, never inside it, so a
+  body that deliberately carries no `name` stays byte-identical to what was
+  stored (#14205).
+  
+  **The action-governance audit now mirrors the router on both halves of the D5
+  bijection.** The declaration half enumerates the plane keyed
+  (`loadStandaloneActionsKeyed`), so a row whose body does not name itself — a
+  `sys_metadata` row keyed by its `name` column, or a `FilesystemLoader` file
+  whose identity is its path — is a declaration to the audit exactly as it is to
+  the router; the handler half also probes the plane BY NAME
+  (`lookupMetadataAction`, `loadDiagnosed`/`load`, injected like the existing
+  registry rung), so a loader fault a plural read swallows can no longer turn a
+  dispatchable handler into an accusation. Both probes stay conservative in one
+  direction only: a source that throws leaves the handler on the list.
+  
+  Additive on every published signature. `runActionGovernanceInventory` and
+  `collectEngineActionDeclarations` gain optional parameters and keep their old
+  ones working unchanged; declaration rows gain an optional `storeKey` (the new
+  exported `ActionDeclarationRow`).
+  
+  **Population change, reported:** `unboundDeclarations` now sees declarations
+  whose identity is the store key. Its BEFORE was **0, structurally rather than
+  by sampling** — a nameless row was dropped before reconciliation ran, so it
+  could never be reported however many a plane held. Its one deliberate
+  subtraction: a row with neither an own `name` nor a store key is no longer
+  reported as `actionName: undefined`, which read as a parse failure in the
+  warning rather than as a finding.
+  
+  Known boundary, stated in the audit's docblock rather than left to be
+  rediscovered: a boot-time audit runs outside any request scope, so if a
+  composition ever registered `metadata` as `SCOPED` the audit could not reach
+  that instance at all — before any read method runs. No shipped composition does
+  (`packages/metadata/src/plugin.ts` registers a static instance), and reaching a
+  request-scoped service from a boot-time audit is a separate change.
+- c1d274d: fix(metadata): two files sharing one stem are refused with both paths named, instead of one being listed twice and served by extension precedence (#14921)
+  
+  **BREAKING** accept-set narrowing on `FilesystemLoader`, shipped as `minor`
+  under the repo's launch-window convention for breaking changes. Ruled on
+  #14921 (2026-09-05, option 1 of three).
+  
+  **Remedy: delete or rename the duplicate file.** The refusal names every
+  colliding path and the metadata type, so the fix is visible at the point of
+  failure.
+  
+  `FilesystemLoader` derives a metadata name by stripping a flat file's
+  extension, and resolves a name back to a file under a FIXED extension
+  precedence (`.json` → `.yaml` → `.yml` → `.ts` → `.js`). Two files sharing a
+  stem therefore produced one name **twice** in `list()` while only the
+  first-precedence file was reachable through any name at all. With
+  `object/twin.json` and `object/twin.yaml` both present, `list()` answered
+  `['twin', 'twin']`, `twin.yaml` was addressable through nothing, and
+  `loadMany()` returned both bodies. `MetadataManager.listNames()` unions loader
+  output into a `Set`, which collapsed the duplicate and took the count
+  discrepancy with it — the file stayed unreachable either way, so a clean
+  `listNames()` was never evidence the collision had been absorbed.
+  
+  The invariant that broke: **what is listed is what is loadable.** The listed
+  set and the addressable set stopped being the same set. The failure was silent
+  in the direction that matters for authoring — convert `twin.json` to
+  `twin.yaml` and leave the old file behind, or land one from each of two
+  packages, and the JSON one is served forever with no diagnostic anywhere,
+  while `admitLoaderItems()`'s documented "keep the first and say nothing"
+  absorbs the collision a second time.
+  
+  `FilesystemLoader.list()` now throws `AmbiguousMetadataStemError`
+  (`AMBIGUOUS_METADATA_STEM`, HTTP 500) naming both paths and the type, and the
+  same refusal fronts the shared `loadMany()` / `loadManyKeyed()` walk, so the
+  two-body answer is gone rather than de-duplicated. `MetadataManager.listNames()`
+  and `list()` **propagate** it rather than absorbing it into their per-loader
+  degradation: an ambiguous stem is an authoring error no retry fixes, and
+  degrading it would drop every item the loader holds into a short-but-served
+  list while the server keeps reporting healthy. A real storage outage still
+  degrades exactly as before — the seams discriminate on a branded predicate,
+  `isAmbiguousMetadataStemError`, not on a blanket rethrow.
+  
+  **Refused shape**, precisely: two or more files **directly under
+  `ROOT/TYPE/`** whose basenames differ only by an extension belonging to one of
+  **this instance's registered serializers**. Register `javascript` and
+  `dual.json` + `dual.js` becomes ambiguous; under the manager's default format
+  set (`typescript` / `json` / `yaml`) it is not, because `.js` derives no name.
+  Nested files are untouched — they are neither listed nor resolvable (#14486),
+  so `crm/solo.json` beside a flat `solo.json` is not a collision. The refusal is
+  scoped to the type directory that holds it: a clean `view/` still lists while
+  `object/` refuses.
+  
+  New exports from the package root entry: `AmbiguousMetadataStemError`,
+  `isAmbiguousMetadataStemError`, `AMBIGUOUS_METADATA_STEM_CODE`,
+  `AMBIGUOUS_METADATA_STEM_STATUS`.
+  
+  Measured migration cost, which is what makes this narrowing cheap: **no tree in
+  this repository carries the shape.** A walk of all 7,770 tracked files across
+  526 directories found zero stem collisions among `.json` / `.yaml` / `.yml` /
+  `.ts` / `.js`, confirmed independently by a `git ls-files` pass, and the repo
+  holds no `.yaml`/`.yml` metadata file at all outside CI and workspace config.
+  No existing tree goes red.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) An accept-set narrowing on a LOADER, not on any authorable key: no property of any spec schema is removed, renamed or re-shaped, so there is no tombstone and nothing for `objectstack migrate meta` to rewrite in a stored document. The affected artifact is a FILESYSTEM LAYOUT — two sibling files — which the ledger cannot address at all: a migration entry rewrites metadata bodies, and neither of the colliding files is wrong on its own. Which one an author wants kept is intent no entry can decide: they may have meant the conversion to `.yaml` to land and forgotten to delete the `.json`, or may have meant the opposite, and the two files carry no evidence of which. The refusal is the channel that reaches them, at the load site, naming both paths, the type, and the remedy. Measured in-repo population of affected trees is zero: a walk of 7,770 tracked files over 526 directories found no directory holding two files with one stem among the registered extensions, and there are no `.yaml`/`.yml` metadata files outside CI and workspace config. -->
+- e9fcd6b: feat(metadata)!: `DatabaseLoaderOptions.cache.ttl` → `cache.ttlMs` — the read-through cache TTL carries its unit in the key name (#14478)
+  
+  <!-- adr-0087: registered metadata-manager-config-cache-ttl-unit-in-key -->
+  
+  **BREAKING** rename on the exported `DatabaseLoaderOptions.cache` shape
+  (`DatabaseLoaderCacheOptions.ttl` → `ttlMs`), shipped as `minor` under the
+  launch-window convention. `MetadataManager` hands `config.cache.databaseLoader`
+  straight to `new DatabaseLoader({ cache })`, so this option is the spec key
+  `cache.databaseLoader.ttlMs` one layer down and renames with it: a loader
+  configured with `ttlMs: 60_000` expires entries after 60 seconds exactly as
+  `ttl: 60_000` did. The README example and the kernel metadata-service docs page
+  spell the new key.
+  
+  ```ts
+  // before
+  new DatabaseLoader({ driver, cache: { enabled: true, maxSize: 500, ttl: 60_000 } });
+  // after
+  new DatabaseLoader({ driver, cache: { enabled: true, maxSize: 500, ttlMs: 60_000 } });
+  ```
+- 3bd9b34: feat(metadata): `deriveViewContainerObject` gets a leaf `/view-container` subpath, so objectql's lean ADR-0076 entry stops loading the manager, chokidar, glob and js-yaml for a six-line pure function
+  
+  `packages/objectql/src/engine.ts` reached `deriveViewContainerObject` through
+  `@objectstack/metadata`'s ROOT entry. `core.ts` — the ADR-0076 lean entry —
+  re-exports `engine.ts`, so `@objectstack/objectql/core`'s module-init closure
+  inherited the whole root entry: `MetadataPlugin` -> `NodeMetadataManager` ->
+  `chokidar`, plus `glob`, `js-yaml` and `readdirp`.
+  
+  The same file already carried the answer 79 lines above, at its
+  `@objectstack/metadata/errors` import: that leaf subpath exists "precisely so a
+  cross-package consumer gets the predicate without the manager, the loaders or
+  the YAML/filesystem machinery behind the root entry". This is that pattern,
+  taken a second time.
+  
+  **Measured on the built artifacts, not asserted** — every module Node actually
+  evaluates when `@objectstack/objectql/core` is loaded in a fresh process,
+  recorded through a `module.registerHooks` load hook (ESM and CJS) plus
+  `require.cache`, byte sizes from `statSync`:
+  
+  | `@objectstack/objectql/core` | modules | bytes |
+  |:---|---:|---:|
+  | before (ESM `dist/core.mjs`) | 190 | 12,348,424 |
+  | after (ESM `dist/core.mjs`) | 185 | 11,849,808 |
+  | **delta** | **-5** | **-498,616 (-486.9 KiB)** |
+  | before (CJS `dist/core.js`) | 188 | 12,654,238 |
+  | after (CJS `dist/core.js`) | 183 | 12,141,034 |
+  | **delta** | **-5** | **-513,204 (-501.2 KiB)** |
+  
+  Six modules stop loading — `packages/metadata/dist/index.js` (237,747 B),
+  `js-yaml` (114,610 B), `glob` (82,749 B), `chokidar` (2 files, 54,220 B) and
+  `readdirp` (9,836 B) — and one 469-byte module takes their place. Marginal
+  module-init time for that root entry, measured on a warm lean closure, was
+  ~22 ms (median of 7; 20.4-27.5 ms) out of ~630 ms.
+  
+  ⚠️ The figure the finding was argued on — "~3.6 KB to ~450 KB" — is right about
+  the delta and wrong about the baseline: the lean entry's closure was already
+  ~11.5 MiB before this import existed, dominated by `@objectstack/spec`
+  (9,587,914 B) and `zod` (567,918 B), neither of which the metadata root entry
+  contributes. What the root import cost was ~487 KiB *on top of* that, not a
+  closure of 450 KB.
+  
+  The derivation itself moves to `packages/metadata/src/view-container.ts`, a
+  module with **no imports at all**, and `view-container-expansion.ts` imports
+  and re-exports it, so `index.ts`'s root export and `plugin.ts` keep their
+  spelling and the symbol stays on the root entry — this subpath is an additional
+  door, not a relocation. A re-export shim onto `view-container-expansion.ts` was
+  tried first and rejected on measurement: esbuild tree-shakes the unused
+  `expandRuntimeViewContainer` but keeps its two `@objectstack/spec` import
+  statements, so that shim's own closure was 84 modules / 3,035 KiB. The real
+  leaf's is 1 module / 469 B.
+  
+  `expandRuntimeViewContainer` is deliberately not exported from the new subpath:
+  `metadata-manager.ts` is its only caller, the root entry does not export it
+  either, and it is the half that carries the spec machinery.
+- 8647c87: A completed run of the ADR-0030 notification cut-over now records itself in the `sys_migration` deployment ledger, per the ruled claim matrix.
+  
+  `migrateSysNotificationToEvent` reports `migrated` / `already_done` / `not_applicable` / `error` to its caller and — until now — recorded nothing anywhere. Once that line had scrolled, "did this cut-over run here, and when" had no answer in the deployment even in principle. The ledger row is what answers it, and what a run of this migration may claim under `NOTIFICATION_EVENT_MIGRATION_ID` is stated on that constant in `@objectstack/spec/system`:
+  
+  - `last_run_at` — stamped on every completed non-`error` run (`migrated`, `already_done`, `not_applicable` alike).
+  - `applied_at` — stamped only on `migrated`. Never cleared: a later `already_done` leaves an earlier backfill's stamp alone, because the backfill really did happen.
+  - `verified_at` — never written, in either direction. This migration has no self-check, and `verified_at` means a self-check passed. On a store created after the cut-over the row already exists and `attestFreshDatastore` set `verified_at` at birth; that certificate survives a run untouched, because the column is omitted from the update rather than sent as `null`.
+  - `blocking: 0`, and `details` carrying `{ outcome }` verbatim.
+  - An `error` run writes no claim at all — it does not know what it did, so it does not say.
+  
+  **Receipt, not gate.** Nothing reads a row under this id as a precondition and nothing may: a gate would need the self-check that does not exist. The row is what an operator reads, in the shape `sys_migration` already documents for the seed-tenancy repair.
+  
+  Two additions to the published surface of `@objectstack/metadata/migrations`, both driven by that: a new `SysNotificationMigrationReceipt` type, and a new `receipt` member on `SysNotificationMigrationResult` reporting what became of the claim (`inserted` / `updated` / `not-claimed` / `no-ledger` / `failed`, with a reason on the last two). This directory takes no logger and reports to its caller, so the claim's own fate is reported the same way the migration's is — a receipt that could not be written is never swallowed. Reading a result is unaffected; code that CONSTRUCTS a `SysNotificationMigrationResult` by hand (a test double) now supplies `receipt`.
+
+### Patch Changes
+
+- 0c5d035: fix(metadata): a `HistoryCleanupManager` run that loses deletes now says so, at both of `start()`'s triggers
+  
+  A failing history cleanup was completely silent. Three things composed: every inner `catch` on the delete path is a bare `catch {`, so the error object is discarded; the only `console.error` in `runCleanup()` sits in its OUTER catch, which those inner catches prevent execution from reaching; and `start()` invoked the run as `void this.runCleanup()`, throwing away the `{ deleted, errors }` the run returns — at BOTH call sites, the immediate run and every interval tick. A driver whose deletes failed on every scheduled run therefore produced zero output and no reachable error count, while the history table grew past its retention policy with nothing to find.
+  
+  The repair reads the envelope instead of replacing it. `runCleanup()`'s contract, its inner catches and its counting are unchanged: reporting a failure to the CALLER is the third answer AGENTS.md → "Degradation log levels" allows a durability seam, and that same section names a log per failed write as the mirror-image failure. What was missing was a reader — `start()` is where the chain ends, since it returns `void` and an interval tick has no caller at all. Both call sites now go through one shared pass that reads the returned counts and, when a run lost deletes, prints one `error` line naming the consequence (rows past the retention policy are still in the table, nothing retries them, and the system keeps reporting healthy) and where to look. A run that loses nothing stays quiet, and a direct caller of `runCleanup()` sees exactly the same `{ deleted, errors }` as before.
+- 281bf0d: `HistoryCleanupManager` computes its retention cutoff on one calendar, not two.
+  
+  Both call sites — the age-based delete in `runCleanup()` and the preview count in `getCleanupStats()` — built the cutoff with `cutoffDate.setDate(cutoffDate.getDate() - maxAgeDays)` and then rendered it with `toISOString()`. `setDate`/`getDate` read and write the **local** calendar; `toISOString()` renders **UTC**. They now use `setUTCDate`/`getUTCDate`, so the arithmetic and the rendering agree.
+  
+  `setDate` preserves wall-clock time, so shifting the local calendar back `n` days moves the *instant* by exactly `n × 24h` only while every local day in the window is 24 hours long. When the window straddles a DST transition it is 23 hours (spring-forward) or 25 (fall-back), and the cutoff instant that goes into the `recorded_at: { $lt: … }` **delete** filter is off by the size of that transition — one hour in most zones, thirty minutes on Lord Howe Island. History rows within that slip of the retention boundary were deleted early, or retained too long.
+  
+  The exposure is not limited to the two transition days: the window only has to *straddle* a transition, so it grows with `maxAgeDays`. Measured over a 12-zone × 366-day × 48-half-hour sweep of 2026, in `America/New_York` the old spelling produced a wrong cutoff for 0.6% of instants at `maxAgeDays: 1`, 16.4% at 30, 49.7% at 90 and 69.4% at 180. In zones that do not observe DST (`UTC`, `Asia/Shanghai`, `Asia/Kolkata`, `Australia/Perth`) the rate is 0.0% at every `maxAgeDays` — which is why no test had ever gone red on this.
+  
+  This does **not** make retention timezone-aware, and does not change what `maxAgeDays` means. The cutoff was already intended to be `now − maxAgeDays × 24h`; it is now that in every zone rather than only in zones without DST. Nothing else in either filter moved: the `organization_id` scoping, the ADR-0009 `executionPinned` exclusion and the `maxVersions` path are untouched.
+- 3e7ef9c: Serve an Invalid `Date` from a driver instead of raising `RangeError` in `DatabaseLoader.stat`.
+  
+  `canonicalIsoInstant` reached `value.toISOString()` for any `Date`, and that call raises `RangeError: Invalid time value` for the one `Date` whose time value is `NaN`. `stat()` is a hot read path — REST `/meta/*`, ObjectQL plan resolution, runtime overlay merges — so one legacy `sys_metadata` row answered **500** where the spelling this repair replaced had served a visibly-wrong value.
+  
+  The shape is measured: mysql2 3.23.1 hands back a constant literally named `INVALID_DATE` for a zero `DATETIME`, and postgres-date 1.0.7 builds `new Date(NaN)` for every year in 275760..294276, which Postgres itself stores.
+  
+  The `Date` arm now guards on `Number.isNaN(value.getTime())` and answers `undefined`, so `stat()`'s own `?? new Date().toISOString()` — the branch an absent column already takes — publishes a parseable `MetadataStats.mtime`. `undefined` rather than visible text is deliberate here: `mtime` is declared `z.string().datetime()`, so the text `"Invalid Date"` would not produce a readable cell, it would produce a zod refusal at the consumer, moving the failure instead of removing it. A blank is excluded for the opposite reason — it hides the producer's bug.
+- 09c1d91: docs(metadata): the `@objectstack/metadata/errors` header records what the leaf entry actually loads — 4 packages, 83 modules, 2.2 MB — instead of leaving the reader to infer it is light (#15346)
+  
+  `packages/metadata/src/errors.ts` is the leaf subpath `@objectstack/metadata/errors`, and its header explains why the subpath exists: the root entry pulls the manager, every loader and the YAML/filesystem machinery behind them, and "a consumer that wants a 40-line predicate should not have to load any of that". Measured, that promise half holds — and the header did not say which half.
+  
+  **The half that holds, and stays:** MEASURED 2026-09-08 on `origin/main` `8c1515e847`, with `scripts/check-lean-entry-closure.mjs`'s exported `measure()`/`byPackage()` (one fresh child per published condition; module set collected through `module.registerHooks` unioned with `require.cache`). Both published conditions load exactly four packages, and the manager, every loader, `chokidar`, `glob`, `js-yaml` and `readdirp` are absent from all of them. That is the claim the header actually wrote, and it is accurate.
+  
+  **The half that had drifted:** the general conclusion a reader takes away. `import` loads 83 modules / 2,201,709 bytes; `require` loads 83 / 2,355,405. Since the maintainer's 2026-08-30 ruling the file re-exports from `@objectstack/types`, which builds to one bundled module importing **both** `@objectstack/spec/api` (1,401,253 B) and `@objectstack/spec/security` (195,367 B) at module top, as values — `api` is the dominant edge at 7x `security`, and the two spec entries are independent of each other.
+  
+  The header now separates the two costs the way the finding did, because conflating them is the available mistake: **in-repo the marginal contribution is 143 bytes** — the only current consumer of the subpath, `@objectstack/metadata-protocol`, declares `@objectstack/spec` itself and pays for that closure anyway — while the megabytes are what an **out-of-repo** consumer pays, which nothing here can measure. The figures are labelled PROVENANCE, dated and tree-pinned, in the manner the neighbouring gate keeps its own: nothing derives from them, nothing compares against them, and the header says to re-take them rather than quote them. They rot fast — the same measurement four days earlier at `6e67b86c0` found the same 83 modules but 2,487,842 bytes, 286,133 more, without this file changing at all.
+  
+  **Why `patch` and not `skip-changeset`, measured rather than assumed.** `@objectstack/metadata` is released (17.3.0) and `errors.ts` is a shipped source file, so "a comment publishes nothing" needed checking rather than asserting. Building the package before and after the edit: `dist/errors.js`, `dist/errors.cjs`, `dist/errors.d.ts` and `dist/errors.d.cts` are **byte-identical** (esbuild strips the comment, and there is no `sourcesContent`), but `dist/errors.js.map` and `dist/errors.cjs.map` **change** — the export statement moved from source line 65 to line 113, so the `mappings` VLQ moves with it (`;AAgEA,…` → `;AAgHA,…`), at identical file size. `npm pack --dry-run` lists both maps in the tarball. So this diff does publish bytes from a released package, which is exactly what `skip-changeset` is not for. Nothing executable and no type changes: a consumer's stack traces resolve to the right source line, and that is the whole of it.
+- 7629f4d: feat(spec)!: retire the three inert outer keys of `MetadataManagerConfig.cache` — `enabled`, `ttlSeconds` (formerly `ttl`) and `maxSize` — read by nothing; `cache.databaseLoader` is the only live half (#15624, ADR-0049)
+  
+  <!-- adr-0087: registered metadata-manager-config-inert-cache-keys-retired -->
+  
+  **BREAKING** accept-set narrowing, landing after the v17.0.0 cut (the lockstep
+  launch-window convention ships it as `minor`; the migration prescription is
+  registered under protocol major 18, where `os migrate meta` users will look).
+  ADR-0049 enforce-or-remove decides it: a declared-but-unenforced key with zero
+  measured readers comes off, and the published reference page stops teaching it.
+  
+  `MetadataManagerConfig.cache` declared three outer knobs — `enabled` (default
+  `true`), `ttlSeconds` (default 3600; spelled `ttl` until #14478) and `maxSize`
+  ("Max cache size in bytes") — beside the nested `databaseLoader` block, and
+  **nothing read the outer three**. The only runtime consumer of the block is
+  `MetadataManager` (`packages/metadata`), which hands `cache.databaseLoader` and
+  nothing else to `new DatabaseLoader({ cache })`; a reader census over
+  `packages/**` (tests and changelogs excluded) found no runtime reader of any
+  outer key, while the same grep shape found the nested `cache?.databaseLoader`
+  read twice — the control that makes the zero a measurement. An author writing
+  `cache: { enabled: false }` or `cache: { ttlSeconds: 60 }` got a clean parse
+  and a cache that behaved exactly as before, with no error and no warning, and
+  the published reference page (`references/kernel/metadata-loader`) documented
+  all three as if they configured something.
+  
+  **What is refused:** authoring `cache.enabled`, `cache.ttlSeconds`, `cache.ttl`
+  or `cache.maxSize` on `MetadataManagerConfig`, with any value — directly, through
+  `MetadataManagerOptions`, or through `MetadataPluginConfig.storage`. The nested
+  object is not `.strict()`, so each key is a `retiredKey()` tombstone rather than
+  a bare deletion (a deletion would have stripped it in silence — the same no-op
+  one layer down): authoring it is a `tsc` error (`never`) and a parse error
+  carrying the prescription, which names the live nested knob.
+  
+  **What stays, byte-identical:** the DatabaseLoader read-through cache under
+  `cache.databaseLoader` — `enabled` (default `true`), `maxSize` (an entry count,
+  default 500) and `ttlMs` (milliseconds, default 60000) — and every runtime
+  path. Parsed configs no longer carry the two former defaults (`enabled: true`,
+  `ttlSeconds: 3600`) that were materialized and never consulted.
+  
+  **The #14478 rename is folded in.** `cache.ttl` → `cache.ttlSeconds` was
+  registered under this same unreleased major and never reached a published
+  release, so it is absorbed by the removal: `cache.ttl`'s tombstone now
+  prescribes deletion (naming `cache.databaseLoader.ttlMs`) instead of a rename to
+  a key that is itself retired — an author upgrading from a published 17.x sees
+  one hop. The nested `cache.databaseLoader.ttl` → `ttlMs` half of that rename is
+  unchanged.
+  
+  ## FROM → TO
+  
+  ```ts
+  // before — parsed green; no runtime ever read the three outer numbers
+  new MetadataManager({
+    datasource: 'default',
+    cache: { enabled: true, ttlSeconds: 3600, maxSize: 10_485_760, databaseLoader: { ttlMs: 60_000 } },
+  });
+  
+  // after — delete the outer keys; the nested block is the cache that runs
+  new MetadataManager({
+    datasource: 'default',
+    cache: { databaseLoader: { enabled: true, maxSize: 500, ttlMs: 60_000 } },
+  });
+  ```
+  
+  **Migration.** Delete `cache.enabled`, `cache.ttlSeconds` / `cache.ttl` and
+  `cache.maxSize`; nothing replaces them, because nothing ever consumed them. If
+  you meant to switch the cache off, cap it or set its TTL, write
+  `cache.databaseLoader.enabled` / `.maxSize` (entries) / `.ttlMs` (milliseconds)
+  — those are honoured. No `os migrate meta` conversion runs on this surface: a
+  `MetadataManager` config is not a stack collection member and never a stored
+  row, so the chain has no seam for it; the D3 semantic entry
+  `metadata-manager-config-inert-cache-keys-retired` carries the prescription
+  into `spec-changes.json`, the upgrade guide and the `spec_changes` MCP tool.
+  
+  The retirement kit: `retiredKey()` tombstones on all three (and the absorbed
+  `ttl`), `RETIRED_KEYS_BY_MAJOR[18]` entries for each, the D3 semantic entry
+  above (the #14478 entry's outer half is re-worded from a rename to a deletion),
+  negative pins asserting each prescription and a positive pin asserting the
+  parse output no longer materializes the retired defaults, the published
+  reference pages regenerated, and the hand-written docs page and this package's
+  README (`@objectstack/metadata` ships `README.md`, hence its `patch`) no longer
+  authoring `cache.enabled`.
+- 6f23f0e: fix(metadata): keep the original notification instant when migrating `sys_notification` to the event model (#16312)
+  
+  `migrateSysNotificationToEvent` materializes each legacy inbox row into a
+  `sys_inbox_message` and a `sys_notification_receipt`, back-dating both to the
+  notification's own `created_at`. Both writes passed no options bag, so they
+  relied on the audit binder's create-side `record.created_at ?? now` — the
+  laundering #15964 removed, on the maintainer ruling of 2026-09-06. Without
+  that accident, every migrated inbox row and receipt is stamped with the moment
+  the migration RAN: a user's whole bell history collapses to "all arrived
+  today".
+  
+  The two writes now declare `{ context: { preserveAudit: true } }`, the explicit
+  historical-import channel the same ruling deliberately kept (#3493; it is what
+  REST import's `treatAsHistorical` sets). This is not a bypass of audit — it is
+  the door audit left open for a historical import. No exported symbol, schema or
+  config key moves.
+  
+  **Release ordering.** `@objectstack/objectql`'s side of #15964 is itself still
+  an unreleased changeset, so no published version of this migration has ever
+  written the flattened timeline. Releasing the two together keeps it that way.
+  
+  **If a deployment did run it from a build that has both halves**, the original
+  timeline is recoverable rather than lost: the source `sys_notification` rows
+  are rewritten in place, never deleted or archived, and `created_at` is not
+  among the legacy columns the run clears — so the notification's own instant is
+  still on the event row and reachable from both new rows through
+  `notification_id`.
+- efc5447: `RemoteLoader.list()` no longer reports a nameless remote body as a literal `undefined`.
+  
+  The method declares `Promise<string[]>` and read the collection as `loadMany<{ name: string }>(type)` before mapping `items.map(i => i.name)`. That type argument is an **assertion** about bodies that arrived over HTTP, and nothing checked it: a body with no top-level `name` yielded `undefined`, which went into an array the signature declares as `string[]`. `MetadataManager.listNames()` unions loader `list()` output unfiltered, so the violation reached consumers — measured on this fixture, `listNames()` answered `[ 'account', undefined, 42 ]`.
+  
+  The guard is `DatabaseLoader.list()`'s, one file away: the same cast-then-map spelling with `.filter(name => typeof name === 'string')` behind it. `RemoteLoader` was the only one of the four loaders in that directory with no guard at all — `MemoryLoader` answers with its store keys, and `FilesystemLoader` reports only names `findFile()` resolves. Dropping silently rather than throwing is the direction those siblings already carry: a name in the list that the door answers `null` for is the silent failure an author reads as their own typo, so the list is narrowed to agree with the door.
+  
+  Nothing that was validly returned before stops being returned: the only entries that disappear are the ones whose type the signature already ruled out. A caller that previously received `[undefined]` now receives `[]`. `loadMany()` is deliberately untouched — it keys nothing, so a body carrying no `name` is still served there; this loader reads over HTTP and holds no store key, so `body.name` is the only identity it has and the family's "identity is the store key" rule cannot be satisfied for it.
+- 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 [2ed6be6]
+- 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 [159dbad]
+- 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 [b0529e1]
+- Updated dependencies [66dc6ab]
+- Updated dependencies [6f94458]
+- Updated dependencies [6e67b86]
+- 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 [2025b1f]
+- Updated dependencies [1a7a7c9]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [cbca47d]
+- Updated dependencies [acf4d38]
+- 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 [088f761]
+- 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 [51ae731]
+- Updated dependencies [af7edfe]
+- Updated dependencies [b60f48b]
+- Updated dependencies [c78c918]
+- Updated dependencies [4ca358d]
+- 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 [6acb37e]
+- Updated dependencies [7797102]
+- Updated dependencies [554a160]
+- Updated dependencies [f7da71e]
+- Updated dependencies [7f745c3]
+- Updated dependencies [0a038cc]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [97adce2]
+- Updated dependencies [a83482c]
+- Updated dependencies [5eb24f8]
+- Updated dependencies [2a3decc]
+- Updated dependencies [cc00df2]
+- Updated dependencies [cc00df2]
+- Updated dependencies [f4e6adf]
+- Updated dependencies [ee4a59b]
+- Updated dependencies [4db3c61]
+- Updated dependencies [5ca314a]
+- Updated dependencies [e0af1a8]
+- Updated dependencies [4771bd9]
+- Updated dependencies [414c1fc]
+- Updated dependencies [22c0279]
+- Updated dependencies [c930f85]
+- 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 [d4f9b2a]
+- Updated dependencies [5f7fa1d]
+- Updated dependencies [87f0ccc]
+- Updated dependencies [aedbaef]
+- Updated dependencies [a727043]
+- 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 [2bb0614]
+- Updated dependencies [b3820c3]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [4df2a98]
+- Updated dependencies [9bcd9be]
+- Updated dependencies [b398ad2]
+- Updated dependencies [99261a7]
+- Updated dependencies [81b426f]
+- Updated dependencies [001af1c]
+- Updated dependencies [fb77aa5]
+- Updated dependencies [3d3f60e]
+- Updated dependencies [581d8f8]
+- Updated dependencies [f81afe3]
+- Updated dependencies [40a44b9]
+- Updated dependencies [f89812e]
+- Updated dependencies [7a7fb03]
+- Updated dependencies [8fd246d]
+- Updated dependencies [021a735]
+- Updated dependencies [7bdb163]
+  - @objectstack/spec@17.4.0
+  - @objectstack/core@17.4.0
+  - @objectstack/platform-objects@17.4.0
+  - @objectstack/types@17.4.0
+  - @objectstack/metadata-core@17.4.0
+  - @objectstack/metadata-fs@17.4.0
+
+## 17.3.0
+
+### Minor Changes
+
+- 32448d4: feat(metadata): the artifact door registers stack-declared `capabilities` (#12892 step 1)
+  
+  `ARTIFACT_FIELD_TO_TYPE` — the map that decides which collections of a compiled
+  artifact reach `MetadataManager` — now carries `capabilities: 'capability'`.
+  This is step 1 of the maintainer's 2026-08-29 ruling on #12892 (option 1: *the
+  door owns the registration route* for the five artifact security collections).
+  
+  **FROM.** `capabilities` is an authorable top-level stack collection (ADR-0066
+  D1), but the door did not map it while `AppPlugin`'s ADR-0057 `SECURITY_FIELDS`
+  block did — making that block the collection's **sole registrar on an artifact
+  boot**, and it registers the raw bundle bytes with no strict parse, no schema
+  default and no ADR-0010 provenance. On a `bootstrap: 'artifact-only'` runtime
+  where `AppPlugin` does not run, a package's declared capabilities reached no
+  registry at all: `GET /meta/capability` answered **empty**, and
+  `bootstrapDeclaredCapabilities` seeded **no `sys_capability` row** for them.
+  
+  **TO.** The door registers them like every other mapped collection: strict
+  parse, schema defaults, ADR-0010 provenance. Measured on a real artifact-only
+  kernel boot with no `AppPlugin`, over a package declaring
+  `{ name: 'crm.export', label: 'Export CRM data' }`:
+  
+  - `GET /meta/capability` went from `[]` to one item carrying `scope:'platform'`
+    (the `CapabilitySchema` default) plus `_packageId` / `_packageVersion` /
+    `_provenance`;
+  - `sys_capability` went from 9 rows (platform-curated only) to 10 — the
+    declaration now materializes with `managed_by:'package'` and its `package_id`.
+  
+  **What this does NOT change, deliberately.** On the ordinary artifact boot
+  `AppPlugin` still registers `capabilities` and still runs last, so its unparsed
+  copy still wins the registry — measured byte-identical before and after this
+  change. Two registrars on one route is the interim state the ruling explicitly
+  permits while step 2 (that block stops registering the five on the **artifact**
+  path, after a census of the non-artifact boots that depend on it) lands. No
+  authoring surface moves, and no artifact that parses today stops parsing.
+- 4b4d5a3: fix(metadata): `FilesystemLoader.list()` reports only names `findFile()` / `load()` / `exists()` can resolve
+  
+  **BREAKING (list output narrows).** Two shapes stop appearing in
+  `FilesystemLoader.list()`, and therefore in `MetadataManager.listNames()`:
+  
+  - **nested files** — `ROOT/TYPE/crm/account.json` was listed as `account`, a
+    name that resolves against `ROOT/TYPE/account.json` and finds nothing;
+  - **extension-less files** — `ROOT/TYPE/noext` was listed as `noext`, which
+    resolves under no appended extension at all.
+  
+  A third shape follows from the same rule rather than from a rule of its own:
+  the extensions a name can be resolved under are now the ones belonging to the
+  loader's **registered serializers**, so under the manager's default format set
+  (`typescript` / `json` / `yaml`) a `.js` file leaves `list()` too. It was
+  previously listed and resolvable while `loadMany()` could never return it and
+  `load()` threw `No serializer found for format: javascript`. Register the
+  `javascript` serializer and it is listed, resolvable and loadable together.
+  
+  `list()`, `findFile()` and `loadManyKeyed()` now share one name-to-path
+  derivation, so `listNames()` and `get()` give the same answer. Previously a name
+  could sit in the list while `get()` answered `null` for it — a silent failure an
+  author reads as their own typo.
+  
+  Nothing changes for a tree whose metadata is laid out as `ROOT/TYPE/NAME.json`
+  (or `.yaml` / `.yml` / `.ts`), which is the layout ADR-0008 §10 already
+  prescribes and `metadata-fs`'s `parseItemPath()` already enforces. `.yaml`,
+  `.yml` and `.ts` are unaffected: the extension set follows the registered
+  serializers, not §10's `.json`-only rule, which governs the `metadata-fs` store.
+  
+  `loadMany()` is unchanged and still returns bodies for nested and
+  extension-less files; `findFile()` still resolves an explicitly path-shaped
+  name such as `crm/account`, which nothing lists.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) No authorable key, Zod schema or stored row moves: this narrows one runtime loader's `list()` output. The ledger's artifacts project metadata rewrites, and there is nothing here for `objectstack migrate meta` to rewrite — a tree carrying a nested or extension-less file needs the FILE relocated into the two-segment layout ADR-0008 §10 already prescribes, which no migration prescription can express. -->
+- f4e7ae5: fix(security): gate the metadata HMR door on an explicit development posture (#12140)
+  
+  **BREAKING** surface narrowing — `GET`/`POST /api/v1/dev/metadata-events` are no
+  longer mounted unless `NODE_ENV` is exactly `development`. Shipped as `minor`
+  under the repo's launch-window convention for breaking changes.
+  
+  `MetadataPlugin` mounted both HMR routes whenever a raw-app-capable HTTP server
+  was present, with no authentication and no environment condition of its own. The
+  dev-only posture the path (`/api/v1/dev/…`) advertises lived only in prose —
+  "production deployments simply won't have a CLI POSTing to this endpoint" — which
+  is a claim about who is on the network, not a gate that stops them, and the same
+  structural shape #9391 closed for the `datasource-admin` family: both mounts take
+  the host's framework-native app handle, which is outside REST's `enforceAuth`
+  seam by construction.
+  
+  The distributions were enumerated rather than assumed, because "a dev-only
+  surface lacking a gate that says so" and "an unauthenticated door on a real
+  deployment" want different repairs. The official container image runs `os start`
+  under `NODE_ENV=production`; that boot reaches `createStandaloneStack`, which
+  composes `MetadataPlugin` unconditionally (only `artifactWatch` was
+  NODE_ENV-gated) onto a kernel that registers the Hono server whenever it serves.
+  So a production-shaped boot did mount both routes and did answer them — `POST`
+  re-reading the compiled artifact from disk and broadcasting a reload frame to
+  every connected client, unauthenticated.
+  
+  `registerMetadataHmrRoutes` now refuses at its first statement, ahead of every
+  side effect it performs, and returns `null` so "nothing was mounted" is a fact
+  the compiler forces its caller to handle. Unset `NODE_ENV` is closed, per the
+  maintainer's 2026-08-06 ruling that an absent value reads as `production`; `test`
+  and unrecognised spellings (`staging`, `preview`, `qa`) are closed too — a gate
+  must not treat a spelling nobody recognises as a key.
+  
+  Who is affected, in both directions:
+  
+  - `os dev` is unchanged. It spawns `os serve --dev`, which sets
+    `NODE_ENV='development'` before any plugin starts, so the watch-recompile loop
+    still gets its `200` and Studio still gets its reload frames.
+  - A deployment that was reaching this endpoint on a production-posture boot now
+    gets its host app's `404`. That door was never advertised, never in the SDK
+    (`@objectstack/client` builds no such URL) and is a build-tool loopback; if you
+    need a supported production reload trigger, that is a product decision, not
+    this endpoint.
+  - The server-side artifact-file watcher is untouched on every boot shape that had
+    it: the reload still happens, only the broadcast to (now absent) SSE clients is
+    skipped.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) a mounted HTTP route stops existing under a non-development posture; no authorable key, no spec declaration, no Zod schema and no stored value moves, so `objectstack migrate meta` has nothing to rewrite and no ledger entry could reach anyone this affects -->
+- ac4fefe: fix(metadata): key loader-held items by the row key they were stored under, so a body with no top-level `name` is no longer dropped from `list()` (#14205)
+  
+  `MetadataManager.readListUncached()` — and its no-catch sibling
+  `listForIndex()`, which builds the endpoint index — merged each loader's answer
+  into the result set keyed by `body.name`, and admitted an item ONLY when the
+  stored body carried a string `name`.
+  
+  A metadata body is not required to name itself. `register(type, name, data)`
+  takes the key as its ARGUMENT, and `assertMetadataRegisterContract` says so in
+  as many words: "A document with NO `name` of its own is fine — the argument is
+  the key". An aggregated `defineView` container is exactly that shape — no own
+  `name` by design, its identity being the target object, carried in the row's
+  `name` COLUMN — and `DatabaseLoader.rowToData()` returns the stored body
+  without folding the column into it.
+  
+  So a container written by `register('view', OBJECT, container)` lived in the
+  registry for the life of the process and was written to `sys_metadata`, and
+  then **disappeared at the next restart**: cold registry, only the loader
+  answering, and `list('view')` refused the row. `listDiagnosed()` reported that
+  short answer as complete (`degraded: false`) because no loader had thrown. Not
+  scoped to views — any loader-held body with no top-level `name` was invisible.
+  
+  **The repair.** A loader-held item's identity is the key its store holds it
+  under, so the manager now asks the loader for that key rather than guessing it
+  from the body: `MetadataLoader` gains an OPTIONAL `loadManyKeyed()` returning
+  `(name, body)` pairs, implemented by `DatabaseLoader` (from the row's `name`
+  column) and `MemoryLoader` (from its storage map key). The key travels BESIDE
+  the body and is never folded into it, so nothing synthesises a `name` into a
+  body that deliberately has none and the register contract's refusal of a
+  disagreeing `data.name` keeps meaning what it says.
+  
+  **Nothing consumers see today changes shape.** For any item that went through
+  `register()`, a `data.name` that exists is required to equal the key, so the
+  keyed merge produces the identical entry; what is new is only the items the old
+  gate refused. `loadManyKeyed()` is optional, and a loader without it (a
+  `RemoteLoader`, whose wire format carries bodies only) falls back to the
+  previous `body.name` keying unchanged — so no implementor of the published
+  `MetadataLoader` interface needs to change.
+  
+  `MetadataManager.loadMany()` is deliberately untouched: its `body.name` test is
+  a de-duplication guard, not an admission gate — a nameless item already fell
+  past it and was returned — so it never carried this defect.
+- 9e0ba21: feat(spec): retire the paper metadata-customization protocol with its full coupling set (#13135, re-charter of #12057; ADR-0049, ADR-0126)
+  
+  <!-- adr-0087: registered metadata-customization-protocol-retired -->
+  
+  **BREAKING** export removal + authorable-key retirement, landing after the
+  v17.0.0 cut (the lockstep launch-window convention ships it as `minor`; the
+  prescriptions are registered under protocol major 18 —
+  `RETIRED_DEFS_BY_MAJOR[18]`, `RETIRED_KEYS_BY_MAJOR[18]` and the D3 semantic
+  entry `metadata-customization-protocol-retired` — where `os migrate meta`
+  users will look).
+  
+  `kernel/metadata-customization.zod.ts` declared a three-layer platform/user
+  patch-overlay protocol (field-level change tracking, customization policies, a
+  3-way-merge story) that nothing reachable implemented: no route ever served
+  the paper `…/overlay` / `…/effective` endpoints, the only implementation
+  (`packages/metadata`'s manager limb) was called solely by its own unit tests,
+  no merge engine ever existed, and no code read a `CustomizationPolicy`.
+  ADR-0126 §6 wall 4 supersedes the protocol as a matter of record ("nothing may
+  build against it"); the maintainer adopted retirement on #12057 (2026-08-29,
+  「同意」), and #13135 charters the full coupling set the fork report measured.
+  
+  FROM → TO:
+  
+  - `MetadataOverlaySchema` / `FieldChangeSchema` / `CustomizationOriginSchema` /
+    `MergeConflictSchema` / `MergeStrategyConfigSchema` / `MergeResultSchema` /
+    `CustomizationPolicySchema` and their `…`/`…Parsed` types
+    (`@objectstack/spec/kernel`) → *(removed — no replacement protocol)*. The
+    customization that actually ships: ADR-0005's org-scoped overlay
+    (`allowOrgOverride` on `DEFAULT_METADATA_TYPE_REGISTRY`, `sys_metadata` org
+    rows, layered read `code`/`overlay`/`effective`) and ADR-0126's
+    packaged-metadata model (clone + ledger disable).
+  - `MetadataOverlayResponseSchema` / `MetadataOverlaySaveRequestSchema` /
+    `MetadataEffectiveResponseSchema` (`@objectstack/spec/api` §5) →
+    *(removed)* — contracts for endpoints no adapter ever served; the layered
+    read's contracts (`getMetaItemLayered`) are the live API.
+  - `IMetadataService.getOverlay` / `.saveOverlay` / `.removeOverlay` /
+    `.getEffective` optional members (`@objectstack/spec/contracts`) →
+    *(removed)*, together with `packages/metadata`'s in-memory limb and its
+    `'overlay'` feature log entry.
+  - `MetadataPluginConfig.customizationPolicies` / `.mergeStrategy` and
+    `MetadataManagerConfig.persistence.overlayWritable` → *(removed — retiredKey
+    tombstones)*: authoring one is now a `tsc` error and a parse error carrying
+    the prescription. Delete the keys; nothing replaces them (`persistence.writable`
+    remains the base write gate).
+  
+  One-line fix: delete the keys and any code building against the removed
+  exports — they configured and described nothing that ever ran; org-level
+  customization keeps riding the ADR-0005 overlay unchanged.
+  
+  The retirement kit: whole-module deletion + kernel barrel line; 10
+  `RETIRED_DEFS_BY_MAJOR[18]` entries (7 kernel defs + 3 api §5 contracts); 3
+  `RETIRED_KEYS_BY_MAJOR[18]` tombstone entries (no D2 conversion —
+  plugin/manager configs are not stack collection members, the
+  `kernel/MetadataPluginConfig:additionalTypes` precedent); D3 semantic entry
+  `metadata-customization-protocol-retired`; retirement pin test
+  (`kernel/metadata-customization-retirement.test.ts`); type-alias pin rows
+  Iso408-411 vacated; api-surface / export-origins / json-schema manifest /
+  authorable-surface / reference docs regenerated (the
+  `kernel/metadata-customization` reference page disappears with the module).
+- 4cda78c: fix(metadata,objectql,metadata-protocol): require a missing-table error to name the table that was READ (#13324)
+  
+  `isMissingTableError` answers the one question that licenses a fail-soft caller
+  to treat an empty result as the truth: "did this read fail because the table has
+  not been provisioned yet?". It matched the *shape* of the dialect phrase and
+  never asked WHICH table the phrase names.
+  
+  Measured on a real libsql database: a view whose base table is gone fails with
+  `no such table: main.<base>` when the view itself is read. The phrase matches,
+  so a read of a relation that **exists and may be backed by rows** was classified
+  benign, and every fail-soft consumer on that path — `probeInstallOrganizations`,
+  `resolveFileReferences`, `seedAutonumber`, the cascade-delete dependents probe,
+  `DatabaseLoader`, `SeedLoaderService`, the `sys_metadata` overlay reads —
+  computed its answer from data it never read. That is a false "benign", the
+  direction the module's own docblock calls far more expensive than a false
+  "real".
+  
+  The predicate now takes the object the caller was reading and refuses the
+  benign verdict when the phrase names a different relation. Shape alone cannot
+  separate the two cases: measured, a view over a missing base table and a
+  genuine missing table the caller qualified produce byte-identical messages, so
+  the read's name is a parameter rather than another regex.
+  
+  The parameter is **optional** — omitting it reproduces the previous behaviour
+  exactly, so no external caller of `@objectstack/metadata/errors` changes. Every
+  in-repo call site now passes it. The comparison folds away schema/database
+  qualifiers, the legacy `namespace__short` prefix and case, so every shape
+  recognised before for a genuine missing table (sqlite `no such table: X`,
+  Postgres `relation "x" does not exist`, MySQL `table "x" doesn't exist`,
+  `unknown table`, the SQLSTATE and errno limbs) still answers benign.
+- 3c1bbd2: fix(objectql,metadata): the ObjectQL boot loop derives a view container's object through the shared `deriveViewContainerObject`, so the row's own `name` is the LAST term at every SOURCE registrar (#14399)
+  
+  Three sites derive "which object does an aggregated `defineView` container bind
+  to". After #13407 / #13913 / #13912 all three read the container's own top-level
+  `object` before the `list.data.object` chain, but they still disagreed about the
+  row's own `name`:
+  
+  - `packages/objectql/src/engine.ts` `resolveMetadataItemName('views', item)` —
+    the boot-loop SOURCE registrar — read `name` FIRST, before `object`;
+  - `deriveViewContainerObject` (`@objectstack/metadata`, used by the artifact/HMR
+    SOURCE registrar and by `getViewsByObject()`) and `expandRuntimeViewContainer`
+    (`@objectstack/metadata-protocol`, the runtime door) both read `name` LAST.
+  
+  A container written as `{ name: 'lead_views', object: 'crm_lead', list: { … } }`
+  therefore registered under `lead_views` through the boot loop and under
+  `crm_lead` everywhere else, with the whole expansion (`<object>.<key>`) carried
+  along — and since `getViewsByObject()` / `GET /meta/view?object=` filter the
+  expanded items by their `object`, which registrar loaded the document decided
+  whether the views were addressable under the object at all. No error, no
+  diagnostic.
+  
+  The boot loop's container branch now calls `deriveViewContainerObject` — by
+  import, not by re-spelling: a fourth hand-copy of the chain was the defect, not
+  the repair. The direction is the 2026-08-07 meta-rule rather than taste (one
+  operation, two inconsistent implementations, the side bound by a DECLARATION
+  wins): `ViewSchema.object`'s own `.describe()` names its readers, while the boot
+  loop's order argued from item identity, which declares nothing about the
+  binding. The two sites that already held the winning order are untouched.
+  
+  **`@objectstack/metadata` — new public export (`minor`).**
+  `deriveViewContainerObject` was module-local; it is now on the package's root
+  entry, because `packages/objectql` is a SOURCE registrar for the same containers
+  and has to mint the same key. `packages/objectql` already declares
+  `@objectstack/metadata` as a dependency and nothing in `packages/metadata`
+  depends on `objectql`, so the import adds no cycle.
+  
+  **Scope of the behaviour change.** Only the `views` CONTAINER branch moves, gated
+  on `isAggregatedViewContainer`: the assembled `viewItems:` channel (standalone
+  ViewItems and flattened overlays, every member of `AssembledViewArtifactSchema`
+  requiring `viewKind`) still keys by its own `name` first, which is its identity
+  and not a binding. `item.id` is untouched and cannot fire for a container —
+  `ViewSchema` is a `strictObject` declaring `name` and `object` and no `id`.
+  
+  **No migration surface.** Measured on this tree: of the 54 non-test sources that
+  author or carry view containers, ZERO declare a `name` that differs from the
+  object they bind to, so every in-tree container derived identically at all three
+  sites before this change and does after it. What moves is the latent shape only.
+  
+  ⚠️ One card premise was measured false and is recorded in the new pin rather
+  than quietly dropped: the artifact/HMR registrar does not silently mint a second
+  key for a divergent container. It derives `crm_lead` correctly and then refuses
+  the whole artifact load — `assertMetadataRegisterContract` (#7378 row 1),
+  `VALIDATION_ERROR` / 400 — because the document's own `data.name` still reads
+  `lead_views`. The boot loop reconciles that field and the artifact door does
+  not; that residual asymmetry is a separate defect at a separate site and is
+  filed as its own card.
+
+### Patch Changes
+
+- 655b106: fix(metadata): register a `packages[]` artifact per package at the metadata door so every object has one owner across every door (#14599)
+  
+  A release artifact carrying `packages[]` (ADR-0130 D4) was read at the metadata
+  door as if it carried one package: `MetadataPlugin._parseAndRegisterArtifact`
+  iterated the **flattened top level** and stamped every item with the artifact's
+  own `manifest.id`. For an artifact composed with `composeStacks(…, { manifest:
+  'preserve' })` that id is one arbitrary member's — `selectManifest`'s `'last'`
+  pick — so a two-package artifact registered the **module's** object under the
+  **App** package's identity, while the ObjectQL load path, reading the same
+  artifact's `packages[]`, owned it under the module's.
+  
+  The platform then held two answers to "who owns this object", and which one a
+  consumer saw depended on the door it went through. Measured on a real boot of
+  `examples/app-multi-package`:
+  
+  - `GET /api/v1/meta/object` served `crm_order` **twice** — the list merge keys
+    slots by `${packageId}${name}`, so the two differently-attributed copies
+    landed in two slots;
+  - `GET /api/v1/meta/object?package=<the App package>` returned the **module's**
+    object, because the App-stamped copy was re-ingested into the registry as that
+    package's contribution;
+  - the layers door named the App package while the item door and
+    `GET /api/v1/packages` named the module;
+  - Studio's Data pillar for the App package listed the module's object — ADR-0130
+    Consequences §1.3a ("Studio's scope is the package") did not hold.
+  
+  **The door now reads both shapes, and attributes every item to the body it was
+  found in.** `packages` present → each assembled package body's collections are
+  registered stamped with **that body's** id; `packages` absent → the single
+  `manifest` branch runs exactly as before (D7). The owner is read off the body an
+  item was found in — never reverse-derived by matching a top-level item's name
+  against a name-to-package index, which would be the second metadata-identity
+  resolution path #14512's triage rejected by name.
+  
+  **Ordering and the entry gate are reused, not re-derived (D5).** The door calls
+  the same `resolveArtifactPackageOrder` the ObjectQL load path calls, so the two
+  readers of one `packages[]` cannot disagree about the registration order **or**
+  about which artifacts are loadable at all.
+  
+  ⚠️ **`resolveArtifactPackageOrder` / `artifactPackageId` moved to
+  `@objectstack/core`** — hence the `minor` there. They were in
+  `@objectstack/objectql`, which **depends on** `@objectstack/metadata`, so the
+  metadata door could not import them from where they lived; `@objectstack/core`
+  already owns `resolvePluginOrder` and is already a dependency of both readers,
+  so hosting them there adds **no edge** to the package graph. `@objectstack/objectql`
+  re-exports both under their existing names — its published surface is unchanged,
+  which is why it is graded `patch`. `@objectstack/runtime` is `patch` for the
+  dispatcher error vocabulary's `file:` anchors, repointed at the new path.
+  
+  **Single-package artifacts are byte-for-byte unaffected (D7)**, measured rather
+  than asserted: the whole `manager.register` sequence for a single-`manifest`
+  artifact — every call, in order, with the id and version each item was stamped
+  with — is pinned as a literal in
+  `packages/metadata/src/plugin-artifact-packages-attribution.test.ts` and was
+  recorded identically on both legs of the ablation. A real boot of
+  `examples/app-todo` answers every door identically before and after.
+  
+  **Nothing a booted instance can see today disappears.** Every live
+  `ARTIFACT_FIELD_TO_TYPE` key is a member of `AssembledPackageBodySchema`
+  (measured, not assumed), so iterating bodies loses no collection; and because
+  `packages` composes by `concat`, an artifact whose top level carries a
+  definition no package body repeats keeps it — registered once, attributed to the
+  artifact's own identity, and logged, because it means the artifact's two halves
+  disagree about what it ships.
+  
+  ⛔ The **producer** half is untouched: `composeStacks` and `os build` keep
+  emitting the flattened top level alongside `packages[]`. Whether they should is
+  #14512's decision, not this door's.
+- 54e2d36: Artifacts built by released 17.x tooling boot again on ≥17.2 runtimes: the artifact-ingestion door now runs a versioned ADR-0087 forward conversion before the strict parse (#12772).
+  
+  A compiled artifact whose declared `engines.protocol` floor predates the running `@objectstack/spec` version replays the full conversion chain — retired entries included — before validation, exactly the policy the stored-row read path already applies to `sys_metadata` rows. Measured incident: `dist/objectstack.json` built by `@objectstack/cli` 17.1.0 carries the then-legal `allowRestore`/`allowPurge` permission bits (75 of each, injected by the released builder), and spec 17.2.0's `retiredKey` tombstone refused the boot with no operator remedy (`os migrate meta` targets sources, not built artifacts).
+  
+  The conversion is versioned, not a blanket amnesty: an artifact authored at the current (or a newer) spec version converts nothing and still refuses at the tombstone — the retired keys return with the M2 lifecycle initiative (#1883), and artifacts authored against that surface are never stripped by history. Conversion notices surface operator-visibly and deduped, one summary line per conversion per artifact. New exports from `@objectstack/metadata-core`: `applyArtifactForwardConversions`, `resolveInstalledSpecVersion`, `parseRangeFloor`, `resolveDeclaredRange`.
+- 7ef0268: fix(metadata,runtime): retire the `policies` dead pointer in both artifact registrars, and pin the map that carried it (#12894)
+  
+  Zero behaviour change, by construction. Both readers of an artifact boot carried
+  a `policies` -> `policy` entry — the artifact door's `ARTIFACT_FIELD_TO_TYPE`
+  (`packages/metadata/src/plugin.ts`) and `AppPlugin`'s ADR-0057 `SECURITY_FIELDS`
+  list (`packages/runtime/src/app-plugin.ts`) — and **neither could ever match**.
+  `ObjectStackDefinitionSchema` is a `strictObject` that declares no top-level
+  `policies` key, so a definition carrying a `policies` array is refused outright
+  by the door's strict parse and reaches neither registry. The word is real but
+  lives one level down: on a permission set `policies` is an alias for
+  `rowLevelSecurity` (`PERMISSION_SET_KEY_ALIASES`) — a key on an **item**, never a
+  collection. Both entries are removed, each leaving in place the note the map
+  already writes for a retirement: what it pointed at, and why it could not match.
+  
+  That was the third entry retired from `ARTIFACT_FIELD_TO_TYPE` for exactly this
+  reason (`themes`, then `roles` -> `positions`, which "matched nothing and
+  silently dropped compiled positions"). So the deletion ships with the thing the
+  two predecessors did not have — a check that fails when the pattern recurs:
+  
+  - `check:stack-collection-maps` now reconciles **eight** hand-maintained
+    enumerations against the schema, not seven. `SECURITY_FIELDS` is the new
+    eighth, and how it was missing is the finding rather than a footnote: it is
+    the only one of the eight that pairs its keys as `[collection, kind]` tuples,
+    which neither existing extractor could read, so the site was skipped rather
+    than reported. Re-adding `policies` — or any other key the schema does not
+    declare — to **either** registrar now fails the gate with the site named.
+  - A new `tupleFirstItems` extractor reads that shape, with a self-test case
+    (13 assertions, up from 12) covering the comment/nesting cases the flat
+    string-array extractor already pins.
+  
+  The mirror-image half of the same measurement is **carried, not shipped**:
+  `capabilities` is a declared top-level collection that `SECURITY_FIELDS`
+  registers and the door's map does not, making `AppPlugin` its sole registrar on
+  an artifact boot. Adding it to the door changes what an artifact boot registers,
+  so it is measured and handed to the route-ownership decision (#12892) instead of
+  being smuggled in here. The new waiver row records the asymmetry in place.
+- b745157: feat(metadata-core,metadata): warn the operator when a pre-current-era artifact carries form-view predicates that fault open (#12915)
+  
+  A form-view predicate binds `record` (+ `previous`, `parent`) in runtime record
+  forms, or `data` in metadata-editing forms. The contract states the failure mode
+  beside the vocabulary: **a bare identifier is unbound, the predicate faults, and
+  `visibleWhen`'s fault fallback is `true`** — so a field the predicate was
+  authored to hide renders for everyone.
+  
+  That is quiet alone and lethal in combination with the authoring pattern it
+  serves. Measured on a real deployment: an artifact built by released
+  `@objectstack/cli` 17.1.0 authors
+  `{ field: 'disqualification_reason', required: true, visibleWhen: 'status == "unqualified"' }`
+  — the era's working spelling. On a 17.2 runtime the predicate faults open, the
+  conditionally hidden field renders, and its unconditional `required: true`
+  blocks **every** record creation through the console, while the same payload
+  POSTs 201 through REST. Nothing refused and nothing logged, so the operator —
+  the only person who can rebuild the artifact — had no signal at all.
+  
+  The framework artifact door now emits **one deduped `warn` line per artifact**
+  naming the authored `engines.protocol` floor and the runtime spec version, how
+  many predicates on which views (with the first path as an anchor), the
+  fault-open consequence, and the remedy (`os build`). It rides the same funnel
+  that already carries the forward-conversion summaries, so both SaaS shapes are
+  covered: a single-DB multi-org runtime warns once at boot, and per-tenant-DB
+  kernels each warn at their own.
+  
+  **No behaviour change.** No refusal, no rewrite, no schema or contract edit —
+  the predicate keeps faulting open exactly as before, and the artifact bytes are
+  untouched. Rewriting a bare root to `record.` is a separate, deferred ADR-0087
+  conversion.
+  
+  **Scoped to legacy artifacts by construction.** The notice fires only inside the
+  versioned window the forward conversion already opens (declared floor below the
+  running spec, or undeclared), read off that pass's own verdict rather than
+  recomputed. An artifact declaring the current or a newer floor gets zero notices
+  from this feature even when it carries bare roots — the boundary that keeps a
+  notice about legacy artifacts out of contract territory.
+  
+  Detection is exported from `@objectstack/metadata-core` as
+  `detectUnboundFormViewPredicateRoots` (with `BOUND_FORM_VIEW_PREDICATE_ROOTS`)
+  so other composed artifact doors can reuse one policy rather than fork it. It is
+  pure, read-only, and tuned to prefer silence over a false accusation: string
+  literals are stripped before the scan, only root position counts, call targets
+  are not roots, comprehension macros (whose iteration variable is locally bound)
+  are skipped whole, and AST-only envelopes pass.
+- 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. -->
+- e7191ce: fix(build): give each `exports` condition its own `types` target in the 28 dual-build packages (#13112)
+  
+  **Published-surface change, zero runtime change.** No emitted byte moves; what
+  moves is which declaration file a resolver READS. Maintainer ruling 2026-08-29
+  (decision batch #3, verbatim 「同意」) chose declaring the files over deleting
+  them.
+  
+  ## What was wrong
+  
+  These 28 packages are `"type": "module"` and dual-built, and each spelled one
+  `types` condition as a **sibling** of `import`/`require`:
+  
+  ```json
+  "exports": { ".": {
+    "types": "./dist/index.d.ts", "import": "./dist/index.js", "require": "./dist/index.cjs"
+  } }
+  ```
+  
+  A sibling `types` answers for **both** conditions, so a CommonJS consumer was
+  handed `dist/index.d.ts` — an ES-module declaration, because the package is
+  `"type": "module"` — for an entry point it reaches with `require`. Measured with
+  `tsc --traceResolution` on a `"type": "commonjs"` fixture at `moduleResolution:
+  node16`:
+  
+  ```
+  error TS1479: The current file is a CommonJS module whose imports will produce
+  'require' calls; however, the referenced file is an ECMAScript module and cannot
+  be imported with 'require'.
+  ```
+  
+  The JavaScript at `dist/index.cjs` loads perfectly (`check:dual-build-cjs-loads`
+  has asserted that for months). It is the **types** that told the consumer the
+  supported `require` entry point could not be required. The `dist/index.d.cts`
+  twin tsup emits beside it — 36 files, 5,517,701 B on this build — was named by
+  no condition at all and shipped in every tarball unreachable.
+  
+  ## What changed
+  
+  Each condition now names its own declaration, the shape TypeScript documents:
+  
+  ```json
+  "exports": { ".": {
+    "import":  { "types": "./dist/index.d.ts",  "default": "./dist/index.js" },
+    "require": { "types": "./dist/index.d.cts", "default": "./dist/index.cjs" }
+  } }
+  ```
+  
+  33 entry points across 27 packages, subpaths included. The root `types` field is
+  untouched, so `node10` resolvers are unaffected; the `import` condition resolves
+  exactly what it resolved before, measured as an unchanged control in the same
+  run.
+  
+  ## `@objectstack/core` is deliberately NOT changed
+  
+  Splitting a declaration in two makes TypeScript compare it nominally, and
+  `ObjectKernel` carries a `private plugins` member that reaches every plugin
+  through `PluginContext.getKernel()`. With core split, whole-repo `pnpm build`
+  fails in `@objectstack/verify` with 5 × TS2345 ("Types have separate
+  declarations of a private property 'plugins'"); with core held back and the
+  other 27 split, 71/71 tasks pass. So core keeps the sibling-`types` shape and
+  its two `.d.cts` files (220,854 B) stay unreachable, declared as such in
+  `check:dual-build-cjs-loads`. Splitting it needs a decision about core's public
+  types, not about an exports map.
+  
+  ## For consumers
+  
+  - **ESM consumers: nothing changes.** Same declaration file, byte for byte.
+  - **CJS consumers under `node16`/`nodenext`: TS1479 goes away** and the
+    declarations they get are the ones built for CommonJS.
+  - **`node10` / `moduleResolution: node` consumers: nothing changes** — they never
+    read `exports`.
+  - Nothing is removed: every path that resolved before still resolves.
+  
+  Packages that are CJS-first (`require` → `./dist/index.js`, no `"type": "module"`)
+  were already correct and are untouched — their `dist/index.d.ts` really is the
+  CommonJS declaration. Their ESM mirror (an unreachable `.d.mts` under the
+  `import` condition) is a separate, larger population and is filed separately per
+  the ruling, not fixed here.
+  
+  `check:dual-build-cjs-loads` grew a fourth invariant (TYPED) that reds on the old
+  shape, so the drift cannot return silently.
+- 2e471e3: `FilesystemLoader` now implements `loadManyKeyed()`, so a metadata file whose
+  body has no top-level `name` is no longer invisible to `MetadataManager.list()`.
+  `loadMany()` globbed files and pushed bodies, discarding the path it had just
+  read; the manager then fell back to keying by `body.name`, which drops every
+  nameless body — an aggregated `defineView` container has none by design. That is
+  the #14205 defect, unrepaired for this loader until now.
+  
+  The key is this loader's own name-to-path derivation — the basename minus
+  extension, the same one `list()` reports — but only where that derivation is a
+  bijection for the file: it sits directly under `ROOT/TYPE/` and carries an
+  extension `findFile()` tries, so `findFile(type, key)` resolves back to that same
+  file. Every other shape (a nested path, an extension-less file) keeps the
+  previous behaviour verbatim: keyed by `body.name` when it has one, dropped when
+  it has none. `list()` and `findFile()` disagree outside the flat shape — `list()`
+  reports the bare basename for a nested file and `findFile()` cannot resolve it —
+  so keying those by the basename would mint names `get()` and `exists()` cannot
+  open, and two directories holding one basename would collide silently. Repairing
+  the derivation itself is tracked separately.
+  
+  One deliberate consequence: a flat file whose `body.name` disagrees with its
+  basename is now keyed by the basename. That is #14205's rule (identity is the
+  key the store holds an item under, not `body.name`) applied to this loader, and
+  it aligns `list()` with `listNames()` for that shape. `loadMany()`'s own
+  signature and answer are unchanged; both methods now share one file walk so
+  their bodies cannot drift.
+- 200d255: fix(metadata-core,metadata): a form SECTION binds `current_user` too, so the unbound-root notice stops flagging one (#13072)
+  
+  Second correction to the unbound-root boot notice, and the same defect as the
+  first one a surface later. The notice judged a SECTION-level predicate against
+  `record` / `previous` / `parent` / `data`, sourced faithfully from the section
+  contract prose — which was stale.
+  
+  `current_user` and its ADR-0068 alias roots (`user`, `ctx.user`, `os.user`)
+  **resolve on a section-level `visibleWhen`**: objectui#6110 threads the host
+  shell's predicate scope into `isSectionVisible` where it used to pass
+  `undefined`, and objectui#6111 copies the authored `visibleWhen` onto the
+  `section-divider` pseudo-field whose predicate the SDUI form renderer evaluates
+  with that scope bound. #12914 re-measured the contract text accordingly. Until
+  this change, a legacy artifact carrying a legitimate section-level
+  `current_user.role == "admin"` predicate was reported at boot as an unbound root
+  that faults open — a notice about a predicate that resolves, which is the
+  cry-wolf failure the module's own doc forbids and the one that trains operators
+  to ignore the channel.
+  
+  **What changes:** one vocabulary now serves both form-view predicate surfaces —
+  `record`, `previous`, `parent`, `data`, `current_user`, `user`, `ctx`, `os`. A
+  section predicate rooted at the `current_user` family is silent; a section
+  predicate rooted at a bare field identifier is still reported, and the operator
+  line still prints the rule per surface for the surfaces the findings implicate.
+  
+  **Blast radius, stated without inflation:** this is a **notice**, not a refusal
+  — no parse change, no gate, no behaviour change, and it only runs inside the
+  versioned window `applyArtifactForwardConversions` opens. The cost it removes is
+  a false operator signal on legacy artifacts, not a broken runtime.
+  
+  **Removed export, with its migration:** `FIELD_ONLY_BOUND_PREDICATE_ROOTS` is
+  gone from `@objectstack/metadata-core`. The section binding empties it, and an
+  exported constant named `FIELD_ONLY_…` holding `[]` asserts a per-surface
+  difference that no renderer makes. FROM → TO: read
+  `BOUND_FORM_VIEW_PREDICATE_ROOTS` (every root bound on any form-view predicate)
+  or `BOUND_FORM_FIELD_PREDICATE_ROOTS` (the field question, the same list today).
+  No consumer can be carrying it: the notice has never shipped — the two
+  changesets that introduce it are still pending in `.changeset/`, the newest
+  published `@objectstack/metadata-core` is 17.2.0, and the commit that added
+  `form-predicate-root-policy.ts` is in no release tag. This was the last moment
+  at which the removal cost nothing.
+  
+  **Why the vocabulary is no longer justified by quoting the contract.** Both
+  times this list has been wrong, it was wrong by transcribing a correct-looking
+  sentence that the renderer had already moved past. The prose is a transcription
+  of a renderer and can only lag one, so membership is now stated as the mechanism
+  — *a root is bound on a surface iff some renderer threads a scope carrying it
+  into that surface's evaluator* — with the threading site named per entry, and
+  the module's test reads the LIVE `.describe()` text of
+  `FormFieldSchema.visibleWhen` / `FormSectionSchema.visibleWhen` out of
+  `@objectstack/spec` instead of copying it into a comment. A comment quoting that
+  sentence goes stale in silence, twice now; an assertion that fetches it cannot.
+  
+  <!-- adr-0087: not-required (unpublished) the removed export FIELD_ONLY_BOUND_PREDICATE_ROOTS was added after 17.2.0 and is in no release tag, so no upgrader can be holding it and there is nothing to migrate from. -->
+- 2852acc: fix(metadata-core,metadata): split the form-view predicate root vocabulary per surface, so a field-level `current_user` test is not false-flagged (#12915)
+  
+  Same-day correction to the unbound-root boot notice. The notice judged **every**
+  form-view predicate against one vocabulary (`record` / `previous` / `parent` /
+  `data`), sourced faithfully from the contract prose — which, for the field-level
+  slot, was stale.
+  
+  `current_user` and its ADR-0068 alias roots (`user`, `ctx.user`, `os.user`)
+  **resolve on a field-level `visibleWhen`** since objectui#6010; three spec text
+  sites still said otherwise until #12930 re-measured them, and one of those sites
+  was the sentence this policy was written against. A legacy artifact carrying a
+  legitimate `current_user.role == "admin"` field predicate was therefore reported
+  as faulting open — the cry-wolf failure the notice is explicitly built to avoid,
+  and the one that trains operators to ignore the channel.
+  
+  The vocabulary is now per surface, which is what the contract actually says:
+  
+  - **Field-level** (`BOUND_FORM_FIELD_PREDICATE_ROOTS`): the shared base plus
+    `current_user`, `user`, `ctx`, `os`. Silent on all of them.
+  - **Section-level** (`BOUND_FORM_VIEW_PREDICATE_ROOTS`, unchanged in name and
+    value): the base alone. `current_user` is still flagged there — the section
+    docblock states it is unbound at that level and faults open.
+  
+  Two limits of the field binding deliberately do **not** change the answer: it is
+  a rendering rule rather than authorization (an authoring hazard, not a
+  version-drift one), and the scope is empty on the console's public `/f/:slug`
+  route (equally true of a freshly built current artifact, so it says nothing
+  about the artifact's era — the only thing this notice claims to detect).
+  
+  The emitted warn line now prints the bound roots **per surface, and only for the
+  surfaces the findings implicate**, so an operator is never shown a rule their
+  artifact has no instance of. Findings carry a `surface` field.
+  
+  `unboundRootsInCelSource` takes the vocabulary as an optional second argument;
+  its default is unchanged (the stricter base), so existing callers behave exactly
+  as before.
+- f7be03f: fix(metadata): `getViewsByObject()` expands aggregated view containers instead of answering empty (#13913)
+  
+  `MetadataManager.getViewsByObject()` reads `this.list('view')` — the manager's
+  own registry + loader store, which is a completely different store from the
+  `sys_metadata` rows the REST route (`GET /meta/view?object=`) reads through
+  `getMetaItems`. #13407 taught that route to expand a runtime-authored aggregated
+  `defineView` container inline; this exit never called it and had no equivalent
+  step, so a container the REST route now serves still answered **empty** here —
+  for every internal/SDK caller that uses this entry point rather than the route.
+  
+  Getting the container into the store was never enough on its own: the filter
+  also requires `viewKind`, and a container has none. Relaxing that requirement
+  would answer with the container itself as a view — the behaviour #7163 ruled
+  wrong — so the repair adds the container's **expansion**, whose items each carry
+  the `viewKind` + `object` pair this filter has always tested. The filter is
+  untouched; it reads the top-level `object` exactly as `ViewSchema.object`
+  declares.
+  
+  The expansion is registry-free and per-read, mirroring #13407's choice at the
+  other exit and for the same reason: the registry is process-wide, so a read must
+  not graft rows into it. Already-present names win, so a container whose expanded
+  ViewItems were registered by a source registrar (the ObjectQL boot loop, the
+  artifact/HMR loader) still answers with those registered, fully-enriched items
+  and gains nothing new.
+  
+  The object-derivation chain (`object` → `list.data.object` → `form.data.object`
+  → the row's own `name`) now has one spelling for this package, in the new
+  `view-container-expansion.ts`, rather than a third private copy to fall behind.
+- e7f56d6: Make the settings engine facade and the metadata database loader bind the row
+  they resolved, not a row the payload names
+  
+  Two ingresses resolved an authoritative row id and then folded it into the
+  write payload with the **losing** spread order — `{ id, ...data }` — so a
+  caller-supplied `data.id` spread over the id the ingress had just resolved and
+  silently retargeted the write:
+  
+  - `wrapEngineAsSettingsEngine`'s by-id `update` branch
+    (`@objectstack/service-settings`), whose id comes from the caller's
+    `where.id`.
+  - `DatabaseLoader._update` (`@objectstack/metadata`), whose id arrives as a
+    separate parameter every caller resolves first (`existing.id`, from the read
+    immediately above).
+  
+  Both now spell it `{ ...data, id }` — the operation's id **after** the spread,
+  so it wins. That is the convention the repo's other two ingresses already
+  document: `rest-server.ts`'s batch update arm ("the operation's id AFTER the
+  spread, so it wins") and `protocol.updateData`'s #6479 fix
+  (`{ ...request.data, id: request.id }`).
+  
+  **No wrong write is known to have been reachable.** Both sites' current callers
+  build fresh field literals and never put an `id` inside `data`, so this is
+  hardening a fragile pattern rather than repairing a measured defect. What makes
+  it worth the three characters is that neither site can be caught downstream:
+  both pass **no `where`** to the engine, so the payload is the only id the engine
+  ever sees, and the engine's conflicting-id refusal (`UPDATE_ID_MISMATCH`, 400)
+  needs two disagreeing declarations before it can fire. The fold is the entire
+  trust boundary at both sites, and it is one refactor — a caller handing back a
+  row copy, and rows carry `id` — from the #6479 shape.
+  
+  Both are pinned with a payload whose `id` names a **different** row than the
+  one the ingress resolved, asserting the resolved row is still the row bound. A
+  pin exercising a payload without an `id` would have passed against both
+  spellings. The doubles answer "which row does this bind?" with the producer's
+  own `assertEngineUpdateDispatch`, so they cannot be kinder about it than a
+  running server.
+- 41aa979: Artifact/HMR loader: read a view container's own top-level `object` field
+  
+  `MetadataPlugin`'s artifact/HMR registrar derived which object a `defineView`
+  container binds to by walking `list.data.object` then `form.data.object`, and
+  never consulted the container's own top-level `object` — the field
+  `ViewSchema.object` documents as "how a stack-level `views: [...]` entry says
+  which object its views belong to; read by `getViewsByObject()` /
+  `GET /meta/view?object=`".
+  
+  A package-shipped `defineView({ object: 'crm_lead', list: { columns: [...] } })`
+  therefore registered nothing at all through this path: the container was dropped
+  before registration, so no expanded `crm_lead.<key>` ViewItems were produced and
+  `getViewsByObject('crm_lead')` / `GET /meta/view?object=crm_lead` answered empty
+  for it. Both derivation sites now call the package's single spelling of that
+  derivation (`deriveViewContainerObject`), which consults the container's own
+  `object` first and keeps the existing `list.data.object` → `form.data.object` →
+  row-name fallback unchanged for every container written before that field was
+  read here. This is the same order #13407 settled at the runtime door.
+- a7002ce: Canonicalise driver-materialised timestamps at the metadata adapter boundaries
+  
+  `MetadataItem.authoredAt` is declared `z.string()` ('ISO-8601 timestamp') and
+  `MetadataStats.mtime` is declared `z.string().datetime()`, but three producers
+  adapted a driver row into those declared types without converting the value.
+  `created_at` / `updated_at` are builtin audit columns and `recorded_at` is a
+  declared `Field.datetime`; `SqlDriver#formatOutput` repairs both only inside its
+  `if (this.isSqlite)` arm, so on Postgres and MySQL a JS `Date` landed in a field
+  every consumer reads as a `string`.
+  
+  `SysMetadataRepository#get` / `#getByHash` and `DatabaseLoader#stat` now emit
+  canonical ISO-8601 text on every dialect, matching the sibling producers that
+  already spelled it correctly. Values that were already canonical (SQLite) pass
+  through byte-identically.
+- 77a532d: Five metadata adapter boundaries now emit the ISO-8601 string their declared type promises
+  when the driver hands them a JS `Date`, instead of asserting `as string` over it
+  
+  `MetadataRecord.createdAt` / `.updatedAt` and `MetadataHistoryRecord.recordedAt` are
+  declared `z.string().datetime()`, and `MetadataEvent.ts` is declared `z.string()`. Four
+  producers in `DatabaseLoader` (`rowToRecord`, `getHistoryRecord`, `queryHistory`) and one
+  in `SysMetadataRepository` (`rowToEvent`) reached those fields through an unchecked
+  `row.<column> as string` cast, which is an assertion about a driver row rather than a
+  measurement of one — so nothing type-checked and nothing reported it.
+  
+  On Postgres and MySQL the assertion is false for both column classes involved.
+  `SqlDriver#formatOutput` repairs the builtin audit columns and folds declared
+  `Field.datetime` columns only inside its `if (this.isSqlite)` arm, and
+  `withPostgresCalendarDayAsText` leaves `timestamptz` / `timestamp` deliberately untouched
+  because those are instants. A column being declared `Field.datetime` therefore does **not**
+  protect it: on the production default driver both classes come out of the record read door
+  as a `Date`, and `.datetime()` is a refinement a `Date` fails outright. Nothing has failed
+  yet only because no production path parses these values today.
+  
+  The repair is producer-side, at the adapter boundary that asserts the declared type — not
+  a tolerant fallback in a consumer, and not a change at the driver's read door, which would
+  reverse a deliberate driver decision. Callers keep their existing behaviour for every other
+  shape: an already-canonical SQLite string passes through byte-identically, an absent column
+  still yields `undefined` so each caller's `?? <default>` chain means what it meant, and an
+  Invalid `Date` is handed through unchanged rather than converted, because what the shared
+  canonical-ISO spelling should do with that one input is still being decided.
+- 93940d4: `DatabaseLoader`'s private driver-path update helper is typed with the `null` arm `IDataDriver.update()` now declares; both of its callers discard the result. No runtime behaviour changes.
+- 8225248: fix(metadata): drop the leftover boot-time debug probe from `MetadataPlugin.init` (#14527)
+  
+  `MetadataPlugin.init()` printed a bare `console.log` immediately after
+  `ctx.registerService('metadata', this.manager)`, reporting
+  `typeof this.manager.getRegisteredTypes`. Nothing gated it on `NODE_ENV`, a debug
+  flag or a logger level, so every kernel boot that installs `MetadataPlugin` wrote
+  it to stdout: the CLI, the dev server and any embedding host alike.
+  
+  What it printed was a probe, not information. `getRegisteredTypes` is a method the
+  class declares statically, so the `typeof` it reported cannot vary in a way an
+  operator could act on, and a repo-wide search finds no reader of the string. The
+  `ctx.logger.info('Initializing Metadata Manager', ...)` call three lines above
+  already announces the same lifecycle step through the plugin's own logger, carrying
+  the fields that are actually actionable (`root`, `watch`, `artifactSource`). Deleted
+  rather than demoted to `ctx.logger.debug` on that reading: once the reported fact is
+  statically known and unread, there is no shape check left worth keeping.
+  
+  Observable change: one fewer line on stdout at boot. No API, no types, no behaviour
+  beyond the removed print. On the two paths where a stray stdout line would break a
+  parser — `--json` payloads and the `os serve` protocol channel — the CLI already
+  reserves stdout by redirecting to stderr, so nothing downstream was relying on this
+  line's presence or its absence.
+  
+  The file's five other `console.*` calls (the dev HMR path) are deliberately
+  untouched: each carries its own marker, and the one that prints on every
+  non-development boot carries a written rationale for doing so.
+- 0ae9e1e: fix(metadata): `migrateProjectIdToEnvironmentId`'s raw-driver guard stated its instruction sentence twice (#13219)
+  
+  An operator who called `migrateProjectIdToEnvironmentId` with a driver that has
+  no `raw()` was refused correctly, but read the same remedy twice in one message:
+  
+  ```
+  migrateProjectIdToEnvironmentId: driver must expose a .raw(sql, bindings?) method. migrateProjectIdToEnvironmentId: driver must expose a .raw(sql, bindings?) method. SqlDriver (better-sqlite3/knex) supports this; cloud-side TursoDriver also conforms.
+  ```
+  
+  The sentence was concatenated twice, a copy-paste artifact — the sibling
+  `migrateEnvIdToProjectId` carries the correct single-sentence form of the
+  identical guard. Cosmetic and operator-facing only: the guard fires on exactly
+  the same condition, the remedy it names is unchanged, and nothing parses the
+  message. The duplicate line is deleted; the surviving sentence keeps the
+  trailing space that separates it from the one naming the conforming drivers.
+  
+  The refusal case in the package's tests now pins the properties — the
+  instruction appears exactly once, no sentence runs into the next, and the
+  supporting sentence is still present — rather than substring-matching the
+  message, which could not see a second copy and so passed either way.
+- ef76342: fix(metadata): stop `migrateProjectIdToEnvironmentId` renaming into a column no declaration knows about (#13205)
+  
+  `AFFECTED_TABLES` was a hand-written list, and it outlived the declarations it
+  described. The branch/project-removal amendment (M1) took `environment_id` out
+  of `sys_metadata_history`'s declaration in `@objectstack/metadata-core`; the
+  migration kept naming that table. Its only guard asks whether `project_id` is
+  present **physically** (`_columnExists`) — which says nothing about the target
+  column being **declared** — so against any database whose physical
+  `sys_metadata_history` still carried the pre-v5 column, the migration renamed it
+  to `environment_id`: a fresh orphan column that no declaration, no `syncSchema`
+  and no reader knows about.
+  
+  The list is now **derived from the declarations** rather than restated beside
+  them. A candidate table is migrated only if its current declaration carries the
+  target column, so the two cannot drift apart again — the derivation and the
+  declaration are the same fact. `@objectstack/metadata-core` was already a
+  dependency of this package, so this adds no dependency edge.
+  
+  A candidate that does not declare the target column is now **reported** as
+  `status: 'skipped_not_declared'` (an additive member of the result union)
+  instead of silently vanishing from the result array: an operator reading the
+  results can tell "considered and deliberately skipped" from "forgotten again",
+  which is the state this defect started in.
+  
+  The sibling `migrateEnvIdToProjectId` is deliberately left alone: its target
+  (`project_id`) is an intermediate column that no current declaration carries by
+  design, so the "target must be declared" rule is sound only for the terminal
+  migration in the chain.
+  
+  No behaviour changes for `sys_metadata`, whose declaration does carry
+  `environment_id`: it is renamed exactly as before.
+- 2a18117: fix(metadata): every migration in `@objectstack/metadata/migrations` refused every driver this repo ships (#14023)
+  
+  All four helpers exported from `@objectstack/metadata/migrations` guarded on —
+  and drove through — `driver.raw(sql, bindings?)`. **No data driver in this repo
+  defines `raw`.** `SqlDriver` keeps its knex handle `protected` and declares no
+  `raw` member, and `SqliteWasmDriver` inherits that; the only `raw(` member
+  anywhere outside a test double is an HTTP harness in `packages/verify` whose
+  signature is `(path, init)`. So an operator who passed their platform driver was
+  refused by all four:
+  
+  ```
+  migrateSysNotificationToEvent({ driver, data })  ->  { status: 'error', migrated: 0 }
+  ```
+  
+  The failure was quiet in the shape that matters. `migrateSysNotificationToEvent`
+  *returns* `{ status: 'error' }` rather than throwing, and the message blamed the
+  caller's driver for lacking a method instead of saying the migration had not
+  run — so someone following the ADR-0030 cut-over runbook, which names this call
+  as the supported way to preserve users' existing bell notifications, would read
+  it as a problem with their own driver.
+  
+  It was not only an operator-facing path. `DatabaseLoader` calls
+  `migrateProjectIdToEnvironmentId(driver)` on bootstrap with a real driver, at
+  two call sites, each wrapped in a catch — so the v5.0 `project_id` ->
+  `environment_id` forward migration threw and was swallowed on every boot.
+  
+  The four helpers now resolve their raw-SQL entry point through one shared
+  resolver (`src/migrations/driver-exec.ts`) that tries `execute` first and falls
+  back to `raw`. `execute` goes first because it is the surface the contract
+  declares: `IDataDriver` (`@objectstack/spec/contracts`) declares
+  `execute(command, parameters?, options?)` **non-optionally**, with bound
+  parameters as the second positional argument — exactly the shape `raw(sql,
+  bindings?)` was being called in — and has never declared `raw`. `raw` is kept as
+  a fallback so a host or third-party driver that does define it keeps working;
+  nothing that worked before stops working, and the refusal now fires only for a
+  driver offering neither surface.
+  
+  Two sibling directories already resolved both surfaces instead of assuming one,
+  in opposite orders (`metadata-protocol`'s `partial-index-probe` tries `raw`
+  first, its `seed-tenancy-backfill` tries `execute` first, and `protocol.ts`'s
+  `ensureOverlayIndex` is a third). One operation with three implementations and
+  two behaviours resolves to the declaration-bound side, which is why this
+  directory adopts `execute`-first uniformly rather than copying either precedent.
+  
+  The refusal message now names both surfaces. It keeps the properties pinned
+  after the doubled-sentence defect: the remedy is stated exactly once, the
+  sentences stay separated, and a conforming driver is still named.
+  
+  Tests: every pre-existing case in this directory built its own double carrying a
+  `raw` method — including the case asserting the guard fires — so the suite
+  pinned the guard's wording while never exercising a driver the platform ships.
+  Swapping `raw` for `execute` in the helpers and in the doubles would have moved
+  that hole rather than closed it. A new `real-driver-exec-surface.test.ts` drives
+  all four migrations through a real `SqliteWasmDriver` against real in-process
+  SQLite, asserting the physical schema rather than the returned status, and pins
+  the surface reality the file exists for: the real driver has no `raw` and does
+  have `execute`.
+- c9d4de3: fix(metadata): `migrateSysNotificationToEvent` writes canonical ISO timestamps, not `Date.prototype.toString` (#13998)
+  
+  `selectLegacyRows` reads the legacy `sys_notification` table through
+  `driver.raw`/`execute` — a door that does not run `formatOutput`, so none of its
+  repairs apply. On SQLite the legacy stamps come back as canonical ISO text and
+  `String(row.created_at)` is the identity. On Postgres and MySQL an instant
+  column materialises as a JS `Date`, so the migration wrote
+  
+  ```
+  Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)
+  ```
+  
+  into `created_at` on the new `sys_inbox_message` row and into `created_at` / `at`
+  on the new `sys_notification_receipt` row — whole seconds in the **migrating
+  host's** zone with the milliseconds dropped, or a value no dialect's timestamp
+  grammar accepts at all. The migration is one-way, so that spelling is what the
+  platform would carry afterwards.
+  
+  Both stamps are now canonicalised at the migration, matching the repo's existing
+  correct form: a `Date` is rendered with `toISOString()`, ISO text passes through
+  untouched. Neither column could be repaired further upstream —  `created_at` is a
+  builtin audit column that `formatOutput` repairs only in its `if (this.isSqlite)`
+  arm, and `read_at` is a legacy column ADR-0030 removed from the object, so it is
+  not a declared `Field.datetime` either and no coercion could ever reach it.
+  
+  Pinned with a hand-made `Date` driven through the migration's read path under a
+  forced process zone, which is what breaks the SQLite identity that kept the
+  existing cases green while the defect was live.
+- a23603e: fix(runtime,metadata): the default local environment id is `env_local`, not `proj_local` (#13366)
+  
+  The v5.0 `project` to `environment` rename changed the default local environment
+  id and shipped that change on the surfaces most people meet: `packages/cli`'s
+  `CHANGELOG.md` records "Default local env id: `proj_local` -> `env_local`", the
+  `os dev` / `os start` / `os serve` commands emit `env_local`, and
+  `content/docs/deployment/cli.mdx` documents `env_local` as the default. Two
+  sites never received it and kept stamping `proj_local`.
+  
+  FROM: `createStandaloneStack()` — with no `environmentId` in its config and no
+  `OS_ENVIRONMENT_ID` in the environment — stamped `proj_local` on the kernel it
+  composed, and `MetadataPlugin` used `proj_local` to fill the environment-artifact
+  validation envelope for a bare definition.
+  
+  TO: both stamp `env_local`.
+  
+  WHO SEES IT. Two audiences, both on the DEFAULT path — no `environmentId` in
+  the config and no `OS_ENVIRONMENT_ID` in the environment:
+  
+  1. a host that calls `createStandaloneStack` / `createDefaultHostConfig`
+     **directly**;
+  2. a **bare `os serve`** — one not spawned by `os dev` / `os start`. Those two
+     commands export `OS_ENVIRONMENT_ID=env_local` into the child process, which
+     the fallback yields to, so a boot they start never reached the changed line.
+     `os serve` sets no such variable for its own boot: it only READS one to name
+     the runtime state file. So a bare `os serve` used to run a kernel stamped
+     `proj_local` while publishing `runtime.env_local.json` beside it; the two now
+     agree.
+  
+  Where the id is observable — row scoping in `ObjectQLPlugin`, the
+  `X-Environment-Id` header, `sys_metadata.environment_id` — such an embedder now
+  sees `env_local` where it saw `proj_local`, so an install with rows already
+  written under the old id should set `environmentId: 'proj_local'` (or
+  `OS_ENVIRONMENT_ID=proj_local`) explicitly to keep them addressed. That escape
+  hatch is unchanged and still wins over the default.
+  
+  NOT CHANGED, deliberately: `@objectstack/cloud-connection` still treats BOTH
+  spellings as the local sentinel, so a persisted `OS_ENVIRONMENT_ID=proj_local`
+  config keeps being recognised as local rather than presented to the control
+  plane as a cloud environment id; and `package-state-store`'s separate `'default'`
+  fallback keeps its own spelling, because renaming it would re-key persisted
+  package-disable state files.
+- 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 [efb3513]
+- Updated dependencies [d62f990]
+- Updated dependencies [c45d8e6]
+- Updated dependencies [2e3e8c7]
+- Updated dependencies [e621291]
+- Updated dependencies [655b106]
+- Updated dependencies [40a93b5]
+- Updated dependencies [101ad2c]
+- Updated dependencies [d5b330d]
+- Updated dependencies [dda969c]
+- Updated dependencies [1f45690]
+- Updated dependencies [277948f]
+- Updated dependencies [8bdd955]
+- Updated dependencies [54e2d36]
+- Updated dependencies [b745157]
+- Updated dependencies [f3bbbef]
+- Updated dependencies [4f24e9d]
+- Updated dependencies [e27583e]
+- Updated dependencies [4bd6faa]
+- Updated dependencies [86cbe37]
+- Updated dependencies [6a180e4]
+- Updated dependencies [474242f]
+- Updated dependencies [63cd487]
+- Updated dependencies [bd4aa4e]
+- Updated dependencies [803eaab]
+- Updated dependencies [f8e8f03]
+- Updated dependencies [983edf1]
+- Updated dependencies [eae824e]
+- Updated dependencies [f6fa22c]
+- Updated dependencies [8a483b3]
+- Updated dependencies [3bc2e38]
+- 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 [d8024f0]
+- Updated dependencies [8120808]
+- Updated dependencies [776a098]
+- Updated dependencies [5060877]
+- Updated dependencies [4f6325d]
+- Updated dependencies [52954c0]
+- Updated dependencies [2aa8456]
+- Updated dependencies [d23ebb9]
+- Updated dependencies [93809a3]
+- Updated dependencies [7c0d0c3]
+- Updated dependencies [daae7aa]
+- Updated dependencies [8dc22d6]
+- Updated dependencies [fa5d137]
+- Updated dependencies [a392dbf]
+- Updated dependencies [279431e]
+- Updated dependencies [948dd6b]
+- Updated dependencies [3b4c56c]
+- Updated dependencies [ae8edd2]
+- Updated dependencies [e25403c]
+- Updated dependencies [a81aa9d]
+- Updated dependencies [64baa68]
+- Updated dependencies [9fa70d7]
+- Updated dependencies [09db64a]
+- Updated dependencies [92916e7]
+- Updated dependencies [a84f3ea]
+- Updated dependencies [f2eaae8]
+- Updated dependencies [56c093c]
+- Updated dependencies [c09451b]
+- Updated dependencies [ba64877]
+- Updated dependencies [e7191ce]
+- Updated dependencies [7345308]
+- Updated dependencies [79b6a22]
+- Updated dependencies [30d96ab]
+- Updated dependencies [f658793]
+- Updated dependencies [0fd4899]
+- 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 [00d8f65]
+- 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 [200d255]
+- Updated dependencies [2852acc]
+- Updated dependencies [daeaaf9]
+- Updated dependencies [c459da6]
+- Updated dependencies [e914733]
+- Updated dependencies [f887e52]
+- Updated dependencies [881f8d8]
+- Updated dependencies [3bfa1e6]
+- Updated dependencies [0a8ebf3]
+- Updated dependencies [901355c]
+- Updated dependencies [34ce8e7]
+- Updated dependencies [33681ea]
+- Updated dependencies [bfe13c8]
+- Updated dependencies [0fb3044]
+- Updated dependencies [4635f3e]
+- Updated dependencies [fd289be]
+- Updated dependencies [ee3595c]
+- Updated dependencies [09b4f4e]
+- Updated dependencies [b2eab95]
+- Updated dependencies [93940d4]
+- Updated dependencies [3a04b01]
+- Updated dependencies [45b9051]
+- Updated dependencies [3954fb7]
+- Updated dependencies [4805b56]
+- Updated dependencies [b9e9227]
+- Updated dependencies [d395692]
+- Updated dependencies [5894d30]
+- Updated dependencies [a3765f6]
+- Updated dependencies [2d5cee3]
+- Updated dependencies [e22158f]
+- Updated dependencies [7404925]
+- Updated dependencies [0c2334f]
+- Updated dependencies [778c59f]
+- Updated dependencies [d2619fd]
+- Updated dependencies [af56546]
+- 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 [a17da05]
+- Updated dependencies [a8c00e2]
+- Updated dependencies [22e5236]
+- 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 [15d55fb]
+- Updated dependencies [9e0ba21]
+- Updated dependencies [a07a831]
+- 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 [f6344e7]
+- Updated dependencies [42a117b]
+- Updated dependencies [1401ae7]
+- Updated dependencies [4297fe7]
+- Updated dependencies [e398863]
+- Updated dependencies [d16df74]
+- Updated dependencies [d79c602]
+- Updated dependencies [f11fc61]
+- Updated dependencies [e808890]
+- Updated dependencies [8f79379]
+- Updated dependencies [e6ca40e]
+- Updated dependencies [0c77ea4]
+- Updated dependencies [52954c0]
+- Updated dependencies [89eb997]
+- Updated dependencies [7131f12]
+- Updated dependencies [aa5994e]
+- Updated dependencies [be93457]
+- Updated dependencies [a65db76]
+- Updated dependencies [2cf5a96]
+- Updated dependencies [15eb2c9]
+- Updated dependencies [5691b07]
+- Updated dependencies [2a6122b]
+- Updated dependencies [225e769]
+- Updated dependencies [8af88dd]
+- Updated dependencies [fb5fbb8]
+- Updated dependencies [d7b3963]
+- Updated dependencies [33184fd]
+- Updated dependencies [7c41693]
+- Updated dependencies [b72db01]
+- Updated dependencies [dce5cd4]
+- Updated dependencies [9688f58]
+- Updated dependencies [556ebc1]
+- 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 [064d484]
+- Updated dependencies [527e050]
+- Updated dependencies [dd33bf9]
+- Updated dependencies [4cb2a90]
+- Updated dependencies [74a7804]
+- Updated dependencies [53d3689]
+- Updated dependencies [b3a63d3]
+- Updated dependencies [49f0dcf]
+- 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 [db8c288]
+- Updated dependencies [0e5fe7f]
+- Updated dependencies [add4360]
+- Updated dependencies [e0abc38]
+- Updated dependencies [fc9ba76]
+- Updated dependencies [1272f0a]
+- 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 [598b7ec]
+- Updated dependencies [d028b37]
+- Updated dependencies [f7b25c5]
+- Updated dependencies [122ef38]
+- Updated dependencies [4a37870]
+- Updated dependencies [428f9b2]
+- Updated dependencies [aa7ff56]
+- Updated dependencies [811a3c2]
+- Updated dependencies [1401ae7]
+- Updated dependencies [2fd3f1c]
+- Updated dependencies [c41b42e]
+- Updated dependencies [d41d166]
+- 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 [87ad30c]
+- 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 [9735662]
+- Updated dependencies [4d5b4f8]
+- Updated dependencies [3e8f5b0]
+- Updated dependencies [5d16379]
+- Updated dependencies [0da7cd2]
+- Updated dependencies [28a5c3e]
+- Updated dependencies [4bc18e5]
+- Updated dependencies [9f57f1e]
+  - @objectstack/spec@17.3.0
+  - @objectstack/platform-objects@17.3.0
+  - @objectstack/core@17.3.0
+  - @objectstack/types@17.3.0
+  - @objectstack/metadata-core@17.3.0
+  - @objectstack/metadata-fs@17.3.0
+
 ## 17.2.0
 
 ### Patch Changes