@@ -0,0 +1,22 @@
+---
+'@objectstack/spec': minor
+'@objectstack/metadata-protocol': minor
+'@objectstack/mcp': minor
+---
+
+fix(spec,metadata-protocol,mcp)!: a field marked `sortable: false` is no longer offered or performed as a sort — the sortability projection reports it unsortable, and the Data API and the stdio MCP `query_records` refuse a sort on it with `400 INVALID_SORT` (#29896)
+
+Clause-②: yes (narrowing) — `GET /api/v1/data/:object` (and every request that reaches the same list door: `POST /api/v1/data/:object/query`, the export route, the RPC dispatcher, the record-page `related[].sort`) and the stdio MCP `query_records` refuse a sort on a field whose author declared `sortable: false`, which they used to answer sorted by the column; a stored list view `sort` or `record:related_list` `sort` naming such a field is now refused when it is read. The widening half: `@objectstack/spec/api` exports `FIELD_UNSORTABLE_AUTHOR_DECLARED`, and `FieldSortabilitySchema.reason` accepts `'author-declared'` beside `'virtual-type'`.
+Metadata-protocol: narrowed
+Skills-docs: none — `skills/**` names no `sortable` field key, and `content/docs/**` already teaches `sortable: false` as "do not allow sorting by this field" and `INVALID_SORT` as "the field must exist and have `sortable: true`", which is what the platform now does. The prescription ships in the refusal text and the upgrade-guide entry.
+
+<!-- adr-0087: registered field-sortable-false-sort-refused -->
+
+**BREAKING** accept-set narrowing at the Data API list door (`@objectstack/metadata-protocol`) and the stdio MCP `query_records` (`@objectstack/mcp`): a sort on a field marked `sortable: false` is refused.
+
+- **Before.** An author who marked a field `sortable: false` (a long text, an unindexed column on a large table) got nothing for it. The sortability projection served on `GET /api/v1/meta/object/NAME` reported the field `{ sortable: true }`, so the list header and the Sort picker offered it, `GET /api/v1/data/NAME?sort=FIELD` answered 200 sorted by it, and so did the stdio MCP `query_records` with that `orderBy`.
+- **Now.** The projection reports `{ sortable: false, reason: 'author-declared' }` for that field, so the grid header and the Sort picker, which read the projection, stop offering it. The Data API judges the sort by the same projection and refuses it with `400 INVALID_SORT` before any read, the answer a sort on a `formula` field already gets; the stdio MCP `query_records` refuses it the same way before the engine runs. Only the literal `false` counts: a field with no `sortable` key, or with `sortable: true`, sorts as before. A `formula` field also marked `sortable: false` keeps its `reason: 'virtual-type'` answer.
+- **Stored sorts.** A list view whose `sort` names such a field, or a page `record:related_list` block whose `sort` does, used to load sorted and is now refused when it is read. Lint does not yet judge these at authoring. The upgrade-guide entry `field-sortable-false-sort-refused` lists them.
+- **Not changed.** In-process callers that reach `ObjectQL.find` directly (hooks, flows) keep sorting by the stored column: the engine door judges only whether a column is stored, and `sortable: false` governs what the platform offers callers, not what its storage can do.
+
+**The remedy.** Drop the sort on that field or sort by another one, in requests and in stored view and related-list sorts. An author who wants the field sortable removes `sortable: false` from it.
@@ -1471,7 +1471,7 @@ This schema accepts one of the following structures:
 
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
-| **fields** | `Record<string, { sortable: boolean; reason?: 'virtual-type'; caveat?: 'unprovisioned-anchor' }>` | ✅ | Verdict per sortable-addressable column, keyed by field name. The domain is the served field map plus the always-provisioned `id`, less any field the caller's own field permission withholds: a caller exempt from the object-schema mask (ADR-0106 D4) is served such fields in `item` and gets no entry for them; for every other caller the served map already excludes them. A name absent from this map (an unknown field, a dotted path, an unprovisioned audit column, a field the caller may not read) has no platform sort behind it and must get no sort affordance. |
+| **fields** | `Record<string, { sortable: boolean; reason?: Enum<'virtual-type' \| 'author-declared'>; caveat?: 'unprovisioned-anchor' }>` | ✅ | Verdict per sortable-addressable column, keyed by field name. The domain is the served field map plus the always-provisioned `id`, less any field the caller's own field permission withholds: a caller exempt from the object-schema mask (ADR-0106 D4) is served such fields in `item` and gets no entry for them; for every other caller the served map already excludes them. A name absent from this map (an unknown field, a dotted path, an unprovisioned audit column, a field the caller may not read) has no platform sort behind it and must get no sort affordance. |
 
 ### Nested Shape: `GetMetaItemResponse.registration[state='registered']`
 
 
@@ -35,8 +35,8 @@ records as deliberately rejected).
 "Unsortable" is judged by what the two runtime doors —
 `assertSortFieldsExist` (`@objectstack/metadata-protocol`, #6994) and
 `assertOrderByIsMaterializable` (`@objectstack/objectql`, #7095) — actually
-do with an `orderBy` over the name. Three verdicts are REFUSALS, and one
-measured degradation is not refused; the projection covers all four, and
+do with an `orderBy` over the name. Four verdicts are REFUSALS, and one
+measured degradation is not refused; the projection covers all five, and
 one more absence that is a fact about the CALLER, not the column (5.):
 
 1. **Unknown name** — not a field of the object. Refused (`400
@@ -51,10 +51,10 @@ one more absence that is a fact about the CALLER, not the column (5.):
 3. **Virtual type** (`isVirtualSearchField` / `SEARCH_VIRTUAL_TYPES`
    — exactly `formula` today) — computed on read, no driver materialises a
    column. Refused at both doors. Encoded as `sortable: false` with
-   `reason: 'virtual-type'`. This is the ONE per-field refusal fact, and it
-   is judged by the same spec predicate the linter
-   (`validate-sortable-fields`) and the search axis read — never by a local
-   type list.
+   `reason: 'virtual-type'`. This is the one per-field STORAGE refusal
+   fact (6. is the author's), and it is judged by the same spec predicate
+   the linter (`validate-sortable-fields`) and the search axis read — never
+   by a local type list.
 4. **Unprovisioned injected anchor** (`unprovisionedInjectedColumns`
    — the platform's own injected columns on an ADR-0015 `external` object,
    which registers them and provisions no storage). NOT refused: both doors
@@ -74,6 +74,23 @@ one more absence that is a fact about the CALLER, not the column (5.):
    `setup.access`), who IS served the field in `item.fields` because
    authoring needs the whole definition. For every other caller the mask
    has already removed the field from `item`, so this is case 1's absence.
+6. **Declared unsortable by its author** (`field.sortable: false`, #29896)
+   — a stored column the author chose not to offer as a sort (a long text,
+   an unindexed column on a large table). Refused at the INGRESS door
+   (`assertSortFieldsExist`: `400 INVALID_SORT`) and on the stdio MCP
+   `query_records` (`unofferedSortRefusal`, the same envelope), both of
+   which judge it by THIS projection rather than by a second reading of the
+   key. Encoded as
+   `sortable: false` with `reason: 'author-declared'`. Only the literal
+   `false` counts: a field with no `sortable` key (or `sortable: true`)
+   keeps its storage verdict. A virtual field marked `sortable: false`
+   keeps `reason: 'virtual-type'` — the storage fact is the stronger one.
+   The engine door (`assertOrderByIsMaterializable`) does NOT judge it: that
+   door answers "can a driver order by this column", and a stored column
+   can be ordered by, so an in-process caller (a hook, a flow) keeps sorting
+   by it. The key governs what the platform OFFERS — the list header, the
+   Sort picker, the Data API and the MCP tools — not what the storage can
+   do.
 
 ## Considered and deliberately NOT members
 
@@ -132,7 +149,7 @@ const result = FieldSortabilitySchema.parse(data);
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
 | **sortable** | `boolean` | ✅ | Whether the platform honors an ORDER BY over this field. `false` means the runtime REFUSES the sort (`400 INVALID_SORT`) — render no sort affordance. `true` means the sort is accepted; see `caveat` for the one accepted-but-degradable case. A derived verdict: do not recompute it from field `type` client-side. |
-| **reason** | `'virtual-type'` | optional | Present exactly when `sortable` is false: the field's type is virtual (computed on read, no stored column), so no driver materialises anything to ORDER BY. |
+| **reason** | `Enum<'virtual-type' \| 'author-declared'>` | optional | Present exactly when `sortable` is false, naming why. `virtual-type`: the field's type is virtual (computed on read, no stored column), so no driver materialises anything to ORDER BY. `author-declared`: the field declares `sortable: false`, so the Data API refuses a sort on it although a column is stored. |
 | **caveat** | `'unprovisioned-anchor'` | optional | Present only with `sortable: true`: the field is a platform-injected anchor on an ADR-0015 `external` object with no storage provisioned behind it. The runtime accepts the sort, but when the remote table carries no such column the ORDER BY is silently dropped (asc === desc under a 200). Consumers may choose a conservative affordance for these entries. |
 
 
@@ -144,14 +161,14 @@ const result = FieldSortabilitySchema.parse(data);
 
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
-| **fields** | `Record<string, { sortable: boolean; reason?: 'virtual-type'; caveat?: 'unprovisioned-anchor' }>` | ✅ | Verdict per sortable-addressable column, keyed by field name. The domain is the served field map plus the always-provisioned `id`, less any field the caller's own field permission withholds: a caller exempt from the object-schema mask (ADR-0106 D4) is served such fields in `item` and gets no entry for them; for every other caller the served map already excludes them. A name absent from this map (an unknown field, a dotted path, an unprovisioned audit column, a field the caller may not read) has no platform sort behind it and must get no sort affordance. |
+| **fields** | `Record<string, { sortable: boolean; reason?: Enum<'virtual-type' \| 'author-declared'>; caveat?: 'unprovisioned-anchor' }>` | ✅ | Verdict per sortable-addressable column, keyed by field name. The domain is the served field map plus the always-provisioned `id`, less any field the caller's own field permission withholds: a caller exempt from the object-schema mask (ADR-0106 D4) is served such fields in `item` and gets no entry for them; for every other caller the served map already excludes them. A name absent from this map (an unknown field, a dotted path, an unprovisioned audit column, a field the caller may not read) has no platform sort behind it and must get no sort affordance. |
 
 ### Nested Shape: `ObjectSortability.fields[string]`
 
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
 | **sortable** | `boolean` | ✅ | Whether the platform honors an ORDER BY over this field. `false` means the runtime REFUSES the sort (`400 INVALID_SORT`) — render no sort affordance. `true` means the sort is accepted; see `caveat` for the one accepted-but-degradable case. A derived verdict: do not recompute it from field `type` client-side. |
-| **reason** | `'virtual-type'` | optional | Present exactly when `sortable` is false: the field's type is virtual (computed on read, no stored column), so no driver materialises anything to ORDER BY. |
+| **reason** | `Enum<'virtual-type' \| 'author-declared'>` | optional | Present exactly when `sortable` is false, naming why. `virtual-type`: the field's type is virtual (computed on read, no stored column), so no driver materialises anything to ORDER BY. `author-declared`: the field declares `sortable: false`, so the Data API refuses a sort on it although a column is stored. |
 | **caveat** | `'unprovisioned-anchor'` | optional | Present only with `sortable: true`: the field is a platform-injected anchor on an ADR-0015 `external` object with no storage provisioned behind it. The runtime accepts the sort, but when the remote table carries no such column the ORDER BY is silently dropped (asc === desc under a 200). Consumers may choose a conservative affordance for these entries. |
 
 
 
@@ -0,0 +1,104 @@
+// Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
+
+/**
+ * [#29896] The stdio data bridge's `query` refuses a sort on a field whose
+ * author declared `sortable: false` with the Data API list door's
+ * `400 INVALID_SORT`, before the engine runs anything. This transport hands
+ * `orderBy` straight to `engine.find`, which judges only whether a column is
+ * stored, so the stdio `query_records` was the one public door that still
+ * sorted by such a field. The verdict is the served sortability projection's
+ * (`resolveObjectSortability`), over the object `describe_object` serves.
+ *
+ * Controls: a field with no `sortable` key, a field with `sortable: true`, and
+ * a query with no sort reach the engine unchanged. Refusals are asserted on the
+ * envelope, never on a bare throw; the harness is the stand-in engine of
+ * `stdio-data-bridge.internal-field-evaluation.test.ts`.
+ */
+
+import { describe, it, expect, vi } from 'vitest';
+import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
+import { Client } from '@modelcontextprotocol/sdk/client/index.js';
+import { InMemoryTransport } from '@modelcontextprotocol/sdk/inMemory.js';
+import type { ExecutionContext } from '@objectstack/spec/kernel';
+import type { IDataEngine, IMetadataService } from '@objectstack/spec/contracts';
+import { createStdioDataBridge } from './stdio-data-bridge.js';
+import { registerObjectTools } from './mcp-http-tools.js';
+
+const OBJECT = 'sfx_note';
+const DEF = {
+  name: OBJECT,
+  fields: {
+    name: { type: 'text' },
+    nosort: { type: 'textarea', sortable: false },
+    rank: { type: 'number', sortable: true },
+  },
+};
+
+const PRINCIPAL = { userId: 'u1', isSystem: false } as unknown as ExecutionContext;
+
+function makeBridge() {
+  const engine = {
+    find: vi.fn(async (_object: string, _query: unknown) => [{ id: 'r1', name: 'alpha' }]),
+  };
+  const metadataService = { getObject: vi.fn(async (name: string) => (name === OBJECT ? DEF : undefined)) };
+  const bridge = createStdioDataBridge({
+    engine: engine as unknown as IDataEngine,
+    metadataService: metadataService as unknown as IMetadataService,
+    resolvePrincipal: async () => PRINCIPAL,
+  });
+  return { bridge, engine };
+}
+
+const refusalOf = async (run: () => Promise<unknown>) => {
+  const err: any = await run().then(() => undefined, (e: unknown) => e);
+  expect(err, 'the call resolved: the sort refusal did not reach the caller').toBeDefined();
+  return { code: err.code, status: err.status, field: err.field, object: err.object, param: err.param };
+};
+const REFUSED = { code: 'INVALID_SORT', status: 400, field: 'nosort', object: OBJECT, param: 'orderBy' };
+
+describe('[#29896] stdio query: a sort on a `sortable: false` field is refused before the engine', () => {
+  it('refuses the sort, alone or behind a sortable one, and never calls the engine', async () => {
+    const { bridge, engine } = makeBridge();
+    for (const orderBy of [
+      [{ field: 'nosort', order: 'asc' as const }],
+      [{ field: 'name', order: 'asc' as const }, { field: 'nosort', order: 'desc' as const }],
+    ]) {
+      expect(await refusalOf(() => bridge.query(OBJECT, { orderBy }))).toEqual(REFUSED);
+    }
+    expect(engine.find).not.toHaveBeenCalled();
+  });
+
+  it('CONTROL — no `sortable` key, `sortable: true` and no sort at all reach the engine unchanged', async () => {
+    const { bridge, engine } = makeBridge();
+    const orderBy = [{ field: 'name', order: 'asc' as const }, { field: 'rank', order: 'desc' as const }];
+    await bridge.query(OBJECT, { orderBy, limit: 5 });
+    expect(engine.find).toHaveBeenCalledTimes(1);
+    expect(engine.find.mock.calls[0]![1]).toMatchObject({ orderBy, limit: 5 });
+    // A filter on the field is not a sort: `sortable: false` governs ordering only.
+    await bridge.query(OBJECT, { where: { nosort: 'x' } });
+    expect(engine.find).toHaveBeenCalledTimes(2);
+  });
+
+  it('query_records renders the refusal as its envelope', async () => {
+    const { bridge, engine } = makeBridge();
+    const server = new McpServer({ name: 'pin', version: '0' });
+    registerObjectTools(server, bridge);
+    const [clientSide, serverSide] = InMemoryTransport.createLinkedPair();
+    await server.connect(serverSide);
+    const client = new Client({ name: 'pin', version: '0' });
+    await client.connect(clientSide);
+    try {
+      const res = (await client.callTool({
+        name: 'query_records',
+        arguments: { objectName: OBJECT, orderBy: [{ field: 'nosort', order: 'asc' }] },
+      })) as { isError?: boolean; content: Array<{ text: string }> };
+      expect(res.isError).toBe(true);
+      const { error } = JSON.parse(res.content[0]!.text) as { error: { code: unknown; status: unknown; message: string } };
+      expect({ code: error.code, status: error.status }).toEqual({ code: 'INVALID_SORT', status: 400 });
+      expect(error.message).toContain("'nosort'");
+      expect(engine.find).not.toHaveBeenCalled();
+    } finally {
+      await client.close();
+    }
+  });
+});