finding(docs/guide): schema-rendering.md teaches a chart node binding node-level `data` to a `${...}` expression — not evaluated (the #6665 shape), and a parse refusal since #7113

[claude]

Measured while implementing #7112 (PR #7679), which corrects the chart examples in
packages/types/examples/data-display-examples.json, content/docs/api/schema-reference.md
and content/docs/core/report-schema.mdx. This site is in a fourth file, outside that
card's dispatched surface, so it is filed here rather than fixed there.

Measured on origin/main a472b0716.

The site

content/docs/guide/schema-rendering.md:144 teaches a chart node that binds its rows to an
expression written at node level:

{
  "type": "chart",
  "chartType": "bar",
  "data": "${chartData}"
}

Two things are wrong with it, and the second one is new

1. The expression is not evaluated there. This is the chart sibling of #6665, which
measured the same shape on data-table and was closed as completed: a ${...} expression
written into node-level data is not evaluated — Array.isArray is false and the node falls
back to empty — while the same expression under properties IS evaluated. The author gets a
correct-looking chart frame with nothing plotted, no error and no warning.

2. Since #7113 it is also a parse refusal. ChartSchema.data is now declared
z.array(z.record(...)), so the documented node no longer merely renders empty — it is
refused by name. Measured against the built @object-ui/types zod mirror, with a control in
the same run so the instrument is demonstrably not blind:

FAIL  expression-bound data: "${chartData}"
        path=["data"] :: Invalid input: expected array, received string
PASS  CONTROL same node with literal rows

The control is the identical node with data: [{ x: 1 }]; it passes, so the refusal is about
the authored string and not about the rest of the document.

Why this is not #7112, and not a duplicate of #6665

• Not finding(docs/types): five documentation and example sites author the retired ChartDataSeries.data and teach categories as X-axis labels #7112. That card's dispatched file surface is the three files named above, and its
  defect family is the retired inline series[].data model plus categories taught as axis
  labels. This node authors neither: it carries no series and no categories. Different
  file, different key, different mechanism.
• Not data-table: a ${...} expression authored in node-level data is not evaluated and renders an empty body silently #6665. That one is data-table, it is closed, and its remediation was the renderer
  diagnostic plus skills/objectui/rules/protocol.md. It did not touch this page and did not
  cover chart. What is quoted from it here is the mechanism, which it established; the
  parse-refusal half above did not exist when it was written.

What a fix would decide

Whether the page should teach the properties spelling that #6665 measured as working, or
teach literal rows plus the documented data-binding route, is a judgement about what this
guide is for — it is the schema-rendering guide, and the surrounding examples are deliberately
minimal. Worth one look at whether other nodes on the same page bind node-level data to an
expression; only this one is a chart.

⛔ Deliberately unassigned and unlabelled, for triage.

---

Generated by Claude Code