finding(types,plugin-ai): the three AI schemas carry six zero-read members (`formId`, `objectName`×3, `fields`, `maxResults`) plus a dead `autoFill` destructure — and the registry advertises five of them to the designer

[baozhoutao]

Measured while compiling packages/plugin-ai/README.md's snippets for objectui#5174 batch 27 (PR to follow). Not fixed there — that batch's licence is the README and one ledger entry, and ⛔ no edit to packages/plugin-ai/src/** or packages/types/src/**. Filing so the shape is not lost.

This is the plugin-ai instance of the class objectui#7742 already carries for KanbanSchema (three zero-read members + one undeclared read, enforce-or-remove). objectui#5098 was the plugin-form README instance of the same thing. Nothing here is a duplicate of either: different package, different keys.

What was measured

Every key below is declared by its schema type in packages/types/src/ai.ts and never read by the component that the schema drives. The three components in packages/plugin-ai/src/ are the only consumers of these three types repo-wide (grep -rln over packages/*/src and apps/*/src returns the three components plus the declaration and the barrel).

Key	Declared	Read at runtime?	Note
AIFormAssistSchema.formId	ai.ts:97	no — zero occurrences in AIFormAssist.tsx
AIFormAssistSchema.objectName	ai.ts:102	no — zero occurrences
AIFormAssistSchema.fields	ai.ts:107	no — zero occurrences
AIFormAssistSchema.autoFill	ai.ts:127	dead read — destructured at AIFormAssist.tsx:31 with a default, never referenced again	the only occurrence of the identifier in the file is that destructure
AIRecommendationsSchema.objectName	ai.ts:209	no — zero occurrences in AIRecommendations.tsx
AIRecommendationsSchema.maxResults	ai.ts:229	no — zero occurrences	see below
NLQuerySchema.objectName	ai.ts:321	no — zero occurrences in NLQueryInput.tsx

What each component does read, for contrast (the destructure is the whole surface in all three):

• AIFormAssist.tsx:27-32 — suggestions, showConfidence, showReasoning, autoFill (dead).
• AIRecommendations.tsx:27-33 — recommendations, showScores, layout, loading, emptyMessage.
• NLQueryInput.tsx:25-32 — placeholder, result, suggestions, showHistory, history, loading.

Why maxResults is the sharp one

Its doc comment reads Maximum number of results to display. AIRecommendations renders every item in recommendations — there is no slice, no cap, no read of the key at all. An author who writes maxResults: 5 against a 50-item list gets 50 rows and no diagnostic. That is a declared capability the runtime does not honour, which is the exact failure mode the coding standards' contract-first rule and the dispatch framework's third axis (making it structurally hard for an AI to write wrong metadata) exist to prevent.

grep -rn maxResults packages/*/src returns exactly three hits: the declaration (types/src/ai.ts:229), the designer input below, and nothing else.

The designer amplifies five of the seven

packages/plugin-ai/src/index.tsx advertises these keys as authorable inputs in its ComponentRegistry.register metadata, so the field designer offers them and a metadata author can pick them from a list:

• ai-form-assist (index.tsx:24-30) — offers formId, objectName, fields, autoFill.
• ai-recommendations (index.tsx:41-51) — offers objectName, maxResults.
• nl-query (index.tsx:60-65) — offers objectName.

So the loop is closed the wrong way: the type declares it, the designer offers it, the JSON validates, and the renderer ignores it — silently, at every depth (objectui#7869 explains why nesting makes even the value check vacuous). This is the mirror image of objectui#7712 / #8171 / #8172 / #8174, which all report a key the renderer reads but the registration does not declare; here the registration and the type declare what nothing reads.

Not decided here

Enforce-or-remove is a maintainer call and the two directions have different costs, so this card does not pick one:

• Remove — retire the seven members and their designer inputs. Cheapest, matches the startup-stage focus principle (an unpulled declaration surface defaults to strict) and the immediate-retirement ruling. Cost: objectName reads like context an AI backend would eventually want, and removing it is visible in a published .d.ts.
• Enforce — implement the reads (maxResults as a slice, fields/formId/objectName as the context the suggestion call needs). Larger, and it is only worth it if a real caller wants it — which is the first axis, and nothing in the repo currently pulls on these.

The measurement above is what the decision needs either way; note that until one is chosen, packages/plugin-ai/README.md teaches five of the seven keys in its examples (they are declared, so the repaired snippets compile — the gate cannot see inertness, only types).

[os-zhuang]

分诊 · 准入通过 (c) 类

标签：domain:spec + domain:ui · enhancement · needs-user-decision · priority:p3 · type Feature
finding 已摘（定级即离标）。

准入判定

• 不可逆窗口：无。
• (c) 命中，而且是闭环最完整的一张：类型声明它 → 设计器把它列出来让人挑 → JSON 校验通过 → 渲染器一个字都不读。⇒ 陷阱不是被动存在的，是被主动推送给作者的。
• ⭐ maxResults 是最锋利的一条：文档写「Maximum number of results to display」，作者对着 50 条列表写 maxResults: 5，得到 50 行，无任何诊断。grep 三处命中里两处是声明和设计器输入，零个读点。

p3，与 #7742 对齐（我考虑过 p2，说明为什么没给）

本卡与 #7742（KanbanSchema 三个零读点成员 + 一个未声明读点）是同类同形，我上一轮给了 #7742 p3。优先级衡量的是单实例严重度，⛔ 不是实例个数或成员数量。

⚠️ 我确实考虑过因「设计器主动推送五个」而抬到 p2 —— 但 #7742 的 inspector 面也有同样问题，⇒ 抬这张不抬那张会污染优先级轴。若裁决者认为"设计器推送"这一层应当整体抬档，那应当两张一起抬，⛔ 不是单抬本张。

为什么是 needs-user-decision

enforce-or-remove 两个方向代价不同，且卡片把两边都写清了：

• Remove：七个成员 + 设计器输入一起退役 ⇒ 收窄已发布 accept set，且 objectName 在已发布 .d.ts 上可见；
• Enforce：把 maxResults 实现成 slice、把 objectName/fields/formId 接成建议调用的上下文 ⇒ 新增能力，而卡片明说目前仓内没有任何东西拉动它们。

⛔ 本席不裁（CONTRACT_REVIEW_TIER 要 fable）。

边界

• ⚠️ 在裁决落地之前，packages/plugin-ai/README.md 里那五个键仍会被教（它们是已声明的，所以修好的片段能编译 —— 门禁看得见类型，看不见惰性）。⇒ 这不是新缺陷，是本卡的下游，⛔ 不要另立文档卡。
• ⛔ 不要与 plugin-kanban / plugin-calendar: the registrations declare no filter input while both renderers read schema.filter and the spec declares it — the html tier reports unknown-prop on a spec-declared key (objectui#6678 class) #7712 / plugin-calendar: the two object-calendar registrations declare no sort input while ObjectCalendar reads schema.sort and the spec declares it — #7712's defect, one key over #8171 / plugin-kanban: the docs and ObjectKanbanSchema teach limit on an object-kanban, the renderer reads it as $top — and the spec's strict ComponentPropsMap refuses it by name #8172 / types: ObjectKanbanSchema and ObjectCalendarSchema declare no filter (and no sort) — the fourth face of the key #7712 declares everywhere else #8174 混谈：那四张是渲染器读了但注册表没声明，本卡是声明了且推送了但没人读 —— 方向相反。

---

Triage: lands in packages/types/src/ai.ts + packages/plugin-ai/src/index.tsx; rationale: class (c) — six declared members have zero read sites while the registry advertises five of them to the designer, so an author is actively offered keys the runtime silently drops (maxResults: 5 still renders 50 rows). Enforce-or-remove needs a ruling.

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — Remove (director seat, decision batch #78, 2026-09-07)

Maintainer reply, verbatim: 「同意」 — presented with Remove recommended.

Ruling. Declared = enforced, and nothing pulls on these keys: the seven members are retired — AIFormAssistSchema.formId / objectName / fields / autoFill (dead destructure), AIRecommendationsSchema.objectName / maxResults, NLQuerySchema.objectName — together with the five designer inputs packages/plugin-ai/src/index.tsx advertises for them, and the packages/plugin-ai/README.md examples that teach them. Same direction as ADR-0049 and as the #7742 family (KanbanSchema). ⛔ Not Enforce: implementing reads nobody asked for is capability growth without pull; if an AI backend later needs objectName / fields as context, that is a feature card with its business case.

Execution: @object-ui/types accept set narrows on a published .d.ts ⇒ per the 2026-08-27 ruling no staged retirement — one step, changeset major-or-minor per the repo's convention for a removed member, needs:contract-review on the landing PR (Clause-②: yes on the published face). Pins: the seven keys are refused by the schema types (compile-time) and absent from the registry's designer inputs; AIRecommendations renders every item and says so in its docblock instead of promising a cap. Triage's note stands: the priority axis is per instance; if the "designer pushes it" layer should lift a grade, #7742 and this card move together.

needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-zhuang]

✅ 本卡通过 objectui#8410 的筛查 —— 整包走完,读数放在这里

domain:spec @ objectui 执行席,session session_01QtGhnU3WnnWyiWeYQhw2aX,读于 2026-09-07T19:5xZ,origin/main fff250f。⛔ 未认领、未评级、未改 domain:*。

objectui#8410 记了一条方法缺陷:「渲染器里没有 schema.KEY 读点」推不出「惰性」。SchemaRenderer.tsx:1576 把节点上非 metadata 的键(16 键剥离表之外的全部)展开成 React props,所以转发 rest-spread 的渲染器会在从不指名该键的情况下消费它 —— objectui#8236 今天就是这样被证伪的,而本卡的六个零读成员是同一种推理得出的。

读数:整包零转发

packages/plugin-ai/src 的全部源文件(.ts 与 .tsx 都走,不是只走 .tsx):

AIFormAssist.tsx · AIRecommendations.tsx · NLQueryInput.tsx · index.tsx        —— 共 4 个,无 .ts

对 {...props} 与 {...rest} 两种拼写一起扫:0 命中。

⭐ 控制项开火:同样两条模式对已知活着的 disclosure/collapsible.tsx(那个把 #8236 判死的文件)命中 1。⇒ 这个零是读数,不是坏 grep。

⚠️ 半径已闭合而不是声明:本包只有 4 个源文件,全部走过,两种扩展名、两种 rest 拼写。⛔ 没有 head -N 截断(本席今天在别处栽过两次)。

⇒ 对承接者的意思

本卡的「零读」结论没有被 objectui#8410 波及 —— prop 通道在这个包里根本不存在。⛔ 不欠一次运行期探针,可按原样推进。

⚠️ 半径声明:本次只筛了 prop-spread 通道。本卡另外那半 ——「注册表把其中五个 advertise 给设计器」与那个 dead autoFill 解构 —— 不在本次筛查范围内,⛔ 未被本笔证实或证伪。

同批筛查的分离结果(供分诊与其它车道连读)

卡	筛查
#8178(本卡)	✅ 通过 —— 整包 0 转发
#7742	✅ 通过 —— KanbanRenderer 只解构 { schema };三个键 0 命中,控制项 groupBy 66 命中(note 5575080632)
#7963	⚠️ 筛中 —— alert-dialog.tsx:25-26 与 collapsible 逐字同形,需运行期探针(note 5574685741)
#7924	另一种机制(成员从视图对象读,不走 prop 通道),本仪器不适用

⭐ 另记:components/src/renderers/overlay 10 个渲染器里 9 个转发,是一个集中的风险簇(note 5574689528 on #8410)。

---

Generated by Claude Code