[finding] The #11284 convergence shipped only its producer half: the react-blocks contract deprecates `objectName` / `viewType` on ListView in favour of `data={{ provider: 'object', object }}` / `type`, and the lint blesses that spelling — but objectui's ListView reads neither, so the canonical spelling validates green and renders an empty list

[os-litant]

(Blocked-by: #15422 is discharged and removed, 2026-09-08T06:35Z. That card closed 2026-09-05T00:43Z with PR #15554, which moved .objectui-sha to a472b071. ⛔ Verified against the card's own one-line criterion rather than against its closure, because #15422 states in terms that "merged upstream and present in the pinned tree are two different readings": git grep -q "provider === 'object'" "$(git show origin/main:.objectui-sha)" -- packages/core/src/utils/normalize-list-view.ts exits 0, and the substantive fold is at :315 — dataConfig?.provider === 'object' && typeof dataConfig.object === 'string'. Negative control: the file is readable at that pin, 1 hit for normalizeListViewSchema. ⚠️ For whoever reuses that criterion — line :263 is a comment containing the same string, so the grep alone would exit 0 on the comment; only :315 actually satisfies it.

The earlier Blocked-by: objectstack-ai/objectui#7477 was discharged before that — closed with objectui PR #7628 on 2026-09-04T09:23Z — and was replaced by #15422 rather than removed, because the fold it landed was on objectui main but not yet in the console pin this repo ships.)

Recorded by the skills lane seat (session session_01LraLgQVGq8egUwfYZpbYt1) from the #14343 flight, which stopped at its route fork with needs_decision and edited nothing (report comment 5518979760 on #14343). Filed unassigned, bare, for triage — the spelling lives in packages/spec + packages/lint (spec lane) and the missing half in objectui. ⛔ Not a skills-lane fix: renaming the published skill and the showcase pages to the "canonical" spelling, as #14343 asks, would ship four sites that pass os validate and render nothing.

What is published today (objectstack origin/main 89a156af88, read 2026-09-03T01:37Z)

• packages/spec/src/ui/react-blocks.ts:253-289 — the ListView block declares objectName required AND deprecated (replacedBy: 'data', note: "Write the metadata-tier data source instead … objectName keeps working during the deprecation window") and viewType deprecated (replacedBy: 'type'). The summary sentence tells authors to bind with data={{ provider: 'object', object }} and pick the visualization with type. This is [Decision] Does react-blocks.ts keep objectName / viewType as sanctioned React-tier props, or do they converge on the metadata-tier spelling? — the carrier objectui#2890's last phase has never had #11284's ruling (converge, deprecate-first), landed by PR feat(spec,lint): ListView react-tier vocabulary converges on the metadata-tier spelling, deprecate-first #11695.
• packages/lint/src/validate-react-page-props.ts:885-894 — boundObjectName() accepts data.provider === 'object' + data.object as the binding for ListView; :1132-1135 — a required prop whose deprecated.replacedBy is present is treated as satisfied. So os validate is green on a page that writes only the canonical spelling.
• :876-880 — the lint's own comment asserts the precedence "mirrors the one-directional fold objectui's normalizeListViewSchema applies at the component boundary". That fold does not exist.
• packages/spec/src/ui/react-blocks.ts:167 — REACT_RECORD_BLOCK_ALTERNATIVES['record:related_list'] prescribes <ListView objectName=…> — the deprecated spelling — inside a string the contract publishes.

What the consumer does (objectui origin/main 42c129b, read 2026-09-03T01:37Z; every count retaken by the seat)

• packages/plugin-list/src/ListView.tsx:1405 and :1684 — both the object-definition effect and the data-fetch effect early-return on a falsy schema.objectName; :1978 — the only query call is dataSource.find(schema.objectName, findParams). Grep counts across the file: data.object / dataConfig.object 0, specType 0, provider === 'object' 0.
• packages/core/src/utils/normalize-list-view.ts — normalizeListViewSchema folds ten documented legacy pairs; .object occurs 0 times, so data.object is never folded into objectName. :248 / :359 — with viewType absent the kind is forced to grid, so a react page writing type="kanban" renders a grid rather than failing.
• packages/components/src/renderers/layout/react-page.tsx:91-93 — the react-tier wrapper gives the type slot to the SDUI discriminator and parks the author's value as specType; only plugin-charts reads specType (the ObjectChart precedent the spec comment cites does not extend to ListView).
• packages/core/src/adapters/resolveDataSource.ts:55-57 — provider: 'object' returns the context adapter and drops viewData.object; the object name is never carried.
• Six sibling blocks implement the data.object fold locally (ObjectCalendar, ObjectGantt, ObjectGrid, ObjectMap, ObjectTree, plugin-dashboard utils); ListView never took it. Zero tests in packages/plugin-list exercise provider: 'object' on ListView. git grep 11284 over objectui packages/: 0 hits — the consumer half of the convergence never landed.
• The carrier for that half exists and is parked: objectui#2890 (step 6, objectName → data.provider: 'object') is pm:on-hold · pm:blocking · domain:spec.

⇒ A declared-but-unenforced contract of the AGENTS.md #0.1 class, and a sharper one than usual: the validator actively blesses a spelling that renders an empty list with no diagnostic, and the tree documents a cross-repo fold that does not exist.

Related, same door (reported, not settled here)

• Metadata tier: packages/spec/src/ui/view.zod.ts:1630-1660 — ListViewShapeSchema declares data and no objectName; a metadata page carrying a list view bound with data={{ provider: 'object', object }} reaches ListViewBlock with no objectName too. Metadata list views work because the host stamps objectName (objectui packages/app-shell/src/views/ObjectView.tsx:1193 et al.), not because ListView reads data.object.
• The published skill and the showcase corpus: skills/objectstack-ui/rules/pages.md:180, :218; examples/app-showcase/src/ui/pages/crm-workbench.page.ts:88, renewals-pipeline.page.ts:135-137, :169, task-desk.page.ts:44 — all four real sites write the deprecated-but-working spelling; zero sites anywhere write the canonical one.

The fork, for the spec lane (not this seat's to rule)

• A — retract the deprecation at its source. Drop the two deprecated blocks and the summary sentence in react-blocks.ts:253-289; revert the lint's canonical-first boundObjectName branch and the replaced-by satisfaction (validate-react-page-props.ts:885-894, :1132-1135) and its false fold comment. objectName / viewType become plain spellings again; skills(ui) + examples: retire the deprecated objectName / viewType ListView spelling in one stroke — the published skill teaches it and three showcase pages repeat it #14343 closes as premise-false with nothing renamed; react-blocks.ts:167 is then already correct.
• B — land the consumer half first. Release objectui#2890 step 6: a data.provider === 'object' → objectName fold and a specType / type read for the view kind, in normalizeListViewSchema or a shared helper (not a seventh per-block copy), with a test; then re-dispatch skills(ui) + examples: retire the deprecated objectName / viewType ListView spelling in one stroke — the published skill teaches it and three showcase pages repeat it #14343 to rename the four sites, and rename react-blocks.ts:167 in the same PR.
• C — rename the four sites now is not a live option: it publishes a skill that teaches a spelling that renders nothing.

The #14343 flight's four-axis reading, relayed as the skills lane's view and nothing more: long-term soundness (≥ 50 %) points to A — the canonical type cannot reach the block except through the specType rescue the SDUI envelope forces, so the "simpler" vocabulary needs a bridge the deprecated one does not; AI-authorability rules C out; measured pull for the canonical spelling is zero; a deprecation window for a zero-user spelling is the gradual migration the 2026-08-27 principle declines. Whichever way it goes, one guard would stop the class recurring: the react-blocks generator refusing to publish a deprecated.replacedBy whose replacement no renderer reads.

Dedup (2026-09-03T01:38Z): objectstack search_issues on this shape returns only #11284 (closed — the producer ruling); objectui returns only #1544 (closed, unrelated). objectui#2890 carries the work, not the contradiction. No open card records that the published contract and the consumer disagree.

Refs: #14343 (blocked on this) · #11284 · PR #11695 · objectui#2890 · ADR-0049 · AGENTS.md #0.1.

[huangyiirene]

Triage — graded bug · priority:p2 · needs-user-decision · domain:spec. ⛔ Not dispatchable: both live options change a published contract (option A retracts a shipped deprecation and reverses #11284's own ruling; option B commits the platform to a cross-repo migration). That is the human floor, and the seat does not rule it.

Every load-bearing claim re-measured, and all of them hold — several against tips newer than the card's.

一句话问题:开发者照着官方契约摘要推荐的写法绑定一个列表页,os validate 全绿,页面上一条数据都没有,没有任何报错。

实测(objectstack 89a156a / objectui 39af82f,均比卡读的 tip 更新)

消费端 —— packages/plugin-list/src/ListView.tsx:

拼写	出现次数
data.object	0
dataConfig.object	0
specType	0
provider === 'object'	0
schema.objectName	52

normalize-list-view.ts 里 .object 0 次 ⇒ 折叠不存在。git grep 11284 扫 objectui packages/ ⇒ 0 命中,收敛的消费端从未落地。

生产端确认:react-blocks.ts 的摘要句确实教作者写 data={{ provider: 'object', object }} + type,objectName 是 required: true 且 deprecated.replacedBy: 'data';validate-react-page-props.ts:1132-1135 明写 if (dep && used.has(dep.replacedBy)) continue; ⇒ 只写 canonical 拼写也算满足必填。

⭐ 最锋利的一条已确认:lint 自己在 :878-879 用来论证优先级的理由是「mirroring the one-directional fold objectui's normalizeListViewSchema applies at the component boundary」—— 而那个 fold 不存在。校验器用一个不存在的机制来为「祝福一个渲染空列表的拼写」辩护。

选项 × 真实代价

选项	做什么	业务上 =
A	源头撤回弃用:删 react-blocks.ts:253-289 两个 deprecated 块与摘要句,回退 lint 的 canonical-first 分支、replaced-by 满足逻辑及那句假注释。objectName/viewType 回到普通拼写,#14343 以前提不成立关闭,:167 自动变正确	承认 #11284 的收敛在这条渲染路径上没走通,回到今天唯一能工作的词汇。⚠️ 这是推翻已落地的维护者裁决,只有维护者能做
B	先落地消费端:放行 objectui#2890 step 6,在 normalizeListViewSchema 或共享 helper(⛔ 不是第七份 per-block 拷贝)里做 data.provider==='object' → objectName 折叠 + specType/type 读取,带测试;再重派 #14343	兑现 #11284。⚠️ 但落地前绿灯继续祝福空列表,且要跨仓解冻一张 pm:on-hold 卡
C	现在就改四处站点	⛔ 不是活选项 —— 会把「渲染空列表」写进已发布的 skill

四棱

① 长远合理性(≥50%):⭐ A 的最强论据是结构性的,不是偏好:react-page.tsx:91-93 把 type 槽让给 SDUI discriminator,作者的值被停放到 specType,而只有 plugin-charts 读 specType。所以 canonical 拼写需要一座 deprecated 拼写不需要的桥。一个「更简单的词汇」在真实渲染路径上结构性更贵,那它就不是更简单。⇒ A。
② 实际业务拉动:canonical 拼写的实测用户 0(全仓四处真实站点全写 deprecated 拼写,零站点写 canonical);deprecated 拼写有 52 处实现支撑。为一个零用户的拼写维持弃用窗口,正是 2026-08-27 原则拒绝的渐进迁移。⇒ A。
③ 防 AI 犯错:最重的一棱。今天的状态是「工具主动祝福错误答案」—— AI 读摘要 → 写 canonical → 校验绿 → 空列表无诊断,比没有校验器更糟。A 立刻消除;B 在落地前一直存在;C 主动放大。⇒ A。
④ 创业阶段不扩散:A 是净删除(两个 deprecated 块 + 两处 lint 分支 + 一句假注释);B 新增折叠 + specType 读取 + 测试,并要跨仓解冻。⇒ A。

推荐:A。
回退:B —— 若维护者坚持 #11284 的收敛方向,则消费端必须先落地,并且在落地前先把 lint 的 replaced-by 满足分支关掉,否则绿灯会在整个迁移窗口里持续祝福空列表。
⭐ 无论哪条都该加的护栏:react-blocks 生成器拒绝发布「deprecated.replacedBy 指向的替代拼写没有任何 renderer 读取」的块。这条值得单独立卡 —— 它是唯一能阻止此类复发的机制。

置信缺口(本分析看不见什么):① 我没有端到端观测「写 canonical 拼写的 react 页面真的渲染成空列表」—— 结论是从消费端的 0 计数加 :1405/:1684 在 falsy objectName 上 early-return 推出来的,推理很强但是推理,不是观测。② #11284 裁决当时是否已知消费端不读:若 objectui 当时就规划了 step 6 而后被 park,那 A 等于放弃一次未完成的迁移,而不是纠正一个错误 —— objectui#2890 为何 pm:on-hold,我没有读。③ metadata tier 的 ListViewShapeSchema 声明 data 而无 objectName,靠 host 在 ObjectView.tsx:1193 补盖才工作;A 是否会让 metadata tier 与 react tier 的词汇再度分叉,未评估。

裁后执行(维护者只裁方向)

裁 A ⇒ domain:spec 派发,packages/spec + packages/lint 同一 PR,带 **BREAKING** 横幅与 needs:contract-review;#14343 以前提不成立关闭。裁 B ⇒ 先在 objectui 立卡解冻 #2890 step 6,本卡转 pm:blocked 挂其上,#14343 继续阻塞。⛔ 无论哪种都不要先改那四处站点。

⛔ 本座位不认领、不派发、不合并。#14343 保持阻塞在本卡上是正确的,该 flight 停在 needs_decision 且未编辑任何文件 —— 那是本卡能在一轮内定级的原因。

---

Generated by Claude Code

[huangyiirene]

os-decision-facets

Marker repost — the one above did not survive. I wrote it as an HTML comment (<!-- … -->) at the head of the decision comment; reading that comment back through MCP returns a body beginning with a bare \n\n, with the marker gone. The precedent decision card (#14099, comment 5507407642) reads back with os-decision-facets as plain text, which is why its marker is discoverable and mine was not.

⇒ Platform reading, recorded because it silently breaks discovery rather than erroring: an HTML-comment marker does not survive the MCP comment channel. Write the token bare. A decision card whose marker was eaten is a decision card the maintainer's query never returns — it reads as "no decisions pending" exactly the way #14743's search_issues zero reads as "no duplicates".

The decision content is the comment immediately above this one: recommendation A (retract the deprecation at its source), fallback B (land objectui's consumer half first, and disable the lint's replaced-by satisfaction branch for the duration), with option C ruled out. Three confidence gaps stated there, the largest being that the empty-list outcome is inferred from consumer-side zero-counts rather than observed end to end.

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling recorded — B: finish the #11284 convergence on the consumer side, with no deprecation window; first stop the validator blessing an empty list

Director seat, summon #11, session session_01ShyhexkB2d1AeRZ85tgAAe, 2026-09-03.

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat, 2026-09-03, replying to decision batch #18 in which this card was item 5 with the director seat's recommendation B (the triage seat, 5519158500, and the skills lane had recommended A; both readings were presented and the maintainer was asked to set the direction). Verbatim reply: 「同意」 — adopts B.

Ruled: B, in three steps, 不渐进. #11284's direction stands — one vocabulary across the metadata and react tiers (data={{ provider: 'object', object }} + type), the vocabulary ListViewShapeSchema already uses and six sibling blocks already fold. Option A (retract the deprecation at its source) is not taken: it would fork the two tiers' vocabularies permanently. Option C is not live.

1. Now, spec lane, S: packages/lint/src/validate-react-page-props.ts stops treating a present deprecated.replacedBy as satisfying a required prop for ListView and drops the canonical-first boundObjectName branch, and the false "mirrors objectui's normalizeListViewSchema fold" comment goes — a page that writes only the canonical spelling now fails os validate loudly instead of rendering nothing. ⛔ No site renames; the four real sites and the skill keep the working spelling until step 3. Clause-②: no (a validator tightens back to what renders).
2. objectui, step 6 of objectui#2890 released by this ruling: normalizeListViewSchema (or a shared helper — ⛔ not a seventh per-block copy) folds data.provider === 'object' + data.object → objectName and reads specType / type for the view kind, with tests; the six per-block folds may collapse into it. Tracked as its own objectui card, filed by this seat.
3. After step 2 lands and the objectui pin bumps, spec lane, claude-fable-5: objectName / viewType are retired as authored spellings on the react ListView block (ADR-0087 registry, no window), the lint re-enables canonical binding, react-blocks.ts:167's alternative string is rewritten, and skills(ui) + examples: retire the deprecated objectName / viewType ListView spelling in one stroke — the published skill teaches it and three showcase pages repeat it #14343 renames the four showcase sites and the skill in one PR. Clause-②: yes, needs:contract-review.

#14343 stays pm:blocked on this card until step 3. A guard card — the react-blocks generator refuses to publish a deprecated.replacedBy whose replacement no renderer reads — is filed by this seat as a finding, independent of the steps.

State transition, same stroke: needs-user-decision → pm:queue. Ledger: director seat post #12708, summon #11.

---

Generated by Claude Code

[zhuangjianguo]

Claim: PM loop, domain:spec seat (seat post #6017), R2 of this shift — step 1 of the ruling only
Session: session_0174WZTU6XcFcS7g2kykC53i (GitHub zhuangjianguo)
Branch: claude/issue-14791-listview-lint-stop-blessing-canonical
Worktree: objectstack-issue-14791
Domain: domain:spec (the ruling routes step 1 to this lane: "Now, spec lane, S")
File surface: packages/lint/src/validate-react-page-props.ts only — (a) the required-prop satisfaction at :1135 (if (dep && used.has(dep.replacedBy)) continue;) stops applying to ListView, so a page that writes only data={{ provider: 'object', object }} fails os validate loudly; (b) the canonical-first boundObjectName branch (:885-894, data.provider === 'object' + data.object read as the binding for ListView) dropped; (c) the false comment at :876-880 ("mirroring the one-directional fold objectui's normalizeListViewSchema applies") removed; (d) the diagnostic text at :1141 no longer advertises the canonical spelling as satisfying for ListView; the rule's own test file gains the two pins (canonical-only page ⇒ refused loudly; objectName page ⇒ passes). ⛔ No site renames (skills / showcase untouched — step 3), ⛔ no react-blocks.ts change (step 3 retires the deprecated blocks), ⛔ nothing in packages/spec. Changeset @objectstack/lint patch (a validator tightens back to what renders; previously green pages go red by design). Stop on breach; explain in the report.
Container & model: S, mode:subagent, model: opus (judgment: whether the :1135 satisfaction and the boundObjectName branch are shared with other blocks — the ruling scopes the tightening to ListView; the dev measures the blast radius before cutting). node scripts/pm/dispatch-gates.mjs --tier packages/lint/src/validate-react-page-props.ts at origin/main 77a532d6 (17:00Z): "no path-derived mandate: the surface hits none of the 3 declared glob(s)".
Clause-②: no — ruled verbatim in 5522890150: "Clause-②: no (a validator tightens back to what renders)"; no contract file, no accept-set move on a spec schema.
Serial constraints cleared: fresh open-PR file scan at 17:00Z (27 open PRs, every file list read via REST) — none touches validate-react-page-props.ts; last commit on it b8fc7280 (2026-09-02) — no same-day churn; lane siblings in flight (#14825 ai/knowledge-source.zod.ts, #14847 stack.zod.ts) file-disjoint; H17 on-hold index: no row. Downstream: #14343 (skills lane) stays pm:blocked on this card until step 3.

Decision re-read (all comments read): maintainer ruling B recorded 5522890150 (director seat, batch #18, 2026-09-03T08:30Z, verbatim 「同意」) — three steps, 不渐进; step 1 is this dispatch, step 2 = objectui#7477 (released by the ruling, objectui lane), step 3 (retire objectName / viewType, re-enable canonical binding, rename the four sites — claude-fable-5, Clause ② yes) waits for step 2 + the objectui pin bump. Triage 5519158500 (+ marker repost 5519162845) recommended A; the ruling overrides it. PR shape: Part of #14791 (step 1 of 3; the card stays open); on MERGED this card goes pm:blocked with Blocked-by: objectstack-ai/objectui#7477. Premise re-read on origin/main 77a532d6 (17:00Z): :1135 replaced-by satisfaction present, :885 boundObjectName present, :878 the false fold comment present. Premise holds.

---

Generated by Claude Code

[zhuangjianguo]

Dispatch (R2 of this shift, 2026-09-03T17:03Z) — domain:spec seat, session_0174WZTU6XcFcS7g2kykC53i, seat post #6017. mode:subagent, model: opus, size S, Clause ② no (ruled). Step 1 of ruling B only. The dev leaves its own Claim: comment below; the assignee stays the PM's.

Dispatch text handed to the dev, in brief (the ruling's step 1 is quoted verbatim from 5522890150 and marked non-renegotiable; steps 2 and 3 fenced off):

• validate-react-page-props.ts: the replaced-by satisfaction no longer applies to ListView, the canonical-first boundObjectName branch dropped, the false fold comment removed, the diagnostic reworded to point at objectName (the spelling that renders today), the deprecation warning's text adjusted without a severity change; tests inverted (never deleted) plus two pins (canonical-only page refused loudly; objectName page passes).
• Hypotheses to measure: whether the two branches are shared by other blocks (scope to ListView if so, with pins that the others are unchanged); no other consumer of the replaced-by satisfaction outside the file; react-blocks.ts read only; changeset @objectstack/lint patch stating that previously green pages go red by design.
• Landing: draft PR with Part of #14791 (steps 2 and 3 remain; the card stays open); no needs:contract-review (no spec path, Clause ② no); ⛔ no ready flip. On MERGED this card goes pm:blocked with Blocked-by: objectstack-ai/objectui#7477 (step 2).

---

Generated by Claude Code

[claude]

Claim: os-dev subagent dispatched by the domain:spec seat (seat post #6017) — step 1 of the maintainer's ruling B only.

• Session: session_0174WZTU6XcFcS7g2kykC53i (GitHub zhuangjianguo)
• Branch: claude/issue-14791-listview-lint-stop-blessing-canonical (pushed empty before the first edit)
• Worktree: objectstack-issue-14791, base 6392b9c2
• Clause-②: no — ruled verbatim in 5522890150: a validator tightens back to what renders. No contract file, no accept-set move.

Complete file surface (nothing else is touched):

1. packages/lint/src/validate-react-page-props.ts — the required-prop replaced-by satisfaction stops applying to the ListView object binding; the canonical-first boundObjectName branch is dropped; the false fold comment goes; the missing-required diagnostic and the deprecation warning text are reworded to the ruled state.
2. packages/lint/src/validate-react-page-props.test.ts — the vocabulary-window cases are INVERTED (never deleted), two pins added, and the ListView fixtures that merely used the canonical spelling as a binding are re-spelled to the one that renders.
3. .changeset/*.md — @objectstack/lint patch.

⛔ No site renames (skill / showcase stay on the working spelling until step 3). ⛔ No packages/spec change — the deprecated blocks are step 3's to retire. ⛔ Nothing in objectui.

Premise re-read on my base 6392b9c2 (newer than the PM's 77a532d6): the replaced-by satisfaction, the boundObjectName canonical branch and the false fold comment are all present. Consumer counts re-measured against the objectui tip a27d153c, also newer than the card's: data.object 0, dataConfig.object 0, specType 0, provider === 'object' 0, schema.objectName 52. Premise holds.

One measured refinement I will report in full: the objectui ListView fetch effect does implement provider: 'value', a plain-array shorthand and the renderer-owned api provider — only provider: 'object' falls through to the objectName-gated fetch and renders empty. So the tightening is scoped to the object provider rather than to the data prop as a whole; tightening the providers that render would tighten past what renders, against the ruling's own stated reason.

PR will land as draft with Part of #14791 on line 1 — step 1 of 3, so the card stays open.

---

Generated by Claude Code