@@ -0,0 +1,59 @@
+---
+"@objectstack/metadata-core": minor
+"@objectstack/objectql": patch
+"@objectstack/service-automation": patch
+"@objectstack/service-datasource": patch
+---
+
+feat(devx,datasource,automation): published `src/**` may only import workspace packages it declares (#10062)
+
+A package's non-test `src/**` was free to import any workspace package,
+declared or not, and nothing checked it. The class was filed with one member
+and a mitigation — the import was type-only, so nothing reached the emitted
+JavaScript and rollup-plugin-dts inlined the declaration rather than naming an
+unresolvable module. It grew to four members with no signal, and one of them
+killed the mitigation: `service-automation/src/flow-precedence.ts` **value**
+imports from `@objectstack/objectql`, which it does not declare, and because
+the shared tsup config externalises only `dependencies`/`peerDependencies`, the
+bundler answered by inlining objectql's implementation into
+`service-automation/dist/index.js` — a second copy of another package's code,
+kept correct by build configuration alone.
+
+`pnpm check:undeclared-dep-imports` is the gate, and the per-member fixes here
+are decided one at a time rather than by a uniform policy — declaring makes a
+coupling real and installable, routing it away removes it, and the two are not
+interchangeable:
+
+* **`@objectstack/service-datasource`** now declares `@objectstack/driver-sql`
+  and `@objectstack/driver-memory` as **dependencies**. Both are loaded through
+  an *unguarded* `await import(...)` on the postgres, mysql, sqlite and memory
+  arms, so a consumer reaching one of those paths needed a package it was never
+  told to install, and would have met `ERR_MODULE_NOT_FOUND` rather than a
+  diagnosis. The three *guarded* driver arms — `@objectstack/driver-sqlite-wasm`,
+  `@objectstack/driver-mongodb`, `@objectstack/driver-turso` — are deliberately
+  left undeclared: each load sits in a `try`/`catch` that answers an absent
+  package with the fault, the consequence and the install command, and each
+  rides as an optional install. Declaring them would install them (turso drags
+  `@libsql/client`'s native bindings) and, measured on this branch, takes a live
+  assertion out of the tree: `default-datasource-driver-factory.test.ts` reaches
+  the missing-package arm with no stub precisely because the package does not
+  resolve from here.
+* **`@objectstack/metadata-core`** now owns the ADR-0029 D9.6 provenance pair,
+  `isCodeArtifactBody` and `isTenantAuthored`, sunk out of
+  `@objectstack/objectql`'s registry by the same criterion as the write-verb
+  dispatch predicates and the audit governance table beside them: a second layer
+  needs the answer and the reverse import would either close a cycle or make the
+  consumer depend on the whole data engine for one predicate. `objectql`
+  re-exports `isCodeArtifactBody` from its original path, so its public API is
+  unchanged; `service-automation` imports it from `metadata-core`, which it
+  already declared, and its bundle no longer carries a copy of objectql's code.
+
+Two members stay recorded rather than remediated, because the tree already
+carries the decision not to declare them together with its reason
+(`@objectstack/runtime` → `@objectstack/driver-turso`, whose bare `import()` is
+a host-replaceable default thunk under #6268; `@objectstack/rest` →
+`@objectstack/objectql`, whose absence must degrade to `501 NOT_IMPLEMENTED`
+rather than fail module load). Their ledger rows carry mechanical evidence and
+go red the moment that evidence stops holding — in particular, a `type-only`
+row reds on the day its import becomes a value import, which is exactly the
+transition nothing caught the first time.
@@ -0,0 +1,33 @@
+---
+"@objectstack/core": patch
+"@objectstack/service-cluster": patch
+---
+
+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.
@@ -0,0 +1,67 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): retire preview mode — the `'preview'` RuntimeMode value and the whole `KernelContext.previewMode` / `PreviewModeConfig` block (#11846, ADR-0049)
+
+<!-- adr-0087: registered kernel-context-preview-mode-retired -->
+
+**BREAKING** accept-set narrowing and 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_KEYS_BY_MAJOR[18]` for both walked-shape keys,
+`RETIRED_DEFS_BY_MAJOR[18]` for the def, plus the D3 semantic entry
+`kernel-context-preview-mode-retired` — where `os migrate meta` users will
+look).
+
+The declaration was the sharpest declared-≠-enforced shape on a SECURITY
+surface: the schema promised "bypass auth, simulate admin identity" and named
+a production guard "the runtime must enforce", and NO code path implemented
+either half. Measured zero consumers in objectstack, objectui and cloud
+(cloud#1651, closed 2026-08-26 with positive controls: `RuntimeMode` has zero
+hits repo-wide there, and `ArtifactKernelFactory` — where preview auto-login
+would live if anywhere — has 20+ hits and never touches `previewMode`;
+re-verified in objectstack at dispatch, 2026-08-27). An author — very often
+an AI — could write the six-key block per the reference docs, parse cleanly,
+and get no behaviour and no diagnostic.
+
+FROM → TO:
+
+- `mode: 'preview'` → *(removed value)* — `mode` defaults to `'production'`;
+  use `'development'` for local demo work. The rejection carries the
+  prescription via the enum's own error map (the `HookBodyCapability`
+  precedent); every other mode keeps zod's own message.
+- `previewMode: { … }` on `KernelContext` / `TenantRuntimeContext` →
+  *(removed key)* — tombstoned with `retiredKey()` (the schemas are not
+  `.strict()`, so a bare deletion would be a silent strip): authoring it is
+  now a `tsc` error and a parse error carrying the prescription.
+- `PreviewModeConfigSchema` / `PreviewModeConfig` / `PreviewModeConfigParsed`
+  → *(removed — no replacement)*. The def described behaviour no layer
+  implemented; an exported value schema with no consumer reads as a
+  capability (#3950).
+
+One-line fix: delete the key and the value — neither ever changed runtime
+behaviour, so removing them changes nothing observable. Preview deployment
+ROUTING is untouched: `OS_PREVIEW_MODE` / `OS_PREVIEW_BASE_DOMAINS` keep
+working exactly as documented (deployment routing, never identity). If a
+preview experience becomes a product capability it re-declares fresh, with
+the production-posture hard-refusal as the first-landed half (#11846 ruling
+record, maintainer 2026-08-27).
+
+The retirement kit:
+
+- tombstones at both declarations (`kernel/KernelContext:previewMode` and the
+  `.extend()` copy `kernel/TenantRuntimeContext:previewMode`, both in
+  `RETIRED_KEYS_BY_MAJOR[18]`); the enum value's prescription on
+  `RuntimeMode`'s error map (enum-VALUE retirements register nothing in
+  RETIRED_KEYS_BY_MAJOR and leave the surface ratchets byte-identical)
+- whole-def deletion `kernel/PreviewModeConfig` in `RETIRED_DEFS_BY_MAJOR[18]`
+  (manifest key deliberately removed; the #4725 gate adjudicated it)
+- deliberately NO D2 conversion: a kernel context is constructed by host code
+  at boot — not a stack collection member, never a `sys_metadata` row — so
+  the conversion chain has no seam that would ever see one (the
+  `kernel/Manifest:loading` disposition); the D3 semantic entry carries the
+  prescription
+- pin tests (`kernel/preview-mode-retirement.test.ts`): both rejection sites
+  flip from silent parse to the prescription; zero holders for all 3 retired
+  export names on every public entry; the carrier schemas survive
@@ -0,0 +1,42 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(objectql): a failed `sys_organization` tenant scan no longer decides a retention window (#12853)
+
+`LifecycleService.loadGovernance()` filled `snapshot.tenantOverrides` — the
+ADR-0057 §3.2 per-tenant retention/expiry window set — behind a bare `catch {}`
+whose comment named ONE benign cause ("No sys_organization (single-tenant
+kernel)") while the `catch` swallowed every cause. On a connection drop, a
+timeout, a permission refusal or a driver fault the map came back EMPTY, and an
+empty map is not a neutral value: `reap()` and `archiveObject()` read it as
+"this deployment has tuned no tenant" and fall every tenant back to the global
+window. That window is wrong in both directions, and the expensive direction is
+a tenant configured to retain LONGER having its rows expired early. Nothing
+reported it: `GovernanceSnapshot` carries no field saying the tenant pass did not
+complete, and the catch logged nothing — so the platform deleted on knowingly
+incomplete evidence, without knowing the evidence was incomplete.
+
+The scan now discriminates by error TYPE through the shared
+`isMissingTableError` predicate. An unprovisioned `sys_organization` really does
+mean "no tenant overrides", so a single-tenant kernel is unchanged. Every other
+cause aborts the sweep **before any policy is applied** — for a deletion action,
+"do not act on incomplete evidence" is the correct failure direction, and a log
+cannot bring back a reaped row. The rows a deferred sweep leaves are still there
+for the next one.
+
+Operational posture change, deliberate and worth stating: a transient
+`sys_organization` outage now costs a sweep. The abort is REPORTED, not thrown —
+one `report.errors` entry per declared object plus a `warn` — because `sweep()`'s
+declared contract is that it never throws and the scheduler enters it as
+`void this.sweep()`, where a rejection would be unhandled. That is the same
+objection #8906 recorded when it declined to rethrow from `checkGovernance` one
+method below.
+
+Bump argued, not defaulted: `patch`. No exported signature, type, option or
+report field moves — the failure surfaces through `LifecycleSweepReport.errors`,
+which already exists for exactly this. The tension is honest and does not change
+the answer: what a deployment observes on a failure path DOES change (a sweep
+that used to complete silently now aborts and says so), but that is the
+correction of a defect, not a new capability, and the sibling repairs in this
+family (#8896, #8906, #9817) all shipped as `patch`.
@@ -0,0 +1,47 @@
+---
+"@objectstack/plugin-security": minor
+---
+
+feat(security): the referential FK-clear write is exempt from the object-level CRUD check (#12597)
+
+**This changes which deletes succeed** — an observable behavioural contract
+change on the delete path, which is why it ships `minor` rather than as a
+patch-grade defect repair.
+
+Deleting a record makes the engine clear every optional lookup that points at it
+(`deleteBehavior: 'set_null'`). That cleanup `UPDATE` is engine-owned referential
+integrity, and it has carried the server-derived `__referentialFieldClear` marker
+since #3023 — but the marker reached only the ownership-anchor guard, so the
+write still had to pass the **object-level CRUD check** on the referencing
+object. Consequence, measured on a real deployment across 17 role×object pairs: a
+role with full delete rights on A and no grant at all on B could delete an A only
+while B was **empty**. The moment a real row referenced it, the delete failed with
+one generic "you do not have permission", and nothing on any permission screen
+showed that deleting A also required write authority on B.
+
+**What is exempt: the object-level CRUD grant check, and nothing else.** A marked
+`update` skips that one gate (both the caller's grant and the ADR-0090 D10
+delegator half of the same question). Everything else in the security middleware
+runs unchanged and is pinned test-by-test:
+
+- field-level security on the FK column still refuses;
+- the RLS `using` row scope on the referencing object still refuses;
+- the RLS post-image `check` still refuses — so a deployment declaring
+  `product != null` keeps getting a truthful refusal instead of a silent clear;
+- declared validation rules keep firing (they were never in this path);
+- a caller without delete rights on the target is still refused;
+- an ordinary, unmarked update on the referencing object is untouched.
+
+⛔ Deliberately **not** `isSystem`: that bypass is total (see
+`content/docs/permissions/system-context.mdx` — "Elevation is total, and it is not
+granular"), and it would have switched off all three guards above. ⛔ The
+`cascade` arm — deleting whole referencing rows — is **unchanged** and still
+requires the caller's own delete authority on those rows.
+
+The write is not elevated at all, so audit attribution is unchanged: the cleanup
+`UPDATE` still runs under the operator's identity and lands in the ledger as that
+operator (`user_id` / `actor`, and the `updated_by` stamp).
+
+No authorable surface changes, and no metadata needs migrating: a deployment that
+was working around this by granting write access on referencing tables can narrow
+those grants, but nothing forces it to.
@@ -0,0 +1,47 @@
+---
+"@objectstack/core": minor
+---
+
+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.