`object-grid` / `object-form` read the dataSource from CONTEXT while `detail-view` takes it as a PROP — the two wirings are mutually exclusive, and the getting-started guide uses the one that breaks the grid

[os-support-ai]

Measured while acting on a review request against PR #5376 (#5342) to make content/docs/guide/building-crud-app.md actually render. It does not reduce to a prop rename, and this is why. Filed unassigned, not claimed.

The fact

Two blocks in the same family disagree about how the data-source adapter reaches them, and the registry gives an author no signal about which one they are holding.

• object-grid and object-form are registered through wrappers (ObjectGridRenderer, ObjectFormRenderer) that pull the adapter out of useSchemaContext() / SchemaRendererContext. They need a SchemaRendererProvider ancestor.
• detail-view is registered as the raw DetailView component (packages/plugin-detail/src/index.tsx:133), and DetailView destructures dataSource from its own props (DetailView.tsx:191). It needs the adapter spread onto the node, which is what a dataSource prop on SchemaRenderer does — SchemaRenderer.tsx:703 says so explicitly ("An explicit React dataSource prop is unaffected: it arrives via ...props, spread last").

SchemaRenderer itself reads only context (SchemaRenderer.tsx:371: const dataSource = context?.dataSource || NO_DATA_SOURCE), so a dataSource prop never becomes context for descendants.

Measured, both directions, on f2e11ae6f

Rendered through the real registry with a fake adapter, in both wirings. find / findOne call counts and whether the row text appears:

wiring	object-grid	detail-view
SchemaRendererProvider dataSource=... wrapping SchemaRenderer	find 1, row renders	findOne 0, renders nothing
SchemaRenderer dataSource=... (prop, no provider)	find 0, renders nothing	findOne 1, row renders

Both blocks were given correct, declared keys (objectName, resourceId) in every cell — so this is purely the wiring axis, with the key axis held fixed. Neither wiring reports anything: no error, no warning, no empty-state explaining itself. Both failures are the silent-empty shape of #5349.

Why it matters beyond one page

content/docs/guide/building-crud-app.md is the getting-started CRUD walkthrough. It imports only SchemaRenderer, never SchemaRendererProvider, and passes dataSource as a prop at all five call sites. So on the wiring axis alone, before any key question:

• its three object-grid snippets and its one object-form snippet cannot fetch, and
• its one detail-view snippet can.

That also puts the page in direct contradiction with AGENTS.md commandment #1, which states the injection pattern as SchemaRendererProvider dataSource={...}.

The interaction with #5377 is the reason this is its own card: #5377 is the KEY axis (object vs objectName, recordId vs resourceId) and is real — with the provider wiring, renaming the grid's one key takes it from find 0 to find 1 and the row appears. But fixing the keys alone does not make the guide render, because the guide's wiring is the other one. Two axes, both live, and a card that fixed only one would report success on a page that still renders nothing.

What needs deciding

1. Converge the blocks. Give detail-view the same context-reading wrapper its siblings have, so every block resolves the adapter the same way. This looks like the long-term-correct direction — one contract, and the wrappers already exist as the pattern — but detail-view's prop form has existing callers that pass dataSource directly, so it needs a compatibility judgment rather than a rename.
2. Or declare the split and make it visible, so an author is told which blocks need a provider instead of discovering it as an empty view.
3. Either way, the silence is its own defect: a block that has no adapter should say so, not render an empty shell. That is the ObjectGrid renders a header-only grid in total silence when no column resolves — one wrong first column used to take the whole set down, now every wrong column does #5349 shape again and argues for a shared "no data source resolved" report.

Reproduce

grep -n "const dataSource = context" packages/react/src/SchemaRenderer.tsx # 371, context only
grep -n "dataSource" packages/plugin-detail/src/DetailView.tsx | head -1 # 191, a prop
grep -n "register('detail-view'" packages/plugin-detail/src/index.tsx # 133, raw component
grep -n "useSchemaContext" packages/plugin-grid/src/index.tsx # the wrapper
grep -n "SchemaRendererProvider" content/docs/guide/building-crud-app.md # zero hits

Related: #5377 (the key axis on the same five snippets), #5342 / PR #5376 (the type axis on the same five snippets), #5349 (the silent-empty failure mode), #5372 (another "the only working route is the one the docs discourage" instance).

Generated by Claude Code

[os-zhuang]

Triage: entered the decision inbox (needs-user-decision, type Bug). This is the blocker for #5377 (formalized there); the published getting-started guide uses the wiring that starves the grid at all five call sites.

<!-- os-decision-facets -->

• 项目长远合理性:两个互斥接线(context vs prop)是同一问题的两份答案 —— 收敛(A:统一为 context 供给、prop 显式覆盖优先)消灭分叉;声明分裂(B:文档写清各组件各自的接线)把偶然的不一致固化成契约。
• 实际业务拉动:真实且已测 —— 新手照 getting-started 抄,grid/form 静默空表;这是入门路径上的第一坑。
• 防 AI 犯错:A 配合「no adapter resolved 必须响亮上报」(ObjectGrid renders a header-only grid in total silence when no column resolves — one wrong first column used to take the whole set down, now every wrong column does #5349 形)让接错线立刻可见;B 之下 AI 生成页面时必须记住每个组件的特例接线,静默空表继续是默认失败形态。
• 创业阶段不扩散:A 是一次组件层收敛 + 兼容判断;B 是文档债 + 每个新组件再选一次边。
• 推荐:A(统一 context 供给、prop 覆盖优先,叠加显式 no-adapter 报错),⛔ 兼容面先测 detail-view 现有 prop 调用方再动。
• 置信缺口:本分析看不见 detail-view 既有 prop-form 调用方的存量规模 —— 若外部应用大量依赖 prop-only 接线,收敛方向可能要反转(统一为 prop、context 作回退)。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session session_01PjAP6vbcsg2yMtvySPv1Qo)

Ruled: 1 + 3 together. Provenance: maintainer accepted the batch, verbatim: 「其他接受你的建议。」

1. Converge the blocks: detail-view gains the same context-reading wrapper its siblings have; its existing dataSource-prop form stays accepted for current callers (compatibility judgment: additive wrapper, no prop removal this pass).
2. The silence dies with it: a block that resolves no adapter reports "no data source resolved" loudly (the ObjectGrid renders a header-only grid in total silence when no column resolves — one wrong first column used to take the whole set down, now every wrong column does #5349 shape) — for the whole family, not just detail-view.
3. guide/building-crud-app.md rewrites to the SchemaRendererProvider wiring (matching AGENTS.md commandment Implement visual designer for Object UI schemas #1) — coordinated with finding(docs): guide/building-crud-app.md addresses every renderer with object, but object-grid / object-form / detail-view all declare objectName — the whole guide binds to nothing #5377's key-axis fix on the same file (see that card's unlock note; same-file serial/fold is the seat's call).

Option 2 (declare the split) is rejected — documenting a mutually-exclusive wiring is writing the defect down. State transition in the same stroke: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 22 — folded with #5377, one dispatch, one PR
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5378-datasource-wiring-convergence
Worktree: objectui-issue-5378
Domain: repo:objectui
File surface: packages/plugin-detail (the context-reading wrapper), the no-adapter report across the object-grid / object-form / detail-view family (packages/react + the plugin wrappers), and content/docs/guide/building-crud-app.md (stop on breach; explain in the report)
Container & model: L, mode:subagent, model: opus
Clause-②: yes — item 1 adds a second accepted wiring for detail-view (additive; the existing dataSource-prop form is explicitly retained by the ruling), and item 2 introduces a new user-visible failure report across the family. Neither removes anything published.
Serial constraints cleared: packages/plugin-detail, packages/react, packages/plugin-grid, packages/plugin-form and the guide are all free — #5240 merged (plugin-grid), PR #5434 is open on plugin-list only, #5365 owns packages/components + packages/layout, #5421's surface is TBD with a stop-and-report instruction, #5358 has no file surface.

The fold decision, which the ruling assigned to this seat

The 2026-08-20 ruling (「其他接受你的建议。」) says "same-file serial/fold is the seat's call" for #5377's key-axis fix and this card's item 3, which touch the same five snippets in the same file.

Folded. Serialising them would mean the first PR lands and leaves building-crud-app.md still rendering nothing — which is precisely the failure this card was split out to prevent: "a card that fixed only one would report success on a page that still renders nothing." Both axes are live and independent; only both together make the page work. #5377 is claimed to the same branch and closes with this PR.

What the ruling settled, carried verbatim into the order

1. Converge — detail-view gains the context-reading wrapper its siblings have. ⛔ Its existing dataSource-prop form stays accepted: additive wrapper, no prop removal this pass.
2. The silence dies with it — a block that resolves no adapter reports "no data source resolved" loudly, for the whole family, not just detail-view. (ObjectGrid renders a header-only grid in total silence when no column resolves — one wrong first column used to take the whole set down, now every wrong column does #5349's shape.)
3. The guide rewrites to the SchemaRendererProvider wiring, matching AGENTS.md commandment Implement visual designer for Object UI schemas #1.

⛔ Option 2 (declare the split) is rejected — documenting a mutually-exclusive wiring is writing the defect down.

⚠️ Triage's stated confidence gap is largely defused by the ruling's additive shape, but not erased: "若外部应用大量依赖 prop-only 接线, 收敛方向可能要反转". The dispatch order asks for the caller population to be measured anyway — if it turns out large enough that the additive wrapper creates a genuinely ambiguous precedence, that is a fork to report, not to resolve.

---

Generated by Claude Code