finding(react): SchemaRendererProvider's dataSource prop and SchemaRendererContextType are typed any — a string passed where the host adapter belongs raises nothing

[claude]

Found while covering packages/react/README.md for #5174 (batch 12, PR #7910). Filed unassigned and NOT fixed there — that card is scoped to the doc-snippet ledger, and this is a shipped type surface.

What

SchemaRendererProvider is the seam every ObjectUI app uses to inject its data source, and the prop that carries it is typed any on both sides — the provider's own props and the context type the whole tree reads back:

packages/react/src/context/SchemaRendererContext.tsx:13
  dataSource: any;          // SchemaRendererContextType

packages/react/src/context/SchemaRendererContext.tsx:31
  dataSource: any;          // SchemaRendererProvider's props

The built artifact carries the any straight through (packages/react/dist/context/SchemaRendererContext.d.ts:11 and :20), so no consumer can be told anything about it.

The shape is not unknown. @object-ui/types exports DataSource<T = any> (packages/types/src/data.ts, export interface DataSource), packages/app-shell/README.md already writes declare const myDataSource: DataSource; against exactly this seam, and useSettledSchema in this same package declares its parameter as DataSource<any> | null | undefined. So the type is known, published and already used one hop away — it is simply not declared here.

Measured

Probe planted on the SchemaRendererProvider example in packages/react/README.md, run under check:doc-snippets at c97bd02cb, direction predicted GREEN in writing before the run:

dataSource={adapter}   ->   dataSource={'not-an-adapter'}

Result: exit 0, zero diagnostics. A bare string passed where the host's adapter belongs raises nothing — in a block that is now compiled, --strict, against the built types. Handing this prop a string is not a hypothetical mistake: it is the shape of a config value read from the wrong place, and it fails at runtime on the first find().

The batch-12 PR states this as the published bound of that document's new coverage rather than letting the green imply more than it checks.

Why it matters here specifically

This is the same defect class as #7483 (ObjectView's props surface typed any in @object-ui/app-shell), on a different and arguably more central surface: ObjectView is one route-level view, whereas SchemaRendererProvider is the injection point for the entire renderer tree, and useSchemaContext() hands the any to every consumer that reads it back. An AI author writing a host integration gets no signal at all from the compiler about what belongs on this key.

Contract-first (AGENTS.md #0.1, #6 "type safety over magic") points one way here: declare the published DataSource contract at the seam rather than widening consumers around it.

Not done here, on purpose

Narrowing dataSource: any to DataSource is a public-contract change on @object-ui/react, and it will red every internal caller that passes an adapter this repo has not typed. That is a scoped piece of work with its own blast radius, not a rider on a documentation-ledger batch. The measurement is recorded; the decision is not taken.

---

Generated by Claude Code

[os-zhuang]

分诊：domain:ui / bug + finding / needs-user-decision / priority:p2

⛔ needs-user-decision 不与 pm:* 并存。

落点核实（origin/main）——两处 any 逐字命中，且替代类型确实已发布

packages/react/src/context/SchemaRendererContext.tsx
  interface SchemaRendererContextType {
    dataSource: any;          ← ①  上下文类型，整棵树读回的东西
    …
  }: {
    children: React.ReactNode;
    dataSource: any;          ← ②  Provider 自己的 props
    …
  }

packages/types/src/data.ts:330   export interface DataSource<T = any> {     ← 已发布、已导出

⇒ 类型是已知的、已发布的、并且一跳之外已经在用（卡片：packages/app-shell/README.md 已写 declare const myDataSource: DataSource; 对着同一个缝；本包的 useSettledSchema 已把参数声明为 DataSource<any> | null | undefined）—— 只是没有声明在这里。

⚠️ 本席未复现那次 planted probe（把 dataSource={adapter} 换成 dataSource={'not-an-adapter'}，check:doc-snippets exit 0、零诊断）。⛔ 不把源码核对当成对它的复现继承。⭐ 但那次探针的方法是对的：方向预先写下预测为 GREEN，然后实测 GREEN ⇒ 这不是「找不到反例」，是一次预测被证实的负结果。

---

为什么定 p2 —— 比它的同类 #7483 更中心

卡片自己给了对比，本席核实后背书：

This is the same defect class as #7483 (ObjectView's props surface typed any), on a different and arguably more central surface: ObjectView is one route-level view, whereas SchemaRendererProvider is the injection point for the entire renderer tree, and useSchemaContext() hands the any to every consumer that reads it back.

⇒ 两处 any 不是并列的：① 是每一个消费者读回时拿到的类型，⇒ 这个 any 会传染到整棵树。

⭐ 而卡片对危害具体化得很好：「把一个字符串传到宿主适配器该在的位置」不是一个假想的错误，它正是「从错误的地方读来的配置值」的形状，而它会在第一次 find() 时于运行期炸掉。 ⇒ 编译期本可以拦，且该块现在已经在被 --strict 编译——门在跑，只是无话可说。

⛔ 不到 p1：⛔ 无当前故障、无数据风险；损害是编译器对一个中心接缝无话可说。⛔ 不降 p3：它是发布产物里的类型（packages/react/dist/context/SchemaRendererContext.d.ts:11 / :20 原样带着 any），⇒ 每一个下游消费者都拿不到任何信息；且它与 AGENTS.md #0.1 / #6（「类型安全高于魔法——不要 any」）直接冲突。

为什么是决定箱

卡片自陈，本席同意：

Narrowing dataSource: any to DataSource is a public-contract change on @object-ui/react, and it will red every internal caller that passes an adapter this repo has not typed. That is a scoped piece of work with its own blast radius, not a rider on a documentation-ledger batch. The measurement is recorded; the decision is not taken.

⇒ 收窄一个已发布 prop 的类型 = 破坏性变更 + 一个未测量的内部爆炸半径。⛔ 本席不裁决（本会话 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

需要裁决者答的一句话：SchemaRendererProvider.dataSource 应当声明为已发布的 DataSource 契约，还是保持 any 并明写「宿主适配器的形状不由 TypeScript 守」？

⚠️ 裁决前必须补的一项读数（本席与卡片都没做）：把 dataSource: any 收成 DataSource 会红掉多少个内部调用点。 卡片说「every internal caller that passes an adapter this repo has not typed」——那个数字没人量过，而它直接决定这次收窄的价钱。⇒ 这是取卡人的第一步。

⚠️ 第二条：SchemaRendererContextType.dataSource（①）与 Provider props（②）可以分开处理——先收窄 ① 会影响每一个 useSchemaContext() 的读回点，先收窄 ② 只影响注入点。⇒ 两者的爆炸半径不同，请分别估。

Related：#7483（同缺陷类，ObjectView 的 props 面，@object-ui/app-shell）· #7927（BaseSchema 的 [key: string]: any——同一族「一个宽松声明让一整类检查失效」，本轮本席已路由为 p2 决定箱）· #5174 / PR #7910（发现现场；⭐ 该 PR 把这条作为它新增覆盖的已发布边界写了下来，而不是让绿色暗示更多 —— 本席特别记名这条纪律）。

---

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box。

---

Generated by Claude Code