fix(lint)!: the object publish door refuses an object whose own list view sorts by a field the list door refuses (#30095) - #30564

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 528469b486d1eab995ff7bcb7830494fd9fe4cf7 && git checkout 528469b486d1eab995ff7bcb7830494fd9fe4cf7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 38d416f1145c2dafbe39f00ecfcbc551dc438bbb 0e5a281c235dbae3c55dbd09b15f8ec394dffb71 && git checkout -B drift-repro 38d416f1145c2dafbe39f00ecfcbc551dc438bbb && git merge --no-ff 0e5a281c235dbae3c55dbd09b15f8ec394dffb71

node scripts/docs-audit/affected-docs.mjs --json 38d416f1145c2dafbe39f00ecfcbc551dc438bbb

domain:server#3 · os-bill · session_01Utp6CbPxYq1wQmUNWvMZkC

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 0e5a281c235dbae3c55dbd09b15f8ec394dffb71
Local-runs: probe — in a throwaway worktree at the head (pnpm install, turbo run build --filter=@objectstack/lint... --filter=@objectstack/metadata-protocol...): vitest run src/runtime-gate.object-writes.test.ts (41/41), vitest run src/protocol.runtime-authoring-gate.test.ts -t 30095 (3 passed, 248 skipped), a reviewer census of every *.object.ts through validateSortableFields (see ①.3), the ablation re-run (member object removed, lint rebuilt: door suite 2 failed / 1 passed, lint pin 4 failed / 37 passed; restored, rebuilt, 3/3 and ["flow","view","page","object"] in dist/index.js and dist/runtime.js), check-adr-0087-registration.mjs --base origin/main exit 0 and check-changeset-no-major.mjs --base origin/main exit 0; worktree removed afterwards.
Scope: packages/lint/src/reference-integrity-suite.ts, packages/lint/src/runtime-gate.object-writes.test.ts, packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts + packages/lint/src/validate-sortable-fields.ts (validateSortableFields, checkSortDeclaration, unsortableFinding, indexObjectSortability), packages/lint/src/reference-integrity-suite.ts (validateReferenceIntegrity dispatch, DEFAULT_MEMBER_RUNTIME_TYPES, the #15254 / #15495 / #14107 member notes), packages/lint/src/authoring-rules.ts (the validateReferenceIntegrity entry, runtimeTypes at line 1259), packages/lint/src/runtime-gate.ts (D4 differential), packages/lint/src/validate-searchable-fields.ts (indexObjectSearchTargets), .changeset/30095-object-list-view-sort-door.md (prose face, read for its declaration lines and marker), content/docs/deployment/validating-metadata.mdx, content/docs/references/api/sortability.mdx, skills/objectstack-ui/rules/list-views.md, .github/workflows/ci.yml (dogfood job condition)

Face: narrowing (Clause-②: no (narrowing) line-initial on the PR body and the changeset). record-recognisers.mjs --paths on the four changed paths decides no schema or governed face, so the narrowing face alone sets the tier; the Scope floor is every path of the diff outside the prose faces. Review by an isolated reader of PR #30564 (card #30095, precedent PR #30270 / card #30093, records 6649790600 and 6650369794). Reads: the card body, the PR body, the dev report (comment 6662809673, read for its claims only), git diff c045c341..0e5a281c (4 files, +176/−4; base c045c341 is the #30270 merge; git merge-tree against origin/main at a4c3e738 merges clean, the only origin/main drift on cited files being #30231's runtime-gate.ts dataset-context hunk and a six-line validating-metadata.mdx paragraph on the same), the files in Scope: at this head, the head's check-runs via REST (three readings, last at 2026-11-05T16:22Z). No reading below comes from the dev's self-report; where the report's number is quoted it is beside my own.

① Derived judgments

1. What the object publish door newly refuses (saveMetaItem for type: 'object' going state: 'active', and the draft→active promotion; Studio, PUT /api/v1/meta/object/NAME, MCP). With object in the member's runtimeTypes, validateReferenceIntegrity (writeType === 'object') now runs validateSortableFields on the per-write snapshot, whose first rung walks objects[].listViews.*.sort and resolves each key against the list view's data.object retarget or its own object. Three verdicts, all error and therefore refused 422 INVALID_METADATA with nothing stored: (a) a sort key naming a field that declares sortable: false → sort-field-unsortable (author-declared, via resolveObjectSortability, the same projection the list door refuses by); (b) a sort key naming a virtual formula field → sort-field-unsortable (virtual-type); (c) a sort key whose head segment is neither a declared field nor a SYSTEM_FIELDS name → sort-field-unknown — unknown names are refused too, dotted paths included ('sort' reaches only … own columns hint), exactly as the card's title under-states ("sortable:false") and the PR body states. Not refused: a sort-field-unprovisioned finding on an injected anchor (warning, advisory, not gating); a list view retargeted to an object the snapshot does not carry or an external/introspected object (fieldsByObject miss → silent, the [finding] Both field-resolution gates for a list view (searchableFields and sort) are CLI-only — the reference-integrity suite dispatches at the runtime publish gate for flow alone, so a Studio/MCP view write gets neither #9313 missing-collection channel stays closed); a ?mode=draft save (never gated, unchanged). Right, and the PR body's and changeset's description of the refused set is exact.
2. The CLI already refused all of it. validateReferenceIntegrity skips a member only when options.runtimeWriteType is set (reference-integrity-suite.ts, the writeType !== undefined && …continue guard); os validate / os build / os lint pass none, so every member — this one included — has run on an object's listViews.*.sort since A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257 (existence, virtuality) and on sortable: false since fix(lint)!: refuse a stored sort on a sortable: false field, on list views and every stored page sort #30084 (merged 3a272086). The view and page doors already dispatched the member ([finding] Both field-resolution gates for a list view (searchableFields and sort) are CLI-only — the reference-integrity suite dispatches at the runtime publish gate for flow alone, so a Studio/MCP view write gets neither #9313, lint: a view sort naming a field the author declared sortable: false clears validate, then 400s on every load once #29896 lands — validate-sortable-fields judges only the virtual predicate #30023). Right: nothing moves at the CLI; the object door catches up to the verdict the other three doors give.
3. Census (reviewer's own, through validateSortableFields({ objects }) with every object as context, at the head): 122 *.object.ts under packages/ and examples/; 126 objects loaded (one file, packages/plugins/plugin-audit/src/objects/sys-activity.object.ts, did not import in my partial build and was read by hand: its two list views both sort timestamp, a declared Field.datetime, so 127 objects in all, matching the dev's count); 44 objects carry 100 built-in list views with 111 sort keys (+1/+2/+2 from the hand-read file = the dev's 45 / 102 / 113); 0 findings. Synthetic probe (a list view sorting by a sortable: false field) draws error:sort-field-unsortable, so the zero is non-vacuous. grep corroboration: no *.object.ts under packages/ or examples/ declares sortable: false, and no object file with a formula field also carries a sort:; packages/qa and examples hold no inline sortable: false fixture outside tests. No object in the repo or its examples is newly refused.
4. Public surface. No export is added, removed or retyped in @objectstack/lint; REFERENCE_INTEGRITY_RULES changes one member's runtimeTypes value. @objectstack/lint publishes dist (private unset), so a changeset is owed and present. @objectstack/metadata-protocol is touched only in a test file (files: ["dist", …] ships none of it), so no changeset is owed there — the same reading the fix(lint)!: refuse a stored page sort naming an unknown field, on every page sort slot (#30093) #30270 record made. Right.
5. Snapshot safety. The member resolves only against stack.objects (indexObjectSearchTargets, indexObjectSortability), the collection every per-write snapshot carries; its views[] and pages[] rungs read stack.views / stack.pages behind Array.isArray guards, so on an object snapshot they contribute nothing. The gate's differential ([runtime/metadata] 作者时规则只存在于 CLI:Studio/REST/MCP 的运行时授权面是第四扇门,26 条规则一条不跑——#4409 修完后最大的敞口 #4463 D4, structural in runtime-gate.ts) keeps a stored sibling's violation off this write. The authoring-rules.ts entry already names object (line 1259), so no entry edit is owed — right, authoring-rules.ts untouched is correct.
6. Tests. runtime-gate.object-writes.test.ts: the crossed roster pin now lists validateSortableFields (the former not.toContain assertion and its "this pin is where the adjudication has to be made" note are removed, which is the adjudication being made); three refusals through runRuntimeAuthoringRules at objects.leave_request.listViews.inbox.sort[0] with rule and message asserted; CONTROL publishes on a field with no sortable key and on sortable: true, and asserts rulesRun contains validateReferenceIntegrity (non-vacuity). protocol.runtime-authoring-gate.test.ts lint: the object publish door does not run validateSortableFields, so an object whose listViews sort a sortable:false field saves #30095 describe goes through the real protocol.saveMetaItem({ type: 'object' … }) route: status 422, code INVALID_METADATA, rule / severity / path / message, rulesRun, and no active row; the unknown-name case the same way; CONTROL saves one row. code and status are both asserted (ADR-0112 envelope). Ablation reproduced by me (Local-runs). Right.
7. Declarations (PR body and changeset, both line-initial): Clause-②: no (narrowing) — right: an accept set at a published door narrows, nothing widens. Metadata-protocol: none — right, ruling in ③. Skills-docs: none — REASON — right, reading in ③. Title carries !, changeset carries the BREAKING banner, one ADR-0087 marker not-required (no-migration-prescription): the gate accepts it (exit 0, see Local-runs) and its reason is true at this head — no schema key moves, and a refused sort never ordered a row (the list door answered 400 INVALID_SORT on every load, pinned by packages/rest/src/data-sort-field-sortable-flag-door.test.ts field.sortable: false has no effect — the sortability projection still reports the field sortable, the data door sorts by it, and the list header and Sort picker offer it #29896), so no FROM → TO rewrite exists to prescribe. Observation, no action: fix(lint)!: refuse a stored sort on a sortable: false field, on list views and every stored page sort #30084 cited the registered entry field-sortable-false-sort-refused for the same value; either not-required reading is defensible here.
8. Card closure. Fixes #30095 is right: the card's three asks (member declares object with its own rollout decision; refusal pinned through the real object publish route; the lint suite member pin in the same PR) are all in this diff. First body line references the card; target main; draft; head repo = base repo.

② Semver level

@objectstack/lint: patch, fix(lint)!: title, BREAKING banner, both declaration lines and one ADR-0087 marker in the body — consistent with AGENTS.md Post-Task Checklist step 3 under Metadata-protocol: none: "a non-protocol change, widening or breaking, ships patch and keeps its BREAKING banner and ADR-0087 disposition"; check-changeset-no-major.mjs ruling A text says the same ("A non-protocol … narrowing … ships patch and keeps its BREAKING banner"). Were the line narrowed, minor would be owed instead — the dependency the dev's open question names, decided in ③. Check Changeset succeeded on this head; the two local changeset gates exit 0.

③ Boundary flags

• Open question — Metadata-protocol: none vs narrowed: none, option A, stands. AGENTS.md step 3 defines the line as "the change to what a metadata author can write"; ruling A in check-changeset-no-major.mjs separates it from Clause-②, which keeps "does this diff widen or narrow a published accept set" and loses level coupling. What an author can write is defined once, by the one rule table (AUTHORING_RULES) that validating-metadata.mdx says all four doors run and that "the fourth door is held to the CLI's verdicts" against. That table already refused every one of these three sorts at error: existence and virtuality since A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257, sortable: false since fix(lint)!: refuse a stored sort on a sortable: false field, on list views and every stored page sort #30084 — whose changeset declared narrowed and shipped minor for exactly that protocol move. This PR moves no CLI verdict, adds or refuses no key or value the table did not already refuse, and changes no authorable-surface shard; it makes one door enforce what the protocol already declared (Prime Directive chore: version packages #10, declared ≠ enforced). The fix(lint)!: refuse a stored page sort naming an unknown field, on every page sort slot (#30093) #30270 precedent declared narrowed, and its record called that right, because there the CLI verdict itself moved (silent / warning → error on five page sort slot families) — the protocol narrowed, not only a door. That distinction is the whole difference; declaring narrowed here would count the fix(lint)!: refuse a stored sort on a sortable: false field, on list views and every stored page sort #30084 protocol move twice and lift @objectstack/lint a minor the protocol did not earn, the half of ruling A "with teeth". So: none, patch, and the (narrowing) arm plus the BREAKING banner carry the door's accept-set narrowing, as the gate's own rationale prescribes. The PR body's acceptance note already states this reasoning; no edit owed.
• Skills-docs: none — REASON is true. skills/**: skills/objectstack-ui/rules/list-views.md teaches sortable only as a column option ("Allow sorting") and names no door verdict; nothing there becomes false. content/docs/deployment/validating-metadata.mdx: the only sort sentences are §5's page-sort paragraph (fix(lint)!: refuse a stored page sort naming an unknown field, on every page sort slot (#30093) #30270's, about the page door, still true) and the four-doors table, which has rows per rule family and no row for the sort / search / list-view field members at all (pre-existing, noted by the fix(lint)!: refuse a stored page sort naming an unknown field, on every page sort slot (#30093) #30270 record as "not made false here"); its "Flow reference integrity" row shows ✓ᶠ while the entry's runtimeTypes has been ['flow','view','object','dataset','report','page'] since [finding] Both field-resolution gates for a list view (searchableFields and sort) are CLI-only — the reference-integrity suite dispatches at the runtime publish gate for flow alone, so a Studio/MCP view write gets neither #9313 / [P0] Studio package publish accepts a dangling highlightFields reference — the authoring gate never sees what the app builder produces #15254 / [rebuild of #19474] spec(lint): wire the inert runtime-create rules for action / hook / report / skill / email_template / mapping — six types, one edit (ruling #203/4 group A+C) #19542 / lint: a view sort naming a field the author declared sortable: false clears validate, then 400s on every load once #29896 lands — validate-sortable-fields judges only the virtual predicate #30023 — stale before this PR and not made false by it (object was already in the entry). content/docs/references/api/sortability.mdx names "the linter (validate-sortable-fields)" without a door list. No doc sentence says the object door does not judge a list-view sort, so there is no sentence to correct; the object door therefore does not need naming for this PR to be true. Should-fix S1 (not blocking, card owed by the lane seat): the four-doors table's reference-integrity row (✓ᶠ) contradicts the legend's own authority clause ("that rule's own runtimeTypes in AUTHORING_RULES is the authority") and now under-reports six write types; a docs-only card to re-spell that row, and to give the three list-view members a row, is the right vehicle — not this PR.
• [P0] Studio package publish accepts a dangling highlightFields reference — the authoring gate never sees what the app builder produces #15254 rollout note followed. The suite's note (the ReferenceIntegrityRule.runtimeTypes docblock and the [P0] Studio package publish accepts a dangling highlightFields reference — the authoring gate never sees what the app builder produces #15254 / The object write door still runs no field-existence rule for searchableFields or listViews — the same asymmetry #15254 closed one key over #15495 member notes) asks for: an explicit declaration on the member, a false-positive measurement over the shipped object corpus through the door's own shape, a synthetic probe showing the zero is about the corpus and not the rule, the crossing pinned by name in the crossed roster of runtime-gate.object-writes.test.ts, and the population recorded in the member note. All five are in the diff: the member note records 127 objects / 102 list views / 113 sort keys / 0 findings (my census agrees, ①.3), the probe is the three refusals plus the CONTROL, and the roster pin moves validateSortableFields from "not crossed, adjudication pending" to crossed. The validateListViewFieldRefs note that held the member back gains the one-line "that adjudication is made" cross-reference. Followed.
• Pins go through the real object publish route (protocol.saveMetaItem, type: 'object') — yes, ①.6; ablation recorded in the PR body and the dev report, and reproduced here with the same numbers (Local-runs).
• Dogfood battery. The Dogfood Regression Gate (n/3) shards do not run on pull_request (ci.yml:2395, github.event_name != 'pull_request'); the aggregate check-run Dogfood Regression Gate is success with all shards skipped, so CI carries no dogfood reading for this PR and the push to main will run it in full. The dev's reading names head 0e5a281c (= this head): 420 files passed / 3 skipped, 3496 tests passed / 36 skipped, VERDICT exit 0, under the verify lock. I did not re-run the battery (NOT MEASURED locally); the sha the reading names is the head, the reading is full (no -t narrowing), and no red is reported, so the ! / (narrowing) entry requirement is met on the dev's pinned reading. No packages/qa/dogfood/test case reads a side effect this PR reorders (the diff moves no send or write after an answer).
• Check-runs on 0e5a281c (REST, 2026-11-05T16:22Z): 42 success, 9 skipped (opt-in and non-PR jobs), 10 in_progress (Test Core 1–4/8, Test UI 2, 8, 11, 13, 14, 15/16), 0 failures. Lint · repo & tooling gates, Lint · ESLint, Type Check · source gates, Type Check · workspace, Type Check · consumer gates, Check Changeset, Governed Surface Queue Guard, PR-body guards are all success. Enqueue waits for the ten to finish green (全 check 绿, not the required subset). The docs-drift comment (6662810030) lists nothing and says so.
• Author: objectstack-fleet[bot] (relay) — no external login to name.
• Nothing else flagged by the dev: security_findings: none, out_of_scope_findings: [], premise_still_valid: true — the premise (member names view and page but not object) is confirmed on the base c045c341 by the diff's - line.

④ Design judgment (narrowing face)

The narrowing is judged against the published spec on main: does it take a declared capability away at the consumer, or make the spec's own refusal real? It makes the spec's refusal real. resolveObjectSortability (@objectstack/spec/api) is the served verdict the Data API list door refuses by (assertSortFieldsExist, 400 INVALID_SORT, #29896 / #30023), and the lint member reads the identical projection (indexObjectSortability), so an object the door now refuses is one whose list view could never have loaded; no author loses a sort that worked. The crossing completes the #14107 "identical rungs" invariant — the three list-view siblings now all judge an object's built-in list views at the object door, where before the door judged a list view's columns and searchableFields but not its sort. The #9313 missing-collection argument holds for this member exactly as it did for its two siblings in #15495 (resolution against stack.objects only; absent rungs, not dead rungs). The per-member runtimeTypes discipline is respected: declaration + measurement + roster pin + note, no "all types" shortcut. The refusal text carries the prescription (which field, why, and Sort by another field, or remove \sortable: false`), so the author at the only door Studio has gets the same sentence os validate` gives. Nothing in the diff reaches past the member and its pins. Holds.

Must-fix: none. Should-fix: S1 (docs row, separate card). Observations: ①.7 marker category.

Implemented-by: claude/project-thread-e4pw2l
Reviewed-by: session_01Utp6CbPxYq1wQmUNWvMZkC

VERDICT: PASS

domain:server#3 · os-bill · session_01Utp6CbPxYq1wQmUNWvMZkC

维护者速读（席位终稿）

• 改了什么：对象发布门（Studio、PUT /api/v1/meta/object/NAME、MCP）现在也跑列表视图排序检查。对象自己的 listViews.*.sort 按 sortable: false 字段、formula 字段或不存在的字段排序时，发布被 422 INVALID_METADATA 拒收，什么都不存；正确的排序照常发布。
• 为什么改：CLI、view 门、page 门早就拒收这三种排序，只有对象门放行；放进去的列表视图每次加载都被列表门回 400 INVALID_SORT（lint: the object publish door does not run validateSortableFields, so an object whose listViews sort a sortable:false field saves #30095）。
• 风险与回滚：收窄（BREAKING）：以前能从对象门发布的这类坏排序，下次发布被拒；草稿、别的包或外部对象不判，sort-field-unprovisioned 仍只是警告。仓库与示例里 127 个对象、113 个排序键实测 0 命中。CLI 结论不变，所以 Metadata-protocol: none、lint 走 patch。回滚即 revert。
• 先看：packages/lint/src/reference-integrity-suite.ts 里 validateSortableFields 成员的 runtimeTypes 加了 object；packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts 的 #30095 一节。
• 两分钟验证：pnpm --filter @objectstack/metadata-protocol exec vitest run src/protocol.runtime-authoring-gate.test.ts -t 30095，3 条全过。
• 需要你做的：无。技能定档：非受管面、180 行，不需人审；契约复核 6663292380（Head-sha 0e5a281c235dbae3c55dbd09b15f8ec394dffb71，PASS），席位落地。

席位意见：同意落地。只让对象门补上其余三道门早已给出的结论，全仓实测零误伤。

席位核对

ACCEPT · head 0e5a281c235dbae3c55dbd09b15f8ec394dffb71 · card #30095 · 2026-11-05T16:35Z.

• Shape: draft PR to main, relay author, Fixes #30095 only. 4 files, +176 −4. check-governed-merges.mjs --pr 30564 → exit 0, NOT governed, 180 ≤ 3000. No merge=os-regen path. Merge-tree against origin/main clean (review 6663292380).
• Premise measured: the reviewer reproduced the refusal through the real saveMetaItem({ type: 'object' }) route (3/3) and the ablation (door suite 2 failed / 1 passed, lint pin 4 failed / 37 passed with object removed); census at the head: 127 objects, 102 list views, 113 sort keys, 0 findings, synthetic probe non-vacuous.
• Gates (check-runs on this head): 63 runs, 54 success, 9 path-gated skipped, 0 failed, 0 in progress (read 2026-11-05T16:35Z).
• Dogfood battery (! + narrowing, pinned to this head): 0e5a281c · os-verify-lock VERDICT command-exit 0 · Test Files 420 passed, 3 skipped (423) · Tests 3496 passed, 36 skipped (3532) · no failures (dev report 6662809673; dogfood shards do not run on pull_request).
• Accepted deviation: none.
• Out of scope: should-fix S1 (four-doors table in validating-metadata.mdx stale before this PR) filed as docs: the four-doors table in validating-metadata.mdx under-reports the reference-integrity row and has no row for the list-view sort/search members #30574. Skills-docs: none — REASON confirmed by the review.
• Landing: BREAKING (!, Clause-②: no (narrowing)), not governed, ≤ 3000 ⇒ the skill requires no human merge; maintainer 13:47Z 「技能不需要我审核的不应该等我」 ⇒ seat lands it now.