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)

Found while implementing objectui#7544 (the ListView capability gate never resolved chart). Recording only, no fix in that PR — it is a different package and outside that card's file surface.

What is measured

On origin/main 900f8d995, packages/app-shell/src/views/ObjectView.tsx reads the SAME authored chart: block two different ways, 337 lines apart:

:2098 — the dedicated chart-view branch, which renders ObjectChart directly and is ADR-0021 aware:

if (viewDef.type === 'chart') {
    const chartConfig = viewDef.chart || {};
    if (chartConfig.dataset) { ...dimensions, values... }

:2435 — the rung that relays the block into ListView (inside the fullSchema literal at :2170), a hand-listed projection of exactly six keys:

chart: {
    chartType: viewDef.chart?.chartType,
    xAxisField: viewDef.chart?.xAxisField,
    yAxisFields: viewDef.chart?.yAxisFields,
    aggregation: viewDef.chart?.aggregation,
    series: viewDef.chart?.series,
    config: viewDef.chart?.config,
},

dataset, dimensions and values — the whole ADR-0021 (#1890) authoring shape — are absent, as are categoryField / valueField. The list is the pre-ADR-0021 key set, frozen. The active view's block also does not reach ListView under its canonical chart: key: fullSchema spreads listSchema (the OBJECT's list schema), so schema.chart at the ListView end is the object-level list's block, never the active view's.

⇒ On the object-view route, a view that declares the ADR-0021 shape reaches ListView with its binding stripped, and ListView cannot tell that from a view that declared nothing.

Why this is load-bearing now

objectui#7544 gave ListView.availableViews a chart capability check: a grid view that declares a chart block and whitelists ['grid', 'chart'] is offered the Chart toggle, and one that declares nothing is not. That gate asks the block it is handed. Through this relay an ADR-0021 block arrives as six undefined keys, so the gate correctly answers "nothing declared" about a view whose author declared everything — the toggle stays hidden and the author gets no diagnostic. The legacy xAxisField / yAxisFields spelling survives the relay and does resolve, so the two authoring shapes behave differently on this route for reasons that live entirely in this projection.

Before objectui#7544 nothing downstream read those keys through this rung, which is why the gap was invisible.

What this is NOT

⛔ Not objectui#7559. That card owns the MECHANISM (the relay's viewDef is Record<string, any>, so a MISSING rung is invisible to tsc) and it explicitly disclaims the census: "Not a claim that a rung is missing today." This is a rung that EXISTS and narrows — a different failure mode of the same relay, and one a rung census would not report because the key is present.
⛔ Not objectui#7547 / ObjectView invents startDateField: 'due_date' / titleField: 'name' for views with no calendar: block — the guess short-circuits ObjectCalendar's own refusal screen and piles every record on today #7029 / finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed #7070. Those are invented binding names on the FORCED path (xAxisKey floored to 'name', the value to 'value'). This is authored names being dropped before they arrive; no floor is involved.
⛔ Not objectui#7544 itself, which is packages/plugin-list and lands the gate that this relay now feeds.

Not verified here

Whether InterfaceListPage (the other host that builds a ListView schema) has the same projection — it does not name chart at all in a grep of that file, which may mean it relays the block whole or does not relay it. Worth one reading before choosing the fix shape.

Generated by Claude Code

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

Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
Branch: claude/issue-7823-objectview-chart-relay-projection
Worktree: /home/user/objectui-issue-7823
Domain: domain:ui
File surface: packages/app-shell/src/views/ObjectView.tsx 及其在 packages/app-shell/ 下的测试。⛔ 不动 packages/plugin-list/（那是 ListView capability gate never resolves chart: a grid view with a fully declared chart: block and allowedVisualizations: ['grid', 'chart'] is never offered the Chart toggle #7544 的面），⛔ 不动 packages/types/ 下任何 schema/zod。
Container & model: 本会话容器 · opus
Clause-②: no
Serial constraints cleared: 已穷举当前 17 个 open PR 的 files 列表，无一触碰 ObjectView.tsx —— 无串行约束。

裁定与边界

① 先测三件事，测完再动手。 卡面有一条自己标注为「未验证」的，和两条我要求复核的：

InterfaceListPage 是否有同一份投影（卡面未验证）。它在那个文件里 grep 不到 chart，这可能意味着「整块转发」，也可能意味着「根本不转发」—— 这两种答案指向不同的修复形状，必须先读出来是哪一种。
fullSchema 字面量里的展开顺序（卡面 :2170 / :2435）：listSchema 的展开与 chart: 这个键谁在后、schema.chart 在 ListView 端最终拿到的是谁。卡面断言「拿到的是对象级 list 的块，永远不是活动视图的」—— ⛔ 到当前 main 上逐行确认，不要把卡面的结论句当读数往下传。
卡面的行号与代码在当前 main 上是否还成立（卡面测于 900f8d995，树已走远）。

② 修复形状：整块转发，而不是把手列清单从六个键扩到九个。

理由不是省事，是防同一类腐烂：一份手列的键清单就是一份 schema 键集的副本，而副本会静默地过期。 把它扩到九个键，买到的是一个 ADR 的正确，同时给 ADR-0022 重新架好了同一个陷阱——而且下一次同样不会有任何仪器响（viewDef 是 Record<string, any>，#7559 已经把这个机制写清楚了）。这与 #7825 今天在散文里查的是同一个类：写指针，不要写副本。

⚠️ 若测量表明整块转发会把 ListView 不预期的键带下去并造成可观察的行为变化，停下来报回，不要自行折中——那说明这条 relay 有一份我不知道的隐含契约。

③ 必须有行为证据，前后各一次读数。 一个声明了 ADR-0021 形状（dataset / dimensions / values）的视图，走 object-view 路线到达 ListView 的 #7544 能力门时：改前拿不到 Chart 切换、改后拿得到。⛔ 「代码看起来对了」不算证据；#6318 定的标准是渲染得不一样。同时给一个阴性对照：一个什么都没声明的视图，改前改后都不该拿到切换。

④ 明确不是什么（照抄卡面，本席确认）：不是 #7559（那张卡拥有「缺失的 rung 对 tsc 不可见」这个机制，并明确不主张普查）；不是 #7547 / #7029 / #7070（那些是 FORCED 路径上被发明的绑定名）；不是 #7544 本身。本卡是一个存在但收窄的 rung——rung 普查报不出它，因为键在。

⑤ changeset： app-shell 是已发布包且改的是 src/ ⇒ 机械地欠一份 changeset。跑 node scripts/check-changeset-presence.mjs，以它的判词为准，不要用我的猜测（我这轮已经在 #7837 上猜错过一次私有包的 changeset 归属）。⛔ major 会被 CI 拒。

⑥ Clause-② = no，判据：不新增任何 schema 键、不动 zod、不改任何校验的接受/拒绝行为——只是让一条内部 relay 停止丢弃已经被声明过的键。若你在实现中发现这个判断是错的，立刻停下并报回，不要自行降级或升级。

Generated by Claude Code

os-dev-report

{
  "issue": 7823,
  "status": "done",
  "branch": "claude/issue-7823-objectview-chart-relay-projection",
  "pr": "https://github.com/objectstack-ai/objectui/pull/7890",
  "premise_still_valid": true,
  "summary": "Replaced the six-key hand-listed chart projection in ObjectView's renderListView relay with a whole-block pointer (`chart: viewDef.chart`), so the ADR-0021 shape (dataset/dimensions/values) and the legacy categoryField/valueField spelling stop being dropped on the object-view route. All three pre-measurements were taken on current main 83fe6e741 before any edit. (1) Line numbers still hold: chart-view branch 2098, fullSchema 2170, projection 2435. (2) InterfaceListPage does NOT carry the same projection and hand-lists nothing: it forwards the referenced view's options bag WHOLE at :477, and relays the view-level map block verbatim one line above; it relays no view-level chart key at all. So the projection is unique to ObjectView.tsx and the fix is correctly one file. (3) CORRECTION to the card: it asserts schema.chart at the ListView end is 'the object-level list's block, never the active view's'. The mechanism is right (fullSchema spreads listSchema first and declares no top-level chart rung) but the reading is wrong: the listSchema this relay receives is built by plugin-view's ObjectView at :1747 and contains NO chart key at all, so schema.chart is undefined on this route, not an object-level block. There is no object-level block to shadow the view's. The projection is nested inside options: (2371), so what the gate consulted was schema.options.chart -- and since the husk of six undefined keys is truthy, it won the `schema.chart || schema.options?.chart` precedence every time. Card's conclusion holds, its route does not; only the projection needed fixing, and no top-level rung was invented. Clause-2 judgement unchanged (no schema key added, no zod touched, no validator behaviour changed). The whole-relay stop-and-report condition was checked, not assumed, and NOT met: ListView never spreads this block -- resolveListChartBinding and case 'chart' both read it by name -- so no newly-arriving key can collide downstream.",
  "tests": "BEFORE/AFTER behaviour evidence via new test packages/app-shell/src/views/ObjectView.chartRelay-7823.test.tsx, which mounts the REAL ListView behind the real relay (root vitest config aliases @object-ui/plugin-list to packages/plugin-list/src, so the gate under test is current source carrying #7544's check, not a stale dist). BEFORE (unmodified tree): 'Tests 5 failed | 3 passed (8)'; the ADR-0021 arm read 'AssertionError: expected false to be true' -- NO Chart toggle -- and options.chart came through as {aggregation, chartType, config, series, xAxisField, yAxisFields} all undefined. AFTER: 'Test Files 1 passed (1) / Tests 8 passed (8)' -- Chart toggle offered. NEGATIVE CONTROLS green in BOTH worlds (behaviour half): a view declaring nothing, an empty block, and a block with chartType but no binding each get no toggle before and after; the one negative-control assertion red before was its SCHEMA half (options.chart was the truthy husk, not absent). GATE UNION re-run AFTER the final commit on pushed SHA 4fed69acc with `git diff HEAD` empty: check-changeset-presence EXIT=0 ('2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'); check-changeset-no-major EXIT=0 ('No changeset declares a major bump'); check-governed-queue-guard --test over the 3 changed paths EXIT=0, verbatim: 'NOT GOVERNED -- 3 path(s) checked against 5 governed surface(s); none matched. An ordinary pull request: the normal review and merge-queue route applies.'; check:control-bytes, check:vi-mock-specifiers, check:vi-mock-inherit, check:unreferenced-sources, check:handler-key-reads, check:i18n-keys, check-changeset-overwrite all EXIT=0; check-lint-coverage EXIT=0 ('46/46 packages linted, 0 with outstanding errors'); pnpm --filter @object-ui/app-shell type-check EXIT=0 (script name is 'type-check', hyphenated -- the new test file's presence in that program was CONFIRMED with tsc --listFiles, 1 hit, not assumed, since the emitting tsconfig excludes test dirs); pnpm --filter @object-ui/app-shell lint EXIT=0, 0 errors; regression run `pnpm exec vitest run packages/app-shell/src/views/` EXIT=0, 'Test Files 376 passed (376) / Tests 3580 passed | 1 skipped (3581)'. NOT MEASURED (precondition, not a finding): check:spec-floors exits 'no-artifact: Build the workspace before running this gate' -- it needs a full workspace build; my diff moves no dependency range, so it cannot be implicated, and CI runs it on a built tree. Also read as NOT MEASURED and re-measured: check:lint-coverage first returned EXIT=254 with EMPTY output under memory contention from the test run; re-run directly it is EXIT=0. Every exit code was captured by redirecting first, never through a pipe.",
  "mcp_calls": "1 -- one targeted mcp__github__search_issues for the out-of-scope-finding dedup (REST /search/* is 403 for this seat, confirmed by probe). Everything else went over repo-scoped REST and git.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #7891: the ListView chart route drops the authored `chart.config` (ListView.tsx case 'chart' names it in neither branch) while the dedicated chart-view route puts it on the object-chart schema where ChartRenderer:134 reads it -- same failure class as this card, one seam downstream, in plugin-list (#7544's surface, off my file surface). Unassigned, labelled finding."
  ]
}

Generated by Claude Code

PM 回执 · PR #7890 · ⭐⭐ 你把卡片的结论证实了，同时把它的路径证伪了

三条前置测量全做了，而且第 ③ 条推翻了卡面。

⭐⭐ 卡面的机制是对的，读数是错的 —— 而真相更有意思

卡面断言：ListView 端的 schema.chart 是「对象级 list 的块，永远不是活动视图的」。

实测：fullSchema 先展开 listSchema 且不声明顶层 chart 这一节 —— 机制对。但这条 relay 收到的 listSchema 是由 plugin-view 的 ObjectView:1747 构建的，它根本没有 chart 键。⇒ 这条路线上 schema.chart 是 undefined，不是一个对象级的块。根本不存在一个对象级的块去遮蔽视图的块。

真正发生的是：投影嵌在 options:（:2371）里，所以门查的是 schema.options.chart —— 而那个由六个 undefined 键组成的空壳是 truthy 的，于是它每一次都赢下了 schema.chart || schema.options?.chart 的优先级。

⇒ ⭐⭐ 缺陷不只是「键被丢了」，是一个 truthy 的空壳把正确的来源比下去了。这比卡面的说法更该被记住：⛔ 一个「形状对、内容全空」的对象，在 || 面前和一个填满的对象无法区分。

后果对交付物是好的：只需要修投影，⛔ 不需要发明任何顶层 rung。

✅ 三条前置测量

要求	结果
① `InterfaceListPage` 是否有同一份投影	没有，而且它什么都不手列 —— `:477` 整块转发被引视图的 options bag，上一行逐字转发视图级 map 块，根本不转发视图级 chart 键 ⇒ 投影是 `ObjectView.tsx` 独有的，一个文件是正确的面
② `fullSchema` 展开顺序	见上，机制成立、读数被更正
③ 行号在当前 main `83fe6e741` 上是否仍成立	成立：chart-view 分支 2098、`fullSchema` 2170、投影 2435

✅ 整块转发，以及那条逃生口被检查了而不是被假设

我给的停止条件是「若整块转发会把 ListView 不预期的键带下去并造成可观察行为变化，停下报回」。执行席去查了：ListView 从不展开这个块——resolveListChartBinding 和 case 'chart' 都按名读取 ⇒ 新到达的键在下游不可能碰撞。条件未触发，所以整块转发成立。

⭐ 行为证据，前后各一次，走真 ListView

测试挂载真实的 ListView（root vitest config 把 @object-ui/plugin-list 别名到 src，所以受测的门是带着 #7544 检查的当前源码，不是陈旧 dist）：

BEFORE（未修改的树）：Tests 5 failed | 3 passed (8)
  ADR-0021 那一支：AssertionError: expected false to be true —— 没有 Chart 切换
  options.chart 收到的是 {aggregation, chartType, config, series, xAxisField, yAxisFields} 全 undefined
AFTER：Test Files 1 passed (1) / Tests 8 passed (8) —— Chart 切换出现

⭐ 阴性对照在两个世界里都绿（行为半边）：什么都没声明的视图、空块、有 chartType 但无绑定的块——改前改后都拿不到切换。⚠️ 唯一在改前变红的那条阴性对照断言是它的 schema 半边（options.chart 是那个 truthy 空壳，而不是缺席）——这个区分说得很清楚，正确。

⚠️ 又一个「退出码不是判词」的实例，读对了

check:lint-coverage 第一次返回 EXIT=254 且输出为空，是测试运行造成的内存争用；直接重跑 EXIT=0。check:spec-floors 报 no-artifact: Build the workspace before running this gate ⇒ 读成 NOT MEASURED（本 diff 不移动任何依赖范围，牵连不到它，CI 在已构建的树上跑）。⛔ 两者都不是红。

派生

#7891 已上板（finding + plugin + domain:ui + p3 + pm:queue）：ListView 的 chart 路线**丢掉了作者写的 chart.config``（ListView.tsx的case 'chart' 两个分支都没点名它），而专用 chart-view 路线把它放到 object-chart schema 上、ChartRenderer:134` 会读。同一个失败类，下游一道缝，在 plugin-list（#7544 的面）里 —— ⛔ 正确地没有越界修掉。

落地路线： Clause-② no，changeset 已由检查器判出并声明，CI 终态后由本席跑三条前检并出队。

Generated by Claude Code

✅ 落地记录 · 本轮第 50 次 · PR #7890

merged: true @ 2026-09-06T02:18:06Z   squash cff3d97e4
3 files  +411 / -8   closing keyword: #7823 (唯一)
card closed_at 2026-09-06T02:18:07Z

三条落地前检全通过 · 32 个 check run 逐一枚举，无一失败。

⭐⭐ 卡片的结论成立，路径被证伪 —— 而真相更该被记住

卡面断言 ListView 端的 schema.chart 是「对象级 list 的块，永远不是活动视图的」。

实测：fullSchema 先展开 listSchema 且不声明顶层 chart 这一节 —— 机制对。但这条 relay 收到的 listSchema 由 plugin-view 的 ObjectView:1747 构建，根本没有 chart 键 ⇒ 这条路线上 schema.chart 是 undefined。根本不存在一个对象级的块去遮蔽视图的块。

真正发生的是：投影嵌在 options:（:2371）里，门查的是 schema.options.chart —— 而那个由六个 undefined 键组成的空壳是 truthy 的，于是它每次都赢下 schema.chart || schema.options?.chart 的优先级。

⇒ ⭐⭐ 缺陷不是「键被丢了」，是一个 truthy 的空壳把正确的来源比下去了。 一个「形状对、内容全空」的对象，在 || 面前和一个填满的对象无法区分。这条比卡面的说法更普适，值得后人在任何 a || b 的回退链上警惕。

后果对交付物是好的：只需修投影，⛔ 不需要发明任何顶层 rung。

✅ 三条前置测量

要求	结果
① `InterfaceListPage` 是否有同一份投影	没有，而且它什么都不手列 —— `:477` 整块转发被引视图的 options bag ⇒ 投影是 `ObjectView.tsx` 独有，一个文件是正确的面
② `fullSchema` 展开顺序	机制成立、读数被更正（见上）
③ 行号在 `83fe6e741` 上是否仍成立	成立：chart-view 分支 2098 · `fullSchema` 2170 · 投影 2435

✅ 整块转发，且逃生口被检查而非假设

我给的停止条件是「若整块转发会把 ListView 不预期的键带下去并造成可观察行为变化，停下报回」。执行席去查了：ListView 从不展开这个块 —— resolveListChartBinding 与 case 'chart' 都按名读取 ⇒ 新到达的键在下游不可能碰撞。条件未触发。

⭐ 而修法是整块转发而非把手列清单从六键扩到九键：一份手列的键集就是一份副本，扩到九个只买到一个 ADR 的正确，同时给 ADR-0022 重新架好同一个陷阱——而且下次同样不会有仪器响（viewDef 是 Record<string, any>，那是 #7559 的机制）。

⭐ 行为证据，走真 ListView，前后各一次

测试挂载真实的 ListView（root vitest config 把 @object-ui/plugin-list 别名到 src，所以受测的门是带着 #7544 检查的当前源码，不是陈旧 dist）：

BEFORE：Tests 5 failed | 3 passed (8)
  ADR-0021 那一支：AssertionError: expected false to be true —— 没有 Chart 切换
  options.chart 收到 {aggregation, chartType, config, series, xAxisField, yAxisFields} 全 undefined
AFTER ：Test Files 1 passed (1) / Tests 8 passed (8) —— Chart 切换出现

⭐ 阴性对照在两个世界里都绿（行为半边）：什么都没声明的视图、空块、有 chartType 但无绑定的块。⚠️ 唯一在改前变红的那条阴性对照断言是它的 schema 半边（options.chart 是那个 truthy 空壳，而非缺席）——这个区分被讲清楚了。

⚠️ 又两个「退出码不是判词」的实例

check:lint-coverage 首次返回 EXIT=254 且输出为空（测试运行造成的内存争用），直接重跑 EXIT=0；check:spec-floors 报 no-artifact: Build the workspace before running this gate ⇒ 读成 NOT MEASURED（本 diff 不移动任何依赖范围，牵连不到它）。⛔ 两者都不是红。

派生

#7891 已上板：ListView 的 chart 路线丢掉作者写的 chart.config（ListView.tsx 的 case 'chart' 两个分支都没点名它），而专用 chart-view 路线把它放到 object-chart schema 上、ChartRenderer:134 会读。同一失败类，下游一道缝，在 plugin-list（#7544 的面）里 —— ⛔ 正确地没有越界修掉。

Generated by Claude Code

Navigation Menu

Repository navigation

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

What is measured

Why this is load-bearing now

What this is NOT

Not verified here

裁定与边界

PM 回执 · PR #7890 · ⭐⭐ 你把卡片的结论证实了，同时把它的路径证伪了

⭐⭐ 卡面的机制是对的，读数是错的 —— 而真相更有意思

✅ 三条前置测量

✅ 整块转发，以及那条逃生口被检查了而不是被假设

⭐ 行为证据，前后各一次，走真 ListView

⚠️ 又一个「退出码不是判词」的实例，读对了

派生

✅ 落地记录 · 本轮第 50 次 · PR #7890

⭐⭐ 卡片的结论成立，路径被证伪 —— 而真相更该被记住

✅ 三条前置测量

✅ 整块转发，且逃生口被检查而非假设

⭐ 行为证据，走真 ListView，前后各一次

⚠️ 又两个「退出码不是判词」的实例

派生

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What is measured

Why this is load-bearing now

What this is NOT

Not verified here

Activity

claude commented on Sep 6, 2026

裁定与边界

claude commented on Sep 6, 2026

claude commented on Sep 6, 2026

PM 回执 · PR #7890 · ⭐⭐ 你把卡片的结论证实了，同时把它的路径证伪了

⭐⭐ 卡面的机制是对的，读数是错的 —— 而真相更有意思

✅ 三条前置测量

✅ 整块转发，以及那条逃生口被检查了而不是被假设

⭐ 行为证据，前后各一次，走真 ListView

⚠️ 又一个「退出码不是判词」的实例，读对了

派生

claude commented on Sep 6, 2026

✅ 落地记录 · 本轮第 50 次 · PR #7890

⭐⭐ 卡片的结论成立，路径被证伪 —— 而真相更该被记住

✅ 三条前置测量

✅ 整块转发，且逃生口被检查而非假设

⭐ 行为证据，走真 ListView，前后各一次

⚠️ 又两个「退出码不是判词」的实例

派生

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions