@@ -0,0 +1,33 @@
+---
+"@objectstack/driver-turso": minor
+---
+
+`TursoDriver` in **remote** mode refuses a read over a missing table or a missing column with the same code the local mode answers, instead of answering "no rows" (#20424).
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (already-registered driver-sql-unresolvable-where-column-refused) That registered entry names `TursoDriver` among the `SqlDriver` subclasses whose reads now refuse an unresolvable column, and prescribes this change's remedy: name a column the table has, or run schema sync so a declared field exists as a column. The `aggregate` legs (a table that is really absent, a `groupBy` or aggregation column that is absent) are the same drifted-schema family with the same remedy, so no new migration entry is owed. -->
+
+**BREAKING** — an accept-set narrowing on the remote face of `TursoDriver`'s read doors, shipped as `minor` under the launch-window convention (`check-changeset-no-major` refuses `major` until GA; breaking-ness is carried by this banner and the ADR-0087 disposition above, not by the level). Remote-face users meet this refusal for the first time here.
+
+**FROM → TO.** A remote-face read (`aggregate`, `find`, `findOne`, `count`) that answered `[]` / `null` for a missing table or a missing column now refuses, as the local face does: `DATABASE_ERROR` / 500 for a table that is absent, `INVALID_FIELD` / 400 for a `groupBy` or aggregation column that is absent, `INVALID_FILTER` / 400 for a `where` column that is absent. **The fix:** run schema sync so the declared field has its column (or the object its table), or name a column the table has. `RemoteTransport.find` and `RemoteTransport.aggregate`, exported from the package root, now raise the backend's error where they answered `[]`.
+
+**What was wrong.** Two catches in `RemoteTransport` read a backend "no such table" or "no such column" as an empty result. `aggregate` answered `[]` for both. `find` (and `findOne` through it) answered `[]` (`null`) for a missing column once its projection retry was spent, or when there was no projection to drop. So on a remote Turso database a schema drift or a missing table read as "there is no data", while the local mode of the same driver, over the same file, refused it. Measured with a local driver over the same libSQL file as the control, for a federated and for a managed object alike:
+
+| read | local | remote before |
+|:--|:--|:--|
+| `aggregate` on a table that is really absent | `DATABASE_ERROR` / 500 | `[]` |
+| `aggregate` grouped by, or aggregating, a declared field whose column is absent | `INVALID_FIELD` / 400 | `[]` |
+| `aggregate` whose `where` names that field | `INVALID_FILTER` / 400 | `[]` |
+| `find` / `findOne` whose `where` names that field | `INVALID_FILTER` / 400 | `[]` / `null` |
+| `count` whose `where` names that field | `INVALID_FILTER` / 400 | `DATABASE_ERROR` / 500 |
+| `find` ordered by that field | the rows, unordered | `[]` |
+
+**What changes, on the remote face only:**
+
+- `aggregate`, `find`, `findOne` and `count` answer each row above the way the local face does. The backend's error is classified by the local face's own inherited seam, `SqlDriver.aggregateBackendFault`, and not by a second copy: an unresolvable column named by a `groupBy` or an aggregation is `INVALID_FIELD` / 400, one named by the `where` is `INVALID_FILTER` / 400, and anything else is `DATABASE_ERROR` / 500. The dialect text goes to the server log, never to the caller.
+- `find` keeps the local face's recovery ladder: a projection naming a column the table lacks is dropped first, then an ORDER BY on one, and the rows answer. A `where` is never dropped. Before, the ORDER BY rung was missing and the sort answered `[]`.
+- A refusal the transport raises while it compiles the statement (a filter or aggregate-vocabulary refusal, the timeout envelope) keeps its own code and status.
+- `RemoteTransport.find` and `RemoteTransport.aggregate`, used on their own, now raise the backend's error where they answered `[]`.
+
+This is the refusal the registered migration entry `driver-sql-unresolvable-where-column-refused` already names for `driver-sql` "and its `TursoDriver` / `SqliteWasmDriver` subclasses": the remote face of `TursoDriver` now delivers it. **If a read now refuses for you:** the table or column it names is missing from the remote database. Run schema sync so the declared field has its column (or the object its table), or correct the name the query uses.
@@ -0,0 +1,13 @@
+---
+"@objectstack/rest": patch
+---
+
+**`GET /api/v1/meta/:type/:name/audit` is now an authoring door: a caller without an authoring capability is refused, as `/diff`, `/history` and `GET /api/v1/meta/_drafts` refuse.** Before this release, any signed-in caller who could open an item could read its protection-audit trail. Every save appends a row to that trail, a draft save included, and the row carries `note: "draft"`, the actor and the time. So a member could learn that an item had unpublished authoring work, who saved it and when. For an item that had never been published, where the plain read answers `404`, the member could learn that it existed at all. This carries the maintainer's ruling on #20378 (letter B, comment 5865708652) to this door, as triage graded on #20441: draft and preview reads are admin-gated upstream (ADR-0106 D4), and the audit trail, like the version log, has no published-only answer to fall back to.
+
+Clause-②: no
+
+- **Who may read it:** a system context, or a caller holding `studio.access`, `setup.access` or `manage_metadata`. This is the predicate `/meta/_drafts`, `/diff`, `/history` and every draft switch already ask, not a second rule.
+- **Everyone else:** `403` with code `FORBIDDEN`, in the same nested `error` envelope `/meta/_drafts` answers. The refusal is decided on the caller before the protocol is resolved, before the query is parsed and before any event is read. So it is the same answer for an item that exists, one that does not, and one that exists only as a draft, and it carries no event, actor or item name. The message names the door, not drafts.
+- **Unchanged:** callers with an authoring capability read the trail exactly as before, including the per-caller refusal of an item the plain read refuses them and the organization scope of the read.
+
+A client that read `/audit` (`client.meta.getAudit`) as a member now receives `403 FORBIDDEN`. To read it, call as a caller holding one of the three capabilities above.
@@ -233,6 +233,7 @@ const diff = await client.meta.diffItem('object', 'account', { from: 2, to: 5 })
 // Introspection & governance
 const bad = await client.meta.getDiagnostics({ severity: 'error' });
 const refs = await client.meta.getReferences('object', 'account');
+// Authoring-only too, like diffItem: without studio.access, setup.access or manage_metadata → 403 FORBIDDEN
 const trail = await client.meta.getAudit('object', 'account', { limit: 20 });
 const tree = await client.meta.getBookTree('handbook');
 
 
@@ -379,12 +379,13 @@ an app an author may not open is refused on these doors too. Reading a
 needs an authoring capability (`studio.access`, `setup.access` or
 `manage_metadata`: the check `GET /api/v1/meta/_drafts` makes). A caller
 without one is answered as if the parameter were absent: the published app,
-or `404` for an app that has never been published. `/diff`, and the change log
-`/history` beside it, need that capability outright: both read the version log,
-which records a draft save like any other, so they have no published-only
-answer to fall back to. A caller without one is refused with `403`, as
-`GET /api/v1/meta/_drafts` refuses, before anything is read — the same answer
-whether or not the app exists.
+or `404` for an app that has never been published. `/diff`, the change log
+`/history` beside it and the protection-audit trail `/audit` need that
+capability outright: the version log and the audit trail each record a draft
+save like any other, so none of them has a published-only answer to fall back
+to. A caller without one is refused with `403`, as `GET /api/v1/meta/_drafts`
+refuses, before anything is read — the same answer whether or not the app
+exists.
 
 `visible` did **not** move server-side with them, and that asymmetry is
 deliberate: CEL is evaluated in the browser because server-side evaluation needs
 
@@ -51,12 +51,23 @@ describe('RemoteTransport unknown-$select column', () => {
     expect(calls[1].sql).toMatch(/SELECT \* FROM "product"/);
   });
 
-  it('still returns empty when even SELECT * fails (e.g. unknown table)', async () => {
-    const { t } = transportWithClient(async () => {
+  // [#20424] This case REPLACES the pin 'still returns empty when even SELECT *
+  // fails (e.g. unknown table)', which asserted `[]` for exactly this input.
+  // `[]` was the defect: a column the WHERE still names once the projection is
+  // gone is a predicate that never ran, and "no rows" is a false answer to it.
+  // The transport now raises the backend's error from the last rung, and
+  // `TursoDriver` classifies it (`INVALID_FILTER` / 400, the local face's
+  // answer). The same input, the opposite assertion.
+  it('raises the last rung\'s error when even SELECT * fails, instead of answering []', async () => {
+    const { t, calls } = transportWithClient(async () => {
       throw new Error('SQLITE_ERROR: no such column: status');
     });
-    const result = await t.find('ghost', { fields: ['id', 'status'], limit: 10 });
-    expect(result).toEqual([]);
+    await expect(t.find('ghost', { fields: ['id', 'status'], limit: 10 })).rejects.toThrow(
+      /no such column: status/,
+    );
+    // The projection attempt, then the one rung this query has.
+    expect(calls).toHaveLength(2);
+    expect(calls[1].sql).toMatch(/SELECT \* FROM "ghost"/);
   });
 
   it('propagates non-column errors instead of hiding them as empty', async () => {
 
@@ -1412,16 +1412,39 @@ export class RemoteTransport {
         // real rows still come back; the unknown field is simply absent from
         // each row (it never existed). Mirrors the SqlDriver backstop — the
         // remote Turso path overrides find(), so it needs its own copy.
+        //
+        // [#20424] The copy now has the local ladder's two rungs and its
+        // terminal. The rungs, in `SqlDriver.findRows`' order: the projection
+        // first, then the ORDER BY (#3821: rows matter more than their order),
+        // each rebuilt with the caller's WHERE, which neither rung may drop.
+        // The terminal was `return []` here, on both the no-rung path and a
+        // failed rung, so an unresolvable column in the WHERE, or an ORDER BY
+        // on a column the table lacks, read as "there are no rows". The local
+        // face answers the first with `INVALID_FILTER` / 400 (#8790) and the
+        // second with its rows, unordered. Now the last error leaves this
+        // method as the backend raised it, and `TursoDriver` classifies it
+        // with the local face's own read-exit seam. The refusal and its code
+        // are the driver's, not this transport's.
+        const rungs: any[] = [];
         if (query?.fields && Array.isArray(query.fields) && query.fields.length > 0) {
+          rungs.push({ ...query, fields: undefined });
+        }
+        if (Array.isArray(query?.orderBy) && query.orderBy.some((item: any) => item?.field)) {
+          rungs.push({ ...query, fields: undefined, orderBy: undefined });
+        }
+        let lastError: unknown = error;
+        for (const rung of rungs) {
           try {
-            const fallback = this.buildSelectSQL(object, { ...query, fields: undefined }, table);
+            const fallback = this.buildSelectSQL(object, rung, table);
             const result = await this.client!.execute({ sql: fallback.sql, args: fallback.args });
             return this.mapRows(result);
-          } catch {
-            return [];
+          } catch (rungError) {
+            // The next, broader rung. The last one to fail names the column
+            // the WHERE still holds, once the projection and the sort are gone.
+            lastError = rungError;
           }
         }
-        return [];
+        throw lastError;
       }
       throw error;
     }
@@ -1626,19 +1649,18 @@ export class RemoteTransport {
       sql += ` GROUP BY ${groupBy.map((g) => `"${g.field}"`).join(', ')}`;
     }
 
-    try {
-      const result = await this.client!.execute({ sql, args });
-      return this.foldEmptyAggregateAnswers(this.mapRows(result), foldedOutput);
-    } catch (error: any) {
-      if (
-        error.message &&
-        (error.message.includes('no such table') ||
-          error.message.includes('no such column'))
-      ) {
-        return [];
-      }
-      throw error;
-    }
+    // [#20424] The backend's error leaves this method as it was raised. A
+    // catch here used to answer `no such table` and `no such column` with `[]`,
+    // so a table that is really absent, or a groupBy, aggregation or WHERE
+    // naming a declared field whose column is absent, read as "no data". The
+    // local face of the same driver refuses all of them. `TursoDriver`
+    // classifies the error with the local face's own aggregate seam
+    // (`SqlDriver.aggregateBackendFault`): `INVALID_FIELD` / 400 for a groupBy
+    // or aggregation column, `INVALID_FILTER` / 400 for a WHERE column, and
+    // `DATABASE_ERROR` / 500 for the rest. The catch arrived with this method's
+    // first version, with no comment, no pin and no case it was written for.
+    const result = await this.client!.execute({ sql, args });
+    return this.foldEmptyAggregateAnswers(this.mapRows(result), foldedOutput);
   }
 
   /**
@@ -2883,11 +2905,12 @@ export class RemoteTransport {
       //
       // The first two are the silent empty set: SQLite's backwards-compatible
       // rule degrades a double-quoted name that resolves to no column into a
-      // STRING LITERAL, so the statement compiles, runs and matches nothing —
-      // and where a build disables that rule (`SQLITE_DQS=0`) `find()`'s own
-      // `no such column` backstop swallows the error into `[]` anyway. Two
-      // roads, one answer, and neither is distinguishable from "no rows
-      // matched".
+      // STRING LITERAL, so the statement compiles, runs and matches nothing,
+      // which is not distinguishable from "no rows matched". Where a build
+      // disables that rule (`SQLITE_DQS=0`), the statement fails with
+      // `no such column` instead, and `find()`'s backstop now refuses it, as
+      // the local face does (`INVALID_FILTER` / 400, see #20424). It used to
+      // swallow that error into `[]` too: a second road to the same answer.
       //
       // The third is the expensive direction, and it needs no dialect quirk at
       // all: a `{}` disjunct absorbs its `$or` to TRUE, the compiled clauses are