@@ -0,0 +1,16 @@
+---
+'@objectstack/driver-turso': patch
+---
+
+fix(driver-turso): a Turso remote database enforces the `storage.notNull` a field declares, on the tables and columns its schema sync creates
+
+Clause-②: no
+
+**What was wrong.** On a Turso database reached over the remote transport (`libsql://…`, the transport hosted environments use), schema sync created every declared column nullable. A field declared `storage: { notNull: true }` was not enforced there: an insert that left it empty was stored. The same declaration on a local SQLite file (`file:`) has always produced a `NOT NULL` column. The drift report, which compares the database with the declarations through the shared differ, also read each such column as destructive `tighten_not_null` drift on a database the remote sync had just created.
+
+**What changes.** The remote face's `CREATE TABLE` and `ALTER TABLE … ADD COLUMN` add `NOT NULL` to a column whose field declares `storage.notNull`, wherever the local face adds it: on every field type, multi-value fields included, and never for `required` alone. On a remote database synced after this release, an insert that leaves such a field empty is refused by the database, and the drift report names no `tighten_not_null` for it.
+
+**What does not change.**
+
+- A column that already exists is not touched. A remote database synced by an earlier release keeps its nullable columns, and its drift report still names them `tighten_not_null`; no data at rest is migrated. So the remote face still declares its drift-report caveat (reworded to say this), and the `OS_ARTIFACT_URL` boot gate still does not act on a remote report.
+- Adding a `storage.notNull` field to a remote table that already holds rows is refused by SQLite (`Cannot add a NOT NULL column with default value NULL`), as it is on a local SQLite file, and that object's schema sync fails loudly. The remote error now names the refused statement. One case still differs: when the field also declares a literal `defaultValue`, the local face creates the column with that DEFAULT and accepts it, while the remote face emits no declared column DEFAULT and refuses it.
@@ -99,6 +99,17 @@ const DEFAULT_ID_LENGTH = 16;
  */
 const BUILTIN_COLUMNS = new Set(['id', 'created_at', 'updated_at']);
 
+/**
+ * [#23847] ADR-0113's physical column constraint: does this field declare a
+ * NOT NULL column? Asked exactly as the local face's `declaresColumnNotNull`
+ * (`driver-sql`'s `sql-driver.ts`) asks it — truthiness of `storage.notNull`,
+ * whatever the field's type, `multiple: true` included, and never `required`.
+ * See {@link RemoteTransport.columnDeclarationSQL}, its one reader here.
+ */
+function declaresColumnNotNull(field: unknown): boolean {
+  return Boolean((field as { storage?: { notNull?: unknown } } | null | undefined)?.storage?.notNull);
+}
+
 /**
  * [#17609] Every index name the database already carries — ONE statement for a
  * whole schema sync, read beside the column probe. SQLite index names are
@@ -2098,8 +2109,7 @@ export class RemoteTransport {
           const type = (field as any).type || 'string';
           if (type === 'formula') continue; // Virtual — no column
           this.assertSafeIdentifier(name);
-          const colType = this.mapFieldTypeToSQL(field);
-          await this.client!.execute(`ALTER TABLE "${tableName}" ADD COLUMN "${name}" ${colType}`);
+          await this.executeAddColumn(`ALTER TABLE "${tableName}" ADD COLUMN "${name}" ${this.columnDeclarationSQL(field)}`);
           materialized.add(name);
         }
       }
@@ -2230,8 +2240,7 @@ export class RemoteTransport {
           const type = (field as any).type || 'string';
           if (type === 'formula') continue;
           this.assertSafeIdentifier(name);
-          const colType = this.mapFieldTypeToSQL(field);
-          ddlStatements.push(`ALTER TABLE "${object}" ADD COLUMN "${name}" ${colType}`);
+          ddlStatements.push(`ALTER TABLE "${object}" ADD COLUMN "${name}" ${this.columnDeclarationSQL(field)}`);
           materialized.add(name);
         }
 
@@ -2396,15 +2405,86 @@ export class RemoteTransport {
         const type = (field as any).type || 'string';
         if (type === 'formula') continue; // Virtual — no column
         this.assertSafeIdentifier(name);
-        const colType = this.mapFieldTypeToSQL(field);
-        sql += `, "${name}" ${colType}`;
+        sql += `, "${name}" ${this.columnDeclarationSQL(field)}`;
       }
     }
 
     sql += ')';
     return sql;
   }
 
+  /**
+   * [#23847] What follows a declared field's column NAME in this transport's
+   * DDL: the storage type {@link mapFieldTypeToSQL} decides, then ` NOT NULL`
+   * when the field declares `storage: { notNull: true }`. The ONE renderer for
+   * every statement that materializes a declared field's column here — the
+   * `CREATE TABLE` {@link buildCreateTableSQL} builds and the `ALTER TABLE …
+   * ADD COLUMN` of {@link syncSchema} and {@link syncSchemasBatch} — so no door
+   * can create the column without the constraint another door creates it with.
+   *
+   * # The reference: `SqlDriver.createColumn`, this driver's local face
+   *
+   * ADR-0113: the physical NOT NULL comes from the EXPLICIT storage
+   * constraint, never from `required` (the write-time contract the record
+   * validator enforces). `createColumn` asks one question for it,
+   * `declaresColumnNotNull` — truthiness of `storage.notNull` — on BOTH of its
+   * exits, the multi-value JSON column included (#17231), and runs on `CREATE
+   * TABLE` and on `ALTER TABLE ADD COLUMN` alike. {@link declaresColumnNotNull}
+   * below asks the same question, the same way, on the same two statements.
+   * `turso-remote-not-null.test.ts` holds the two faces to one answer: the
+   * columns a remote sync creates carry the `notnull` flag the local face's
+   * columns carry for the same declarations.
+   *
+   * Until this renderer the remote face never emitted the constraint, so every
+   * `storage.notNull` was unenforced on a Turso remote database, and the shared
+   * drift differ read each such column as DESTRUCTIVE `tighten_not_null` drift
+   * against a table this transport had itself just created.
+   *
+   * # ADD COLUMN on a table that already holds rows
+   *
+   * SQLite refuses `ADD COLUMN … NOT NULL` without a non-NULL `DEFAULT` once
+   * the table has a row (`Cannot add a NOT NULL column with default value
+   * NULL`); an empty table accepts it. The local face sends the same
+   * statement and gets the same refusal, so the sync of that object fails
+   * loudly on both faces, and the engine reports it per object. ⛔ Never drop
+   * the ` NOT NULL` to let such a statement through: a nullable column under a
+   * `storage.notNull` declaration is exactly the silent, unenforced state this
+   * renderer replaced. Imposing NOT NULL on a column that already exists is
+   * not done here at all — that is `tighten_not_null`, destructive, and
+   * belongs to the migration path, not to an additive sync.
+   *
+   * ⚠️ One case still differs, and it is a DEFAULT question, not a nullability
+   * one: this transport emits no declared column DEFAULT for any field, while
+   * `createColumn` emits a literal `defaultValue` (`applyDeclaredColumnDefault`).
+   * So a `storage.notNull` field that also declares a literal `defaultValue`,
+   * added to a populated table, is accepted locally (existing rows take the
+   * default) and refused here. `turso-remote-not-null.test.ts` records that
+   * asymmetry; closing it means deciding whether, and from which shared source,
+   * this face emits declared defaults.
+   */
+  private columnDeclarationSQL(field: any): string {
+    const colType = this.mapFieldTypeToSQL(field);
+    return declaresColumnNotNull(field) ? `${colType} NOT NULL` : colType;
+  }
+
+  /**
+   * [#23847] Send one `ALTER TABLE … ADD COLUMN`, and when the database refuses
+   * it, say which statement was refused. The local face's error already names
+   * it — knex prefixes the failing SQL to the driver's message — while libSQL's
+   * own message (`Cannot add a NOT NULL column with default value NULL`) names
+   * no table and no column, and the engine's per-object report says only which
+   * object failed. Same error object, same class and code; only its message
+   * gains the statement, in knex's `<sql> - <message>` form.
+   */
+  private async executeAddColumn(ddl: string): Promise<void> {
+    try {
+      await this.client!.execute(ddl);
+    } catch (e) {
+      if (e instanceof Error) e.message = `${ddl} - ${e.message}`;
+      throw e;
+    }
+  }
+
   /**
    * [#8413 · #17609] Every index an object's metadata declares, as executable
    * DDL: field-level `unique` (tenancy-aware) PLUS the object's own
 
@@ -603,8 +603,10 @@ function refuseRemoteDeferredDdl(): never {
  * # What this face does NOT claim: a boot may not act on its report
  *
  * The report is accurate about the database, but not every finding is real
- * drift. This face's schema sync (`RemoteTransport`) does not create the NOT NULL
- * constraint a field declares, so a table it created reads as `tighten_not_null`
+ * drift. A table this face's schema sync (`RemoteTransport`) created before
+ * #23847 has no NOT NULL constraint for the fields that declare one: the sync
+ * creates it now, but an additive sync never tightens a column that already
+ * exists. So such a table reads as `tighten_not_null`
  * (destructive) against its own declaration. Nor is there a remedy for a
  * destructive entry on this transport: `os migrate apply` arms deferred DDL,
  * which this face refuses. So {@link TursoDriver.driftReportCaveat} says so,
@@ -615,7 +617,8 @@ function refuseRemoteDeferredDdl(): never {
 
 /** [#23816] {@link TursoDriver.driftReportCaveat} on the REMOTE face. */
 const REMOTE_DRIFT_REPORT_CAVEAT =
-  'the Turso REMOTE transport\'s schema sync does not create the NOT NULL constraint a field declares, so ' +
+  'a table the Turso REMOTE transport\'s schema sync created in an earlier release has no NOT NULL ' +
+  'constraint on the fields that declare one (the sync creates it now, but never tightens an existing column), so ' +
   'this driver\'s drift report can name a tightening its own sync produced, and a destructive entry has no ' +
   'remedy on this transport (`os migrate apply` refuses against it). The report is for reading; nothing is ' +
   'applied or refused on it unattended. To review the drift, run `os migrate plan` against a local SQLite ' +