@@ -1,32 +1,34 @@
 ---
 '@objectstack/spec': minor
 '@objectstack/driver-turso': minor
+'@objectstack/service-datasource': patch
 ---
 
 fix(spec,driver-turso)!: a turso datasource that declares `encryptionKey` on a local file or an embedded replica is refused where it is written and when the driver is built, instead of being accepted and written in plaintext
 
-Clause-②: no (narrowing) — the accept set of the `turso` `datasource.config` contract, of the published `TursoConfigSchema` mirror and of `new TursoDriver()` narrows by one key in two modes. No key is added, removed or renamed, and no exported symbol moves.
+Clause-②: no (narrowing) — the accept set of the `turso` `datasource.config` contract, of the published `TursoConfigSchema` mirror and of `new TursoDriver()` narrows by one key beside a `file:` url or `:memory:`, in every mode. No key is added, removed or renamed, and no exported symbol moves. `@objectstack/service-datasource` is graded `patch`: the TSDoc of its exported `TursoDriverConfigInput.encryptionKey` no longer promises an encrypted file, and nothing else in it changes.
 
 `encryptionKey` was declared as an "AES-256 encryption key for the local database file", and nothing applied it. The turso driver reads and writes a local or replica file through better-sqlite3, which has no encryption codec (`PRAGMA key` is a silent no-op there). Measured on the driver source with a test key: a local datasource with `encryptionKey` constructed, connected and wrote its rows, and plain better-sqlite3, opening the file read-only with no key, read them back. An embedded replica fared no better: only its sync client was handed the key, after the local engine had already written the file in plaintext, and a file that client encrypted is one the local engine cannot open. An operator who declared the key got an unencrypted file and no signal.
 
-**BREAKING** accept-set narrowing on a published schema and a published constructor, shipped as `minor` under the repo's launch-window convention for breaking changes (`scripts/check-changeset-no-major.mjs`). A non-empty `encryptionKey` on a local datasource (a `file:` url or `:memory:`) or an embedded replica (a `file:` url beside `syncUrl`), detected or forced with `mode`, is refused now, at both doors together, with one message per mode that names the mode and what does encrypt:
+**BREAKING** accept-set narrowing on a published schema and a published constructor, shipped as `minor` under the repo's launch-window convention for breaking changes (`scripts/check-changeset-no-major.mjs`). A non-empty `encryptionKey` on a local datasource (a `file:` url or `:memory:`) or an embedded replica (a `file:` url beside `syncUrl`), detected or forced with `mode`, is refused now, at both doors together, with one message per mode that names the mode and what does encrypt. The key is judged by where the database lives, not by the mode: the same `file:` url or `:memory:` under a forced `mode: 'remote'` is refused too, in its own words, because the driver hands that url to the libSQL client it builds, which is handed no key, so the file was written in plaintext all the same:
 
 - **at authoring**, as one `custom` issue on `encryptionKey` (`config.encryptionKey` on a datasource): `DatasourceSchema`, `validateDriverConfig`, `defineStack` / `os validate`, and a save or test connection through the datasource admin service;
 - **at construction**, `VALIDATION_ERROR` / 400 from `new TursoDriver()` (and `createTursoDriver()`), before any database file is opened.
 
-The message is the same text at all three places, and a test holds the constructor's copy equal to the schema's issue byte for byte. It comes last among the local-engine refusals: a url the engine cannot open, a lone `sync` and a forced `mode` the driver would ignore each keep their own message. An empty `encryptionKey` is unset and is still accepted. A remote datasource is not judged by this refusal. The `encryptionKey` describe texts no longer promise an encrypted file.
+The message is the same text at all three places, and a test holds the constructor's copy equal to the schema's issue byte for byte. It comes last among the local-engine refusals: a url the engine cannot open, a lone `sync` and a forced `mode` the driver would ignore each keep their own message. An empty `encryptionKey` is unset and is still accepted. A remote url (`libsql://`, `https://`, `ws(s)://`) is not judged by this refusal. The `encryptionKey` describe texts no longer promise an encrypted file.
 
 ### Migration: FROM → TO
 
 | You wrote | Write instead |
 | --- | --- |
 | `url: 'file:./data/app.db', encryptionKey: '…'` | drop `encryptionKey`; put the file on an encrypted disk or volume if it must be encrypted at rest |
 | `url: 'file:./data/replica.db', syncUrl: 'libsql://my-db.turso.io', encryptionKey: '…'` | drop `encryptionKey`, the same way |
+| `url: 'file:./data/app.db', mode: 'remote', encryptionKey: '…'` (or `url: ':memory:'`) | drop `encryptionKey`, the same way |
 | either, where the data must be encrypted at rest and no encrypted volume is available | a remote Turso database (`url: 'libsql://my-db.turso.io'`), whose storage encryption is the server's to configure, not this key's |
 
-The fix in one line: delete `encryptionKey` from every local or replica turso datasource.
+The fix in one line: delete `encryptionKey` from every turso datasource whose `url` is a `file:` url or `:memory:`.
 
-A datasource row stored in this shape is not re-parsed when it loads, so it now fails when the driver is built. `factory.create` throws the refusal. The connection service records the datasource as `failed-degraded` with the message, and a test connection answers `ok: false` ("Failed to build driver: …"). Under ADR-0062 D5, the boot fails fast when objects bind to that datasource or are routed to it, or when it is boot-critical, unless `OS_ALLOW_DRIVER_CONNECT_FAILURE` is set. Otherwise it is left unconnected with a warning. Before this change the same row booted and wrote its file in plaintext.
+A datasource row stored in this shape is not re-parsed when it loads, so it now fails when the driver is built. `factory.create` throws the refusal. The connection service records the datasource as `failed-degraded` with the message, and a test connection answers `ok: false` ("Failed to build driver: …"). Under ADR-0062 D5, the boot fails fast when objects bind to that datasource or are routed to it, or when it is boot-critical. Otherwise it is left unconnected with a warning. Before this change the same row booted and wrote its file in plaintext.
 
 Blast radius, measured on this tree: no example, template, CLI scaffold or published skill authors the key, and no host default or environment variable sets it (a turso `encryptionKey` reaches the driver only from an authored `datasource.config`). Whether any out-of-repo deployment declares such a config is NOT measured and is not claimed to be zero.
 
 
@@ -238,9 +238,12 @@ the file was written in plaintext whatever the key said. A local or
 embedded-replica turso datasource that declares it is now refused at write
 time and when the driver is built: drop the key, and put the file on an
 encrypted disk or volume if it must be encrypted at rest. A remote turso
-datasource still parses with the key, which the driver does not forward
-(a remote database's storage encryption is the server's), and a stored value
-is redacted on read like the rest of this table.
+datasource (a `libsql://`, `https://` or `ws(s)://` url) still parses with the
+key, which the driver does not forward (a remote database's storage encryption
+is the server's), while a `file:` url or `:memory:` under a forced
+`mode: 'remote'` is refused like a local one, because the libSQL client the
+driver builds for it is handed no key; a stored value is redacted on read like
+the rest of this table.
 </Callout>
 
 ## Startup: a driver that cannot connect aborts the boot
 
@@ -523,7 +523,7 @@ carries the prescription. The live keys:
 |:---|:---|:---:|:---|
 | `url` | `string` | (required) | Database URL (`libsql://`, `https://`, `file:`, `:memory:`) — in replica mode, also the local file |
 | `authToken` | `string?` | — | JWT auth token for remote databases |
-| `encryptionKey` | `string?` | — | Encrypts nothing, in any mode: refused for a local or replica datasource (`VALIDATION_ERROR` / 400 at construction, a `custom` issue at authoring), because the local engine (better-sqlite3) has no encryption codec; a remote database's storage encryption is the server's, not set by this key |
+| `encryptionKey` | `string?` | — | Encrypts nothing, in any mode: refused for a local or replica datasource (`VALIDATION_ERROR` / 400 at construction, a `custom` issue at authoring), because the local engine (better-sqlite3) has no encryption codec, and for a `file:` url or `:memory:` under a forced `mode: 'remote'`, whose libSQL client is handed no key; a remote database's storage encryption is the server's, not set by this key |
 | `concurrency` | `number` | `20` | Maximum concurrent requests |
 | `syncUrl` | `string?` | — | Remote sync URL for embedded replica mode |
 | `sync.intervalSeconds` | `number` | `60` | Periodic sync interval (0 = manual only) |
 
@@ -257,7 +257,9 @@ better-sqlite3, which has no encryption codec, so the key would encrypt nothing
 and the file would be written in plaintext that any SQLite reader opens without
 it. Drop `encryptionKey`, and put the file on an encrypted disk or volume if it
 must be encrypted at rest, or use a remote Turso database, whose storage
-encryption is the server's to configure.
+encryption is the server's to configure. A `file:` url or `:memory:` under a
+forced `mode: 'remote'` is refused the same way: the libSQL client the driver
+builds for that url is handed no key.
 
 You can also force a specific mode:
 
@@ -337,7 +339,8 @@ interface TursoDriverConfig {
 
   /**
    * Encrypts nothing, in any mode: refused in local and replica modes
-   * (VALIDATION_ERROR / 400), because the local engine cannot encrypt the file.
+   * (VALIDATION_ERROR / 400), because the local engine cannot encrypt the file,
+   * and beside a file: url or :memory: under a forced mode: 'remote'.
    */
   encryptionKey?: string;
 
 
@@ -324,6 +324,32 @@ function tursoTransportIssues(cfg: TursoTransportKeys): TursoTransportIssue[] {
         + "file beside `syncUrl`: `url: 'file:./data/replica.db'`.",
     });
   }
+  if (
+    (isFileTursoUrl(url) || url === ':memory:')
+    && typeof cfg.encryptionKey === 'string' && cfg.encryptionKey.length > 0
+  ) {
+    // #25020, patch round 1. Only a FORCED remote mode reaches here with a
+    // `file:` url or `:memory:` (with no `mode`, those urls select a local
+    // engine). The key is judged by where the database lives, not by the
+    // mode: `connect()` hands that url to the libSQL client this driver
+    // builds, which is handed no key, so the issue sits on `encryptionKey`,
+    // last, like the local-engine arm's.
+    issues.push({
+      path: 'encryptionKey',
+      message: namesInMemoryTursoDatabase(url)
+        ? "`encryptionKey` asks for this datasource's database to be encrypted, but `url` names an in-memory "
+          + "database, and `mode: 'remote'` runs every read and write of it through the libSQL client this "
+          + 'driver builds, which is handed no key: there is no file for the key to encrypt, so it would change '
+          + 'nothing — the turso driver refuses this configuration when it starts. Drop `encryptionKey`.'
+        : "`encryptionKey` asks for this datasource's database file to be encrypted, but `url` is a local "
+          + "`file:` url, and `mode: 'remote'` runs every read and write of that file through the libSQL client "
+          + 'this driver builds, which is handed no key: nothing would encrypt the file, so it would be written '
+          + 'in plaintext that any SQLite reader opens without the key — the turso driver refuses this '
+          + 'configuration when it starts. Nothing in this driver encrypts a local file. Drop `encryptionKey`, '
+          + 'and encrypt the disk or volume the file lives on instead, or point `url` at a remote Turso '
+          + "database, whose storage encryption is the server's to configure, not this key's.",
+    });
+  }
   return issues;
 }
 
@@ -347,8 +373,11 @@ export const TursoConfigSchema = lazySchema(() => z.object({
 
   /**
    * Encryption Key — encrypts nothing, in any mode, and is REFUSED for a local
-   * or embedded-replica database (#25020; the refusal is the
-   * `tursoTransportIssues` arm above, in the spec contract's words).
+   * or embedded-replica database, and beside a `file:` url or `:memory:` under
+   * a forced `mode: 'remote'` (#25020; the refusals are the
+   * `tursoTransportIssues` arms above, in the spec contract's words — this
+   * mirror declares no `mode`, so it judges such a config as the local
+   * database its url selects, and refuses it with that arm's text).
    *
    * It used to promise to encrypt the local database file at rest with
    * AES-256. The driver reads and writes that file through better-sqlite3,
@@ -357,7 +386,7 @@ export const TursoConfigSchema = lazySchema(() => z.object({
    * its sync client only. The driver does not forward it to a remote database
    * either, whose storage encryption is the server's.
    */
-  encryptionKey: z.string().optional().describe("Not honoured in any mode: refused for a local or replica datasource, whose SQLite engine cannot encrypt the file; a remote database's storage encryption is the server's, not set by this key"),
+  encryptionKey: z.string().optional().describe("Not honoured in any mode: refused for a local or replica datasource, whose SQLite engine cannot encrypt the file, and for a file: url or :memory: under a forced remote mode, whose libSQL client is handed no key; a remote database's storage encryption is the server's, not set by this key"),
 
   /**
    * Concurrency Limit.