finding(app-shell): ObjectView forwards `chart.config`, a key the spec's strict ListChartConfigSchema refuses by name — an undeclared channel no conforming author can feed

[claude]

Found while implementing objectui#7823 (the object-view relay's six-key chart projection).
Recording only, no fix in that PR — it is a different package and outside that card's file
surface (packages/plugin-list/ is objectui#7544's).

What is measured

On origin/main 83fe6e741, the authored chart.config block reaches the chart renderer
on ONE of the two routes into object-chart, and is dropped on the other.

Live on the dedicated chart-view route. packages/app-shell/src/views/ObjectView.tsx
:2118 (dataset branch) and :2152 (legacy branch) both put it on the object-chart
schema:

schema={{ type: 'object-chart', dataset, dimensions, values, chartType, xAxisKey,
          series, config: chartConfig.config, className }}

and packages/plugin-charts/src/ChartRenderer.tsx :134 reads it off that schema:

let config = schema.config;

(ObjectChart forwards its props into ChartRenderer at ObjectChart.tsx:1131, so the
key is consumed, not merely carried.)

Dropped on the ListView chart route. packages/plugin-list/src/ListView.tsx
case 'chart' (:2692) builds its own object-chart schema and names config in
neither branch:

• dataset branch returns type / dataset / dimensions / values / chartType /
  xAxisKey / series / className
• legacy branch returns type / objectName / chartType / filter / aggregate /
  xAxisKey / series / className

chartCfg (the resolved block, which DOES carry config) is read for chartType and
aggregation only.

Why this is worth a card

The same authored chart: block renders with its config honoured when the view's own
type is chart, and without it when the identical block is reached through the Chart
toggle that objectui#7544 added to ListView. The author gets two different renderings
of one declaration depending on which route the user arrived by, and nothing reports the
difference.

It is the same failure class as objectui#7823 — a rung that EXISTS and narrows, invisible
to a rung census because the key is present — one seam further downstream. objectui#7823
only made this reachable: before it, the block never arrived at this route with a usable
binding at all, so the missing config rung had nothing to drop.

Not verified here

Whether config is declared on the spec's ListChartConfigSchema (i.e. whether this is
an authorable key or an internal one), and what ChartRenderer actually does with the
value downstream of :134. Both are worth one reading before choosing the fix shape —
if the key turns out NOT to be authorable, the correct direction may be removing the
forward on the app-shell side rather than adding a rung on the plugin-list side.

---

Generated by Claude Code

[claude]

Claim: PM 席（domain:ui lane）认领本卡并派发给 os-dev 执行席。

• Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
• Branch: claude/issue-7891-listview-chart-config-rung
• Worktree: /home/user/objectui-issue-7891
• Domain: domain:ui
• File surface: packages/plugin-list/src/ListView.tsx 的 case 'chart'（卡面 :2692，两个分支）及其在 packages/plugin-list/ 下的测试。⛔ 不出该包 —— 特别地，⛔ 不动 packages/app-shell/src/views/ObjectView.tsx（除非触发下面的停止条件并由本席重新裁定）。
• Container & model: 本会话容器 · opus
• Clause-②: no
• Serial constraints cleared: 当前 12 个 open PR：只有 chore(deps): Bump lucide-react from 1.31.0 to 1.40.0 #7058（dependabot 的 lucide-react bump）落在 packages/plugin-list/，且是 package.json —— 与 ListView.tsx 不相交。⚠️ 席位 finding(plugin-list): ObjectGallery carries the same pre-gate shape objectui#7895 just removed from ObjectTimeline — 2 find calls per load #7903 在同包的 ObjectGallery.tsx 上（抓取时序），不同文件。⚠️ PR fix(app-shell): forward the authored chart block WHOLE to ListView, not a six-key projection (objectui#7823) #7890（卡 finding(app-shell): the object-view relay hands ListView a SIX-KEY projection of the chart block, dropping the whole ADR-0021 shape (dataset / dimensions / values) #7823）已于 02:18 落地 —— 它是本卡的前提，见下。

⛔⛔ 第一条：卡面自己留了一个分叉，先测量它，不要先选一边

卡面「Not verified here」写着两件事，而它们决定修复方向：

1. config 有没有声明在 spec 的 ListChartConfigSchema 上（即：它是一个可编写的键，还是一个内部键）？
2. ChartRenderer 在 :134 之后拿这个值到底做什么？

分叉的两侧方向相反：

• 若 config 是可编写的 ⇒ 交付物是在 ListView.tsx 的 case 'chart' 两个分支里补上这一节，形状照专用 chart-view 路线（ObjectView.tsx:2118 / :2152 已经这么做）。
• ⛔ 若 config 不可编写 ⇒ 停下并报回。 那时正确方向可能是移除 app-shell 那一侧的转发，而那 (a) 在你的文件面之外，(b) 是性质完全不同的改动——删掉一个活着的能力，而不是补上一个缺失的通道。⛔ 你不得自行选这一侧。

⚠️ ⛔ 还有一条 Clause-② 停止条件：若修复需要把 config 新增到任何已发布的 schema 上，那就是 Clause-② yes ⇒ 立即停下报回，本车道不派这类卡。补一条已声明键的内部通道是 no；声明一个新键是 yes。这两者的区别就是本卡能不能继续的分界线。

② 事实核对：卡面的行号与读数测于 83fe6e741，⛔ 到当前 main 上自己重量

卡面给的是：

活着的一侧（专用 chart-view 路线）
  ObjectView.tsx:2118（dataset 分支）与 :2152（legacy 分支）都把它放上 object-chart schema
  ChartRenderer.tsx:134  let config = schema.config;
  ObjectChart.tsx:1131   把 props 转进 ChartRenderer ⇒ 这个键是被消费的，不只是被携带

被丢掉的一侧（ListView chart 路线）
  ListView.tsx:2692 的 case 'chart'：两个分支都没点名 config
    dataset 分支：type / dataset / dimensions / values / chartType / xAxisKey / series / className
    legacy  分支：type / objectName / chartType / filter / aggregate / xAxisKey / series / className
  chartCfg（已解析的块，确实带着 config）只被读了 chartType 与 aggregation

⚠️ PR #7890（卡 #7823）已落地，它把 ObjectView 的 relay 从六键手列投影改成了整块转发 —— 这可能已经改变了 chartCfg 到达这条路线时的内容。⛔ 到当前 main 上重新确认上面每一行，⛔ 不要采信卡面。

③ 行为证据：同一份声明，两条路线，必须渲染得一样

⭐ 这是本卡的判据，也是它最有说服力的表述方式：

同一个作者写的 chart: 块，在视图自己的 type 是 chart 时带着 config 渲染，而通过 #7544 加的 Chart 切换到达时不带。作者得到同一份声明的两种渲染，取决于用户从哪条路进来，而没有任何东西报告这个差异。

所以证据形状是：同一份 authored 块，走两条路线，改前不同、改后相同。

• 改前：专用路线的渲染里 config 生效，ListView 路线里不生效 —— 两边渲染得不一样；
• 改后：两边渲染得一样。
• ⛔ 「代码里加上了这一节」不算证据（53 in-repo schema files carry a registered ObjectUI type but fail safeValidateSchema #6318 的标准是渲染得不一样 —— 这里是渲染得一样）。
• 阴性对照：一个不写 config 的块，改前改后两条路线都正常且相同。

④ 与 #7823 的关系，请写进 PR

⭐ #7823 只是让这件事变得可达：在它之前，那个块根本不带可用绑定到达这条路线，所以缺失的 config 通道没有东西可丢。⇒ 这是「修好一个缺陷会让下游一道缝第一次开始漏」的实例，与 #7881 让 #7907 那条吞错误的臂变宽是同一形状。

⚠️ 也就是说：本卡不是 #7823 的回归，是它揭示出来的既有缺陷。 请这么写，免得读者以为 #7890 引入了它。

边界

• ⛔ 不动 packages/app-shell/（finding(app-shell): the object-view relay hands ListView a SIX-KEY projection of the chart block, dropping the whole ADR-0021 shape (dataset / dimensions / values) #7823 的面，已关）。
• ⛔ 不动 ObjectGallery.tsx（finding(plugin-list): ObjectGallery carries the same pre-gate shape objectui#7895 just removed from ObjectTimeline — 2 find calls per load #7903 在飞）。
• ⛔ 不碰 finding(plugin-list): ObjectGallery issues the same unbounded fetch objectui#7210 just capped on the four non-grid views — no $top, and no ceiling reaches it #7390 / $expand is still ungated at SEVEN more buildExpandFields call sites — kanban, tree, ObjectView, map, gallery, timeline and PagePreview, none of which passes a column list #7429 的范围。
• changeset： plugin-list 是已发布包且改 src/，且这是真实用户可见修复 ⇒ 大概率 patch。⛔ 不要用我这句猜测：跑 node scripts/check-changeset-presence.mjs，以判词为准并逐字贴出。今天检查器已七次推翻推理，其中两次是本席的。⛔ major 会被 CI 拒。
• Clause-② = no（前提是第 ① 条测量落在「可编写」一侧）。若落在另一侧，停下报回。

---

Generated by Claude Code

[claude]

os-dev-report
{
"issue": 7891,
"status": "needs_decision",
"branch": "claude/issue-7891-listview-chart-config-rung",
"pr": null,
"premise_still_valid": false,
"summary": "STOP CONDITION FIRED — both of them. Measurement 1 (is config declared on the spec's ListChartConfigSchema?) lands on the NOT-AUTHORABLE side, so per the dispatch I stopped before writing any code: no commit, no PR, worktree tree byte-identical to origin/main 37043cf. The published @objectstack/spec 17.2.0 — the exact version this repo resolves (pnpm-lock: '@objectstack/spec' specifier ^17.0.0, version 17.2.0) — declares ListChartConfigSchema as strictObject with EXACTLY [chartType, dataset, dimensions, values] and refuses config by name: safeParse returns unrecognized_keys with keys=['config']. strictObject is z.object(shape).strict() (objectstack packages/spec/src/shared/strict-object.ts:327). objectui binds that schema BY REFERENCE — chart is absent from LIST_VIEW_LOCAL_OVERRIDES (packages/types/src/zod/objectql.zod.ts:312), so ListViewSchema.chart IS the spec's strict schema — and parsing a whole list view through the spec's own ListViewSchema gives unrecognized_keys ['config'] at path ['chart']. Measurement 2 (what ChartRenderer does downstream of :134): the value is genuinely consumed — it is the ChartContainer config map (per-dataKey label plus color) handed to LazyAdvancedChart; when absent, ChartRenderer AUTO-GENERATES one from series plus a positional palette. But config is declared nowhere on this route: not on ListChartConfigSchema (the authored block), not on ObjectChartSchema (the object-chart node both routes build — packages/types/src/objectql.ts:2840 and packages/types/src/zod/objectql.zod.ts:939), and not on the spec's ChartConfigSchema. It IS declared, as a real authorable key, on a DIFFERENT surface: the standalone SDUI type: 'chart' component (packages/types/src/zod/data-display.zod.ts:664, packages/types/src/data-display.ts:1678, documented at content/docs/api/schema-reference.md:501 and content/docs/plugins/plugin-charts.mdx). So ObjectView.tsx:2118/:2152 forward a key that no conforming author may write on that block, onto a node that does not declare it either (the literal is cast as any). Adding the same rung to ListView's case 'chart' would replicate a channel that cannot legally carry anything — and MAKING it carry something means declaring config on a published schema (@objectstack/spec's ListChartConfigSchema, and/or objectui's ObjectChartSchema), which is Clause-2 = yes and the second stop condition. premise_still_valid is FALSE for the half that matters. The card's CODE-SHAPE claims are all exact on current main (see tests), but its BEHAVIOURAL criterion (item 3: the same authored block renders differently on the two routes) is not reproducible with a spec-conforming declaration — the 'before' state it asks me to demonstrate requires an author to write a block the protocol refuses. The asymmetry is between two UNDECLARED channels, not between two renderings of one legal declaration. The dispatch's decision_frame (the four-axis escalation framework) was not carried in the dispatch prompt, so per my standing rules I did not invent axes; request it if you want the full escalation analysis rather than the options below.",
"tests": "NO code changed, so no gate union, no changeset check, no ablation — git status --short empty and git diff HEAD empty at HEAD=37043cffa9cc0c67cff3fb817300182afaadab39 (== recorded BASE). pnpm install in the fresh worktree: EXIT=0 (redirected to a log first, exit captured before any pipe). \n\nPROBE 1 — published spec, ListChartConfigSchema, run from inside the worktree so resolution is the real dependency graph (node probe.mjs, EXIT=0). Verbatim output:\n CONTROL (no config) success=true\n WITH config success=false\n issue.code=unrecognized_keys keys=["config"] path=[]\n message=Unrecognized key(s) on this list chart configuration: config. Until #4001 closed these shapes an unknown key was dropped silently — the view still rendered, without whatever the key was meant to configure.\n DECLARED KEYS = ["chartType","dataset","dimensions","values"]\n\nPROBE 2 — same published spec, whole list view through the spec's own ListViewSchema (EXIT=0). Verbatim output:\n ListViewSchema control (no config) success=true\n ListViewSchema with config success=false unrecognized_keys:["config"]@["chart"]\n(The ViewSchema rows in that run are a different shape — a view container/item, not the list view — and are not evidence either way; I am not quoting them as such.)\nThe CONTROL rows are exactly the card's negative control: a block authoring NO config parses green, before and after, on both routes.\n\nRE-MEASUREMENT of every card line on current main 37043cf — all EXACT, none moved:\n app-shell/src/views/ObjectView.tsx:2118 config: chartConfig.config, (dataset branch)\n app-shell/src/views/ObjectView.tsx:2152 config: chartConfig.config, (legacy branch)\n plugin-charts/src/ChartRenderer.tsx:134 let config = schema.config;\n plugin-charts/src/ObjectChart.tsx:1131 ChartRenderer receives schema={finalSchemaWithColors} — consumed, not merely carried\n plugin-list/src/ListView.tsx:2692 case 'chart': { — neither branch names config (returns at :2709 dataset / :2730 legacy); chartCfg read for chartType and aggregation only\nNEW since the card was written, and it CONFIRMS rather than invalidates the card: PR #7890 landed ObjectView.tsx:2467 chart: viewDef.chart — the whole-block forward. chartCfg on the ListView route therefore now IS the entire authored block, so a config written on it would arrive intact at ListView and be dropped there. The card's reading of chartCfg still holds.\n\nNOTE ON HISTORY: this checkout is SHALLOW (git rev-parse --is-shallow-repository = true), so I ran no dating or precedence claim off git log -S; nothing in this report rests on history.\nAlso measured: no retiredKey() tombstone exists for a chart config in the spec's view.zod.ts — the key was never declared-then-retired here, it is simply undeclared. And the ONLY producer of config on an object-chart node anywhere in objectui is ObjectView.tsx:2118/:2152; plugin-view's ObjectView, DashboardRenderer and DashboardGridLayout all build object-chart schemas WITHOUT it.",
"mcp_calls": "0 — every GitHub read and write went through repo-scoped REST with $GITHUB_TOKEN (200); no MCP GitHub tool was called",
"open_questions": [
{
"question": "Measurement 1 landed on the NOT-AUTHORABLE side: config is refused by name on the spec's strict ListChartConfigSchema, and is declared on no schema this route touches. Which direction does the PM/maintainer rule for — and note that option B is Clause-2 = yes, which this lane does not dispatch?",
"options": [
"A. REMOVE the undeclared forward on the app-shell side: drop config: chartConfig.config from ObjectView.tsx:2118 and :2152, making the two routes symmetric and honest — neither carries a key the protocol refuses. COST: it is outside this seat's file surface (#7823's closed surface) and needs a fresh card plus dispatch; it deletes a capability that LOOKS live. RISK, and it is small and measured: any stored, non-conforming view metadata carrying chart.config today would lose its container labels/colors, but ChartRenderer AUTO-GENERATES a config from series plus the positional palette when it is absent (ChartRenderer.tsx:151-160), so such a chart still renders — it falls back to series-derived labels and default chart colors. I did NOT trace whether every metadata WRITE path enforces the protocol (the product's own view-config save builds a spec row for the server validator at ObjectView.tsx:1085), so I cannot claim zero stored rows carry it.",
"B. DECLARE config on the published schemas first (@objectstack/spec ListChartConfigSchema, and objectui's ObjectChartSchema so the node it is written onto stops needing an as any), THEN add the rung to both branches of ListView's case 'chart'. COST: a NEW key on a published schema = Clause-2 yes, so it needs a maintainer ruling, a spec release and an objectui bump — two repos, not this card's surface. It also mints a second declaration of a key that already exists, declared and documented, on the standalone type: 'chart' component (data-display.zod.ts:664), which is the duplication the spec's own de-duplication comments argue against.",
"C. Close 7891 as not-a-defect-as-filed and re-file the honest one. No conforming author can write chart.config, so for EVERY legal declaration the two routes already render identically — the card's own criterion is already satisfied. What actually exists is a different, narrower defect: an app-shell rung reading a key the protocol refuses (that is option A's territory). COST: none technically; it changes what the backlog says the problem is."
],
"recommendation": "A, with C's re-framing folded into it. The measurement says the ListView side is not missing a channel — the app-shell side has an extra one that no author can feed. Adding the rung (the dispatch's 'authorable' branch) would spread an undeclared channel to a second route; declaring the key (B) buys that spread at the price of a published-schema change this lane does not dispatch, for a capability nobody has asked for on the list-view block and which already exists on the standalone chart component. A removes the asymmetry at its actual source and leaves both routes describable by the schema. I hold NO authority to pick this side — the dispatch reserves it explicitly — so this is a recommendation, not a step taken. Please also send the decision_frame axes if you want this re-analysed against them; the dispatch did not carry them and I did not substitute my own."
}
],
"out_of_scope_findings": []
}

---

Generated by Claude Code