@objectstack/core 17.2.0 → 17.4.0

package/CHANGELOG.md

@@ -1,5 +1,2104 @@
 # @objectstack/core
 
+## 17.4.0
+
+### Minor Changes
+
+- 2ed6be6: Advisory validation rules no longer flood the startup log, and no longer count a row twice on a clean first boot.
+  
+  A `severity: 'warning'` (or `'info'`) validation rule is advisory: it never blocks a write, and its message is written for a person filling in a form. Evaluated across a seed load it produced one `WARN` line per row, so a clean-database first boot opened with a wall of form hints re-cast as boot diagnostics — and an app could reach "zero warnings" only by bending its data or deleting the rule.
+  
+  Two changes, and neither moves what a rule evaluates to:
+  
+  - **Aggregated reporting on the seed/boot path.** `SeedLoaderService.load()` now runs inside an advisory aggregation scope, and reports one summary line per rule — the rule, the object, the row count, the rule's own message and example rows — instead of one line per row. Off that path (an ordinary interactive write) nothing changes: the same per-write line is emitted verbatim. The new scope is `runWithAdvisoryAggregation` / `recordAdvisoryHit` in `@objectstack/core`.
+  - **Advisory rules are counted by row, not by write.** An `update` whose payload touches only platform-injected system columns — the shape `claimSeedOwnership` writes when it hands seeded rows to the first admin, `{ owner_id }` — changes no business field, so it no longer re-evaluates the object's advisory rules. Previously a seeded row rang once on insert and again when the claim scan rewrote `owner_id`, so anyone counting startup warnings over-estimated by the number of claimed objects.
+  
+  `error`-severity rules are untouched by both changes: an invariant is still enforced on every write, whoever issued it and however little it moved. Membership of the "system column" set is resolved per object by `resolveInjectedSystemColumns`, so an object that declares `ownership: 'org'` (no `owner_id`) or `systemFields: false` is judged on its own columns rather than a fixed list.
+- b0529e1: fix(core): `ResolvedAuthzContext.authRefusal` is removed — a published member nothing ever read (#14273)
+  
+  **BREAKING** published-type narrowing, shipped as `minor` under the repo's
+  launch-window convention for breaking changes. `ResolvedAuthzContext` — the
+  envelope `resolveAuthzContext` answers, exported from `@objectstack/core`'s
+  root entry — loses its optional `authRefusal?: { reason; message }` member.
+  Maintainer ruling 2026-09-02 (option A, ADR-0049 enforce-or-remove),
+  re-affirmed 2026-09-03 as A1 with the carriers a published narrowing owes
+  once the type was measured as public API: the member was written by the two
+  posture-conditional API-key refusals (`organization_required` at admission,
+  `organization_membership_ended` after grants) since #8287 and read by nothing
+  — zero runtime readers across every transport and consumer in the repo for
+  its whole life; only test assertions ever looked at it.
+  
+  What changes:
+  
+  - `ResolvedAuthzContext` no longer declares `authRefusal`. Code that reads
+    `ctx.authRefusal` stops compiling (`TS2339`); at runtime the property was
+    already absent from every resolved context except the two refused ones.
+  - The two refusals themselves are UNCHANGED: they still fire, still fail
+    closed (no `userId`, empty grants), and every transport still answers the
+    generic anonymous `401 UNAUTHENTICATED`. No status code, body or header
+    moves — a holder of someone else's key learns nothing, exactly as before.
+  - The refusal REASON is observable on exactly one surface, and it is not the
+    envelope: the server-side `[security] API key refused (reason) ...` `warn`
+    line at the decision point (#15256 / 2A), which names the key row id,
+    principal and organization for the operator. The pins that kept the two
+    reasons distinguishable through the field now read that line.
+  - `ApiKeyRefusalReason` and `ApiKeyAdmission` are unchanged — the reason
+    vocabulary still exists; it just no longer has a copy on the resolved
+    context.
+  
+  **Migration.** A consumer that read `ctx.authRefusal` deletes the read; there
+  is no replacement on the envelope, by design — disclosing the reason to a
+  caller (option B) was ruled out as a security-boundary question, and the
+  recorded fallback if a reader ever appears is an audit-side outlet (option C),
+  never the wire. Fail-closed handling keys on the absent `userId`, as every
+  in-repo transport already did. An operator who needs the reason reads the
+  server log line.
+  
+  <!-- adr-0087: not-required (runtime-interface-only packages/core/src/security/resolve-authz-context.ts#ResolvedAuthzContext) A published runtime TypeScript interface lost an optional member. No Zod schema, no `packages/spec` declaration, no object definition and no stored representation is touched — `ResolvedAuthzContext` is a plain interface in `packages/core`, projected from no schema and referenced by no metadata surface — so `objectstack migrate meta` has nothing to rewrite and there is no tombstone to mint. The channel that reaches an affected consumer is the compiler at the read site (`TS2339`), which is more precise than a ledger line. The in-repo census (zero runtime readers; the only readers were test assertions, relocated onto the `warnApiKeyRefusal` line) and the workspace typecheck are recorded on the PR. -->
+- 66dc6ab: Plugin startup elapsed time is now reported as `durationMs` — the unit-bearing name the spec contract for the same result declares. `startTime`, which never held a start time, is deprecated and still populated.
+  
+  `PluginStartupResult.startTime` (`packages/core/src/plugin-loader.ts`) has always been assigned `Date.now() - startTime`, an elapsed duration, on both the success and the failure path. The name therefore asserts the opposite of the value: a reader who correctly takes `startTime` for an instant and writes `Date.now() - result.startTime` gets an age near the epoch rather than a wait. That is the one failure mode a unit convention cannot rescue — an ambiguous name makes someone stop and check, this one lets them proceed confidently wrong.
+  
+  This is not a naming preference but a divergence between what is declared and what is enforced. `packages/spec/src/kernel/startup-orchestrator.zod.ts` declares `durationMs: z.number().min(0)` — "Time taken to start the plugin in milliseconds" — for the same measure on the same result, the outcome of starting one plugin; the bare `duration` spelling is retired there with a `retiredKey()` tombstone whose prescription is "Rename the key to `durationMs`", because a duration-shaped number carries its unit in its key name, never only in describe prose. The contract surface was already correct and `packages/core` had drifted away from it. The same computation already has an honest name twelve lines above the defect in the same file: `PluginLoadResult.loadTime` carries the identical `Date.now() - startTime` under a name that does not lie.
+  
+  Three sites move, and every one of them is additive — nothing is removed, so no consumer has to change anything on this release:
+  
+  - `PluginStartupResult` gains `durationMs?: number`. `startTime?: number` stays, still carrying the same value, marked `@deprecated` with a doc comment that states plainly it is elapsed milliseconds and not an instant.
+  - `ObjectKernel.getPluginStartupDurations()` is added; `getPluginMetrics()` becomes a `@deprecated` delegating alias returning the same map.
+  - The private `pluginStartTimes` map is renamed `pluginStartupDurations` (private; no reader outside `kernel.ts` in this repo or in the pinned `objectui` sibling).
+  
+  Migration, where you want it: read `result.durationMs` where you read `result.startTime`, and `kernel.getPluginStartupDurations()` where you called `kernel.getPluginMetrics()`. The values are identical, so the change can be made at leisure; both old spellings keep working until they are removed.
+  
+  ADR-0087 disposition: no migration-ledger entry, and none is required. Nothing is retired by this release — the old member and the old method both remain, populated and callable, which is ADR-0087's L1 outcome (the old shape keeps loading while the fleet moves) rather than a retirement. There is also nothing for `objectstack migrate meta` to rewrite: `packages/core/src/plugin-loader.ts#PluginStartupResult` is a runtime TypeScript interface with no Zod schema, no `packages/spec` declaration and no stored representation — the `PluginStartupResult` in `packages/spec/src/kernel/startup-orchestrator.zod.ts` is a separate, differently-shaped declaration that this change does not touch, and that schema's own `duration` tombstone entry (`packages/spec/src/migrations/entries/retired-keys/18.kernel__PluginStartupResult__duration.ts`) records that core's interface is not a reader of it. Core simply does not adopt the retired spelling. When the deprecated spellings are removed, that removal is the change that carries the ledger disposition.
+- 2025b1f: `kernel.use()` now enforces the declared plugin contract. A plugin object that `PluginSchema` (`@objectstack/spec`, `kernel/plugin.zod.ts`) refuses is refused at load instead of being stored and mounted.
+  
+  **BREAKING** accept-set narrowing on a published runtime entry point, shipped as `minor` under the repo's launch-window convention for breaking changes (`scripts/check-changeset-no-major.mjs`). **This refuses input the runtime accepted before**, which is also why it is not a `patch`: `PluginSchema` had zero runtime callers, so every constraint it declared beyond `name`, `init` and semver was a declaration with nothing behind it. The sharpest reading of that gap, one input and two answers: `defineStack` accepted `type: 'ui-plugin'` while `PluginSchema.safeParse` refused it — and only one of those answers was on the path a real plugin takes. Maintainer ruling of 2026-09-06 (ADR-0049 enforce-or-remove): the protocol is the baseline, the runtime aligns to it.
+  
+  **Exactly what is newly refused: all EIGHT declared keys, not three.** The schema declares nine optional keys; the loader excludes `version` (below), so enforcement reaches these eight, each refused with the offending key named in the message:
+  
+  - **`id`** — a non-string, or the empty string (`z.string().min(1)`).
+  - **`type`** — any value outside the closed set `standard`, `ui`, `driver`, `server`, `app`, `theme`, `agent`, `objectql`.
+  - **`staticPath`** — a non-string.
+  - **`slug`** — a non-string, or a string that does not match `/^[a-z0-9-_]+$/`.
+  - **`default`** — a non-boolean.
+  - **`description`** — a non-string.
+  - **`author`** — a non-string. An object such as `{ name: 'x' }` is refused; the declared type is a plain string.
+  - **`homepage`** — a non-string, or a string that is not a URL.
+  
+  **`null` is refused on every one of the eight.** These keys are `.optional()`, which admits absence and `undefined` — never an explicit `null`. A plugin object that spells "no value" as `null` on any of the eight loaded before and is refused now.
+  
+  **What a refusal looks like.** It travels the loader's existing plugin-load error path — no new error channel — carrying the stable code `PLUGIN_CONTRACT_VIOLATION` at the head of the message and on the error's `code` property, and naming the plugin plus the first violated key:
+  
+  ```
+  PLUGIN_CONTRACT_VIOLATION: plugin '@acme/console' is refused by the declared
+  plugin contract at 'type': Invalid option: expected one of "standard"|"ui"|…
+  ```
+  
+  A wrong `type` is therefore diagnosable at boot rather than at route mount. The code is a **boot refusal**, not wire vocabulary: it is raised before any HTTP boundary exists, and no door answers with it.
+  
+  **What is STILL ACCEPTED — the door is not narrowed past those eight keys.** Measured on this tree, not assumed:
+  
+  - **Unknown keys still pass.** `PluginSchema` is a plain `z.object` with **no `.strict()`** — the strip posture — and the parse output is discarded, so a valid plugin carrying four keys the schema never declares loads, and is stored as the very object that was passed in with all of its keys intact. A plugin is refused for what it says about a **declared** key, never for saying something extra.
+  - **A version-less plugin still loads**, exactly as before.
+  - **A plugin declaring no `type` still loads and still stores no `type`**: `PluginSchema`'s `.default('standard')` is **not** written back.
+  - **A class-based plugin keeps its identity, its prototype and its prototype methods.** The plugin object is validated, never replaced: `safeParse` is read for `success` and its output discarded, because a copy destroys the prototype chain of class-based plugins — the reason `PluginLoader.toPluginMetadata` is a cast. That survival is pinned by test, not asserted in prose.
+  - **`version` is excluded from this enforcement entirely**, so `1.0.0-alpha.1` and `1.0.0+20230101` still load. The schema spells `version` as `/^\d+\.\d+\.\d+$/`, which refuses the prerelease and build-metadata forms SemVer 2.0.0 defines, while the loader's own `isValidSemanticVersion` implements the full grammar and accepts them — deliberately, pinned by `plugin-loader.test.ts`. Enforcing the narrower spelling would retire that capability silently, so the loader's check remains authoritative for `version`. Reconciling the two spellings is spec work, tracked separately.
+  
+  **Blast radius, measured rather than assumed.** Every in-repo plugin object declares a `type` inside the closed set (`standard` ×62, `server` ×2, `driver` ×2, `objectql`, `app`), and the repo contains no producer of `slug` or `homepage` on a plugin object at all — so no in-repo plugin changes behaviour. Externally authored plugins are the population this reaches, and they are exactly the population that never met the compile-time `Plugin.type` union either.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) An accept-set narrowing performed entirely at the runtime boot path: `PluginSchema` is READ by `kernel.use()`, not changed. No metadata key, spec symbol, Zod schema, object definition or stored representation is added, removed or given a different name, so `objectstack migrate meta` has nothing to visit and there is no tombstone to mint. Stored metadata is untouched; what moves is which plugin OBJECTS a boot accepts. The channel that reaches an affected plugin author is the refusal itself, which names the offending key at `kernel.use()` and is more precise than a ledger line — and which value a formerly-refused key should carry is authoring intent no ledger entry can decide. -->
+- 51ae731: `LiteKernel.use()` now enforces the declared plugin contract — the same check, the same refusal, as `ObjectKernel.use()`. A plugin object that `PluginSchema` (`@objectstack/spec`, `kernel/plugin.zod.ts`) refuses is refused at registration on **both** published kernels instead of on one.
+  
+  **BREAKING** accept-set narrowing on a published runtime entry point, shipped as `minor` under the repo's launch-window convention for breaking changes (`scripts/check-changeset-no-major.mjs`). **A plugin object `LiteKernel` accepted before can be refused now.** Until this release `LiteKernel.use()` wrote the object straight into its registry: `PluginSchema` was run by `PluginLoader.validatePluginContract` only, and `PluginLoader` is reached from `ObjectKernel.use()` alone. So the same plugin was accepted by one kernel and refused by the other — a `type: 'ui'` plugin with no `slug` was refused by `ObjectKernel` with `PLUGIN_CONTRACT_VIOLATION` and mounted a route on `LiteKernel`. `AGENTS.md` names `LiteKernel` for tests, serverless and edge, so the lenient kernel was the one authors develop against and the strict one was production: a plugin could be green in vitest and refused at boot. Maintainer ruling of 2026-09-08 (option A, under the precedent that the two kernels converge rather than diverge): `LiteKernel` validates too.
+  
+  **Exactly what `LiteKernel.use()` newly refuses** is exactly what `ObjectKernel.use()` has refused since the `kernel.use()` enforcement release: all EIGHT declared keys, each refused with the offending key named in the message —
+  
+  - **`id`** — a non-string, or the empty string.
+  - **`type`** — any value outside the closed set `standard`, `ui`, `driver`, `server`, `app`, `theme`, `agent`, `objectql`.
+  - **`staticPath`** — a non-string.
+  - **`slug`** — a non-string, or a string that does not match `/^[a-z0-9-_]+$/`.
+  - **`default`** — a non-boolean.
+  - **`description`** — a non-string.
+  - **`author`** — a non-string.
+  - **`homepage`** — a non-string, or a string that is not a URL.
+  
+  **`null` is refused on every one of the eight**, and a `type: 'ui'` plugin missing `staticPath` or `slug` is refused with `PLUGIN_UI_REQUIRED_KEY_MISSING` inside the same envelope.
+  
+  **What a refusal looks like — one refusal, from either kernel.** The check is now one function (`assertPluginContract`, package-internal) that both kernels call, so the code and the message are produced once:
+  
+  ```
+  PLUGIN_CONTRACT_VIOLATION: plugin '@acme/console' is refused by the declared
+  plugin contract at 'slug': PLUGIN_UI_REQUIRED_KEY_MISSING: a `type: 'ui'` plugin must declare `slug` — …
+  ```
+  
+  `LiteKernel.use()` is synchronous and throws that error as-is, so the stable code is on the error's `code` property as well as at the head of the message. `ObjectKernel.use()` is unchanged: it still re-wraps a failed load as `Failed to load plugin: <name> - <that message>`, its existing wrapper for every load failure. The text after that prefix is byte-for-byte the `LiteKernel` message for the same input, pinned by test.
+  
+  **What is STILL ACCEPTED on `LiteKernel` — the narrowing stops where `ObjectKernel`'s does.** Unknown keys still pass (`PluginSchema` carries no `.strict()`, and the parse output is discarded, so the stored object is the very object passed in). A version-less plugin still loads, and so do `1.0.0-alpha.1` and `1.0.0+20230101`: `version` is excluded from the schema check on both kernels, and `LiteKernel` — which has never judged `version` — still does not. A plugin declaring no `type` still loads and still stores no `type`. A class-based plugin keeps its identity, its prototype and its prototype methods. And `PluginLoader`'s structural checks (`name`, `init`, semver) stay the loader's own: the convergence is on the schema, not on the loader.
+  
+  **Ordering, stated because it is observable.** `LiteKernel.use()` checks its state first (a kernel past bootstrap still says `Cannot register plugins after bootstrap has started`, never `PLUGIN_CONTRACT_VIOLATION`), then the contract, then registers — so a refused plugin never reaches the registry and cannot supersede an earlier registration under its name.
+  
+  **Blast radius, measured before landing rather than assumed.** Across this repository's suites, 813 `LiteKernel.use()` calls were reachable; 807 were accepted by the schema unchanged and the six refusals came from three test-local fixture objects in two files — zero product or library code. Externally authored plugins registered on `LiteKernel` are the population this reaches, and they are exactly the plugins that would already have been refused by `ObjectKernel` at production boot.
+  
+  **Migration.** There is nothing to rename. A plugin refused on `LiteKernel` now was already refused on `ObjectKernel`; fix the named key: give `type` a value from the closed set (or drop it — an absent `type` reads as `standard`), declare `staticPath` and `slug` on a `type: 'ui'` plugin, spell `slug` in `[a-z0-9-_]`, make `homepage` a URL, and never `null` a declared key. The refusal names the plugin and the first violated key.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) An accept-set narrowing performed entirely at the runtime registration path: `PluginSchema` is READ by `LiteKernel.use()` now, exactly as `ObjectKernel.use()` has read it since the `kernel.use()` enforcement release — the schema itself is not changed. No metadata key, spec symbol, Zod schema, object definition or stored representation is added, removed or given a different name, so `objectstack migrate meta` has nothing to visit and there is no tombstone to mint. Stored metadata is untouched; what moves is which plugin OBJECTS the second kernel accepts, and every object it newly refuses was already refused by the first. The channel that reaches an affected plugin author is the refusal itself, which names the offending key at `use()` and is more precise than a ledger line — and which value a refused key should carry is authoring intent no ledger entry can decide. -->
+- cf9bda4: The kernel's in-memory i18n fallback learns the declared `i18n.fallbackLocale`, so one declaration stops answering two ways (#15694)
+  
+  `i18n.fallbackLocale` is authorable on the stack artifact (`TranslationConfigSchema`), and `FileI18nAdapter` — the provider `I18nServicePlugin` installs — has always honoured it: both boot paths construct it with `fallbackLocale || defaultLocale || 'en'`, and its `t()` consults that locale, per key, after the requested one.
+  
+  The kernel's in-memory fallback is constructed with nothing. `AppPlugin.loadTranslations` injected the declared `defaultLocale` and `supportedLocales` (#7679) into whichever `i18n` service was registered, but never `fallbackLocale`, and the provider had no setter to receive one. On every stack running that fallback — any stack that declares `translations` without `@objectstack/service-i18n` registered (not installed, or `tierEnabled('i18n')` false) — the declaration was inert. A stack declaring `defaultLocale: 'zh-CN'` with `fallbackLocale: 'en'` answered a missing `zh-CN` key from `en` under `I18nServicePlugin` and from `zh-CN`, i.e. not at all, under the fallback: one declaration, two providers, two answers. That the fallback self-declares `degraded` licenses fewer capabilities, not a different answer to the same declared key.
+  
+  What changed:
+  
+  - **`II18nService.setFallbackLocale?(locale)`** — a new OPTIONAL member, the injection counterpart of `getFallbackLocale`. It is the same shape `setDefaultLocale` and `setSupportedLocales` already have, and for the same reason: the declaration lives on the stack artifact, which only the runtime app-plugin layer can see. A provider constructed with its fallback (`FileI18nAdapter`) omits the method and keeps the value it was built with.
+  - **`createMemoryI18n` receives it and acts on it.** `t()` now consults the declared fallback per KEY after the requested locale — the same second leg `FileI18nAdapter.t()` has. Per key, not per bundle: the pre-existing `resolveTranslations(locale) ?? mergedLocale(defaultLocale)` line swaps whole bundles and only when the requested locale has none, so a `zh-CN` bundle that simply lacked the key never reached anything else. That older leg is unchanged.
+  - **`AppPlugin.loadTranslations` threads the declaration**, through the same `typeof … === 'function'` optional-capability probe as `setDefaultLocale`, and guarded on the app having declared something — several `AppPlugin`s can share one kernel, and an app that declares no `i18n` block must not clear a fallback another app declared.
+  
+  A stack that declares no `fallbackLocale` gets exactly the behaviour it has today: the setter is never called, and `t()` walks the same chain it always did. A fallback nobody asked for would be a new chain, not a fix.
+  
+  `getFallbackLocale()` is deliberately still absent from the memory fallback. The setter is what the provider is TOLD; the accessor is what the serving layer ASKS it when building the metadata-document translators' fallback chain (#14882). Answering the second from `defaultLocale` — the only value always available there — would settle the default-locale contract question #14882 leaves deliberately open, from a degraded provider. Those reads keep the resolvers' own default, which is known and intentional.
+- 2a3decc: `PluginSchema` now REQUIRES `staticPath` and `slug` when `type` is `'ui'`, and core's `Plugin` interface inherits every `PluginSchema` key from `PluginDefinition` instead of restating two of them.
+  
+  **BREAKING** accept-set narrowing on a published schema, shipped as `minor` under the repo's launch-window convention for breaking changes (`scripts/check-changeset-no-major.mjs`). `packages/spec/src/kernel/plugin.zod.ts` described `staticPath` and `slug` as *"Required for type=\"ui\""* while declaring both `.optional()`, with nothing behind the prose; since `kernel.use()` runs the schema on the boot path (#16049), that was a promise the runtime visibly did not keep. This is the spec half of #16049, split by director ruling (decision batch #58, 2026-09-06).
+  
+  **Exactly what is newly refused.** A plugin object with `type: 'ui'` that omits `staticPath`, omits `slug`, or spells either as `undefined`. Nothing else: every other declared type (`standard`, `driver`, `server`, `app`, `theme`, `agent`, `objectql`), and a plugin declaring no `type` at all, still parses with neither key. A PRESENT value is judged exactly as before — `slug` keeps its `/^[a-z0-9-_]+$/` regex, `staticPath` stays any string, and the empty string is not refused by this change.
+  
+  **What a refusal looks like.** One zod issue per missing key, `path` naming the key, the new stable code `PLUGIN_UI_REQUIRED_KEY_MISSING` (exported from `@objectstack/spec/kernel`) at the head of the issue `message` and on the issue's `params.code`. At `kernel.use()` it rides the existing `PLUGIN_CONTRACT_VIOLATION` envelope unchanged, because the loader surfaces the first issue's `path` and `message` and reads nothing else:
+  
+  ```
+  PLUGIN_CONTRACT_VIOLATION: plugin '@acme/console' is refused by the declared
+  plugin contract at 'staticPath': PLUGIN_UI_REQUIRED_KEY_MISSING: a `type: 'ui'`
+  plugin must declare `staticPath` — the absolute path of the static assets it
+  serves. Declare it, or drop `type: 'ui'` if this plugin serves no assets.
+  ```
+  
+  **The fix for an affected plugin** is the one the message names: declare both keys (`staticPath`: the absolute path of the assets it serves; `slug`: the URL segment it is mounted under), or drop `type: 'ui'` if the plugin serves no assets. There is no fallback to lean on: the Hono server's `slug || name.split('/').pop()` derivation is no longer reachable through the kernel, because the object is refused before it is stored.
+  
+  **`@objectstack/core` — `Plugin` derives its metadata keys.** `Plugin` now `extends PluginDefinition` (`z.input<typeof PluginSchema>`), so `id`, `type`, `staticPath`, `slug`, `default`, `version`, `description`, `author` and `homepage` are ONE declaration shared with the schema the kernel enforces. Additive for every existing implementer: `type` and `version` keep the shapes they had (`type` is still `PluginType | undefined`, pinned type-equal in `packages/rest`; `version` still `string | undefined`), and the seven other keys are new optional members. A `ui` plugin can now carry `staticPath` / `slug` without widening its own type. Runtime-only members (`name`, `dependencies`, `optionalDependencies`, `requiresServices`, `providesServices`, `init`, `start`, `destroy`) stay declared on the interface.
+  
+  **Blast radius, measured.** No in-repo plugin object outside test fixtures declares `type: 'ui'` (searched `packages/`, `apps/`, `examples/` non-dist sources for a `type` key or class field holding the literal `'ui'`: three test files, nothing shipped), so no in-repo composition changes behaviour. Externally authored `ui` plugins that relied on the slug derivation, or declared no assets, are the population this reaches — and they are refused at boot, by name, with the key to add.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) An accept-set narrowing on plugin OBJECTS, which are never stored metadata: `PluginSchema` gains a refinement and one exported constant; no metadata key, object definition or stored representation is added, removed or renamed, so `objectstack migrate meta` has nothing to visit and there is no tombstone to mint. The channel that reaches an affected plugin author is the refusal itself, which names the missing key at `kernel.use()`; which value that key should carry is authoring intent no ledger entry can decide. -->
+- cc00df2: feat(core)!: retire `PluginSecurityScanner` — plugin security scanning is not a platform capability (#14919)
+  
+  <!-- adr-0087: registered plugin-security-scanner-retired -->
+  
+  **ADR-0087 disposition: registered**, as `plugin-security-scanner-retired` in
+  `MIGRATIONS_BY_MAJOR[18].semantic` — a **D3 semantic** entry, not a D2 conversion,
+  and so not the metadata migration the ruling excludes. The class has no spec schema
+  and never had one, so there is no authorable key to tombstone with `retiredKey()`
+  and no stored `sys_metadata` row a conversion could rewrite: a scanner was
+  constructed per call and every result lived in a per-instance Map discarded with the
+  object, so `applyConversionsToStoredItem` has no seam that would ever see one. An
+  entry is nevertheless owed rather than optional, because this changeset carries a
+  real consumer prescription — the enforced channel is tsc at the import site, and for
+  any consumer it does not reach, the ledger and the generated upgrade guide are the
+  only channel there is. Same disposition as `contracts.IDataDriver.findStream` and
+  `actor-user-roles-to-positions`.
+  
+  **BREAKING** — `PluginSecurityScanner` is removed from `@objectstack/core`,
+  together with its two companion types `ScanTarget` and `SecurityIssue`. Landing
+  as `minor` under the repo's launch-window convention for breaking changes.
+  **There is no replacement**, and none is planned.
+  
+  ⚠️ **The out-of-repo consumer population for these three exports is NOT
+  MEASURED.** This changeset can state only what was measured *inside* the
+  sources this repo can read: zero constructors in objectstack, zero in objectui
+  at the pinned sha, and zero in the deleted example itself. How many published
+  consumers of `@objectstack/core` import the class is unknown — no download,
+  dependent or source telemetry was consulted. Read the removal as breaking for
+  an unmeasured population, not as a removal proven to break nobody.
+  
+  ## Why it was removed rather than repaired
+  
+  The class was a shell that reported success. `scan()` composed five private
+  scanners: four of them (`scanCode`, `scanMalware`, `scanLicenses`,
+  `scanConfiguration`) allocated an empty issue array, logged, and returned it
+  with no code in between — none could report a finding for any input. The fifth,
+  `scanDependencies`, ran a real loop but matched only against an in-memory
+  vulnerability database whose sole writer, the public `addVulnerability`, had
+  zero callers; `updateVulnerabilityDatabase()` logged twice and fetched nothing.
+  The database was therefore empty on every code path that has ever executed, so
+  no issue was ever produced, the score stayed 100, and the result was
+  `status: 'passed'` for every plugin the scanner was ever handed — a malicious
+  one included.
+  
+  A security control that cannot fail is worse than no security control, because
+  callers rely on it. Repair — writing a real vulnerability scanner — was refused
+  by name: it is a feature with a design surface and no demand, not a defect fix.
+  
+  ## FROM → TO
+  
+  ```ts
+  // FROM — compiles today, and passes every plugin it is given
+  import { PluginSecurityScanner } from '@objectstack/core';
+  
+  const scanner = new PluginSecurityScanner(kernel.logger);
+  const result = await scanner.scan({ pluginId, version, dependencies });
+  if (result.status === 'passed') { await kernel.use(plugin); }
+  
+  // TO — delete it. The condition above was always true.
+  await kernel.use(plugin);
+  ```
+  
+  **The one-line fix:** delete the import and every call; no symbol replaces it.
+  If your code branched on `result.status`, take the `'passed'` branch — that is
+  the only branch it ever took.
+  
+  **If you were relying on it for actual security**, you were not getting any.
+  Audit dependencies with the tools built for it (`npm audit` / `pnpm audit`,
+  Dependabot, the GitHub Advisory Database, OSV) and treat an unaudited
+  third-party plugin as untrusted code. What ObjectStack does still enforce is
+  artifact **integrity and signatures** (`verifyPluginArtifactIntegrity`, the
+  plugin signature verifier — "is this what the publisher signed?", never "is
+  this safe?"), explicit plugin **permissions**, and the sandbox **resource
+  limits**; all three are unchanged.
+  
+  Removed under ADR-0049 enforce-or-remove, per the maintainer ruling of
+  2026-09-05 (director summon #14, decision batch #42). The retirement is pinned
+  as an export-list assertion on both barrels in
+  `packages/core/src/security/security-scanner-retirement.pin.test.ts`.
+
+### Patch Changes
+
+- 6f94458: fix(core): narrow the operation-private-keys pin's scanner to `.ts`, so it judges exactly the population turbo re-runs it for (#15090)
+  
+  `packages/core/src/security/operation-private-keys.pin.test.ts` filtered its
+  candidate set with `/\.tsx?$/` — `.ts` **and** `.tsx` — while this package's
+  declared radius in the cross-package declaration table is a `packages/**`
+  subtree glob ending in `.ts`. So the pin judged a population **strictly wider**
+  than the one either scoping layer of `check:cross-package-test-inputs` knows
+  about: Layer A never unions this package into the test shard when a `.tsx` file
+  changes, and Layer B never moves the `test` task's cache hash for one. A `.tsx`
+  file under `packages/` declaring its own `OPERATION_PRIVATE_KEY_PREFIX` or
+  `withoutOperationPrivateKeys` was therefore scanned by the pin and invisible to
+  CI's scoping — landing on `main` with every PR green and then reddening whichever
+  unrelated PR next touched a `.ts` file. That is the #7802 shape the declaration
+  table exists to close, one extension wide.
+  
+  Repaired by narrowing the **scanner**, not by widening the **glob** — and that
+  asymmetry is measured rather than assumed. On `b548e438d`, adding a `.tsx` glob
+  to this package's roster entry and re-deriving `check:cross-package-test-inputs`'
+  watch hints flips the dispatch-gates self-test case *"nor a .tsx test file inside
+  it"* from true to false, with the added glob itself as the covering hint. That
+  case is a live specimen for "a test class the hint route cannot reach", so the
+  red is real and re-pointing it is a decision in another lane, not a fixup.
+  
+  What the boundary costs, measured on the pin's own surface (tracked **plus**
+  untracked, ignored paths excluded) at `b548e438d`: **5408** `.ts` files scanned,
+  8 of them mentioning a guarded symbol; **8** `.tsx` files excluded, **0** of them
+  mentioning either symbol. The loss is empty today — and that reading is no longer
+  transcribed and trusted. A new case re-measures it on every run: it asserts the
+  excluded `.tsx` population is non-empty (so the boundary is an exclusion and not
+  an empty tree describing itself), that the filter really drops those files, and
+  that none of them declares either symbol. Ablation, with the restore proven by
+  blob hash rather than by exit code: re-widening the scanner reddens it while the
+  offender assertion stays green — which is precisely the failure mode, since a
+  wider scanner reads as coverage CI never runs — and planting a `.tsx`
+  redeclaration reddens it with a message that says the choice is a second-gate
+  trade, not a one-line widening.
+  
+  The correspondence between scanner and glob is now stated at **both** ends: the
+  pin's header and the declaration table's entry for this package. No published
+  surface moves — the only source file edited is a test.
+- 6e67b86: refactor(core): the authz context's time-zone probe is now the shared value-domain predicate, not a third copy of it
+  
+  `resolve-authz-context.ts` carried a module-private `isValidTimeZone` — the
+  `Intl.DateTimeFormat` probe, re-stated. It was the third copy of one
+  definition, alongside `@objectstack/spec/shared`'s `isValueDomainMember` and
+  `service-settings`' own re-statement. `coerceTimeZone` now calls
+  `isValueDomainMember('iana_time_zone', …)` and the copy is gone.
+  
+  **No behavioural change, measured rather than asserted.** The two predicates
+  were run over a shared 4,058-input corpus — the zones
+  `Intl.supportedValuesOf('timeZone')` omits (`UTC`, `Asia/Kolkata`,
+  `Europe/Kyiv`, `Asia/Ho_Chi_Minh`, `US/Eastern`, `GMT`), every member of that
+  enumeration plus its case- and space-padded variants, refusals, `Etc/` and
+  offset spellings, legacy aliases, and fuzz — with **zero disagreements**, and
+  the same zero at the `coerceTimeZone` level. The call site's own
+  pre-processing (trim, stringify a non-string, refuse blank) is unchanged.
+  
+  What this buys is drift resistance, not a fix: core's time-zone acceptance now
+  sits under the shared pins, so a future "modernisation" to
+  `Intl.supportedValuesOf('timeZone')` — which would silently narrow what the
+  authz context accepts, since that enumeration omits this platform's own
+  default `UTC` — turns a test red instead of shipping.
+- e9fcd6b: feat(spec)!: the fourteen `kernel/` duration keys carry their unit in the key name (#15678, ruling B on #14478)
+  
+  <!-- adr-0087: registered kernel-event-bus-retention-unit-in-key, kernel-package-lifecycle-durations-unit-in-key, kernel-plugin-health-report-durations-unit-in-key, kernel-plugin-security-durations-unit-in-key, kernel-startup-orchestrator-durations-unit-in-key -->
+  
+  **BREAKING** — fourteen published `kernel/` duration keys are renamed and
+  tombstoned. Shipped as `minor` under the repo's launch-window convention for
+  breaking changes; the hand-migration prescriptions are registered under protocol
+  major 18. Maintainer ruling B on #14478 (2026-09-02, decision batch #43,
+  「同意」).
+  
+  `check:duration-unit-keys` makes a duration-shaped `z.number()` carry its unit
+  in the key NAME, never only in its `.describe()` prose, and grandfathers no
+  existing offender. Stack card 1/6 (#15676) landed the rule's two structural
+  exemptions and card 2/6 (#15677) cleared `api/`; this card clears `kernel/`.
+  Measured with the gate itself: `src/kernel/**` goes from 14 offenders to **0**,
+  and the whole-tree count falls **36 → 22**.
+  
+  ## FROM → TO
+  
+  | key | replacement | unit |
+  |:--|:--|:--|
+  | `EventPersistence.retention` | `retentionDays` | days |
+  | `EventSourcingConfig.retention` | `retentionDays` | days |
+  | `UpgradePlan.estimatedDuration` | `estimatedDurationSeconds` | seconds |
+  | `PluginHealthReport.metrics.uptime` | `uptimeMs` | milliseconds |
+  | `PluginHealthReport.metrics.responseTime` | `responseTimeMs` | milliseconds |
+  | `SandboxConfig.process.timeout` | `timeoutMs` | milliseconds |
+  | `KernelSecurityPolicy.authentication.tokenExpiration` | `tokenExpirationSeconds` | seconds |
+  | `KernelSecurityPolicy.auditLog.retention` | `retentionDays` | days |
+  | `PluginSecurityManifest.vulnerabilityDisclosure.responseTime` | `responseTimeHours` | hours |
+  | `PackageDependencyResolutionResult.resolvedIn` | `resolvedInMs` | milliseconds |
+  | `MultiVersionSupport.rollout.duration` | `durationMs` | milliseconds |
+  | `StartupOptions.timeout` | `timeoutMs` | milliseconds |
+  | `PluginStartupResult.duration` | `durationMs` | milliseconds |
+  | `StartupOrchestrationResult.totalDuration` | `totalDurationMs` | milliseconds |
+  
+  **Every value is unchanged** — only key names move, and every default moves with
+  its key (`StartupOptions` still defaults to 30000, `EventSourcingConfig` to
+  365). Every old spelling is a `retiredKey()` tombstone, so it fails `tsc` at the
+  authoring site (input type `never`) and fails the parse with the rename
+  prescription rather than a bare unrecognized-key error.
+  
+  ## ⚠️ Two collisions this rename removes — check these by hand, not by search-and-replace
+  
+  **`responseTime` meant two different units on two kernel shapes.** On
+  `PluginSecurityManifest.vulnerabilityDisclosure` it is HOURS (how fast a
+  publisher promises to answer a vulnerability report); on
+  `PluginHealthReport.metrics` the identical bare name is MILLISECONDS. So
+  `responseTime: 24` was a day on one shape and a fortieth of a second on the
+  other, with nothing at the authoring site to tell them apart. They land on
+  `responseTimeHours` and `responseTimeMs` respectively — do not let one
+  find-and-replace rewrite both.
+  
+  **`uptime` is milliseconds here and SECONDS on `GET /health`.** That collision
+  was already costing prose: the protocol lifecycle page carried a standing
+  paragraph whose only job was telling the two apart. `metrics.uptime` becomes
+  `metrics.uptimeMs`; the seconds-valued `uptime` of the HTTP health body is a
+  separate, unchanged surface and must not be renamed with it.
+  
+  A third split worth reading before you migrate: `estimatedDurationSeconds: 120`
+  is two MINUTES while `durationMs: 3600000` is one HOUR. Three adjacent
+  measurements of the same package install carried two different units, and no
+  parse can catch a value moved between them — both bounds accept any
+  non-negative integer.
+  
+  ## Dispositions — five semantic entries, no D2 conversion
+  
+  Justified per key rather than defaulted, and this card's answer is uniform:
+  **none of the fourteen gets an ADR-0087 D2 conversion.** A D2 conversion runs
+  over a stack document, and `stack.zod.ts` declares no `eventBus`, `startup`,
+  `upgrade` or plugin-security root — none of these twelve defs is a stack
+  collection member or a registered metadata kind stored as a `sys_metadata` row,
+  so the conversion chain has no seam that would see one. They are host
+  construction arguments (`EventBusConfig`, `StartupOptions`, `SandboxConfig`,
+  `MultiVersionSupport`), package artifacts (`PluginSecurityManifest`) and
+  runtime-emitted measurements (`PluginHealthReport`, `PluginStartupResult`,
+  `StartupOrchestrationResult`, `UpgradePlan`,
+  `PackageDependencyResolutionResult`). Each therefore carries a **semantic**
+  entry, which is the disposition `kernel/HealthStatus:timestamp` already holds on
+  one of these very files (`epoch-instant-keys-renamed`, card 1/6) and what ruling
+  B prescribes for a key that is not authorable metadata. All fourteen are
+  registered by exact key in `RETIRED_KEYS_BY_MAJOR`.
+  
+  ## Keys deliberately left alone
+  
+  `EventSourcingConfig.snapshotRetention` is a COUNT of snapshots and
+  `MultiVersionSupport.rollout.percentage` is a proportion — neither is a
+  duration, so neither has a unit to carry and both keep their names.
+  `RuntimeConfig.resourceLimits.timeout` names its unit only in the JSDoc above
+  the key ("Execution timeout in milliseconds"), a channel
+  `check:duration-unit-keys` does not read: it reads `.describe()` and
+  `.meta({ description })`, and this key's describe ("Maximum execution time")
+  names none. The gate therefore lists it among the duration-shaped keys but
+  deliberately does not judge it — neither an offender nor an exemption — so it is
+  outside this rename; that JSDoc-channel gap is filed as #15939. A pin test
+  asserts the key still parses bare, so a later sweep cannot read the four
+  security renames as "every timeout on that file".
+  
+  ## Readers moved in the same PR, at the same magnitude
+  
+  `@objectstack/core`'s health monitor (`metrics.uptimeMs: Date.now() -
+  startTime`), the kernel and contracts test suites, and the hand-written
+  `content/docs/protocol/kernel/lifecycle.mdx`, whose `uptime` paragraph now
+  states the collision the rename removes.
+  
+  ⚠️ `packages/core/src/plugin-loader.ts` declares its OWN local
+  `PluginStartupResult` interface — a different type, carrying `startTime` rather
+  than any duration key. It is not a reader of this schema, it is untouched by
+  this rename, and the divergence between the two shapes is tracked separately.
+- c78c918: Documentation: the manifest surface no longer describes itself as an open object.
+  
+  `ManifestSchema` became a `strictObject` when the manifest surface was closed against unknown keys, but five prose sites still described the earlier posture. They shipped, so an author (or an AI writing metadata) reading the declarations was told the manifest tolerates undeclared keys — while the runtime rejects them by name and offers the declared spelling for a near miss. Prose that contradicts a tightened contract teaches exactly the wrong reflex, so each site now states the current refusal rather than merely dropping the old claim:
+  
+  - `AssembledPackageBodySchema`'s docblock no longer explains its lack of a `strictObject` spelling by calling `ManifestSchema` open. The posture is inherited: the schema is `ManifestSchema.extend(...)`, and `.extend()` carries the base's unknown-key handling, so an undeclared key on an assembled body is refused — measured, with the rename suggestion intact.
+  - The artifact-registration seam kept the half of its reasoning that still holds (the schema applies defaults, so a parsed clone would not be byte-identical) and retired the half that does not ("Zod strips undeclared keys") — the key is now refused at that parse rather than dropped from the clone.
+  - The `os compile` per-package rule pass explains why a body may be re-read as its own manifest: nothing parses that superset, and against `ManifestSchema` it would now be refused.
+  
+  No schema, behaviour or export changed; `check:api-surface` and the generated reference pages are unmoved.
+- 4771bd9: The `Server is ready` line now reports the degraded boot it is standing on, instead of printing a green `✓` over it.
+  
+  `✓ Server is ready` and the kernel's `System started with degraded capabilities. Missing core services: …` were two statements about one boot, produced by two packages — the banner in `@objectstack/cli`, the conclusion in `@objectstack/core` — with **no data path between them**. So the ready signal did not depend on the thing that broke, and therefore could not report it. Measured twice within a day, from unrelated causes: an objectui CI boot where the auth plugin failed and not one `sys_*` table existed, and this repo's own weekly registry canary on the published `npx create-objectstack@latest` on-ramp, where the tick printed directly **above** four boot warnings. In the second case the ready line carried no weight in the job's verdict at all — it was present, green, wrong, and believed by nobody.
+  
+  - **The data path.** `ObjectKernel.validateSystemRequirements()` now publishes the list it had already computed — the same array behind its own warning — on the kernel's service registry, which is the seam boot facts already cross to reach the banner (`serve` reads `auth` and `seed-summary` off it the same way). No member and no type is added to `@objectstack/core`'s public surface, and nothing re-derives which services count as `core`: that judgement stays in `ServiceRequirementDef` alone.
+  - **The line.** On a degraded boot the banner prints `⚠ Server is ready — DEGRADED: missing core services: <names>`, naming exactly what the kernel found missing. On a healthy boot the ready block is byte-for-byte unchanged, so an ordinary boot's output does not move.
+  - **Readiness is NOT made strict.** Nothing about what boots, binds, or exits changes. A machine deliberately running without auth still starts, still prints ready, and still exits 0 — the line just says what state it is ready in.
+- d4f9b2a: A session whose active organization is no longer one the user belongs to now resolves with no active organization instead of that one's data.
+  
+  Under a wall-enforcing tenancy posture (`isolated` / `group`), `resolveAuthzContext` took a browser session's stored `activeOrganizationId` as the request tenant without ever comparing it to the user's current memberships — the framework's only such comparison was gated on an API-key principal. A session whose owner had been removed from an organization therefore kept reading that organization's rows and writing into it until the session expired on its own (7 days by default), including when the removal went through the product's own offboarding path.
+  
+  That claim is now vetted: if it is not in the caller's `accessible_org_ids`, it is dropped and the context resolves with no active organization at all, which the tenant wall already fails closed on (reads resolve to nothing; a tenant-scoped write is refused by ADR-0123 D2). The principal is **not** refused — a session is a person who may hold memberships elsewhere, so they stay signed in and can switch to an organization they are actually in. The API-key arm is unchanged: a key is its organization binding and is still refused outright. The wire is unchanged; the drop is reported to the operator as a single server-side `warn`.
+- a727043: fix(rest,core): an organization-less or ex-member API key on a walled single-kernel deployment now answers 401 where it answered 200
+  
+  Under a wall-enforcing tenancy posture (`isolated`), an API key stamped with an
+  organization its owner is no longer a member of **read and wrote that
+  organization's rows** on the wiring the open core actually builds. Not a silent
+  empty set — a GET that returned the other organization's records, and a POST
+  that landed a row read back from the store carrying that organization's id and
+  the ex-member as its creator. An organization-less key on the same deployment
+  read `200` with an empty set, which is the silent failure the wall exists to
+  replace.
+  
+  The cause was a seam, not a predicate. `RestServer.computeExecCtx` derived the
+  effective tenancy posture from a per-request kernel, and on the single-kernel
+  wiring there is no per-request kernel — so the posture was `undefined` on every
+  request, and both posture-conditional API-key refusals are gated on it:
+  `organization_required` in `api-key.ts` and `organization_membership_ended` in
+  `resolve-authz-context.ts`. Neither ever ran. The Layer 0 wall itself was
+  active the whole time; it compares against the caller's active organization,
+  and an API key's tenant is `sys_api_key.active_organization_id` copied verbatim
+  — the holder's own stored claim. Enforcing the wall is what let the ex-member
+  through, because the one fact that would expose the ended membership was not an
+  input to the layer that could act on it.
+  
+  The single-kernel branch now derives the posture from a provider `rest-api-plugin`
+  wires to the lone local kernel's `tenancy` service, in the same shape as the
+  auth-service provider beside it. A host that registers no `tenancy` service is
+  unchanged and still admits: there is no wall on such a deployment, so there is
+  nothing for an organization-less key to be walled out of. A `tenancy` service
+  that was registered and **failed to build** is an outage and answers `503`, not
+  an admission — a posture that could not be read is not a posture that is absent.
+  
+  Refusals are now also said out loud on the server side, at `warn`, where each
+  one is decided: the key's row id (never the credential or its hash), the
+  principal, the organization and the reason. **The wire is unchanged** — both
+  refusals still answer the generic `401 UNAUTHENTICATED` with no reason in the
+  body, so a holder of someone else's key learns nothing a plain 401 does not
+  already tell them. The operator, who previously had a key that was neither
+  revoked nor expired and a 401 that said nothing, now has a line to find.
+  
+  Behaviour that does not move: a current member's key on the same route still
+  returns its rows and still writes; a request with no credential still answers
+  401; and an unknown, revoked or expired key is not a refusal at all, so a key
+  scanner produces no log volume.
+- 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.
+- f89812e: Five source comments in `@objectstack/cli` and `@objectstack/core` stop attributing unpack-time `manifest.integrity` re-verification to the cloud control plane and name the owner this repo has already ruled: the **future runtime loader** (ADR-0025 §3.5 steps 4–7). The enforce leg stays tracked on #11331.
+  
+  `packages/spec`'s `manifest.zod.ts` was corrected to that owner in an earlier change, and these five sites were left behind — so the repo stated both things at once. A comment that names the wrong owner costs nobody a build, but it teaches a reader (and a reading AI) to expect a verification that no component performs and that ADR-0025's own status line records as unimplemented.
+  
+  - `packages/cli/src/utils/osplugin.ts` — the `.osplugin` packaging docblock, and the `sriDigest` TSDoc.
+  - `packages/cli/src/commands/plugin/publish.ts` — the integrity-preflight comment.
+  - `packages/core/src/security/index.ts` — the `verifyIntegrity` export comment.
+  - `packages/core/src/security/plugin-artifact-integrity.ts` — the verifier's own module docblock, which had explained the module's byte-for-byte portability *by* the wrong owner. It now explains it by the leg itself: the module stays portable to whatever runs unpack-time re-verification.
+  
+  **What does NOT change.** The other half of every one of these comments — the digest map is computed by `os plugin build` and self-checked by the `os plugin publish` preflight — is true and is kept verbatim. No accept set, export, signature or runtime behaviour moves; the diff is comment prose only.
+  
+  **What moves for consumers, measured on the built output.** `@objectstack/cli` ships `dist/`, and the `sriDigest` TSDoc rides into `dist/utils/osplugin.d.ts`, so an editor's hover on `sriDigest` stops naming the control plane. `@objectstack/core`'s two sites do **not** reach its published bundle — a module docblock and a line comment above an `export {}` are both dropped from `dist/index.d.ts` — so nothing in that package's shipped bytes moves. It is declared here anyway because the pre-correction attribution is quoted in `packages/core/CHANGELOG.md`, a generated record that may not be hand-edited; a changeset naming the package is the only way the correction reaches that published record.
+- Updated dependencies [fe0d9a4]
+- Updated dependencies [ecd2158]
+- Updated dependencies [f2b5e46]
+- Updated dependencies [ed7243d]
+- Updated dependencies [6ba0db4]
+- Updated dependencies [625b0c3]
+- Updated dependencies [233222e]
+- Updated dependencies [07f40e5]
+- Updated dependencies [ceb4877]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [90e7e6d]
+- Updated dependencies [2bdabe6]
+- Updated dependencies [ca326b5]
+- Updated dependencies [8f404a5]
+- Updated dependencies [68437d4]
+- Updated dependencies [abb140c]
+- Updated dependencies [8333a6c]
+- Updated dependencies [3e3ecb0]
+- Updated dependencies [3030369]
+- Updated dependencies [d5d8d50]
+- Updated dependencies [e08892d]
+- Updated dependencies [ae05f2e]
+- Updated dependencies [b548e43]
+- Updated dependencies [c463d03]
+- Updated dependencies [64bd6a3]
+- Updated dependencies [13c48c2]
+- Updated dependencies [132742f]
+- Updated dependencies [85a2459]
+- Updated dependencies [50dc214]
+- Updated dependencies [e89fa92]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [8976ea1]
+- Updated dependencies [56fe8c2]
+- Updated dependencies [acabd24]
+- Updated dependencies [ab50c8f]
+- Updated dependencies [6491463]
+- Updated dependencies [89cf4d6]
+- Updated dependencies [21c5dcb]
+- Updated dependencies [6d4d5d3]
+- Updated dependencies [ed5d557]
+- Updated dependencies [bca21f7]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [1a7a7c9]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [ef3a138]
+- Updated dependencies [68d5dfd]
+- Updated dependencies [3e21cf0]
+- Updated dependencies [4cfc93b]
+- Updated dependencies [efd6b43]
+- Updated dependencies [859ded3]
+- Updated dependencies [fa125f3]
+- Updated dependencies [74628d9]
+- Updated dependencies [a646120]
+- Updated dependencies [6f1ce7d]
+- Updated dependencies [7778115]
+- Updated dependencies [2c753fe]
+- Updated dependencies [52804cd]
+- Updated dependencies [3f89967]
+- Updated dependencies [53cf263]
+- Updated dependencies [21aabbc]
+- Updated dependencies [9c270bb]
+- Updated dependencies [76c8c5a]
+- Updated dependencies [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 [af7edfe]
+- Updated dependencies [b60f48b]
+- Updated dependencies [c78c918]
+- Updated dependencies [cf9bda4]
+- Updated dependencies [784cb92]
+- Updated dependencies [7629f4d]
+- Updated dependencies [51df9fd]
+- Updated dependencies [a7da4de]
+- Updated dependencies [de0bcdd]
+- Updated dependencies [70f7d6d]
+- Updated dependencies [c677cda]
+- Updated dependencies [554a160]
+- Updated dependencies [f7da71e]
+- Updated dependencies [7f745c3]
+- Updated dependencies [5eb24f8]
+- Updated dependencies [2a3decc]
+- Updated dependencies [cc00df2]
+- Updated dependencies [f4e6adf]
+- Updated dependencies [ee4a59b]
+- Updated dependencies [4db3c61]
+- Updated dependencies [5ca314a]
+- Updated dependencies [e0af1a8]
+- Updated dependencies [414c1fc]
+- Updated dependencies [22c0279]
+- Updated dependencies [0db2947]
+- Updated dependencies [92b5d7f]
+- Updated dependencies [613bfbd]
+- Updated dependencies [abae16a]
+- Updated dependencies [094b8fd]
+- Updated dependencies [c7aca0d]
+- Updated dependencies [c1d8f98]
+- Updated dependencies [8e0b297]
+- Updated dependencies [5f7fa1d]
+- Updated dependencies [87f0ccc]
+- Updated dependencies [aedbaef]
+- Updated dependencies [c5d6803]
+- Updated dependencies [10d05bb]
+- Updated dependencies [69602e5]
+- Updated dependencies [c3ce76c]
+- Updated dependencies [7936b29]
+- Updated dependencies [46803fa]
+- Updated dependencies [c2a336c]
+- Updated dependencies [9f890d3]
+- Updated dependencies [0bb2318]
+- Updated dependencies [f7db8f4]
+- Updated dependencies [1ecee3e]
+- Updated dependencies [9408b7f]
+- Updated dependencies [e9fcd6b]
+- Updated dependencies [9bcd9be]
+- Updated dependencies [b398ad2]
+- Updated dependencies [99261a7]
+- Updated dependencies [81b426f]
+- Updated dependencies [001af1c]
+- Updated dependencies [fb77aa5]
+- Updated dependencies [3d3f60e]
+- Updated dependencies [581d8f8]
+- Updated dependencies [f81afe3]
+- Updated dependencies [40a44b9]
+- Updated dependencies [7a7fb03]
+- Updated dependencies [8fd246d]
+  - @objectstack/spec@17.4.0
+  - @objectstack/types@17.4.0
+
+## 17.3.0
+
+### Minor 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.
+- 4bd6faa: feat(engine,core,cluster): the authorization-cache invalidation substrate — an engine-seam write epoch, the `authz.invalidated` channel, and a non-optional boot-time posture statement (#11968)
+  
+  The substrate step (§10.3) of the accepted #11633 cross-request caching design
+  (maintainer acceptance 2026-08-25, Fork 2 → B). It ships the invalidation
+  machinery once, before the grants cache (#11967) that will consume it, so that
+  leg does not carry it. **Nothing here caches anything.**
+  
+  - **`ObjectQL.writeEpoch`** — a monotonic counter advanced by the engine
+    middleware seam on every `insert` / `update` / `delete`, ahead of the whole
+    chain (and so ahead of any `isSystem` bypass a middleware applies). It
+    generalises the private counter `@objectstack/plugin-security` has carried
+    since #10757: the mechanism was always the engine's, and hoisting it lets a
+    second consumer share **one** signal instead of minting a parallel one that
+    watches a different set of writes. A seam rather than a list of call sites,
+    because a forgotten call site fails as silent over-permission and writing
+    through the engine is the only way to write at all — including better-auth's
+    own adapter.
+  - **`authz.invalidated`** — one new channel on the existing `IPubSub`, bridged
+    in the shape `MetadataClusterBridgePlugin` already uses. ⭐ **The TTL a
+    consuming cache carries is the correctness contract; this channel is not.** No
+    shipped driver delivers better than at-most-once (`cluster.mdx` §4.2), so a
+    missed message is *expected*, the bridge stays out of the write path (a
+    publish failure is logged and swallowed, never awaited by the writer), and the
+    channel only moves the *typical* convergence from one TTL to one network hop.
+    That statement lives in the code at the channel, where a consumer reads it.
+  - **The boot-time posture statement** — non-optional by the ruling. Whenever a
+    grants cache is enabled (`OS_AUTHZ_GRANTS_CACHE_TTL_MS` > 0) and there is no
+    cross-node invalidation bus, the deployment is told so at `warn`, every boot,
+    naming the window it accepted and the remedy. It is a statement, not a
+    refusal: a TTL-bounded per-process cache is a legitimate configuration. It is
+    said out loud because a silently-absent invalidation bridge is how a security
+    control gets disabled with nobody noticing (#4785). The in-process `memory`
+    driver counts as **no** bus — a cluster service exists on the shipped default
+    while fanning out to nobody, which is the case a "is a cluster service
+    registered?" check answers `yes` to and is wrong about.
+  
+  **Runtime behaviour is unchanged.** With no cache consumer the epoch has zero
+  subscribers, so nothing is published and nothing is invalidated; with the
+  shipped default TTL of `0` the bridge attaches nothing and logs nothing above
+  `debug`. The one composition change worth naming: `Runtime` now registers
+  `AuthzClusterBridgePlugin` **unconditionally**, including under `cluster: false`
+  — that is not an oversight, it is the loudest case the posture check has, and
+  skipping it there would put the statement's absence exactly where the missing
+  bus is.
+  
+  `@objectstack/plugin-security` is a `patch`: its permission-set memo now reads
+  the engine's epoch when the wired engine exposes one and keeps its private
+  counter otherwise (test doubles, embeddings). The covered set of writes is
+  identical — the plugin's own middleware was already global — and it is now
+  identical *by construction* rather than by two files agreeing on which
+  operations count.
+- 86cbe37: feat(core): cross-request authorization grants cache — leg B of #11633 (#11971)
+  
+  `resolveUserAuthzGrants` can now cache its resolved envelope across requests,
+  governed by `OS_AUTHZ_GRANTS_CACHE_TTL_MS`. **The default is `0` — the cache is
+  OFF and the shipped behaviour is unchanged** (Fork 4 of the accepted #11633
+  design): a deployment that enables it accepts the configured staleness window
+  explicitly, and the boot-time posture statement says so out loud when no
+  cross-node invalidation bus is attached.
+  
+  With the cache on:
+  
+  - **Coarse write-invalidation (Fork 1A).** Any engine write to a watched
+    authorization object (`sys_member`, `sys_user_position`,
+    `sys_user_permission_set`, `sys_position`, `sys_position_permission_set`,
+    `sys_permission_set`, `sys_user`) retires every entry on the writing node —
+    a grant/revoke/role change is observed by the very next request there, by
+    invalidation and not by TTL. `metadata.changed` and peer-node
+    `authz.invalidated` hints retire wholesale via the engine write epoch.
+    `sys_session` is deliberately not watched (its once-a-minute
+    `last_activity_at` cadence would turn the cache into a non-cache).
+  - **Expiry-boundary rule.** Entries expire at `min(ttl, nextBoundary)`, where
+    `nextBoundary` is the earliest upcoming ADR-0091 `valid_from`/`valid_until`
+    among the rows consulted — a validity window flipping is a permission change
+    with no write anywhere, so the timer is the only mechanism for that class.
+  - **Ruled bypass list.** The permission explainer
+    (`plugin-security` `buildContextForUser`) and `runAs:'user'` automation runs
+    (`service-automation`) always resolve fresh, and never populate the cache.
+  - The TTL remains the correctness contract; the `authz.invalidated` bus only
+    narrows the typical cross-node window (no shipped driver exceeds
+    at-most-once delivery).
+- 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. -->
+- d8024f0: feat(core): `Plugin.type` is the closed set the spec declares — a `PluginType` derived from `CORE_PLUGIN_TYPES` (#13925)
+  
+  **BREAKING** accept-set narrowing on a published type, shipped as `minor`
+  under the repo's launch-window convention for breaking changes. `Plugin.type`
+  (and, through it, `PluginMetadata.type`) was declared `string`, so nothing
+  type-checked a plugin author against the eight values the platform accepts —
+  the TSDoc beside it carried the whole enumeration as prose, and prose drifted.
+  Maintainer ruling 2026-09-01: the Zod enum in `@objectstack/spec`
+  (`PluginSchema.type`, declared `z.enum(['standard', ...CORE_PLUGIN_TYPES])`)
+  is the authority and the contract was always a closed set; the `string` in
+  core was the mismatch, and narrowing it is core aligning to the declared
+  contract rather than a new restriction. Paid in one stroke — no warning window.
+  
+  What changes:
+  
+  - `@objectstack/core` now exports `PluginType`, derived from the spec's own
+    constant: `'standard' | (typeof CORE_PLUGIN_TYPES)[number]` — today
+    `standard`, `ui`, `driver`, `server`, `app`, `theme`, `agent`, `objectql`.
+    It is not re-spelled in core, so the compiler's accept set and the Zod gate's
+    cannot drift apart; a runtime parity test pins the two against each other.
+  - `Plugin.type` is typed `PluginType`. A literal outside the set, or a value
+    typed `string`, no longer compiles. Runtime behaviour is unchanged: the Zod
+    gate refused such a value before and still does (`invalid_value` at `type`).
+  
+  **Migration.** A plugin that declares one of the eight members needs no change.
+  A plugin that assigned a computed or `string`-typed value narrows it at the
+  producer — declare the literal, or type the variable `PluginType` — rather than
+  casting at the assignment; a value that was never one of the eight was never a
+  valid plugin type and was already refused at parse time.
+  
+  <!-- adr-0087: not-required (no-migration-prescription) A TypeScript narrowing on a published runtime interface, aligning `packages/core` to the accept set `packages/spec` already declared. No metadata key, spec symbol, Zod schema, object definition or stored representation is added, removed or renamed — `CORE_PLUGIN_TYPES` and `PluginSchema.type` are read, not changed — so `objectstack migrate meta` has nothing to rewrite and there is no tombstone to mint. The channel that reaches an affected author is the compiler, at the assignment, which is more precise than a ledger line; which member a formerly `string`-typed value should become is authoring intent no migration entry can decide. The in-repo census under the workspace typecheck is recorded on the PR. -->
+- 4635f3e: fix(spec,core): `HotReloadConfig.stateStrategy` refuses the two values it never implemented; `distributedConfig` retired (#12340, ADR-0049)
+  
+  <!-- adr-0087: registered hot-reload-inert-state-strategies-retired -->
+  
+  **BREAKING** accept-set narrowing + export removal, landing after the v17.0.0
+  cut (the lockstep launch-window convention ships it as `minor`; the
+  prescription is registered under protocol major 18 —
+  `RETIRED_DEFS_BY_MAJOR[18]` + the D3 semantic entry
+  `hot-reload-inert-state-strategies-retired` — where `os migrate meta` users
+  will look).
+  
+  This is ADR-0049 applied one level INSIDE the library the 2026-08-25 #11825
+  ruling deliberately kept. That ruling retired the authorable lifecycle-config
+  container and kept `HotReloadConfigSchema` as a host-driven library parameter
+  type; this change measures the kept vocabulary's own remainder and finds the
+  same defect in it. The keep itself stands — `HotReloadConfigSchema`,
+  `PluginStateSnapshotSchema` and the health vocabularies still export, and
+  `HotReloadManager` / `PluginHealthMonitor` are untouched.
+  
+  The `'disk'` and `'distributed'` arms of `PluginStateManager.saveState` both
+  wrote to the SAME in-memory `Map` as `'memory'` — the in-source comments said
+  "memory fallback" — and announced the substitution at DEBUG level only. A host
+  that asked for durable or cluster-replicated state got process-local memory
+  and no error: state that does not survive the restart it was configured to
+  survive. `distributedConfig` had ZERO readers anywhere, so an author could
+  name a Redis endpoint, a TTL and a replication factor and nothing ever opened
+  a connection.
+  
+  FROM → TO:
+  
+  - `stateStrategy: 'disk'` → `stateStrategy: 'memory'` — byte-identical runtime
+    behaviour, because `'disk'` already stored to memory. It is the spelling
+    that was false, not the behaviour.
+  - `stateStrategy: 'distributed'` → `stateStrategy: 'memory'` — same, or
+    `'none'` to disable state preservation outright.
+  - `distributedConfig: { … }` → *(removed)* — delete the key. It left with the
+    `'distributed'` value its own doc comment called it "required" for.
+  - `DistributedStateConfigSchema` / `DistributedStateConfig` /
+    `DistributedStateConfigParsed` → *(removed)* — the orphan value schema of
+    that one key.
+  
+  One-line fix: replace `'disk'` or `'distributed'` with `'memory'` and delete
+  any `distributedConfig` — you were already getting in-memory state. There is
+  no in-tree replacement for durable or distributed plugin state; persist it in
+  the host, which owns the process lifetime these strategies pretended to
+  outlive. Real disk or distributed persistence returns only via the ENFORCE
+  route of ADR-0049 — the implementation first, the declaration with it.
+  
+  The retirement kit:
+  
+  - **enum-value narrowing** (`['memory','disk','distributed','none']` →
+    `['memory','none']`): invisible to all four ratchets by construction (the
+    def still emits), so the prescription hangs on the enum's own `error` map
+    dispatched by `issue.input` — the `crypto.hash` / `managedBy: 'system'`
+    precedent. A value that was never legal still gets zod's own enum message,
+    so a typo is not told it "was removed".
+  - **whole-def deletion** (route 3 — `HotReloadConfig` is not an authorable
+    surface: no metadata-type binding, stack collection or manifest embed ever
+    carried it, and nothing in the tree parses `HotReloadConfigSchema` outside
+    its own unit test, so there is no authored document to rewrite and nobody
+    who could receive a parse-time tombstone): `kernel/DistributedStateConfig`
+    in `RETIRED_DEFS_BY_MAJOR[18]` plus the D3 semantic entry. Ratchets moved as
+    a def removal must — `api-surface` −3, `authorable-surface` −8,
+    `json-schema.manifest` −1.
+  - **runtime doors** in `@objectstack/core`, because route 3 leaves no
+    parse-time prescription: `HotReloadManager.registerPlugin` now refuses an
+    unhonoured `stateStrategy` and a leftover `distributedConfig` with an
+    ADR-0112 envelope (`code: VALIDATION_ERROR`, `status: 400`) carrying the
+    prescription. Refused BEFORE the `enabled` check, so a disabled config
+    cannot smuggle the false declaration through. TypeScript hosts never reach
+    it — `HotReloadConfigParsed['stateStrategy']` is now `'memory' | 'none'`, a
+    compile error at the call site.
+  - **pin move, declared**: `DistributedStateConfigSchema` was NAMED in the
+    #11825 survivor list, so this reverses one line of that ruling on new
+    evidence — #11825 measured the container's six groups, never this key's own
+    readers. The pin in `kernel/plugin-lifecycle-advanced-retirement.test.ts`
+    moves in the same commit with the reasoning recorded beside it, and asserts
+    the surrounding keep is intact.
+  - zero in-tree consumers passed `'disk'` or `'distributed'` (measured at
+    cdbd9204b6 with a firing positive control; every live caller passes
+    `'memory'` or `'none'`), so no in-repo source changes ride along.
+- ee3595c: fix(spec,core): `HotReloadManager.startWatching` refuses instead of reporting success; `HotReloadConfig.watchPatterns` retired (#12428, ADR-0049)
+  
+  <!-- adr-0087: registered hot-reload-watch-placeholder-retired -->
+  
+  **BREAKING** accept-set narrowing, landing after the v17.0.0 cut (the lockstep
+  launch-window convention ships it as `minor`; the prescription is registered
+  under protocol major 18 — `RETIRED_KEYS_BY_MAJOR[18]` + the D3 semantic entry
+  `hot-reload-watch-placeholder-retired` — where `os migrate meta` users will
+  look). Graded `minor` rather than `major` for the same reason #12340 was one
+  day earlier, in this same module.
+  
+  ADR-0049 applied one symbol over from #12340, in the same file and on the same
+  per-key test. The #11825 keep still stands: `HotReloadConfigSchema` and
+  `PluginStateSnapshotSchema` still export, and `HotReloadManager` /
+  `PluginHealthMonitor` are untouched apart from the two doors below.
+  
+  `HotReloadManager.startWatching` contained **no watcher**. Its whole body was a
+  guard plus `logger.info('File watching started', { patterns })`, above an
+  in-source note saying real watching "would require chokidar or similar". Where
+  #12340's inert fallback at least announced itself at DEBUG, this claimed
+  success at **INFO**: an operator who set `enabled: true` with `watchPatterns`
+  and read that line had been told the opposite of the truth. `watchHandles` was
+  only ever read, deleted, iterated and cleared and **never set**, so
+  `stopWatching`'s cleanup branch and the teardown loop over its keys were
+  structurally unreachable rather than merely untaken. `watchPatterns` therefore
+  had no reader that acted on it — its only two uses were log lines.
+  
+  FROM → TO:
+  
+  - `watchPatterns: ['src/**/*.ts']` → *(removed)* — delete the key. Declare your
+    globs wherever your own watcher reads them.
+  - `manager.startWatching(name)` → `manager.scheduleReload(name, reloadFn)`,
+    called from your own watcher's change handler. That is the debounced
+    integration point this class does implement, and it is unchanged.
+  
+  One-line fix: delete `watchPatterns`, and call `scheduleReload` from your own
+  file watcher instead of `startWatching` — nothing was ever watched, so nothing
+  that used to happen stops happening. File watching is the host's job in this
+  host-driven library; `chokidar` is already a dependency of
+  `@objectstack/metadata`, `@objectstack/metadata-fs` and `@objectstack/cli` —
+  never of `@objectstack/core` — so a host has a working model to copy.
+  
+  The retirement kit:
+  
+  - **key tombstone**, and the build is what chose it: the plain deletion was
+    tried first and `gen:schema` gate (a) refused it, because
+    `HotReloadConfigSchema` is not `.strict()` and a bare deletion would be a
+    silent strip (#3733, ADR-0104) — the very defect being retired, one layer
+    down. #12340 could take route 3 because what left there was a whole *def*; a
+    key leaving a *surviving* def has no such exit. So `watchPatterns` is
+    `retiredKey()`-tombstoned, its surface line carries `[RETIRED]`, and
+    `kernel/HotReloadConfig:watchPatterns` is registered by exact key in
+    `RETIRED_KEYS_BY_MAJOR[18]`. A key tombstone on a surviving def moves
+    `authorable-surface` only — the def still emits, so `api-surface` and
+    `json-schema.manifest` do not.
+  - **no D2 conversion**, deliberately: the chain walks a normalized stack, and
+    `HotReloadConfig` is not an authorable surface — no metadata-type binding,
+    stack collection or manifest embed ever carried it — so a conversion would be
+    a transform with no seam that ever runs. For the same reason the prescription
+    carries no `os migrate meta` sentence, exactly as its `stateStrategy` sibling
+    in this module does not.
+  - **runtime doors** in `@objectstack/core`, because nothing in the tree parses
+    `HotReloadConfigSchema` outside its own unit test, so the tombstone alone
+    reaches nobody: `startWatching` now throws an ADR-0112 envelope
+    (`code: VALIDATION_ERROR`, `status: 400`) carrying the prescription, and
+    `registerPlugin` refuses a leftover `watchPatterns` the same way — before the
+    `enabled` check, so a disabled config cannot smuggle the false declaration
+    through. `startWatching` is kept as a throwing door rather than deleted so
+    that caller meets a prescription instead of a bare `TypeError`.
+  - **dead code removed with a firing positive control**: `watchHandles` and both
+    of its unreachable readers are gone. The zero was pinned first —
+    `reloadTimers.set` resolves a real writer in the same file and the same scan,
+    while `watchHandles.set` resolves nothing anywhere. `stopWatching` keeps the
+    half that always did something (it cancels a pending debounced reload), and
+    `shutdown` is unchanged in effect: the loop it lost iterated `watchHandles`
+    and therefore ran zero times.
+  - **ENFORCE and EXPERIMENTAL were both unavailable**, which is why this is a
+    removal: no runtime composes `HotReloadManager`, so enforcing would build for
+    a caller that does not exist; and a scan of every planning doc returned zero
+    mentions of hot-reload file watching against 145 control hits in the same
+    files, so there is no roadmap for `experimental` to point at.
+- af56546: feat(platform-objects): packaged disable works without the automation service, and the activation ledger has one implementation (#12359, #12350)
+  
+  Two halves of ADR-0126's "ledger convergence", bundled by maintainer ruling
+  (2026-08-26, verbatim and untranslated: 「同意」).
+  
+  ## The registration follows the declaration (#12359)
+  
+  `sys_metadata_activation` is declared in `@objectstack/platform-objects`, but
+  the only thing that REGISTERED it was the automation service's manifest —
+  because flows were the ledger's first and, until packaged actions landed, only
+  consumer. Packaged actions are a second consumer with a different owner: their
+  consult and write path live on the ObjectQL engine, present in every
+  composition that can execute an action.
+  
+  So a deployment with actions and no automation service had no ledger table, and
+  the activation door answered **503 SERVICE_UNAVAILABLE** on every flip —
+  correctly (ADR-0126 §6 wall 3: a flip that cannot be made durable must not be
+  reported as one) and permanently. Measured on a real boot; it is now this
+  change's positive test, measured on the same boot:
+  
+  ```
+  POST /api/v1/actions/_activation/showcase_task/showcase_mark_done {"enabled":false}
+    before -> 503 SERVICE_UNAVAILABLE   after -> 200, and dispatch refuses 409 ACTION_DISABLED
+  ```
+  
+  `PlatformObjectsPlugin` registers it now, so every composition carrying
+  platform-objects has the ledger and each future ADR-0126 §8 consumer (`tool`,
+  `skill`, `position`) inherits it. **MOVE, not add** — the automation service no
+  longer names the object. That was not a style choice: a second code package
+  claiming one object throws `Object "…" is already owned by package "…"`
+  (ADR-0029 D3/D7), measured, so adding a registrant would have been a boot
+  failure rather than a duplicate.
+  
+  **Upgrade is a no-op for existing data, and that is measured rather than
+  asserted.** A manifest is also a ROUTING decision — `resolveDatasourceBinding`
+  step 4 routes an object by its owning package's `defaultDatasource` — so the
+  registrar carries the table's datasource with it:
+  
+  ```
+  owner com.objectstack.service-automation (defaultDatasource:'cloud') -> 'cloud'
+  owner com.objectstack.platform-objects   (none)                     -> undefined (global default driver)
+  ```
+  
+  The ledger table already exists in live databases, so on any deployment
+  carrying a `cloud` datasource that difference would leave the rows in one
+  database and read another — every disabled artifact silently re-arming. The
+  ledger therefore rides its own manifest from the same plugin, carrying the
+  automation manifest's `scope` / `namespace` / `defaultDatasource` triple
+  verbatim. The three siblings (`sys_migration`, `sys_migration_journal`,
+  `sys_secret`) deliberately do not get it and keep riding the project database.
+  
+  ## One implementation of the §4 row contract (#12350)
+  
+  ADR-0126 §4 declares one activation ledger; it had two independent
+  implementations of that one row contract — `ObjectStoreFlowActivationStore`
+  (service-automation) and `ObjectStoreActionActivationStore` (objectql). They
+  agreed because the second was written from the first, and nothing structurally
+  held them together; §8 pre-charts `tool`, `skill` and `position`, and a third
+  and fourth copy is where the org-row skip and the `0`-is-false read get lost
+  quietly, in the direction (an artifact re-arming) nothing else measures.
+  
+  Neither consumer could import the other, so the contract now lives once in
+  `@objectstack/core` — the package both already depend on — as
+  `ObjectStoreMetadataActivationStore(engine, metadataType)`, exported alongside
+  `InMemoryMetadataActivationStore`, `MetadataActivationRow`,
+  `MetadataActivationStore`, `MetadataActivationStoreEngine` and
+  `METADATA_ACTIVATION_TABLE`. Each consumer keeps its own name, its own
+  one-argument constructor and its own docs, and fixes the discriminator.
+  
+  **No behaviour change and no API break.** `ObjectStoreFlowActivationStore` /
+  `InMemoryFlowActivationStore` / `FlowActivationStoreEngine` and
+  `ObjectStoreActionActivationStore` / `InMemoryActionActivationStore` /
+  `ActionActivationRow` / `ActionActivationStore` / `ActionActivationStoreEngine`
+  / `ACTION_ACTIVATION_TABLE` are exported from the same modules with the same
+  shapes. Row semantics are byte-equivalent: deployment-level rows scoped only by
+  the `metadata_type` discriminator, a driver `0` read as false, read-then-write
+  rather than a blind upsert, and no `delete` in the engine slice because
+  re-enabling rewrites the row.
+  
+  Both existing pin suites stay green **unchanged**, which is what makes them the
+  proof the consolidation lost nothing — verified by ablation: mutating the one
+  shared implementation turns both of them red on their own assertions, so both
+  really reach it.
+- a8c00e2: feat(core): cache successful `sys_setting` localization reads, invalidated synchronously on write (#11966)
+  
+  Leg C (ship-first) of the accepted #11633 cross-request caching design
+  (maintainer acceptance 2026-08-25, forks 1A / 2B / 3A / TTL-0).
+  `resolveLocalizationContext` re-read `sys_setting` on **every** authenticated
+  request to answer the same three keys — `timezone` / `locale` / `currency` —
+  for a workspace whose values change roughly never. That read is now cached.
+  
+  **Grade: `minor`, not `patch`.** It adds a deployment variable
+  (`OS_LOCALIZATION_CACHE_TTL_MS`) and changes the query pattern of a shipped code
+  path. Not `major`: the observable contract callers actually depend on — a
+  settings write is visible to the very next read — is preserved, and pinned.
+  
+  Caching this read was tried once before and reverted. #10221's first version
+  memoized every outcome for 30s and CI went red on
+  `analytics-timezone.dogfood.test.ts`, which writes a new org timezone and
+  expects the very next analytics query to bucket under it; the cache was narrowed
+  to memoize **failures** only. That verdict was on **TTL-only** caching and it
+  still stands unamended. What changed is that the process now has invalidation
+  seams it did not have then:
+  
+  - **Primary — the settings change seam.** `SettingsService.subscribe(ns, handler)`
+    dispatches synchronously and in-process from the write path, after the row is
+    persisted. (⚠️ #11633 calls this a "settings change bus"; no such module
+    exists — `subscribe()` is the seam. No change was needed in
+    `@objectstack/service-settings`: the seam was already public and already does
+    exactly this.)
+  - **Backstop — the engine write epoch** from #11968's substrate. Needed because
+    this resolver's own fallback reads `sys_setting` *directly*, so a seeder or
+    any other direct engine write emits no settings event at all. It is read
+    structurally rather than imported, because `@objectstack/objectql` depends on
+    `@objectstack/core` and the substrate declared `WriteEpochLike` separately for
+    exactly this consumer. A peer node's hint arrives as a local bump, so an
+    attached `authz.invalidated` bridge narrows cross-node convergence for free.
+  - **TTL** — the residual bound, for what neither seam can see. Default 30s,
+    `0` disables the cache on a real path rather than a degenerate one.
+  
+  Two rules carry the change and are pinned rather than merely documented:
+  
+  1. **A success is cached only when the engine exposes the write epoch.** A `ql`
+     with no seam is a `ql` whose writes the cache cannot observe, so rather than
+     degrade to the TTL-only shape that was already reverted here once, the cache
+     declines. A partial `{ current }` shape is not a seam either — a counter
+     nothing can bump would read as a live invalidation source and pin the answer
+     for a whole TTL.
+  2. **Invalidation retires success entries only.** #10221's failure memo exists
+     for an environment where `sys_setting` is missing; retiring it on a write
+     would restart precisely the per-request driver log spam that memo removed,
+     and no write can create a missing table. It stays TTL-bound and behaves
+     exactly as #10221/#11877 shipped it.
+  
+  `analytics-timezone.dogfood.test.ts` is unchanged and unweakened — it is this
+  leg's acceptance test, and an ablation that reduces the cache to its TTL turns
+  it red on the same assertion the original revert was recorded against.
+- 7131f12: **Security:** the "is this user id a platform admin?" question is now asked in exactly one place, and the two copies that answered it differently are gone (#10348, #10949).
+  
+  ADR-0068 D2 defines platform standing as one thing — an unscoped `admin_full_access` grant, held now. `core/security/resolve-authz-context.ts` is the declared authority for authorization derivation and its header states that every entry point must resolve through it and never re-read the grant tables itself. `plugin-auth`'s `auth-manager.ts` did exactly that twice: once inside the `customSession` callback, and once in the predicate that authorizes `/sso/register` and, through the impersonation oracle, `/admin/impersonate-user`. Both copies are deleted. Both callers — and the session payload — now ask `hasPlatformAdminStanding(engine, userId)`, a projection of `resolveUserAuthzGrants` exported from `@objectstack/core`, so a platform-admin verdict is derived in one place for the whole platform.
+  
+  **What that changes, and it is a tightening on all three counts.** The deleted copies applied neither the ADR-0091 validity window nor the ADR-0049 `active` check, and resolved `admin_full_access` by matching a name over a page of the permission-set catalogue. The authority applies both checks before any derivation and resolves the set by id. So:
+  
+  - an **expired** platform-admin grant no longer authorizes `/sso/register` or `/admin/impersonate-user`, and no longer appears in the session payload;
+  - a **deactivated** `admin_full_access` permission set no longer confers platform standing anywhere — the deactivation dialog's promise now holds on these gates too;
+  - an environment holding **more permission sets than a single catalogue page** can no longer lose the `admin_full_access` row and demote every platform admin at once.
+  
+  **One behaviour widens, and it was ruled deliberately** (maintainer, 2026-08-24). The `customSession` copy read without a system identity while the other read with one. The single authority reads as system, so on a strictly org-scoped deployment the session payload stops under-reporting platform admin — the fail-closed drift between the payload and the gates ends. Open-core composition is unaffected: the two reads reached identical rows there already.
+  
+  **The org boundary is unchanged and now pinned at both gates.** An org owner, an org admin, a `TENANT_ADMIN`-posture principal and an org-scoped `admin_full_access` grant are all refused — the `PLATFORM_ADMIN` rung derives from the unscoped capability grant alone. The predicate takes an engine and a user id and nothing else: it deliberately does not accept the resolver's caller-supplied seeds, so no part of a request can supply part of its own verdict.
+  
+  Population queries are a different kind and are untouched: `ensure-default-organization.ts` asks *which* user is the platform admin, which a per-user predicate cannot express.
+- 33184fd: `PLATFORM_ADMIN` can now be anchored on deployment CONFIGURATION instead of a stored grant row: an account whose `sys_user.email` is on `OS_PLATFORM_OWNER_EMAIL` **and** whose `email_verified` reads verified resolves `PLATFORM_ADMIN` with the declared `admin_full_access` capability set, derived live on each authorization resolution (#11663 leg L2, design accepted 2026-08-25 as bundle 1A/2B/3A/4A/5A/6A/7A).
+  
+  **Additive — nothing is revoked.** The legacy unscoped `admin_full_access` grant still confers exactly as it did; a holder whose standing rests on the row alone now gets a once-per-process pointer at the configuration line that re-anchors them. A deployment that has declared no administrators resolves byte-identically to before: the config list is empty, the derivation answers "not an admin" before it reads any row, and the pinned batch-equivalence query multiset is unchanged.
+  
+  **The variable takes a list.** `OS_PLATFORM_OWNER_EMAIL` accepts one address or a comma-separated list of them — one normalization (`trim().toLowerCase()`), duplicates collapsed, blank entries dropped. ⛔ Any entry that is not an address **fails the whole variable closed** with a loud refusal naming it, rather than being skipped: silently dropping a typo would leave a narrower administrator set than the operator declared, with nothing anywhere to notice. Unset, blank or refused all mean **zero** config-derived administrators.
+  
+  **Verified-email match only.** An unverified account holding a configured address confers nothing, and an ABSENT `email_verified` column reads unverified. The match reads the caller's own **stored** `sys_user` row, never the caller-supplied session email.
+  
+  New exports from `@objectstack/core`: `resolvePlatformAdminEmails`, `parsePlatformAdminEmails`, `matchesConfiguredPlatformAdmin`, `normalizePlatformAdminEmail`, `PLATFORM_ADMIN_EMAIL_SEPARATOR`, `ADMIN_STANDING_NON_TABLE_INPUTS` and the test hooks beside them. `@objectstack/core` now depends on `@objectstack/types` (measured acyclic: `types` depends only on `spec`).
+  
+  `@objectstack/plugin-auth`'s break-glass guard follows the derivation, as it must: `ADMIN_STANDING_SURFACE.sys_user` is reclassified `derives`, the last-administrator enumeration counts config-derived administrators through the resolver's own predicate, and a fifth write shape is judged — a change of address or an `email_verified` reset that would leave the environment with no administrator is refused, naming the configuration as the remedy. An ordinary profile write still costs the guard no reads.
+- b72db01: fix(spec,core): `PluginHealthMonitor` stops claiming a restart it never performed; the three `PluginHealthCheck` restart keys retired (#12032, ADR-0049)
+  
+  <!-- adr-0087: registered plugin-auto-restart-never-reinitialised -->
+  
+  **BREAKING** accept-set narrowing, landing after the v17.0.0 cut (the lockstep
+  launch-window convention ships it as `minor`; the prescriptions are registered
+  under protocol major 18 — three `RETIRED_KEYS_BY_MAJOR[18]` entries plus the D3
+  semantic entry `plugin-auto-restart-never-reinitialised` — where
+  `os migrate meta` users will look). Graded `minor` rather than `major` for the
+  same reason #12340 and #12428 were, the day before, in this same module.
+  
+  ## What was measured
+  
+  `PluginHealthMonitor.attemptRestart` called `plugin.destroy()` and stopped
+  there. The comment above the call read *"Call destroy and init to restart"*,
+  and `init` appeared in `health-monitor.ts` **only inside that comment**. So a
+  plugin whose health checks crossed `failureThreshold` with `autoRestart: true`
+  got: `destroy()`, a log line reading `Plugin restarted`, status `recovering`,
+  and periodic health checks that carried on running against the destroyed
+  instance. The default check when no `checkMethod` resolves is
+  `{ name: 'plugin-loaded', status: 'passed' }`, which a destroyed object passes
+  indefinitely — so the **terminal** report on a torn-down, never-re-initialised
+  plugin was `healthy`.
+  
+  Reproduced at `ee3595cefd` before anything was changed, with
+  `successThreshold: 3`:
+  
+  ```
+  round 1 (failing): status=failed     destroyed=0 alive=true
+  after backoff:     status=recovering destroyed=1 alive=false
+  recovery round 1:  status=recovering destroyed=1 alive=false
+  recovery round 2:  status=recovering destroyed=1 alive=false
+  recovery round 3:  status=healthy    destroyed=1 alive=false
+  ```
+  
+  #11955 made that report *more* convincing rather than less: reaching `healthy`
+  now costs `successThreshold` consecutive passing rounds, so a destroyed plugin
+  has to earn a declared number of passes before it is misreported.
+  `restartAttempts` was incremented as though a restart had occurred, and
+  `maxRestartAttempts` / `restartBackoff` scheduled further "restarts" of a plugin
+  that was never brought back up.
+  
+  ## Why REMOVE and not the other two ADR-0049 states
+  
+  **ENFORCE** would have to build the restart, and the class cannot host one.
+  `Plugin.init(ctx)` needs a `PluginContext`; the only two `plugin.init(...)` call
+  sites in the tree are the kernel's own boot loops (`kernel-base.ts:202`,
+  `kernel.ts:607`), both over the full plugin list, with a context that is
+  `private` on `ObjectKernel` and `protected` on `KernelBase`. No host can obtain
+  one, so a host-provided re-init hook would have had nothing to call. (Positive
+  control for that scan: the same pass resolves five real non-test
+  `plugin.destroy()` call sites, so it does see lifecycle drivers.) Building a
+  per-plugin re-init API for a caller that does not exist — no runtime constructs
+  `PluginHealthMonitor` (#11825) — is the speculation ADR-0049's staged decision
+  names as the wrong default at this milestone, where the shippable liability is
+  the false promise and not the missing feature.
+  
+  **EXPERIMENTAL** requires a roadmap. A scan of the whole `docs/` planning + ADR
+  corpus returned **zero** mentions of plugin auto-restart, against 118 control
+  hits for "health" and 13 for "hot reload" in the same corpus.
+  
+  `maxRestartAttempts` and `restartBackoff` leave with `autoRestart` rather than
+  as a tidy-up: with no restart, *"Maximum restart attempts before giving up"* and
+  *"Backoff strategy for restart delays"* have nothing left to be the vocabulary
+  **of** — the test that took `distributedConfig` out with the `stateStrategy`
+  value it was documented as requiring (#12340).
+  
+  ## What changes for a host
+  
+  All three keys are **tombstoned**, not deleted: `PluginHealthCheckSchema` is not
+  `.strict()`, so a bare deletion would be a silent strip (#3733, ADR-0104) — a
+  milder form of the defect being retired. A TypeScript host gets a `tsc` error
+  (the keys are typed `never`); a parse raises the prescription; and
+  `PluginHealthMonitor.registerPlugin` refuses a hand-built config carrying any of
+  them with an ADR-0112 envelope (`code: VALIDATION_ERROR`, `status: 400`), thrown
+  before any state is stored so a refused config leaves no half-registered plugin
+  behind.
+  
+  `PluginHealthMonitor` no longer calls `plugin.destroy()` at all. A plugin that
+  crosses `failureThreshold` is reported `degraded` / `unhealthy` / `failed` and
+  left running; acting on that is the host's job in this host-driven library
+  (#11825 route 2). Poll `getHealthStatus(pluginName)` / `getHealthReport(pluginName)`
+  and restart at the level that owns the plugin's lifetime.
+  
+  Everything else in the monitor is unchanged: registration, periodic checks, the
+  `timeout` race and its refd-timer guard (#4875), both failure routes sharing the
+  counters (#11852), and `successThreshold` binding from every status that records
+  a failure (#11955). `recovering` is now written only by the success branch —
+  the one writer that ever meant it.
+- 49f0dcf: feat(core): retire the inert `PluginMetadata` surfaces — `configSchema` with `PluginConfigValidator`, and `hotReloadable` (#11982, #12587, ADR-0049)
+  
+  <!-- adr-0087: not-required (runtime-interface-only packages/core/src/plugin-loader.ts#PluginMetadata) PluginMetadata is a runtime TS interface in packages/core with no Zod schema, no spec declaration and no stored representation; no metadata surface references it (the PluginMetadata in packages/spec/src/kernel/plugin-validator.zod.ts is an unrelated locally-declared homonym). The deleted PluginConfigValidator / createPluginConfigValidator were runtime classes in the same non-metadata module family, so `objectstack migrate meta` has nothing to rewrite; the compiler is the notification channel — TS2353 on the removed fields, TS2305 on the removed exports. -->
+  
+  **BREAKING**: removes a published-but-inert capability from the `.` entry of
+  `@objectstack/core`. Shipped as `minor` under the lockstep launch-window
+  convention (a `major` bump is refused repo-wide by `check:changeset-no-major`).
+  
+  Removed, each measured at zero live consumers with positive controls (the
+  sibling `startupTimeout` is read live by the kernel's startup timeout guard);
+  maintainer ruled retire under ADR-0049 enforce-or-remove, 2026-08-27,
+  decision-inbox batch 5; recorded in ADR-0025 §3.7:
+  
+  - `PluginMetadata.configSchema` — declared "Configuration schema for
+    validation", but the mechanism could never run: the loader's only call
+    passed no config, and no caller could — plugin factories close over their
+    config, so the kernel never receives it. Every one of ~40 production
+    `kernel.use()` compositions already passes config as constructor arguments
+    and works.
+  - `PluginConfigValidator` / `createPluginConfigValidator` — the validator
+    behind that field: real code with zero reachable invocations, deleted along
+    with its unit test and its export from the security barrel.
+  - `PluginMetadata.hotReloadable` — declared "Whether plugin supports hot
+    reload" with zero reads and zero declarations: `HotReloadManager.reloadPlugin`
+    gates only on its own registered reload configs, so `hotReloadable: false`
+    was hot-reloaded identically to `true`.
+  - The `packages/core/ADVANCED_FEATURES.md` example whose inline comment
+    promised "Config is validated before init is called" — false on the
+    retired ref, and the retired surface's only in-repo declaration site.
+  
+  One-line fixes, per symbol. If you declared `configSchema` on a plugin:
+  delete the field and parse your config at the plugin's own seam —
+  `MyConfigSchema.parse(options)` in the plugin factory or constructor, the
+  pattern `packages/rest` uses. If you imported `PluginConfigValidator` or
+  `createPluginConfigValidator`: delete the import and hold your own
+  `schema.parse` call; the compiler (TS2305) locates every such site. If you
+  declared `hotReloadable`: delete the field — it never gated anything, and
+  hot-reload participation remains governed solely by
+  `HotReloadManager.registerReloadConfig`.
+  
+  Re-declaring a kernel-owned config-validation surface is a fresh decision for
+  the day ADR-0025's plugin distribution layer lands, with #11982's zero-caller
+  measurement as its starting evidence.
+- add4360: fix(core): tell "service never registered" apart from "service failed to construct" on the async path (#13905)
+  
+  `PluginLoader.getService` — reached through `Kernel.getServiceAsync` — answered two
+  different facts with the same bare `Error`. "Nothing ever registered this service" and
+  "the service is registered and could not be built" arrived at a caller as one
+  indistinguishable rejection, separated only by message text.
+  
+  That was load-bearing one layer out. `RestServer.computeExecCtx`'s kernel branch absorbs a
+  failed `getServiceAsync('objectql')` and degrades to "no engine is wired", and it must keep
+  doing so — a kernel with no data plane is a supported configuration, declared by
+  `rest-api-plugin.ts` as `optionalDependencies: ['com.objectstack.engine.objectql']`. So a
+  multi-tenant host whose engine *failed to construct* reached the same resolver as "no
+  engine is wired", degrading silently where it should have refused loudly. The branch could
+  not be repaired from outside, because the fact it needed had been collapsed before it
+  arrived.
+  
+  The asynchronous path now carries the distinction the **synchronous** context accessor in
+  `kernel.ts` has always drawn from the registry. `@objectstack/core` publishes exactly two
+  new symbols for it:
+  
+  - `isServiceNotRegisteredError(err)` — true only when nothing was ever registered under
+    that name;
+  - `SERVICE_NOT_REGISTERED_CODE` — the code the rejection carries.
+  
+  The test is closed and its default is loud: exactly one rejection in `getService` means
+  "never registered" and only that one is branded, so every other way it can fail — a factory
+  that threw, a missing scope id, an unset loader context, a circular service dependency —
+  stays unbranded, and a consumer that absorbs only the branded rejection is loud about
+  everything else, including rejections added later.
+  
+  ⛔ Not message matching. Adding a second text classifier on a resolution path is the failure
+  mode this change removes: reading "not found" off the async path once reported every
+  missing service as `is async - use await` — the wrong fix, pointing at the wrong layer.
+  
+  Nothing existing moves. The rejection keeps a byte-identical message and `name: 'Error'`;
+  the only observable change is the two added own-properties.
+
+### Patch Changes
+
+- efb3513: fix(platform-objects,core): `sys_metadata_activation` ships tenant-less — drop the reserved organization column (#15024)
+  
+  The ADR-0126 activation ledger records that **this environment** switched a
+  packaged artifact off. That is deployment-level state, owned by no
+  organization — so the table ships with no tenant column at all.
+  
+  It briefly declared one: an `organization_id` marked "RESERVED", nullable, and
+  written by nobody, held for a per-organization dimension ADR-0126 §5
+  pre-charted. A reserved nullable tenant column is exactly the shape the
+  total-organization-ownership record proposed in PR #14976 rules out, and this
+  one had no reader either. **This is a plain removal, not a migration:** the
+  table landed after the 17.2.0 tag, so no released version ever carried the
+  column and no deployment has data in it. Should a per-organization dimension
+  ever be wanted, it returns as a separate org-owned object — never as a column
+  on this ledger.
+  
+  What changed:
+  
+  - **`sys_metadata_activation` declares `systemFields: { tenant: false }`** and
+    no longer declares the column. Both halves are needed: the tenant anchor is
+    INJECTED at registration, so deleting the field alone would have left the
+    column exactly where it was. ⚠️ Deliberately NOT `tenancy: { enabled: false }`
+    — that key is the ADR-0066 D2 platform-global *posture*, which the sibling
+    `sys_sso_provider` uses for the opposite shape (a table that KEEPS its tenant
+    column and needs the wall over it stood down). Here there is no column to
+    wall. Both spellings reach `plugin-security`'s `tenancyDisabled`, which is
+    required rather than incidental: a Layer 0 wall composing an equality on a
+    column the table does not have denies every row.
+  - **The declared unique index states `unique: 'global'`** over
+    `(metadata_type, name)` instead of `'organization'`. ⚠️ The materialized DDL
+    is unchanged: `normalizeDeclaredIndex` prepends the NULL-safe tenant key part
+    only when the table HAS a tenant column, so `'organization'` already degraded
+    to exactly these two columns. What changes is that the declaration now states
+    the boundary it actually gets, rather than claiming a per-organization one
+    that does not exist. Still explicit rather than bare `unique: true`, which
+    lint `unique/unscoped-declared-index` warns on and protocol 18 rejects.
+  - **`ObjectStoreMetadataActivationStore` drops its NULL filter and its
+    org-row skip.** `list()` is now every activation row of its type, scoped by
+    the `metadata_type` discriminator alone, and `setActive` takes the single row
+    its keyed read returns instead of picking the NULL-organization one out of
+    the result. Both guarded a column that no longer exists; the declared unique
+    index over the two columns the lookup keys on is what makes that read
+    single-valued. `ObjectStoreFlowActivationStore` and
+    `ObjectStoreActionActivationStore` inherit the change.
+  
+  Unchanged, and pinned: the operator gate on activation writes under walled
+  postures (ADR-0126 D3), the `execute()`-time flow consult and the dispatch-time
+  action consult, "absence of a row means ACTIVE", re-enabling UPDATES the row
+  rather than deleting it, and a driver `0` reading as false. The pins that
+  asserted the reserved column and the org-row skip are rewritten to pin the
+  column's ABSENCE rather than deleted — including at the injection authority
+  (`resolveInjectedSystemColumns`, which decides whether the column exists) and
+  in a real booted stack, where the row's key set is a reading of the physical
+  table.
+- e27583e: docs(core): the `AuthzStoreUnavailableError` brand doc states the measured `structuredClone` behaviour instead of claiming survival (#14006)
+  
+  Documentation only — no runtime change, no type change, no accept/reject
+  behaviour moves. It ships as a patch because the docblock is a **published
+  byte**: `tsup`'s declaration rollup carries it into `dist/index.d.ts` and
+  `dist/index.d.cts`, so it is what a consumer reads on hover.
+  
+  The brand's docblock justified the string-keyed own property with two reasons
+  joined by an `and`, of which only the second was true:
+  
+  > A string-keyed own property (not a `Symbol.for` registry key) so it survives
+  > `structuredClone`, and so a duplicated copy of this module still brands
+  > identically.
+  
+  Measured on Node 22.22.2: the structured-clone algorithm gives `Error` a
+  dedicated serialization carrying `message`, `stack` and `cause` only, and drops
+  every other own property — the brand, the ADR-0112 `code`, `status` and
+  `object` alike (a subclass's own `name` returns as `'Error'`). The
+  plain-object control is the half that proves it: `{ __brand: true, code: 'C' }`
+  keeps **both** keys through the same call, so the loss is specific to `Error`,
+  not general to `structuredClone`.
+  
+  The property and the reason that actually earns it are kept — a duplicated copy
+  of the module still brands identically, which is exactly what `instanceof`
+  cannot do across two installed copies of `@objectstack/core`. The false half is
+  replaced by the measured behaviour, carrying the reproducible script and the
+  Node version rather than a second unsourced assertion, and phrased to match
+  what `service-not-registered.ts` already records for its own brand (one
+  phrasing across the two modules, not two).
+  
+  ⛔ The clone gap is deliberately NOT "fixed" with a `toJSON` or a custom
+  serialization: no call site crosses a clone boundary today
+  (`rethrowAuthzStoreUnavailable` on the rest rethrow paths,
+  `isAuthzStoreUnavailableError` inside service `catch` blocks — all in-process),
+  and adding one would widen the module's surface with nothing pulling on it. The
+  docblock instead names the trap the false claim invited: branching on the brand
+  across a worker or `postMessage` boundary would answer `false` and fail OPEN on
+  a security path.
+- 983edf1: fix(core): `autoRestart` now fires for a health check that throws or times out, not only for one that returns a failure (#11852)
+  
+  `PluginHealthMonitor.performHealthCheck` reaches its failure handling by two
+  disjoint routes, and only one of them could ever restart the plugin.
+  
+  A check that **returned** a failure (`false` or `{ status: 'unhealthy' }`)
+  incremented `failureCounters`, cleared `successCounters`, and — once
+  `failureThreshold` consecutive failures accumulated — consulted `autoRestart`
+  and restarted the plugin. A check that **threw** took a separate `catch` block
+  that incremented `failureCounters` and stopped there: it never cleared
+  `successCounters` and never read `autoRestart`. Because `raceCheckTimeout`
+  rejects rather than resolving, every `timeout` overrun lands in that `catch`,
+  so a plugin that hung was marked `failed` and never restarted no matter how
+  many rounds passed or what `autoRestart` said. The severer of the two failure
+  modes was the one that could not trigger recovery.
+  
+  Both routes now funnel into one `recordFailedRound` step that owns the
+  counters, the `failureThreshold` comparison and the `autoRestart` decision, so
+  a thrown or timed-out check is restart-eligible on exactly the same terms as a
+  returned failure.
+  
+  The per-route *status* label is deliberately unchanged: a throw is still the
+  separate `failed` status applied immediately with no threshold, as
+  `content/docs/protocol/kernel/lifecycle.mdx` documents. Only the counters and
+  the restart decision are shared — those are what `failureThreshold` and
+  `autoRestart` declare, and neither names a route.
+- 8120808: feat(tooling): `@objectstack/core` declares a `typecheck` script, and its test and examples layers enter the ratchet (#14613)
+  
+  `packages/core/package.json` declared exactly `build`, `test` and `test:watch`.
+  Around twenty sibling packages declare `typecheck`, and `turbo run typecheck`
+  selects only packages that declare the task — so the lint workflow's typecheck
+  job had no way to reach this package, and `pnpm --filter @objectstack/core
+  typecheck` failed with `ERR_PNPM_RECURSIVE_RUN_NO_SCRIPT` for anyone who tried
+  it. The package's types ship anyway: `build` emits a 233 KB `dist/index.d.ts`,
+  and rest, runtime, mcp, services and plugins all import it.
+  
+  The state was tracked but not runnable. `check:type-check-coverage` carried
+  `@objectstack/core` as a DEBT entry of 98 and had already re-measured it once
+  (91 to 98), so nothing was invisible — but a ledger only the gate can read is
+  not something a contributor working in the package can run, which is how a
+  dispatched task came to assume the script existed.
+  
+  **Measured at `84b8190ae`, dependency closure built first.** The undivided
+  program (`tsc --noEmit -p tsconfig.json`, exactly as the DEBT entry measured it)
+  reports 98 errors across 12 files, and every one of the 12 is a `.test.ts`. The
+  same program restricted to the 63 non-test source files reports **zero**. So the
+  build layer graduated as it stood, and the 98 did not have to be repaired before
+  the script could exist.
+  
+  **94 of the 98 were the check, not the code.** The repair is the split this
+  repo already runs for `spec`, `rest`, `objectql` and `client`: `tsconfig.json`
+  stays the build config and excludes the test layer; a new `tsconfig.test.json`
+  compiles that layer under the module semantics vitest actually executes it with
+  (`module: esnext`, `moduleResolution: bundler`), which retires 22 x TS2835, the
+  TS2347 beside them and the share of 71 x TS7006 they cascade into — an import
+  that does not resolve makes every symbol it names `any`. **No test file was
+  edited.** Strictness is inherited and untouched. The residue is 4 errors over 4
+  files, held per file and per signature in `test-typecheck-debt.json`, EXACT and
+  shrink-only.
+  
+  **The `examples/` half was found by the new script, not by the card.** Declaring
+  `typecheck` flips the package from COVERED-BY-LEDGER to COVERED-BY-SCRIPT, and
+  `check:type-check-coverage`'s SOURCES_COVERED invariant immediately reported
+  `packages/core/examples` — 2 non-test source files in no tsc program at all.
+  Neither had ever compiled: `kernel-features-example.ts` imported `../index.js`
+  (above the package root, never existed) and `phase2-integration.ts` imported
+  `@objectstack/core`, i.e. this package self-referencing by a name it declares in
+  no dependency block. Collapsing that cascade exposed rather than removed errors,
+  12 to 29, all of them real and none of them new: 20 reads of `ObjectKernel`'s
+  **private** `logger`; four members of the security scan result that do not exist
+  (`passed`, `score`, `summary.critical`, `summary.high`, where the type carries
+  `status` and per-severity counts); and two config literals passing the unparsed
+  shapes where `PluginHealthMonitor.registerPlugin` and
+  `HotReloadManager.registerPlugin` are declared over the `Parsed` ones. That last
+  pair is retirement drift — this file was edited by two retirements (restart keys,
+  `watchPatterns`) while no tsc program could check the result. Every correction is
+  pinned to this package's own signatures; `packages/spec` was not touched.
+  
+  `packages/core` therefore leaves the DEBT ledger: the coverage gate now reads
+  70/79 packages type-checked with 9 ledgered, where it read 68/78 with 10.
+- f658793: Restore the #10096 standing invariant (「浏览器可达的 spec 导出面必须
+  schema-free」) for `@objectstack/core`'s plural→singular store-key fold.
+  
+  `@objectstack/spec`: the `defineStack()` manifest-collection vocabulary
+  (`PLURAL_TO_SINGULAR`, `SINGULAR_TO_PLURAL`, `pluralToSingular`,
+  `singularToPlural`) moved to a schema-free module and is now ALSO exported
+  from the sanctioned schema-free entry `@objectstack/spec/meta-spelling`
+  (widened per the #10096 ruling's reference pattern). `@objectstack/spec/shared`
+  keeps the same four symbols as re-exports — no consumer-visible removal. The
+  manifest map and `META_URL_TO_SINGULAR` remain deliberately distinct contracts
+  (#8424).
+  
+  `@objectstack/core`: `canonicalMetadataServiceType`'s one value import moves
+  from `@objectstack/spec/shared` to `@objectstack/spec/meta-spelling`, so
+  browser consumers of `@objectstack/core` (every `@objectstack/client` bundle)
+  no longer link the zod schema closure through the store-key fold.
+- 0a8ebf3: Scope the legacy platform-admin deprecation pointer to walled tenancy postures
+  
+  The request-side notice that tells an operator their unscoped `admin_full_access`
+  grant row is the OLD anchor — "it is removed in a later release", "re-anchor this
+  deployment by declaring its administrators in configuration" — was emitted without
+  regard to the deployment's tenancy posture, so it fired on `single` rigs too.
+  
+  `single` is the DEFAULT posture, and on a `single` rig that row is not legacy at
+  all: the boot-time `bootstrapPlatformAdmin` mints it to promote the first human
+  user, and that promotion is ruled correct and unchanged. Such a deployment was
+  therefore being told, once per process, to migrate off an anchor that is not
+  scheduled to go away, toward a variable its own promotion is pinned never to read.
+  
+  The pointer is now gated on `postureEnforcesWall(resolveTenancyPosture())`, the
+  same predicate and the same source the boot-side detector already reads, so the
+  migration window's loudness is scoped to the walled postures actually in it.
+  Walled rigs are unaffected and still receive the notice.
+  
+  ⛔ Standing is not touched: this is a log-line trigger, not access control. Every
+  deployment resolves exactly the `PLATFORM_ADMIN` it resolved before.
+- fd289be: `HotReloadManager`'s refusal messages — the plugin-registration doors for retired `stateStrategy` values and removed config keys, and the `startWatching()` removal notice — no longer cite internal tracker ids. The prescriptions keep their customer-resolvable anchors (ADR-0049 enforce-or-remove, the `@objectstack/spec` / `@objectstack/core` versions, and the `scheduleReload` migration call); the `#NNNN` tokens, which resolve to nothing for the host author reading the refusal, are gone.
+- 2d5cee3: docs(core,service-cluster): retire the two docblocks left stale by `IPubSub`'s corrected delivery guarantee (#12836)
+  
+  #12651 corrected `IPubSub`'s contract docblock: delivery is whatever the
+  configured driver declares, no shipped driver exceeds at-most-once, a missed
+  message is EXPECTED, and handlers must be idempotent **and** tolerate loss.
+  Two docblocks elsewhere still described the world before that correction.
+  
+  **`@objectstack/core` — `security/authz-invalidation-channel.ts`.** It carried a
+  paragraph asserting, in the present tense, that the interface docblock "still
+  says" *At-least-once delivery*, and that repairing it was a `packages/spec`
+  change filed separately. That filing was #12651 and it has landed, so the
+  paragraph is now false rather than merely stale — it sends the next reader
+  looking for a live disagreement between the interface and the drivers that no
+  longer exists. Replaced with a plain pointer to the interface docblock.
+  Everything else in that docblock is unchanged: the at-most-once reasoning, the
+  TTL-is-the-bound rule, and the best-effort-at-the-publish-site note all still
+  hold.
+  
+  **`@objectstack/service-cluster` — `memory/pubsub.ts`.** The line "At-least-once
+  semantics held vacuously (a single in-process delivery)" was wrong on its own
+  terms even before #12651: the same docblock states that handler errors are
+  swallowed and logged via `onError`, so a handler that throws loses the message
+  with no retry and no persistence. That is not at-least-once in any sense, and
+  "vacuously" does not save it. Replaced with the honest statement — one
+  synchronous in-process delivery attempt per subscriber, no persistence, no
+  retry, no replay.
+  
+  Prose only. No behaviour change, and no test changed.
+- a17da05: fix(core): only a backend fault populates `resolveLocalizationContext`'s failure memo (#11877)
+  
+  `resolveLocalizationContext` memoizes an outcome for 30s whenever the read
+  "failed" (#10221 — so a repeatedly-failing `sys_setting` query does not re-run,
+  and the driver does not re-log it, on every request). The write condition was
+  wider than the cache's own docblock: six legs set the flag and only **one** of
+  them is the backend fault the docblock describes (the direct `ql.find` throw).
+  The other five are the **settings service refusing** — a thrown `getMany`, each
+  of the three older per-key `get`s, and the whole-block "service unavailable"
+  handler.
+  
+  Those five legs are reachable inside the settings engine's **bind window**
+  (`SettingsService.getMany` refuses all-or-nothing for a `localization`
+  namespace whose manifest is not yet registered), so:
+  
+  - A caller that deliberately re-reads **after** the bind — the #11580 stdio
+    repair re-resolves at `kernel:bootstrapped` for exactly this reason — was
+    answered from the memo taken **inside** the window for up to 30s. The
+    correction silently did not happen, with nothing in the output saying so.
+  - A settings refusal standing alongside a perfectly **successful** direct read
+    memoized that successful value — the staleness the docblock forbids outright
+    and that `analytics-timezone.dogfood.test.ts` (#1982/#2018) exists to catch.
+  
+  The memo is now written only for the direct-read fault. **#10221's protection
+  is unchanged for the legs it was built for**: its environment (table not
+  migrated yet) still memoizes, because the direct read throws there whether or
+  not a settings refusal stands in front of it — pinned in both directions. And
+  nothing is lost on the narrowed legs: those refusals throw out of an in-memory
+  registry check *before* any query and *before* any log line, so memoizing them
+  suppressed neither.
+  
+  No signature, export or accepted-input change — the flag is internal to the
+  module.
+- 7c41693: fix(core,plugin-auth,plugin-security): every `OS_PLATFORM_OWNER_EMAIL` reader asks the ONE list-aware parser (#13147)
+  
+  `OS_PLATFORM_OWNER_EMAIL` accepts one address **or a comma-separated list** of
+  them (#11663 Choice 2B). The list parse landed in a single home
+  (`@objectstack/core`'s `platform-admin.ts`) and the authorization derivation
+  consumed it — but every other reader kept calling `resolvePlatformOwnerEmail()`,
+  which returns the operator's value trimmed and otherwise verbatim, and kept
+  treating that whole string as ONE address.
+  
+  An operator who configured a list therefore entered a self-contradictory state:
+  authorization recognised them as a platform administrator, while four separate
+  capabilities silently did nothing. Every direction failed **closed** — no
+  privilege escalation existed at any point — but a declared capability vanished
+  with no error anywhere:
+  
+  - `bootstrap-platform-admin` promoted **nobody**, logging "will be promoted when
+    that account registers" on every boot forever;
+  - the walled operator stamp (`plugin-auth`) stamped **no** list member verified,
+    so the account it should have provisioned was then refused elevation as
+    `walled_owner_not_verified`;
+  - `isVerifiedPlatformOwnerSession` / `platform-owner-wall-bypass` let **nobody**
+    across the Layer 0 organization wall — the largest of the affected surfaces;
+  - the walled boot diagnostic printed the raw list in the slot where an operator
+    reads one address, and its dev-seed silence clause never matched.
+  
+  All six readers now ask the same parser. `@objectstack/core` gains
+  `isConfiguredPlatformAdminEmail(email, config)` — the membership half of
+  `matchesConfiguredPlatformAdmin`, spelled once and shared, for the readers that
+  hold a bare address rather than a `sys_user` row (the elevation gate keeps its
+  two halves apart so `walled_owner_not_registered` and `walled_owner_not_verified`
+  stay distinct answers; the stamp is handed an email before any row exists; the
+  wall takes a fast negative before spending a row read). `PlatformAdminEmailConfig`
+  gains `declaredSpellings`, the entries as the operator typed them, so the by-email
+  `sys_user` lookup and the boot diagnostic get the as-typed form **from the one
+  parse** instead of splitting the raw value a second time.
+  
+  Behaviour for a single declared address is unchanged, including the
+  case-insensitive match and the verbatim-spelling store lookup. A **refused**
+  list (Choice 2B fails the whole variable closed on one unparseable entry) now
+  reaches these readers as "zero administrators", which is the same answer they
+  already gave for an unset variable — never a silently narrower set.
+  
+  Two readers deliberately keep reading the raw value: the walled-boot refusal and
+  the verification-path probe guard in `auth-plugin.ts` both use it as a pure
+  truthiness test ("did the operator declare anything at all?"), which is
+  grammar-independent. A census pin now enumerates the raw readers across both
+  plugin packages and fails on a seventh.
+- 9688f58: `os plugin publish` now verifies the artifact's own declared `manifest.integrity` digests before uploading, and refuses the publish on a digest mismatch, a declared entry with no file, or a packaged file the map does not declare (an absent map still publishes — the field is optional). The pure checker, `verifyIntegrity`, lives in `@objectstack/core` beside the artifact-signature contract. Unpack-time re-verification remains the cloud control plane's obligation (#11331) and is not changed by this release.
+- 556ebc1: docs(core): correct `Plugin.type`'s TSDoc enumeration — it omitted `objectql` (#13762)
+  
+  `Plugin.type` is typed `string` in `@objectstack/core`, so its TSDoc is the only
+  enumeration a plugin author reading the interface ever sees; nothing type-checks
+  them against it. That comment listed seven values while the declared set is
+  eight: `PluginSchema.type` in `@objectstack/spec` is
+  `z.enum(['standard', ...CORE_PLUGIN_TYPES])`, and `CORE_PLUGIN_TYPES` carries
+  `objectql` — the type `packages/objectql/src/plugin.ts` declares on the engine
+  plugin essentially every runtime loads first.
+  
+  The comment now lists all eight and names `CORE_PLUGIN_TYPES` as the
+  authoritative set. The same omission in the hand-written
+  `content/docs/plugins/anatomy.mdx` transcription of this interface is corrected
+  in the same change.
+- f7b25c5: fix(core): `successThreshold` now binds from every status that records a failure, so a declared count above 2 stops being unreachable (#11955)
+  
+  `PluginHealthMonitor` consulted `successThreshold` only while a plugin's status
+  was `unhealthy` or `degraded`. The first success in a recovery wrote
+  `recovering` — a status that gate did not name — so the **second** success took
+  the outer `else` and went straight to `healthy` without the counter being read
+  at all. `failed` was in neither set either, so a plugin whose check threw
+  recovered on its **first** success.
+  
+  The declared value was therefore capped in practice:
+  
+  | Status when the successes start | Consecutive successes actually required |
+  | :--- | :--- |
+  | `unhealthy` / `degraded` | 2, whatever `successThreshold` said |
+  | `failed` / `recovering` | 1, whatever `successThreshold` said |
+  
+  A declared `successThreshold: 5` was indistinguishable from `2`. The default is
+  `1`, which is exactly the value at which the defect is invisible — every
+  declared value above it was the one that misbehaved.
+  
+  The counter is now consulted on the way out of every status that records an
+  observed failure — `degraded`, `unhealthy`, `failed` and `recovering` — so
+  `successThreshold: N` requires N consecutive successes from each of them, as
+  its declaration says ("Consecutive successes needed to mark healthy"). The gate
+  is a map that is exhaustive over `PluginHealthStatus`, so a status added to the
+  spec fails to compile until it is placed on one side or the other; that is what
+  `recovering` slipped through before.
+  
+  `healthy` and `unknown` still promote on the first success, deliberately: the
+  count is declared as a **recovery** criterion ("Number of consecutive successes
+  to recover from unhealthy state") and neither of those records a failure to
+  recover from — `unknown` is the status `registerPlugin` writes before any check
+  has run.
+  
+  **Behaviour change, only for configs that declare `successThreshold` above 1.**
+  At the default `1` every route is byte-for-byte what it was: one success has
+  always been enough and still is. A plugin declaring a higher count now takes
+  the number of consecutive successes it asked for before it is reported
+  `healthy`, including after a `failed` round and after an `autoRestart`.
+  
+  This also makes #11852's `successCounters` reset load-bearing. That fix cleared
+  the counter on the thrown failure route, and could not be pinned: the counter's
+  only read site was unreachable with a stale non-zero value, so any test would
+  have passed for the wrong reason. With `failed` gated on the counter, a throw
+  that interrupts a recovery now demonstrably starts the count over.
+- Updated dependencies [809d417]
+- Updated dependencies [387e231]
+- Updated dependencies [f794e4e]
+- Updated dependencies [cae2169]
+- Updated dependencies [b812a54]
+- Updated dependencies [2d4fa75]
+- Updated dependencies [0e4e51b]
+- Updated dependencies [e84bbf6]
+- Updated dependencies [effae80]
+- Updated dependencies [d62f990]
+- Updated dependencies [c45d8e6]
+- Updated dependencies [2e3e8c7]
+- Updated dependencies [e621291]
+- Updated dependencies [40a93b5]
+- Updated dependencies [101ad2c]
+- Updated dependencies [d5b330d]
+- Updated dependencies [dda969c]
+- Updated dependencies [1f45690]
+- Updated dependencies [277948f]
+- Updated dependencies [8bdd955]
+- Updated dependencies [f3bbbef]
+- Updated dependencies [4f24e9d]
+- Updated dependencies [6a180e4]
+- Updated dependencies [474242f]
+- Updated dependencies [63cd487]
+- Updated dependencies [bd4aa4e]
+- Updated dependencies [803eaab]
+- Updated dependencies [f8e8f03]
+- Updated dependencies [eae824e]
+- Updated dependencies [f6fa22c]
+- Updated dependencies [8a483b3]
+- Updated dependencies [97bcd99]
+- Updated dependencies [df59de0]
+- Updated dependencies [96e25a8]
+- Updated dependencies [f75a38a]
+- Updated dependencies [7a25e7d]
+- Updated dependencies [1fa05a6]
+- Updated dependencies [c85a265]
+- Updated dependencies [dcb10a5]
+- Updated dependencies [773a999]
+- Updated dependencies [35dffea]
+- Updated dependencies [776a098]
+- Updated dependencies [5060877]
+- Updated dependencies [4f6325d]
+- Updated dependencies [52954c0]
+- Updated dependencies [2aa8456]
+- Updated dependencies [93809a3]
+- Updated dependencies [7c0d0c3]
+- Updated dependencies [daae7aa]
+- Updated dependencies [8dc22d6]
+- Updated dependencies [279431e]
+- Updated dependencies [948dd6b]
+- Updated dependencies [3b4c56c]
+- Updated dependencies [ae8edd2]
+- Updated dependencies [e25403c]
+- Updated dependencies [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 [7345308]
+- Updated dependencies [79b6a22]
+- Updated dependencies [30d96ab]
+- Updated dependencies [f658793]
+- Updated dependencies [c95ad19]
+- Updated dependencies [e58ea8b]
+- Updated dependencies [4a17645]
+- Updated dependencies [3795c5f]
+- Updated dependencies [8ab926b]
+- Updated dependencies [7317cf2]
+- Updated dependencies [e25e839]
+- Updated dependencies [5997207]
+- Updated dependencies [8b13cc8]
+- Updated dependencies [4a4a35d]
+- Updated dependencies [86e765a]
+- Updated dependencies [1d7e76a]
+- Updated dependencies [53dc739]
+- Updated dependencies [fd289be]
+- Updated dependencies [03bf7b1]
+- Updated dependencies [f90e820]
+- Updated dependencies [18d816a]
+- Updated dependencies [e8bd715]
+- Updated dependencies [b91c351]
+- Updated dependencies [a28a3c0]
+- Updated dependencies [daeaaf9]
+- Updated dependencies [c459da6]
+- Updated dependencies [e914733]
+- Updated dependencies [f887e52]
+- Updated dependencies [881f8d8]
+- Updated dependencies [3bfa1e6]
+- Updated dependencies [901355c]
+- Updated dependencies [34ce8e7]
+- Updated dependencies [33681ea]
+- Updated dependencies [bfe13c8]
+- Updated dependencies [0fb3044]
+- Updated dependencies [4635f3e]
+- Updated dependencies [ee3595c]
+- Updated dependencies [b2eab95]
+- Updated dependencies [93940d4]
+- Updated dependencies [3a04b01]
+- Updated dependencies [45b9051]
+- Updated dependencies [b9e9227]
+- Updated dependencies [d395692]
+- Updated dependencies [5894d30]
+- Updated dependencies [a3765f6]
+- Updated dependencies [e22158f]
+- Updated dependencies [7404925]
+- Updated dependencies [0c2334f]
+- Updated dependencies [778c59f]
+- Updated dependencies [d2619fd]
+- Updated dependencies [6acb11a]
+- Updated dependencies [33c5fd3]
+- Updated dependencies [20b0fdb]
+- Updated dependencies [905019b]
+- Updated dependencies [a286411]
+- Updated dependencies [98c0d33]
+- Updated dependencies [368a82e]
+- Updated dependencies [a3d5724]
+- Updated dependencies [93ea19b]
+- Updated dependencies [9ee2dcf]
+- Updated dependencies [8cb96ec]
+- Updated dependencies [8f10a79]
+- Updated dependencies [6269a55]
+- Updated dependencies [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 [9e0ba21]
+- Updated dependencies [311433f]
+- Updated dependencies [3e5ad08]
+- Updated dependencies [9abe4e4]
+- Updated dependencies [b7131f3]
+- Updated dependencies [e5812fa]
+- Updated dependencies [7085f90]
+- Updated dependencies [dee4dd4]
+- Updated dependencies [ce7e497]
+- Updated dependencies [51ecb2f]
+- Updated dependencies [9086761]
+- Updated dependencies [42a117b]
+- Updated dependencies [1401ae7]
+- Updated dependencies [4297fe7]
+- Updated dependencies [e398863]
+- Updated dependencies [d16df74]
+- Updated dependencies [f11fc61]
+- Updated dependencies [e808890]
+- Updated dependencies [8f79379]
+- Updated dependencies [e6ca40e]
+- Updated dependencies [0c77ea4]
+- Updated dependencies [52954c0]
+- Updated dependencies [89eb997]
+- Updated dependencies [aa5994e]
+- Updated dependencies [be93457]
+- Updated dependencies [a65db76]
+- Updated dependencies [2cf5a96]
+- Updated dependencies [15eb2c9]
+- Updated dependencies [5691b07]
+- Updated dependencies [2a6122b]
+- Updated dependencies [225e769]
+- Updated dependencies [8af88dd]
+- Updated dependencies [fb5fbb8]
+- Updated dependencies [d7b3963]
+- Updated dependencies [b72db01]
+- Updated dependencies [dce5cd4]
+- Updated dependencies [177ebdc]
+- Updated dependencies [8d237b4]
+- Updated dependencies [2d2e6f0]
+- Updated dependencies [2d8dd8d]
+- Updated dependencies [22d573e]
+- Updated dependencies [b5a2398]
+- Updated dependencies [348860c]
+- Updated dependencies [5383fa6]
+- Updated dependencies [5b3ff63]
+- Updated dependencies [1a6a19c]
+- Updated dependencies [527e050]
+- Updated dependencies [dd33bf9]
+- Updated dependencies [4cb2a90]
+- Updated dependencies [74a7804]
+- Updated dependencies [53d3689]
+- Updated dependencies [b3a63d3]
+- Updated dependencies [033a34c]
+- Updated dependencies [4d25d22]
+- Updated dependencies [1ffee51]
+- Updated dependencies [5ae4303]
+- Updated dependencies [ece4dad]
+- Updated dependencies [e9b377e]
+- Updated dependencies [146f448]
+- Updated dependencies [735f5c7]
+- Updated dependencies [a7e18de]
+- Updated dependencies [366f895]
+- Updated dependencies [dc75ba8]
+- Updated dependencies [cce0aa9]
+- Updated dependencies [e764507]
+- Updated dependencies [cff17af]
+- Updated dependencies [39404f3]
+- Updated dependencies [ca1965f]
+- Updated dependencies [8619f95]
+- Updated dependencies [b706af9]
+- Updated dependencies [db8c288]
+- Updated dependencies [0e5fe7f]
+- Updated dependencies [fc9ba76]
+- Updated dependencies [0f94cc7]
+- Updated dependencies [a11c1a5]
+- Updated dependencies [71f9cd1]
+- Updated dependencies [ee17d86]
+- Updated dependencies [cdbd920]
+- Updated dependencies [18c432e]
+- Updated dependencies [3c418c4]
+- Updated dependencies [fa8715a]
+- Updated dependencies [a933ed7]
+- Updated dependencies [b3ca463]
+- Updated dependencies [a933ed7]
+- Updated dependencies [0d4a6a8]
+- Updated dependencies [518d5e5]
+- Updated dependencies [6643ba1]
+- Updated dependencies [eeba2ef]
+- Updated dependencies [ec4c4d2]
+- Updated dependencies [424f73c]
+- Updated dependencies [cccbe51]
+- Updated dependencies [a8d6b1d]
+- Updated dependencies [e4a7695]
+- Updated dependencies [87075b1]
+- Updated dependencies [fc58a99]
+- Updated dependencies [14cfc00]
+- Updated dependencies [1c6f7b4]
+- Updated dependencies [e854a53]
+- Updated dependencies [dfebfc8]
+- Updated dependencies [d028b37]
+- Updated dependencies [122ef38]
+- Updated dependencies [4a37870]
+- Updated dependencies [428f9b2]
+- Updated dependencies [aa7ff56]
+- Updated dependencies [c41b42e]
+- Updated dependencies [c4db311]
+- Updated dependencies [750fff5]
+- Updated dependencies [c19035e]
+- Updated dependencies [ececf7a]
+- Updated dependencies [d173125]
+- Updated dependencies [8eeca27]
+- Updated dependencies [8425c17]
+- Updated dependencies [a5ef1d8]
+- Updated dependencies [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 [0da7cd2]
+- Updated dependencies [28a5c3e]
+- Updated dependencies [4bc18e5]
+  - @objectstack/spec@17.3.0
+  - @objectstack/types@17.3.0
+
 ## 17.2.0
 
 ### Minor Changes