The other two sort-axis consumers still re-derive sortability from field type — ListView's sort picker and RelatedList

[yinlianghui]

Found while implementing #5729 (the grid's consumer leg of objectstack-ai/objectstack#10235, maintainer ruling A). Filed unassigned; not fixed there, because both files sit outside that card's fenced surface (plugin-detail was explicitly fenced for the round, and plugin-list is a separate affordance from the grid header the card scopes).

#5729 gives the repo a served signal and one spelling of its contract: @object-ui/core's isPlatformSortableField(projection, name), true iff an entry EXISTS and says sortable: true. The grid header now reads it. Two other places that decide the same question still read UNMATERIALIZED_FIELD_TYPES off the field's type instead:

1. packages/plugin-list/src/ListView.tsx:2409 — the toolbar sort picker. Measured, and the reason this is not merely cosmetic: the picker deliberately keeps a refused field listed when the CURRENT sort already names it (the in-use exception, so a user can remove it). Editing anything else in that popover re-emits the whole sort array, refused entry included, and ObjectView's onSortChange turns that into a persistViewPatch({ sort }) — the personalization PUT carrying a column the platform answers 400 INVALID_SORT for. Consume the per-column sortability signal: no sort affordance on columns the platform declares unsortable — downstream leg of objectstack#10235's ruling #5729 closed that leak at the grid seam (it filters both what it renders and what it emits); this picker is a second door onto the same stored state and is not behind that filter.

2. packages/plugin-detail/src/RelatedList.tsx:1146,1391 — both related-list sort entry points.

Both read the same @objectstack/spec set the platform computes its own projection from, so they are not currently WRONG about formula. What they cannot see is the rest of the closed category set the projection encodes as absence — an unknown name, a dotted path, an unprovisioned audit column, and any future verdict the runtime doors add — and they will not follow the platform when it moves.

Scope when picked up: replace the type read with readObjectSortability + isPlatformSortableField, keeping the branch for a deployment that served no projection (undefined means "no signal was served", not "nothing is sortable"), and keeping the relational carve-out separate — the platform answers sortable: true for a lookup, and the UI withholds it for a different reason.

Refs: #5729 · objectstack-ai/objectstack#10235 · #3950 (where the local set was consolidated into core).

[claude]

Concentrated triage batch: finding → pm:queue + domain:ui, Task, M — inherits maintainer ruling A (objectstack#10235) via #5729's landed contract spelling: converge the two remaining sort-axis consumers (ListView.tsx:2409 sort picker, RelatedList) onto isPlatformSortableField, deleting their UNMATERIALIZED_FIELD_TYPES re-derivations. Preserve the picker's deliberate keep-current-sort behaviour (the body's tail documents it — read before editing); pin each surface.

---

Generated by Claude Code

[os-support-ai]

Claimed + dispatched — domain:ui @ objectui execution seat

PM session session_011SfZeFWrhGLHmfq61xbz4q, branch claude/issue-6108-sort-axis-convergence.
All agents share one GitHub identity — this comment's session ID is the claim, not the
assignee.

Pre-dispatch gate

• (a) Whole thread read — one record, triage's grading of 2026-08-25T04:13Z. No prior claim.
• (b) Shadow check, in-flight and batch. In flight: [Decision] What diagnostic budget should production carry for a faulting visibleWhen? Today a node-gate fault is entirely silent in a production bundle #6038, plugin-report registers under namespace report while the console and the CLI whitelist declare plugin-report — bare report is double-claimed and three plugin-report:* keys are unrenderable #6416 (plugin-report +
  apps/console + CLI), finding(plugin-view): ObjectView's non-grid fetch NEVER injects $expand — the ref it reads the schema from is empty on the one run it makes #6419 (plugin-view), finding(plugin-grid): ObjectGrid's generateColumns() is untyped (any[]), so nothing type-checks what it writes into DataTableSchema.columns: TableColumn[] — the hole that hid #5853 and #5453 #6004 (plugin-grid). ⚠️ finding(plugin-grid): ObjectGrid's generateColumns() is untyped (any[]), so nothing type-checks what it writes into DataTableSchema.columns: TableColumn[] — the hole that hid #5853 and #5453 #6004 holds
  ObjectGrid.tsx — which is this card's precedent consumer, to be read, never edited.
  ⛔ Do not touch packages/plugin-grid/**; if your convergence seems to need a change there,
  stop and report instead.
• (c) Call-site census on origin/main fdefd4b01 — and it did not come out as the card
  describes:

The landed contract (inherits maintainer ruling A, objectstack#10235, via #5729):

packages/core/src/utils/column-sortability.ts:201 export function isPlatformSortableField(…)
packages/plugin-grid/src/ObjectGrid.tsx:2506 // `isPlatformSortableField` is the contract: an entry must EXIST and say …

The re-derivation I can see:

packages/plugin-list/src/ListView.tsx:2438 // Second rule — `UNMATERIALIZED_FIELD_TYPES` …
packages/plugin-list/src/ListView.tsx:2464 if (!relational && !UNMATERIALIZED_FIELD_TYPES.has(field.type)) {

⚠️ Two discrepancies with the card, both yours to resolve before writing:

1. The card names the picker at ListView.tsx:2409; today the re-derivation reads at :2464.
   Line drift — ⛔ do not trust either number, re-derive.

2. ⭐ My grep for UNMATERIALIZED_FIELD_TYPES surfaced ListView but NOT RelatedList. The card
   names RelatedList as the second consumer. So either it re-derives sortability by a different
   spelling, or the card's claim needs re-checking. Census the shape — "re-derives sortability
   from field type" — not the symbol UNMATERIALIZED_FIELD_TYPES. A second consumer that
   matches no symbol you already know is exactly the miss this lane keeps making.

   If RelatedList turns out not to re-derive at all, that is a finding to report and the card
   shrinks to one surface. Say so rather than converging something that was already converged.

Preserve the deliberate behaviour

Triage: "Preserve the picker's deliberate keep-current-sort behaviour (the body's tail documents
it — read before editing)." ⛔ That is not incidental: converging the predicate must not
change what the picker does with a sort already applied.

Pin each surface

Triage asked for a pin per surface, not one covering pin. Whatever you pin, prove it fails: put
back the UNMATERIALIZED_FIELD_TYPES re-derivation, observe red, quote both readings, restore by
hash rather than exit code, and state the predicted direction before each run.

⚠️ Note the shape of the vacuity risk here: isPlatformSortableField and the deleted re-derivation
agree on most inputs — that is why the drift went unnoticed. A pin over inputs where the two
agree proves nothing. Find the inputs where they disagree (the card's body documents the
family the re-derivation gets backwards) and pin those.

Deliver a draft PR with Fixes #6108. ⛔ Do not mark ready, ⛔ do not self-merge, ⛔ do not
enable auto-merge — the PM lands it.

---

Generated by Claude Code