docs(core): rewrite report-schema.mdx column hydration to the shape the renderer reads

[os-support-ai]

Fixes#5136

Premise re-check (on current origin/main, commit 41f498bcb)

Zero-hit target grep, with its counter-probe in the same files:

$ grep -rn "objectName" packages/plugin-report/src
packages/plugin-report/src/ReportRenderer.tsx:102: // Stored pre-9.0 spec JSON (objectName/columns query form) — its inline
packages/plugin-report/src/__tests__/DatasetReportRenderer.test.tsx:65: expect(isDatasetReport({ name: 'r', objectName: 'task', columns: [{ field: 'x' }] })).toBe(false);
packages/plugin-report/src/__tests__/ReportRendererDispatcher.test.tsx:37: objectName: 'opportunity',
packages/plugin-report/src/DatasetReportRenderer.tsx:7: * single-form) instead of an inline `objectName` + `columns` query. The report
$ echo exit=$?
exit=0
$ grep -n "ReportSchema\|isDatasetReport" packages/plugin-report/src/ReportRenderer.tsx # counter-probe
34:import { DatasetReportRenderer, isDatasetReport, type DatasetDrillArgs } from './DatasetReportRenderer';
90: if (isDatasetReport(schema)) {

The counter-probe (a term known present in the same file) returns real hits, so the tool works — the objectName search is a genuine zero for read points, not a broken grep. The 4 raw hits above are all comments describing the retired pre-9.0 form, a fixture asserting isDatasetReport(...objectName...) === false, and a "legacy spec report" test fixture (ReportRendererDispatcher.test.tsx:37) that is itself routed through specReportToPresentation (see below), which never reads report.columns/report.objectName — it only maps report.values/report.rows (dataset dimension/measure names). No production code branches on objectName. Premise confirmed still valid; the tree has not moved this claim since the card was filed.

Where hydration actually happens

ReportComponentSchema/ReportField (packages/types/src/reports.ts) is the presentation-layer schema this doc page teaches (the type: 'report' / report-builder / report-viewer components). It has no objectName property at all — grepped the whole file, the only objectName occurrence is in a doc-comment describing the aspirational (never-implemented) behaviour that this PR removes.

The actual read point is packages/plugin-report/src/ReportViewer.tsx, renderCellValue() (~line 164-198):

if(field.type){constfieldMeta: any={ ...field};if(field.colorMap&&!fieldMeta.options){/* colorMap → synthetic options */}constRenderer=getCellRenderer(resolveCellRendererType(fieldMeta));return<Renderervalue={value}field={fieldMeta}/>;}

field.type, field.options, field.referenceTo are read directly off the author-declared ReportField object (spread into fieldMeta) and passed straight into @object-ui/fields's getCellRenderer/resolveCellRendererType. Column headers use field.label || field.name (line 335/434, same file). There is no object-schema lookup anywhere in between — I traced ReportRenderer.tsx → DatasetReportRenderer.tsx (the live ADR-0021 dataset-bound path, unrelated — it hydrates measure format/label from the dataset, never from objectName) and specReportToPresentation (packages/types/src/spec-report.ts, the pre-9.0 bridge) — neither reads columns or objectName either.

What the page taught vs. what's real (fixed)

• :92-93 comment ("Auto-hydrated from the bound object's ObjectField when the report has an objectName") → replaced: type is author-provided only, cites ReportComponentSchema has no objectName.
• :130-132 paragraph (same claim for type/options/referenceTo/label) → replaced with the real mechanism above, naming ReportViewer.renderCellValue, getCellRenderer, and the field.label || field.name header fallback.
• Bonus, same file, same defect class (docs teaching a shape the code doesn't have), found while re-verifying the code samples compile against reality: the "Basic Usage", "Complete Example", and "Runtime Validation" snippets imported/annotated a ReportSchema type/schema that does not exist in @object-ui/types or @object-ui/types/zod — confirmed by grep against packages/types/src/reports.ts:359, packages/types/src/zod/reports.zod.ts:141, and both barrel exports (packages/types/src/index.ts, packages/types/src/zod/index.zod.ts). The real exported name is ReportComponentSchema. Fixed all three call sites to the real name; left the page's title/prose use of "ReportSchema" as the informal product name untouched (not a compile-checkable claim, and out of this card's mandate to change page structure/voice).

Gate measurement for this file

• Fence languages in content/docs/core/report-schema.mdx: all 11 fenced blocks are plaintext (verified via grep -n '^```' content/docs/core/report-schema.mdx) — zero ts/tsx/typescript fences.
• scripts/check-doc-snippet-types.mjs only compiles fences whose language is in TS_FENCE_LANGUAGES = new Set(['ts', 'tsx', 'typescript']) (:196) and only collects blocks matching that set (scanFences, :349). This page has none, so this gate does not read this file's code blocks at all — running it (confirmed) requires a full multi-package dist build unrelated to this change and would not exercise the edited content, so I did not build the workspace just to run it.
• UNGATED_DOCS ledger (:212): content/docs/core/report-schema.mdx has no entry — correct, since that table is only for pages that do have ts/tsx fences but are excluded; this page has none of that language, so no entry is owed either way.

Commands run (this file's applicable gates)

At commit c177e16b4 (HEAD of this branch):

$ node scripts/check-doc-component-types.mjs
✅ Every documented component type is registered.
$ node scripts/check-doc-links.mjs
Links are valid across 13 scan roots.
$ node scripts/check-control-bytes.mjs
✅ check-control-bytes: OK (scanned 4663 tracked text file(s); skipped 85 binary).
$ node scripts/check-changeset-presence.mjs
✅ No source of a released package changed in this range, so no changeset is owed.

content/docs/**-only change, confirmed no changeset owed by the script above (not assumed).

Scope

File surface: content/docs/core/report-schema.mdx only. Did not touch packages/plugin-report (read-only, to trace the render path — sibling card #5225 is in flight there for an unrelated test-network fix; nothing I read suggests it changes ReportViewer.renderCellValue or the dispatch path above). Did not touch neighbouring docs (#5047, #4600 cover the same defect class elsewhere, out of this card's scope).

---

Generated by Claude Code