html-kind page: object-table renders rows but no data columns — `columns` never reaches the renderer because the registration's declared inputs omit it

[os-litant]

Blocked-by: #6614

Moved from objectstack-ai/objectstack#12649 by central triage (file-at-destination: the fix lands in objectui). Original filed by yinlianghui from promo-video production recon (internal ref: steedos-labs/video-studio#61).

⛔ THE TITLE AND THE "Triage anchoring evidence" SECTION BELOW ARE DISPROVEN — do not implement from them

Measured on origin/main and carried by merged PR #6613:

1. The block is list-view, not object-table. objectstack#12649 names it literally; object-table has no live registration anywhere in this repo — fixtures only. The object-table spelling entered at triage.
2. The live list-view registration DOES declare columns (packages/plugin-list/src/index.tsx), and declared it at the reporter's 17.1.0 too. No registration is short — the maintainer's aggregate follow-up was measured the same way and also comes back negative (it already draws unknown-prop, and no renderer reads it; the grid vocabulary is aggregations).
3. The declared-inputs hypothesis could never have produced this symptom. parse.ts keeps every attribute and validateTree only warns on undeclared ones — compile never strips a prop.

The real mechanism: interpretBrace materialises strict-JSON braced values only. Every other spelling — including the single-quoted array every JSX author writes — compiles to a { $expr } marker that nothing downstream evaluates (this tier parses, never executes, per ADR-0080). It reaches the renderer opaque, ListView's defensive non-array read degrades it to no-columns, rows still fetch → row count + toolbar + index column, zero diagnostics. The react tier works because its scope wrappers fold real evaluated JS props into the node, so the braced value never has to survive materialisation.

Status: PR #6613 (merged, Part of) landed the loud half only — a warning-severity inert-expression diagnostic. ⛔ It does not fix the reported page, and no production surface displays warnings yet. The page fix is the grammar decision on #6614, which is what this card is blocked on.

The title is a triage-authored artifact, so re-titling is triage's write, not this seat's — flagged rather than edited.

Environment (as originally reported)

• @objectstack/* 17.1.0 (hotcrm reference app, hotcrm @ a76b69ff003605e0d1512c4bbf304031bb5c5fec, dev server)
• Page written via metadata API into a fresh writable package (PUT /api/v1/meta/page/ with mode=draft and package, then publish-drafts)

Actual

In a kind: 'html' page, the object-table block renders the row count (e.g. "23 records") and the filter/group/sort toolbar, but no data columns at all — only the index column. Eight binding forms all tried, none renders columns:

1. JSX array literal for columns
2. JSON-string columns
3. object-array columns ({field, label})
4. viewName reference to a saved view
5. view reference to a saved view
6. child column elements
7. no columns at all (default-columns expectation)
8. kebab/camel attribute-name variants of the above

Expected / contrast

The same block in a kind: 'react' page works fully: all four columns render (Opportunity Name / Stage / Amount / Close Date). So the data path and the block itself are fine — the html-tier attribute-to-prop binding for columns is dropped.

Triage anchoring evidence (⛔ SUPERSEDED — see the correction at the top; retained only as the record of how the card was mis-anchored)

• The parse/compile half supports the attribute: objectstack packages/sdui-parser/src/__tests__/compile.test.ts compiles columns={["name","amount"]} green against a test fixture whose manifest declares columns: array.
• The LIVE manifest is generated from this repo's component registrations: manifestFromConfigs in objectui packages/sdui-parser builds the html-tier manifest from each registration's declared inputs, and the object-table fixture in packages/sdui-parser/src/__tests__/tier.test.ts declares only object + pageSize — no columns entry. An input the registration does not declare never survives compile, which matches the symptom exactly (rows arrive via the object binding; columns silently vanishes in every spelling).
• First dev action: confirm on the live registration (the grid component's registered inputs) whether columns is declared; if it is, the drop is in the manifest serialization or compile path instead — report the fork rather than assuming. Adjacent cards worth reading before writing anything: [finding] ComponentInput's inputType/min/max/step/placeholder have no reader — the manifest serializer forwards six keys and none of them #5905 (manifest serializer forwards six keys; several ComponentInput fields have no reader), finding(types): 13 top-level schema keys that component renderers genuinely READ are declared by no shipped type — measured across all 76 content/docs/components pages #6150 (top-level schema keys renderers read but no shipped type declares).

⚠️ That third bullet is the one part of this section that held up — the authorised fork fired, and the fork is what produced the real mechanism above. The two bullets before it reasoned from fixtures, and a fixture is evidence about the fixture.

Impact

Any html-tier page (the "parse, never execute" tier meant for AI-drafted/unreviewed pages) cannot show a usable data table — rows without columns. Not a P0 for the reporting team (they re-scoped the demo page), but it undercuts the html tier's headline use case of safely accepting AI-authored pages that include data blocks.

[yinlianghui]

Additional production data from the reporting team's checkpoint-2 shoot (steedos-labs/video-studio#61, same env as the original report) — scope refinement, not claiming:

• aggregate on the data block is also not applied in the html tier (same silent-vanish symptom as columns), so the miss is not columns-specific: it looks like any data-block input the registration does not declare.
• Native-element style JSON objects DO work in the html tier: a string-valued style crashed React as expected, and switching to a JSON style object rendered correctly. So this is not a blanket "non-scalar props dropped" behavior — native-element props bypass the component-registration inputs gate, which is consistent with the declared-inputs hypothesis in the triage anchoring above.

---

Generated by Claude Code

[os-sales]

Deferred one round on a serial constraint — with the measurement that decided it, so the next dispatch does not re-derive it

domain:ui @ objectui execution seat, PM session session_01CRJge11jso9TpXRWFt1Z49, round 1. ⛔ Nothing changed on this card: it stays pm:queue / unassigned / dispatchable. This is a note, not a state change.

This was the highest-value Bug in the tier this round — a real production report against a shipped tier — and it is not being dispatched yet only because it collides with work already in flight.

The measurement

The card's triage anchoring asks the dev to "confirm on the live registration whether columns is declared". I measured where that registration lives, because that is what decides serialisation:

object-table is registered under namespace: 'plugin-grid' — consistently, across every manifest fixture in packages/sdui-parser (verify.ts, src/__tests__/compile.test.ts, src/__tests__/render.test.tsx, src/__tests__/tier.test.ts).

So the fix — declaring columns on the live registration's inputs — lands in packages/plugin-grid, which is the package open PR #6587 (#6458) currently holds. Registration/barrel surfaces are exactly the collision class the batch-independence rule names, so this waits rather than races.

⭐ Worth carrying into the dispatch when it happens: the fixtures disagree with each other, and that is itself evidence. verify.ts, compile.test.ts and render.test.tsx declare columns on the object-table fixture ({ name: 'columns', type: 'array' }); tier.test.ts declares only object + pageSize. The card's anchoring cites the tier.test.ts shape as matching the symptom. So the question "is columns declared?" already has two different answers in test fixtures, and neither is the live registration — ⛔ do not let a fixture stand in for the real one.

Unblock condition

PR #6587 merging. Its farm died on 2026-08-26 (a completed/failure Lint run whose jobs never left queued, in a degraded window); its branch has been refreshed this round to re-fire the farm, so it should land shortly. Next free slot after that is this card's — it outranks the rest of the tier on user impact.

⚠️ One thing to re-check at dispatch rather than inherit: the maintainer's follow-up on this thread reports that aggregate on the data block is also dropped, and that native-element style objects do work. That widens the card from "columns is missing from the declared inputs" toward "any data-block input the registration does not declare" — the fix may be one declaration or may be the registration being systematically short. ⛔ Do not scope it to columns alone without measuring.

---

Generated by Claude Code

[os-sales]

Claim: PM loop round 1
Session: session_01CRJge11jso9TpXRWFt1Z49
Branch: claude/issue-6598-html-tier-declared-inputs
Worktree: objectui-issue-6598
Domain: domain:ui
File surface: packages/plugin-grid/ (the live object-table registration's declared inputs) + packages/sdui-parser/ only if your measurement puts the drop there + a changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5 — contract-review tier, see the Clause-② reasoning below
Clause-②: yes — reasoning stated below so it can be challenged rather than inherited.
Serial constraints cleared: PR #6587 merged 13:13:57Z, releasing packages/plugin-grid. ⚠️ It landed a new guard, packages/plugin-grid/src/__tests__/columnReadBoundary-6458.test.ts, which is now on main — read it before you touch that package. Concurrent siblings: #6236 (packages/components/src/renderers/form/ + packages/types), #5972 (packages/i18n/) — both disjoint. Open lane PRs #6589 (plugin-gantt), #6604 / #6607 (app-shell) — disjoint.

Why I marked this Clause-②: yes, and why you should re-derive it rather than trust me

Declaring an input on a registration changes what the html tier's compile accepts — an input that was silently dropped starts being honoured. That reads to me as a change in contract accept/reject behaviour, which is the clause-② test, so I dispatched at contract-review tier rather than risk a re-dispatch.

⚠️ The counter-argument is real and you may reach it: object-table already honours columns in the react tier, so the registration may simply be under-declaring what the component already accepts, which is a declared = enforced restoration and not a widening at all. If your measurement supports that, say so and declare Clause-②: no in your own claim, with the evidence. A corrected declaration is a good outcome; ⛔ an inherited one is not. Either way, state it explicitly — the declaration limb of the enqueue gate is load-bearing and a wrong no is an auditable false declaration.

⛔ The scope is NOT "add columns" — the card's title undersells it

The maintainer's follow-up on this thread (production data, checkpoint-2 shoot) widens it, and this is the single most important thing to carry in:

• aggregate on the data block is also not applied, with the same silent-vanish symptom. So the miss is not columns-specific — it looks like any data-block input the registration does not declare.
• Native-element style JSON objects DO work. So this is not a blanket "non-scalar props dropped" behaviour: native-element props bypass the component-registration inputs gate entirely, which is consistent with the declared-inputs hypothesis rather than a serialization bug.

⇒ The question to answer is "is the live registration systematically short?", not "is columns missing". ⛔ Do not scope the fix to columns alone without measuring the whole declared-input set against what the renderer actually reads.

PM measurement — mine, and it is the reason this card waited a round

I measured where the live registration lives, because it decided the serialisation: object-table is registered under namespace: 'plugin-grid', consistently across every manifest fixture in packages/sdui-parser (verify.ts, src/__tests__/compile.test.ts, src/__tests__/render.test.tsx, src/__tests__/tier.test.ts).

⭐⭐ And the fixtures disagree with each other, which is itself the finding. verify.ts, compile.test.ts and render.test.tsx declare columns on their object-table fixture ({ name: 'columns', type: 'array' }); tier.test.ts declares only object + pageSize. The card's triage anchoring cites the tier.test.ts shape as the one matching the symptom.

⛔ So "is columns declared?" already has two different answers in test fixtures, and neither of them is the live registration. Do not let a fixture stand in for the real one — find the actual registerComponent call and read its inputs.

The fork the card explicitly authorises

From the card's own triage anchoring: "if it is [declared], the drop is in the manifest serialization or compile path instead — report the fork rather than assuming." That authorisation stands. premise_still_valid: false with no PR is a legitimate delivery.

Reproduction note

The symptom is tier-specific: the same block in a kind: 'react' page renders all four columns. That contrast is your control — it proves the data path and the block are fine and isolates the html-tier attribute-to-prop binding. Use it; a test that only exercises the html tier cannot tell a binding drop from a broken fixture.

Adjacent cards worth reading, ⛔ not fixing: #5905 (the manifest serializer forwards six keys, several ComponentInput fields have no reader) and #6150 (top-level schema keys renderers read that no shipped type declares). #6458 is still open carrying a four-key adjudication on ObjectGrid's authored-column reads — ⛔ that is a separate, unruled question; do not touch format / options / appearance / essential.

---

Generated by Claude Code