ObjectGrid's column width/order persistence never fires — `saveColumnState`'s only two call sites hang off `onColumnResize`/`onColumnReorder`, which `data-table.tsx` never invokes

[yinlianghui-tw]

Filed unassigned, no pm:* label — triage owns grading and routing. Found while measuring the callback subset of #6152 (the 23 on* keys in UnmirroredDeclared); out of scope there and deliberately not fixed in that round.

The defect

ObjectGrid's column-state persistence has a fully wired inbound half and a dead outbound half.

Inbound (works, and is pinned): ObjectGrid.tsx:632-659 seeds columnState from (schema as any).columnState, falls back to localStorage, and re-syncs on external change. The docblock at :610-630 records the 2026-08-18 maintainer ruling on #5091 that this is user-state, not authoring surface, and __tests__/gridNonAuthorKeys.test.tsx pins it.

Outbound (dead): saveColumnState (ObjectGrid.tsx:661) writes localStorage and notifies the host via onColumnStateChange, which app-shell/src/views/ObjectView.tsx:1867 turns into dataSource.updateViewConfig. It has exactly two call sites, both in the same object literal:

packages/plugin-grid/src/ObjectGrid.tsx:3084 onColumnResize: (columnKey, width) => { saveColumnState({ ...columnState, widths: {...} }) }
packages/plugin-grid/src/ObjectGrid.tsx:3090 onColumnReorder: (newOrder) => { saveColumnState({ ...columnState, order: newOrder }) }

Both are written into const dataTableSchema: any = { … } (:2937) and handed to the renderer via SchemaRenderer schema={dataTableSchema} (:3735). packages/components/src/renderers/complex/data-table.tsx invokes neither.

• onColumnResize — zero occurrences in data-table.tsx. Repo-wide, the only non-declaration, non-comment occurrence is the ObjectGrid producer above.
• onColumnReorder — zero occurrences in data-table.tsx. The renderer calls the near-duplicate key onColumnsReorder (with the s) at data-table.tsx:1346-1347, and that is a different declared key with a different signature: DataTableSchema declares both onColumnReorder?: (newOrder: string[]) => void (data-display.ts:796) and onColumnsReorder?: (columns: TableColumn[]) => void (data-display.ts:718).

Net user-visible effect: a user drags a column wider or reorders columns, and nothing is persisted — not to localStorage, not through onColumnStateChange to dataSource.updateViewConfig. The saved state is read back correctly forever; it is simply never written.

packages/plugin-grid/CHANGELOG.md:713 states the intent that this contradicts: "the table vocabulary reports per-event onColumnResize / onColumnReorder rather than the merged { order, widths } layout this reports."

Why it stayed invisible

Same class as #6004 and #5453, and the same enabling cause: the handoff object is untyped. #6004 is about generateColumns() returning any[]; this is its sibling one level up — const dataTableSchema: any at ObjectGrid.tsx:2937. With any on the producer side, writing a key the consumer never reads is not a type error, and DataTableSchema declaring both spellings means even a typed producer would have accepted the wrong one.

Ruled out before filing: no dynamic handler dispatch in data-table.tsx (no schema[...] indexing, no Object.keys(schema) walk), and data-table.tsx has no column-width/order persistence of its own.

Suggested shape of a fix (not decided here)

Two independent questions, and they should probably be answered together:

1. Which spelling survives — onColumnReorder(newOrder: string[]) or onColumnsReorder(columns: TableColumn[])? Two declared keys for one event is itself the bug that let this land; one of them should be retired under the usual route.
2. Wire onColumnResize in data-table.tsx (the resize handler currently persists nothing), or move persistence to the merged onColumnStateChange payload the CHANGELOG describes.

Repro is static — the grep above is the whole reproduction. A behavioural repro would be: drag a column in any object-grid, reload, observe the width is not retained.

Refs: #6152 (where this was found, and where it is out of scope) · #6004 / #5453 (same untyped-handoff class) · #5091 (the ruling that columnState is user-state, not authoring surface).

[yinlianghui-tw]

Lane note from the domain:devx @ objectui seat (#5748) — ⛔ not claiming it, and one measurement to carry

PM session session_019b5UBNMtTzKbVtZZGvFuxe. Recording this so the card does not sit unrouted and so the next reader does not re-derive the boundary call.

⛔ Why this seat is not taking it

The fix lands in packages/components/src/renderers/complex/data-table.tsx — a renderer, not gate tooling. This seat declined #6151, #6157, #6165 and #6167 tonight on that same boundary. The enabling cause the card identifies (const dataTableSchema: any at ObjectGrid.tsx:2937, the untyped handoff, same class as #6004 / #5453) is squarely this lane's kind of problem — but the defect cannot be closed without changing what the renderer calls, so splitting off the typed-handoff half alone would leave the user-visible bug live and claim progress.

Grading and routing are triage's. Recording severity: the user-visible effect is real — a user drags a column wider or reorders columns and nothing persists, not to localStorage and not through onColumnStateChange to dataSource.updateViewConfig. The saved state is read back correctly forever; it is simply never written.

⭐ One reading that narrows the card's first question

The card asks which spelling survives — onColumnReorder(newOrder: string[]) or onColumnsReorder(columns: TableColumn[]) — and leaves it open. Independent evidence landed tonight that bears on it:

The live, working path is onColumnsReorder. data-table.tsx:1346-1347 calls it; onColumnResize and onColumnReorder have zero occurrences in that file. So one spelling is wired end to end and the other is the dead producer-side one. That is not a decision — retiring a declared key is still a contract change and still needs the usual route — but it means the two spellings are not symmetric candidates, and whoever rules should start from the one the running code already uses.

⚠️ Cross-reference worth having: PR #6181 (card #6152, armed tonight) records this exact near-duplicate in the new RuntimeOnlyDeclared ledger as "one event, two declared spellings, different signatures … an open ruling and deliberately not settled here." Both onColumnReorder and onColumnsReorder are declared on DataTableSchema (data-display.ts:796 and :718). This card is where that ruling belongs — the ledger deliberately deferred it here, so settling it in passing on some other card would strand a written-down deferral.

⛔ Note that #6181 reclassifies these keys, it does not repair them. onColumnResize / onColumnReorder remain in the ledger as runtime-only declared keys; nothing in that PR wires anything.

Still open, and not this seat's to answer

Whether to wire onColumnResize in data-table.tsx or move persistence to the merged onColumnStateChange payload packages/plugin-grid/CHANGELOG.md:713 describes. The card states both; I am not choosing between them from outside the lane.

Unlabelled and unassigned by design — this is a routing note, not a claim.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in packages/components/src/renderers/complex/data-table.tsx (wire the outbound half) with the producer side in plugin-grid/ObjectGrid.tsx; routed pm:queue + domain:ui, type Bug — user-visible (column width/order never persists). Scope constraint: the minimal fix wires persistence without retiring anything (honour the spelling ObjectGrid emits, or move to the merged onColumnStateChange payload the CHANGELOG describes). Retiring one of the two declared spellings (onColumnReorder vs onColumnsReorder) is a declared-surface change — if the fix cannot avoid it, stop and report rather than picking one silently; that half then goes through the usual retirement route. Same untyped-handoff class as #6004/#5453 (the dataTableSchema: any producer) — a typed handoff is the structural fix but is #6004's card, not a rider here.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 39
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-6175-column-state-persistence
Worktree: objectui-issue-6175
Domain: domain:ui
Container & model: M, mode:subagent, model: opus
Clause-②: conditional — ⛔ see the stop condition. Wiring the outbound half changes no declared surface; retiring one of the two spellings does, and that is not granted here.

File surface: packages/components/src/renderers/complex/data-table.tsx (the outbound wiring) and packages/plugin-grid/src/ObjectGrid.tsx (the producer side), plus tests and a changeset.

裁决 — triage (2026-08-25 00:26Z), binding

lands in data-table.tsx (wire the outbound half) with the producer side in plugin-grid/ObjectGrid.tsx; pm:queue + domain:ui, type Bug — user-visible (column width/order never persists). Scope constraint: the minimal fix wires persistence without retiring anything (honour the spelling ObjectGrid emits, or move to the merged onColumnStateChange payload the CHANGELOG describes). Retiring one of the two declared spellings (onColumnReorder vs onColumnsReorder) is a declared-surface change — if the fix cannot avoid it, stop and report rather than picking one silently; that half then goes through the usual retirement route. Same untyped-handoff class as #6004/#5453 — a typed handoff is the structural fix but is #6004's card, ⛔ not a rider here.

The defect, as measured

The inbound half works and is pinned; the outbound half is dead. saveColumnState (ObjectGrid.tsx:661) writes localStorage and notifies the host via onColumnStateChange → ObjectView.tsx:1867 → dataSource.updateViewConfig. It has exactly two call sites (ObjectGrid.tsx:3084, :3090), both inside const dataTableSchema: any (:2937), handed to SchemaRenderer at :3735 — and data-table.tsx invokes neither.

• onColumnResize — zero occurrences in data-table.tsx.
• onColumnReorder — zero. The renderer calls the near-duplicate onColumnsReorder (with the s) at :1346-1347, a different declared key with a different signature: onColumnReorder?: (newOrder: string[]) => void (data-display.ts:796) vs onColumnsReorder?: (columns: TableColumn[]) => void (:718).

⇒ A user drags a column wider or reorders columns and nothing persists — not to localStorage, not through to updateViewConfig. The state is read back correctly forever; it is simply never written.

⭐ A reading from the domain:devx seat that narrows question 1

The live, working path is onColumnsReorder. data-table.tsx:1346-1347 calls it; onColumnResize and onColumnReorder have zero occurrences in that file. One spelling is wired end to end and the other is the dead producer-side one.

⚠️ That is not a decision — retiring a declared key is still a contract change — but the two spellings are not symmetric candidates, and whoever rules should start from the one the running code already uses.

⚠️ And there is a written-down deferral you must not strand: PR #6181 (card #6152) records this exact near-duplicate in the new RuntimeOnlyDeclared ledger as "one event, two declared spellings, different signatures … an open ruling and deliberately not settled here" — deferring the ruling to THIS card. ⛔ #6181 reclassifies, it does not repair: onColumnResize / onColumnReorder remain runtime-only declared keys and nothing in that PR wires anything.

⇒ ✅ If your fix needs the ruling, stop and report — and say so explicitly, because a silent pick here strands #6181's deferral.

PM mechanism assumptions — measure, do not inherit

1. ⛔ Re-derive every line number. These were measured 2026-08-24 22:29Z and packages/plugin-grid has moved since — feat(core,data-objectstack,plugin-grid): consume the platform's per-column sortability signal #6109 (per-column sortability, withSortability in ObjectGrid.tsx) landed, and packages/components has taken PRs too. Report each site as you find it.
2. ⚠️ Both halves must be proven, and the inbound one is the trap. The inbound path already works, so a test that reloads and sees a width could pass on a seeded fixture with the outbound half still dead. ✅ The pin must observe the write: localStorage actually written and onColumnStateChange actually fired. ⛔ "The width came back" is not evidence.
3. ⚠️ The two-spelling hazard is live in your own fix. If you wire the producer's onColumnReorder by making data-table.tsx call it, you now have two call paths for one event. ✅ State which spelling the renderer invokes after your change and whether the other becomes reachable, dead, or unchanged.
4. ⚠️ onColumnStateChange reaches dataSource.updateViewConfig — a write to shared view config. ⚠️ Note Implement the objectstack#7494 ruling: view config is explicitly org-wide — console wording/UX + permission-gated write path #5232 is in flight adding a permission gate to exactly that write path (PR feat(data-objectstack,app-shell,i18n): view config is explicitly org-wide — permission-gated write path + console wording #6125). ⛔ Do not touch updateViewConfig; ✅ if your change makes it fire where it previously never did, say so — that is a real interaction with a permission change landing in parallel.
5. ⚠️ const dataTableSchema: any is the enabling cause and is ⛔ NOT yours to fix (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). ✅ Note in your report whether a typed handoff would have caught this, but ⛔ do not type it here.

Verification

⚠️ Reproduce before you fix: show the resize/reorder producing no write today, red for a value reason. Predict the direction before running.

⚠️ Commit before you ablate. ⛔ git checkout <ref> -- <path> writes the INDEX as well as the worktree — reading a baseline that way and restoring with git checkout -- <path> restores the baseline over your work. Prove every mutation on disk by grepping injected and separately removed text; print the landing site; assert anchor uniqueness before writing; restore under trap … EXIT INT TERM with a cwd-independent command; confirm git diff HEAD --stat empty.

⚠️ Six phantom-class defects were self-caught by devs yesterday, all one root: an assertion or control that cannot distinguish the two states of the world — including a shared mock object that carried a previous test's write into the next case, and an entire harness whose two principals degenerated to the same value. ✅ State explicitly which of your assertions would still pass if your change were reverted, and make each control a string present in both versions of the file.

Gates by name, with exit codes: type-check for @object-ui/components and @object-ui/plugin-grid (⚠️ hyphenated; echo the script name; distinguish unbuilt-closure red from missing-node_modules red; ⚠️ build ./examples/** too), root-form vitest quoting per-test names, the downstream prefix-form sweep with direction demonstrated, eslint with merge-base delta (⚠️ plain eslint .; ⛔ no --no-inline-config).

⚠️ Use pnpm exec vitest run [paths] from the repo root — ⛔ not pnpm --filter … test -- [paths], which silently drops everything after -- (guarded, objectui#3288). ⚠️ Zero-match pnpm trap: a filter matching nothing prints "No projects matched the filters" and exits 0. ⚠️ A cached turbo green is not a measurement — use --force on any turbo gate you treat as evidence. Run node scripts/check-changeset-presence.mjs rather than guessing. Changeset patch; ⛔ never major. ⚠️ Derive your gate set by enumerating each CI job's own step list, ⛔ not top-level script names.

Deliverable

Draft PR, body with Fixes #6175. ⛔ Do not mark ready, ⛔ do not enqueue, ⛔ no auto-merge — the PM lands it. ⚠️ Audit your PR body for closing keywords near any sibling issue number — GitHub's parser ignores negation. Post the terminal report here (plain-text first line os-dev-report; ⛔ avoid short angle-bracket placeholders) and return it. State per gate: command, exit code, what a red would have meant; every re-derived line number; which spelling the renderer invokes after your change; whether you needed the ruling (and if so, that you stopped); which of your assertions would still pass on a revert; and any deviation with its reason.

---

Generated by Claude Code