@@ -1,20 +1,21 @@
 ---
-'@objectstack/driver-sql': minor
-'@objectstack/driver-turso': minor
+'@objectstack/driver-sql': patch
+'@objectstack/driver-turso': patch
 '@objectstack/spec': patch
 ---
 
 feat(driver-sql,driver-turso)!: a table the driver creates carries its tenant column NOT NULL, so a write that names no organization is refused at the database
 
 Clause-②: yes (narrowing)
+Metadata-protocol: none
 
 <!-- adr-0087: not-required (no-migration-prescription) A storage constraint at CREATE TABLE: no key of any metadata schema is removed, renamed or re-shaped, so there is nothing for `objectstack migrate meta` to rewrite and no tombstone. No export, type or error code is removed or renamed; `TENANT_SCOPE_FIELD_DEF` keeps its shape and only its description text is corrected. The remedy is a run-time one, stated below. -->
 
-**BREAKING** accept-set narrowing at the database, shipped as `minor` under the repo's launch-window convention for breaking changes (ADR-0131 D1: "There is no nullable tenant column anywhere").
+**BREAKING** accept-set narrowing at the database (ADR-0131 D1: "There is no nullable tenant column anywhere"). It changes what a data writer can store, not what a metadata author can write, so it ships as `patch` with this banner.
 
 - **Before.** The SQL driver created a table's tenant column (`organization_id`, or a declared `tenancy.tenantField`) nullable, as the injected field's declaration says (`required: false`, no `storage`). A write that reached the driver without an organization landed a row no organization owns.
 - **Now.** Every table the driver CREATES takes its tenant column `NOT NULL`, with no metadata change: the plain managed table (`initObjects`), every newly rotated shard (asked of the base table's declaration), and a table the Turso remote face creates (`syncSchema`, `syncSchemasBatch`, `initObjects`). A write with no organization on such a table is refused by the database (`NOT NULL constraint failed: <table>.organization_id`, `violates not-null constraint`, or `cannot be null`). That includes an `upsert` whose payload omits the organization: the database checks the proposed row before it resolves the conflict.
-- **Unchanged.** A tenant column ADDED to a table that already exists stays nullable, and so does an existing shard or an existing remote table: a table that already holds rows is the organization-ownership ceremony's to tighten (`os migrate organization-ownership`), which reports a shard and the Turso remote face as unable to. The schema differ reports no drift over the tenant column's nullability either way. An object with no tenant column (`tenancy: { enabled: false }`, `systemFields: { tenant: false }`) is untouched, even when it carries a field named `organization_id`.
+- **Unchanged.** A tenant column ADDED to a table that already exists stays nullable, and so does an existing shard or an existing remote table: a table that already holds rows is the organization-ownership ceremony's to tighten (`os migrate organization-ownership`), which reports a shard and the Turso remote face as unable to. The schema differ reports no drift over the tenant column's nullability either way. On a database that has not taken the ceremony, a table this release creates (a newly rotated shard, or a cold table a newly configured lifecycle tier creates) is NOT NULL beside nullable siblings: an organization-less row the lifecycle mover would carry into it is refused there, and stays where it is until the ceremony attributes it. An object with no tenant column (`tenancy: { enabled: false }`, `systemFields: { tenant: false }`) is untouched, even when it carries a field named `organization_id`.
 - **Who sees it.** A composed `os serve` / `os dev` / `os start` with auth stamps every write with its organization, so nothing changes there. A production `os serve` whose `AuthPlugin` did not compose (no `OS_AUTH_SECRET`) and a lean embedding (`@objectstack/objectql/core` or `createStandaloneStack` over a SQL driver, with no organization object) used to write those rows with a NULL organization; now each such write fails, loudly.
 
 **The remedy.** Carry the organization on the write: `ql.insert(object, { ...row, organization_id: orgId })`, or `{ context: { tenantId: orgId } }`. Compose authentication (set `OS_AUTH_SECRET`) so the platform derives it. If the object's rows legitimately belong to no organization, declare it so and it has no tenant column: `systemFields: { tenant: false }` or `tenancy: { enabled: false }`.
@@ -597,10 +597,11 @@ export interface SchemaRegistryOptions {
  * Currently injects:
  *   - `organization_id` — always provisioned (unless the object opts out via
  *     `systemFields`/`tenancy.enabled:false` or is `better-auth` managed) so
- *     the column never depends on the global multi-tenant flag. Required-false;
- *     org-scoping populates it on insert in multi-tenant mode, and it stays
- *     NULL on single-tenant stacks. Only the column's INDEX is gated on
- *     `multiTenant` (no per-tenant filtering exists single-tenant).
+ *     the column never depends on the global multi-tenant flag. Required-false
+ *     in the declaration; org-scoping stamps it on insert (under `single` with
+ *     the Default Organization), and it is never NULL (ADR-0131 D1). Only the
+ *     column's INDEX is gated on `multiTenant` (no per-tenant filtering exists
+ *     single-tenant).
  *   - `created_at` / `created_by` / `updated_at` / `updated_by` — audit
  *     fields. Marked `system: true, readonly: true` so detail views can
  *     surface them in a dedicated "System Information" section while
 
@@ -196,17 +196,6 @@ describe('[#24523] statements per warm request: an organization-owned admin gran
 
 describe('[#24523 / #21868] a sys_organization write retires the memoised Default Organization', () => {
   it('⭐ the Default Organization deleted and recreated: the next request reads the new id', async () => {
-    // Deleting an organization runs the engine's referential cascade, whose
-    // `set_null` on every `organization_id` lookup a fresh, NOT NULL tenant
-    // column refuses (ADR-0131 D1). This test's subject is the memo, not the
-    // cascade, so the store is a pre-18 one: every tenant table it holds is
-    // relaxed through its driver's own drift apply door.
-    for (const o of (engine as any).registry.getAllObjects() as Array<{ name: string; fields?: Record<string, unknown>; tenancy?: { enabled?: boolean } }>) {
-      if (!o.fields?.organization_id || o.tenancy?.enabled === false) continue;
-      const driver = (engine as any).getDriver(o.name);
-      if (!(await driver?.knex?.schema.hasTable(o.name))) continue;
-      await relaxTenantColumns(driver, [o.name]);
-    }
     const [old] = await find('sys_organization', { slug: 'default' });
     await standing(); // the control above wrote the organization: read it once
     expect(await standing()).toEqual({ standing: true, organizationReads: 0 });
 
@@ -221,8 +221,8 @@ export const SystemFieldName = {
   OWNING_BUSINESS_UNIT_ID: 'owning_business_unit_id',
   /**
    * THE tenant isolation key — a lookup to `sys_organization`. INJECTED unless
-   * tenancy is disabled for the object; org-scoping populates it on insert and
-   * it stays NULL on single-tenant stacks.
+   * tenancy is disabled for the object; org-scoping stamps it on insert (under
+   * `single` with the Default Organization), and it is never NULL (ADR-0131 D1).
    */
   ORGANIZATION_ID: 'organization_id',
   /**