@@ -0,0 +1,22 @@
+---
+'@objectstack/lint': minor
+'@objectstack/spec': minor
+---
+
+fix(lint)!: a stored sort naming a field that declares `sortable: false` is refused by `os validate` and at publish, judged by the same sortability projection the Data API list door refuses it by — on a list view and on every stored page sort (#30023)
+
+Clause-②: yes (narrowing) — `sort-field-unsortable` (error) now also fires on a sort naming a field whose author declared `sortable: false`, on the list-view rungs it already walked and on every stored page sort it did not walk before (a block's own `sort`, every element `dataSource.sort`, a related list's `parentDataSource.sort`, a list page's `interfaceConfig.sort`, an app page's `record.sort`, where a `formula` sort is now refused too), so `os validate` / `os build` / `os lint` and the `page` and `view` publish doors refuse metadata they used to accept. The widening half: `@objectstack/lint` exports `indexObjectSortability` and the `SortabilityFields` type, and `checkSortDeclaration` takes an optional trailing `sortability` index.
+Metadata-protocol: narrowed
+Skills-docs: none — `skills/**` names no `sortable` field key and no page or view `sort` rule; `content/docs/**` already teaches `sortable: false` as "do not allow sorting by this field". The prescription ships in the finding's fix line, `os explain sort-field-unsortable` and the upgrade-guide entry.
+
+<!-- adr-0087: not-required (already-registered field-sortable-false-sort-refused) the entry already prescribes this change: it names the stored sorts this rule now judges and, from this release, names `os validate` and the publish door as where an affected view or page surfaces; its surface and acceptance criteria are widened here to every stored page sort -->
+
+**BREAKING** accept-set narrowing at authoring (`@objectstack/lint`): a stored sort the Data API list door refuses is refused before it is stored.
+
+- **Before.** A list view whose `sort` named a field marked `sortable: false` passed `os validate` and the `PUT /api/v1/meta/view` door, then answered `400 INVALID_SORT` on its first fetch and on every fetch after it. No page sort was judged for sortability at all: a `record:related_list`, `record:line_items`, `list-view` or `object-*` block sorting by such a field (or by a `formula` field), an element `dataSource.sort`, a related list's `parentDataSource.sort`, a list page's `interfaceConfig.sort` and an app page's `record.sort` all saved green and failed at read.
+- **Now.** `validateSortableFields` judges each of those positions by `resolveObjectSortability`, the projection the list door refuses by, and reports `sort-field-unsortable` at `error` with the door's own clause ("a field on object X that declares `sortable: false`") at the slot's path. The reference-integrity suite now runs on a `page` write for this one member, so the Studio, REST `/meta` and MCP page doors give the same refusal (422). Only the literal `false` counts: a field with no `sortable` key, or `sortable: true`, sorts as before. A `formula` field also marked `sortable: false` keeps its virtual-field verdict. Existence on page sorts stays `page-field-unknown`.
+- **Not changed.** A stored view or page already carrying such a sort keeps loading and serving; only its next save is judged, and its first fetch still answers 400 as it did since the list door started refusing it.
+
+**The remedy.** Sort by another field, or remove `sortable: false` from the field to make it sortable.
+
+**Supersedes, in the same release.** The `@objectstack/spec` / `@objectstack/metadata-protocol` / `@objectstack/mcp` note for #29896 says "Lint does not yet judge these at authoring." From this release it does: `os validate` and the publish doors refuse every stored sort that note lists, and the stored page sorts it did not list.
@@ -1249,8 +1249,13 @@ export const AUTHORING_RULES: readonly AuthoringRule[] = [
     // tier 1 («the parsers load NEVER») from a standing fact into a red. The
     // measurement that named their bridge named `validateStackExpressions`, a
     // CEL-only rule, for exactly this reason.
+    // [#30023] `page` joins, NARROW by the same mechanism: a page write reaches
+    // exactly `validateSortableFields`, the one member that declares `page`,
+    // so a stored page sort naming a field the list door refuses
+    // (`sortable: false`, a `formula`) is refused at publish rather than at
+    // its first fetch. Every other member keeps its declaration.
     surfaces: CLI_AND_RUNTIME,
-    runtimeTypes: ['flow', 'view', 'object', 'dataset', 'report'],
+    runtimeTypes: ['flow', 'view', 'object', 'dataset', 'report', 'page'],
     run: (stack, ctx) => validateReferenceIntegrity(stack, ctx),
   },
   // ADR-0078 / #5068 — the SDUI component-props gate. `PageComponent.properties`
 
@@ -521,16 +521,21 @@ export type {
 // ingress, `assertOrderByIsMaterializable` #7095 in the engine); this is the
 // authoring-time half, which is what makes the refusal traceable back to the
 // declaration that caused it.
+// [#30023] `indexObjectSortability` builds the optional trailing argument of
+// `checkSortDeclaration` that answers the author-declared verdict
+// (`sortable: false`), so an out-of-repo caller of the core can pass it.
 export {
   validateSortableFields,
   checkSortDeclaration,
+  indexObjectSortability,
   SORT_FIELD_UNKNOWN,
   SORT_FIELD_UNSORTABLE,
   SORT_FIELD_UNPROVISIONED,
 } from './validate-sortable-fields.js';
 export type {
   SortableFieldFinding,
   SortableFieldSeverity,
+  SortabilityFields,
 } from './validate-sortable-fields.js';
 
 // [#14107] The rest of the list view's field surface — the two rules above own
 
@@ -282,7 +282,16 @@ export const REFERENCE_INTEGRITY_RULES: readonly ReferenceIntegrityRule[] = [
   // `assertSortFieldsExist` (#6994) and `assertOrderByIsMaterializable` (#7095)
   // both answer `400 INVALID_SORT` — and a view's sort is its FIRST fetch, so
   // the refusal is the whole view, on every load, traced to nothing.
-  { name: 'validateSortableFields', runtimeTypes: ['flow', 'view'], run: validateSortableFields },
+  //
+  // [#30023] `page` joins: since the projection's `author-declared` verdict
+  // the member also walks every stored PAGE sort (element `dataSource.sort`, a
+  // block's own `sort`, `interfaceConfig.sort`, `record.sort`) and judges it
+  // by the sortability projection alone. It resolves only against
+  // `stack.objects`, which the per-write page snapshot carries, so it has no
+  // missing-collection false-positive channel — the #9313 reason, one write
+  // type over. It is the only member that declares `page`, so a page write
+  // dispatches nothing else from this suite.
+  { name: 'validateSortableFields', runtimeTypes: ['flow', 'view', 'page'], run: validateSortableFields },
   // [#14107] The REST of the same list view's field surface. The two members
   // above own `sort` and `searchableFields`; every OTHER field-naming position
   // on a list view — `columns`, filter keys, `grouping`, `rowColor`,
 
@@ -2479,14 +2479,21 @@ const SORT_FIELD_UNKNOWN_EXPLANATION: RuleExplanation = {
 
 const SORT_FIELD_UNSORTABLE_EXPLANATION: RuleExplanation = {
   rule: 'sort-field-unsortable',
-  covers: 'why a formula field cannot be sorted by',
+  covers: 'why a formula or `sortable: false` field cannot sort',
   paragraphs: [
     VIRTUAL_FIELD_STORAGE,
     'Measured before the runtime refused it: an ORDER BY over a formula returned \'asc\' and \'desc\' ' +
       'in byte-identical row order, carrying the very values it was asked to order by, unordered, ' +
       'under a success. Both runtime doors now refuse it with `400 INVALID_SORT` — the REST ingress ' +
       '(`assertSortFieldsExist`) and the engine (`assertOrderByIsMaterializable`) — so the declaration ' +
       'breaks the view\'s first fetch, and every fetch after it.',
+    'A stored field whose author declared `sortable: false` is refused the same way at the REST ingress ' +
+      '(`400 INVALID_SORT`, "a field that declares `sortable: false`"), though a column stands behind it: ' +
+      'the key says what the platform offers, so the list header and the Sort picker do not offer it and ' +
+      'the Data API does not perform it. Both verdicts are the served sortability projection\'s ' +
+      '`sortable: false`, which this rule reads, so it and the door agree. A list view\'s sort and every ' +
+      'stored page sort (a block\'s `sort` or `dataSource.sort`, a list page\'s `interfaceConfig.sort`, an ' +
+      'app page\'s `record.sort`) are judged. Sort by another field, or remove `sortable: false`.',
     LIST_VIEW_FIELD_SKIPS,
   ],
 };
 
@@ -138,6 +138,9 @@ describe('#24491 — the page door gives the build\'s visibility-predicate verdi
       // slots (warnings only); first because it is the registry's first rule.
       'validateStackExpressions',
       'validatePresetComparands',
+      // #30023 — the reference-integrity suite, for its one `page` member
+      // (`validateSortableFields`: a stored page sort the list door refuses).
+      'validateReferenceIntegrity',
       'validateComponentProps',
       'validateComponentTypes',
       'validatePrintPageBlocks',