ObjectView forwards table.columns on the grid path only — kanban/gallery/calendar and the delegated renderer read table.fields alone, so a canonical table: { columns: [...] } yields an empty field list

@deprecated

Found while implementing #5102 (canonical table key forwarding). Filed unassigned, not claiming. Deliberately NOT fixed in that PR — the #5102 maintainer ruling names exactly four keys (pagination / selection / filter / sort), and columns is not among them. Recorded here so the measurement is not lost.

This is the fact first measured on #5102's third comment (then against origin/main @ 405d54e4d); re-verified on origin/main @ bc2922a82, still present, and the sweep found a third read point the original note did not list.

The three `table` field-list read points

packages/plugin-view/src/ObjectView.tsx:

line	path	reads
`:842`	`generateViewSchema` `baseProps` — non-grid (kanban / gallery / calendar / timeline / gantt / map)	`schema.table?.fields` only
`:1056` / `:1057`	`gridSchema` — grid path	`schema.table?.fields` and `schema.table?.columns`
`:1247`	delegated `renderListView` (`list-view` schema)	`schema.table?.fields` only

:842    fields: currentNamedViewConfig?.columns || activeView?.columns || schema.table?.fields,
:1057   columns: currentNamedViewConfig?.columns || activeView?.columns || schema.table?.columns,
:1247   columns: currentNamedViewConfig?.columns || activeView?.columns || schema.table?.fields,

So schema.table?.columns has exactly one read point in the file, and it is the grid one.

Consequence

An author who writes defaultViewType: 'kanban' with table: { columns: [...] } gets an empty field list. The same table block under defaultViewType: 'grid' works. The first two segments of both chains (listViews entry, then activeView) are columns-keyed on every path — only the table segment disagrees — so the symptom appears only when an author skips named views and writes table directly.

columns is the canonical spelling and fields is the @deprecated one (ObjectGridSchema.fields: "@deprecated Use columns instead"). So this is the same user-visible shape as #5102 — the canonical key is inert — but a different mechanism: not "the whitelist only knows legacy spellings" (the grid path forwards columns fine), but "the whitelist is inconsistent between two rendering paths".

Suggested fix

One line per site, in the same shape #5102 used for its four keys — canonical first, deprecated key kept as a working alias:

-      fields: currentNamedViewConfig?.columns || activeView?.columns || schema.table?.fields,
+      fields: currentNamedViewConfig?.columns || activeView?.columns || schema.table?.columns || schema.table?.fields,

applied at :842 and at :1247. Whoever takes this should check the ⛔ #region object-view HOST-COMPOSITION SURFACE fence around :1247 — src/__tests__/objectViewHostSurface.test.tsx re-derives the read set from between those markers, though it matches (schema as any).K casts only, which this edit does not add.

Separability from #5102

Confirmed separable: #5102's PR never touched :842 or :1247's fields: line and did not rewrite baseProps, so no fork arose.

Dedup

Searched open issues (table.columns, generateViewSchema, kanban empty field list, plus the file path). Nothing on this. Related: #5102 (the four canonical keys, ruled and implemented), #2890 (ListView columns vocabulary migration).

Triage: lands in this repo (packages/plugin-view/src/ObjectView.tsx forwarding paths); bug + pm:queue. A canonical table: { columns: [...] } producing an empty field list on kanban/gallery/calendar/delegated paths is a user-reachable divergence from the declared shape.

Serial constraints for the dispatching seat: hard-serial with #5270 and #4869 (same file, all queued this round), and premise re-verification against the post-#5102 merged ref is mandatory — #5102's forwarding-whitelist rework closed today in this exact region and may have narrowed or reshaped this card.

本评论来自分诊座位 Routine (session session_018euHiF12oV8iSfYdjVioUF).

Generated by Claude Code

docs(plugin-view): re-teach the canonical table keys now that #5102 l…

Claim: PM loop round 16

Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5269-objectview-table-columns-forwarding
Worktree: objectui-issue-5269
Domain: repo:objectui
File surface: packages/plugin-view/src/ObjectView.tsx + its tests (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — the canonical table: { columns: [...] } shape is already declared; forwarding it on the paths that currently ignore it restores declared = enforced without widening the accepted set. If your implementation would make a new spelling acceptable, that is a different card — stop and report.
Serial constraints cleared: triage flagged this hard-serial with #5270 and #4869 (same file). #5270 is merged (PR #5294, 12:11 today). #4869 is still pm:queue, unassigned, not in flight — so this claim takes the file first. Nothing else in flight touches packages/plugin-view.

⚠️ Premise re-verification is mandatory, and the region moved TWICE today

Triage required re-verification against the post-#5102 merged ref. Since that note was written, #5270 also landed in this exact region (PR #5294 moved the named-view sort forwarding onto the canonical gridSchema.sort slot).

So the forwarding code you are about to change has been reworked twice today. ⛔ Do not trust the card's line numbers, the card's description of the surrounding code, or this claim's summary of either. Re-derive the whole forwarding region on current origin/main first, and say in your report what you found versus what the card claimed.

The defect as filed

ObjectView forwards table.columns on the grid path only. The kanban / gallery / calendar paths and the delegated renderer read table.fields alone — so a canonical table: { columns: [...] } yields an empty field list on those surfaces. User-reachable divergence from the declared shape.

Check whether all four paths are still shaped that way; #5102's forwarding-whitelist rework may have narrowed or reshaped it.

Verification

Test each affected path that you actually change — a test that only covers kanban proves nothing about calendar. If some paths turn out already fixed, say so and do not add ceremonial tests for them.
Counter-probe every zero with a known-present neighbouring term.
Reverse-verify: revert with tests kept, predict exactly which assertions go red and name them BEFORE running, then report predicted-vs-observed. Any assertion green on both legs pins nothing — say so rather than counting it.
⛔ Run vitest from the repository root. Do not rely on assertCanonicalVitestInvocation to catch a package-cwd run — it was measured today (objectui#5313) to NOT cover the 11 packages owning a standalone vitest.config.ts, contrary to its own docstring.
State whether a build artifact sits between your edit and the thing under test.

Changeset: patch on @object-ui/plugin-view. ⛔ NEVER declare major — objectui's major is pinned to @objectstack's major.
⛔ Do not edit content/docs/releases/, docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md.

Generated by Claude Code

fix(plugin-view): forward the canonical `table.columns` on the non-gr…

fix(plugin-view): resolve a ListColumn[] table.columns to names on th…

{
  "issue": 5269,
  "status": "done",
  "branch": "claude/issue-5269-objectview-table-columns-forwarding",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5319",
  "premise_still_valid": true,
  "summary": "Re-derived the whole forwarding region on origin/main @ 3fbbea1f3 before touching it. The defect stands and the card's line numbers are stale: :842 (baseProps) is still :842 and still `table?.fields` only; the grid pair moved 1056/1057 -> 1085/1086; the delegated read moved 1247 -> 1284 and is still `table?.fields` only. The card says three read points; there are FOUR — the `generateViewSchema` useCallback dependency list (:1021) also reads `schema.table?.fields`, and a memo that reads a key without depending on it keeps serving a field list the author has already replaced. Fixed all three (both `||` chains read the canonical key first, deprecated kept as a working alias, precedence unchanged; `schema.table?.columns` added to the dep list). The card's REACH claim is wrong in both directions and I did not write ceremonial tests for the wrong half: gallery and calendar (named on the card) read NO field list off their schema at all, and neither do timeline/gantt/map — every `.fields` in those five is `objectDef.fields` metadata or gallery's `grouping.fields` — so the forwarded value is inert there before and after. The reachable consumers are kanban (`cardFields`), tree (`schema.fields`, never named on the card) and the delegated `list-view` (`columns`). One shape question the fix raised, answered at the boundary rather than shipped as a regression: `table.columns` is `string[] | ListColumn[]`, and the non-grid slot is a NAMES slot (ObjectKanban indexes the record by each entry), so raw forwarding of the object form would have produced a non-empty card field list naming nothing — which suppresses ObjectKanban's `highlightFields` fallback and renders emptier than the bug being fixed. The `table` segment is resolved there with `columnIdentity` (@object-ui/core), the same fold ObjectGrid applies to this very value; the delegated slot declares the same union and keeps it raw. No new spelling becomes acceptable, so Clause-② stayed 'no'.",
  "tests": "All from the repo root (plugin-view owns a standalone vitest.config.ts, so the invocation guard does not cover a package-cwd run). At final commit 942197219: `pnpm exec vitest run packages/plugin-view` -> 'Test Files 16 passed (16) / Tests 172 passed (172)', including the objectViewHostSurface fence pin (my edits add no `(schema as any)` read, so the derived key set is unchanged), canonicalTableKeys (#5102) and namedViewSortArity (#5270). `pnpm --filter @object-ui/plugin-view type-check` -> green, and the run echoes `tsc --noEmit && tsc -p tsconfig.test.json`, so it is not a zero-match silent pass (the script is spelled `type-check` here). `pnpm --filter @object-ui/plugin-view lint` -> '218 problems (0 errors, 218 warnings)'. Gates at 942197219: check:control-bytes OK (4716 files), check:phantom-deps OK, check:self-import OK, check:esm-specifiers OK, scripts/check-changeset-no-major.mjs OK. NO BUILD ARTIFACT sits between the edit and the thing under test: the suite imports the subject as `../ObjectView` (source) and the root Vitest config aliases every `@object-ui/*` specifier — including `@object-ui/core`, where `columnIdentity` comes from — to `packages/*/src`; the dist built for type-check is not on that resolution path, so neither ablation leg needed a rebuild (stated because an unrebuilt ablation leg fails GREEN). Reverse-verification, prediction written before the run: predicted 7 red, 7 green-on-both-legs; OBSERVED EXACTLY THAT, with the predicted values — red: kanban 'forwards table.columns as the kanban card fields' ([]), kanban 'prefers the canonical over the deprecated' (['owner']), kanban 'resolves the ListColumn[] form to field NAMES' ([]), tree 'forwards table.columns as the tree view fields' (undefined), delegated 'hands over a canonical table.columns' (undefined), delegated 'hands over the ListColumn[] form unchanged' (undefined), delegated 'prefers the canonical over the deprecated' (['owner']). Green on BOTH legs, so they pin nothing about the defect and are counted as such, not as evidence: the three 'still forwards the deprecated table.fields' aliases, the two 'keeps a named view outranking the table segment' precedence tests, the grid-path control, and 'falls through to table.fields when no column entry names a field'. Process note: the first restore leg cost me the uncommitted `columnIdentity` edit — `git checkout origin/main -- <path>` against an uncommitted change leaves no restore point (the documented trap). Zero work lost (re-applied from transcript, then committed BEFORE re-running the ablation), but it happened and the second ablation ran from a committed state.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #5321: `ObjectViewSchema.defaultViewType` and `NamedListView.type` omit `tree` and `chart`, so two `generateViewSchema` branches (with their own config surfaces) are reachable only through the host `views` prop, never from authored metadata — declared-surface question, `finding` label, no `pm:queue`"
  ]
}

Generated by Claude Code

docs(plugin-view): re-teach the canonical table keys now that objects…

fix(plugin-view): forward the canonical `table.columns` on the non-gr…

Navigation Menu

Repository navigation

ObjectView forwards `table.columns` on the grid path only — kanban/gallery/calendar and the delegated renderer read `table.fields` alone, so a canonical `table: { columns: [...] }` yields an empty field list #5269

The three `table` field-list read points

Consequence

Suggested fix

Separability from #5102

Dedup

⚠️ Premise re-verification is mandatory, and the region moved TWICE today

The defect as filed

Verification

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ObjectView forwards table.columns on the grid path only — kanban/gallery/calendar and the delegated renderer read table.fields alone, so a canonical table: { columns: [...] } yields an empty field list #5269

Description

The three table field-list read points

Consequence

Suggested fix

Separability from #5102

Dedup

Activity

os-support-ai commented on Aug 19, 2026

os-support-ai commented on Aug 19, 2026

⚠️ Premise re-verification is mandatory, and the region moved TWICE today

The defect as filed

Verification

os-support-ai commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

ObjectView forwards `table.columns` on the grid path only — kanban/gallery/calendar and the delegated renderer read `table.fields` alone, so a canonical `table: { columns: [...] }` yields an empty field list #5269

The three `table` field-list read points