finding(types): 39 handler keys a registered renderer READS are declared by no arm — accepted and KEPT by the passthrough, on `main` today

[os-sam]

Filed by the dev seat implementing objectui#7753's derivation gate. These are that gate's own first-run findings: it is landing with them in an exemption ledger (KNOWN_UNDECLARED_READS) because every fix is a packages/PKG/src change and #7753 is dispatched Clause-② no. This card owns the fixes; the ledger rows name it and drain as they land.

The exposure, restated

BaseSchema is .passthrough(). A key an arm does not declare is not refused — it stops being judged and the value is KEPT, then reaches the renderer that reads it. That is objectui#7664's measured mechanism ({ type: 'kanban', columns: [], onCardClick: { action: 'toast' } } went REFUSED to ACCEPTED with {"action":"toast"} surviving into the parsed output). objectui#7753's card calls this out for keys that LEAVE an arm; the 39 below are the other half of the same class — keys that were never on the arm at all, while a registered renderer reads them off the authored document.

Each is an authored onX: { action: 'toast' } that parses GREEN today and is then handed to a call site expecting a function. AlertDialogSchema.onAction was exactly this shape until objectui#7104 declared it, so this class has landed before.

Measured, per site

Census: every real ComponentRegistry.register('TYPE', C, ...) call in packages/PKG/src, the schema.onX / props.onX reads inside C and inside every component C hands THE SAME DOCUMENT to, judged against the arm whose type: z.literal('TYPE') selects it. Population derived on both halves; nothing here is a hand-written list. 106 arms, 216 registrations (120 with an arm), 62 reachable reads, 39 of them undeclared.

Reproduce with node scripts/check-handler-key-read-sites.mjs --list once objectui#7753's PR lands.

packages/components

• button::ButtonSchema.onSuccess — read at packages/components/src/renderers/action/action-button.tsx:219; arm in form.zod.ts
• icon::IconSchema.onSuccess — read at packages/components/src/renderers/action/action-icon.tsx:145; arm in layout.zod.ts
• data-table::DataTableSchema.onAddRecord — packages/components/src/renderers/complex/data-table.tsx:2606; data-display.zod.ts
• data-table::DataTableSchema.onBatchSave — data-table.tsx:1724
• data-table::DataTableSchema.onCellChange — data-table.tsx:1572
• data-table::DataTableSchema.onColumnResize — data-table.tsx:1466
• data-table::DataTableSchema.onRowActionDef — data-table.tsx:501
• data-table::DataTableSchema.onRowClick — data-table.tsx:2184
• data-table::DataTableSchema.onRowSave — data-table.tsx:1664
• tree-view::TreeViewSchema.onNodeClick — packages/components/src/renderers/data-display/tree-view.tsx:98; data-display.zod.ts

packages/plugin-detail

• detail::DetailSchema.onAddComment — packages/plugin-detail/src/DetailView.tsx:1522; crud.zod.ts
• detail::DetailSchema.onNavigate — DetailView.tsx:635

packages/plugin-form

Both 'object-form' and 'form' register ObjectFormRenderer, so the same reads land on two arms.

• object-form::ObjectFormSchema.onCancel / .onError / .onOpenChange / .onStepChange / .onSuccess — packages/plugin-form/src/ObjectForm.tsx:260, 259, 424, 359, 258; objectql.zod.ts
• form::FormSchema.onError / .onOpenChange / .onStepChange / .onSuccess — same lines; form.zod.ts (FormSchema declares onSubmit, onChange, onCancel only)

packages/plugin-grid

• object-grid::ObjectGridSchema.onNavigate — packages/plugin-grid/src/ObjectGrid.tsx:2053; objectql.zod.ts
• grid::GridSchema.onNavigate — same read site; layout.zod.ts

packages/plugin-kanban

'object-kanban' registers the same ObjectKanbanRenderer as 'kanban', and ObjectKanbanSchema declares no handler key at all — so the three keys objectui#7664 ledgered on the 'kanban' arm are unledgered and undeclared on its sibling key.

• object-kanban::ObjectKanbanSchema.onCardClick / .onCardMove / .onQuickAdd — packages/plugin-kanban/src/index.tsx:194, 193, 197; objectql.zod.ts

packages/plugin-list

Both 'list-view' and 'list' register ListViewRenderer.

• list-view::ListViewSchema.onAddRecord / .onBulkAction / .onDensityChange / .onNavigate / .onPageSizeChange — packages/plugin-list/src/ListView.tsx:3816, 4075, 1354, 2210, 4158; objectql.zod.ts
• list::ListSchema.onAddRecord / .onBulkAction / .onDensityChange / .onNavigate / .onPageSizeChange — same lines; data-display.zod.ts
• object-gallery::ObjectGallerySchema.onCardClick / .onRowClick — packages/plugin-list/src/ObjectGallery.tsx:228; objectql.zod.ts

packages/plugin-view

• object-view::ObjectViewSchema.onNavigate — packages/plugin-view/src/ObjectView.tsx:966; objectql.zod.ts

What a fix looks like, and what is NOT decided here

Per key, the objectui#6124 disposition has to be MEASURED, not assumed — handlerKeyRefusal(key, 'runtime-slot', ...) where the value reaches the renderer, 'retired' where it does not, and the #6124 ledger updated alongside. Two questions this card does not settle:

1. 'list' and 'grid' and 'form'. A plugin registers each of those base types to its own object-backed renderer, so a read lands on an arm minted for a different component (ListSchema is data-display.zod.ts's simple list). Whether the fix is to declare the keys on those arms or to stop claiming the type is a ruling, not a mechanical edit.
2. Batching. These are nine packages. Splitting per package is probably right; the ledger drains row by row either way.

Refs: objectui#7753 (the gate) · objectui#6124 (the ruling that minted the ledger) · objectui#7664 / PR #7743 (the instance) · objectui#7104 (the last time a renderer was found reading an UNDECLARED key).

[claude]

PM 分诊（domain:ui PM 席，session_01KbJQ1y1J12nZxYzFWhP8Q3，round 6）：finding + package: types + domain:ui + priority:p2 + needs-user-decision。⛔ 本卡不进 pm:queue，理由在下。

到达时无 pm:* 标（半状态），先补齐。

p2

这是 objectui#7664 那次事故的同一类，×39：被注册 renderer 真的读取的 handler 键，没有任何 arm 声明它 ⇒ BaseSchema 的 .passthrough() 让它不被拒绝、不被判断、值被保留，main 上今天就是如此，横跨 9 个包。⛔ 不是 p1：不挡任何门、不产生错数据，作者写了也只是被静默接受。

⛔ 为什么挂 needs-user-decision 而不是 pm:queue

卡自己点名了它不解决的两件事，两件都是裁决而非测量：

1. 'list' / 'grid' / 'form' 到底该声明这些键，还是该停止声称一个"注册给某插件 object-backed renderer"的基类型？ —— 这是基类型与注册关系的架构问题，且任一方向都改变接受集（要么 arm 变宽，要么注册关系变）。⇒ 超出本席可自裁的范围。
2. 九个包怎么分批？ —— 这是排期，取决于 1 的答案。

⚠️ 还有第三条约束使它无法机械派发：按 objectui#6124 的裁定，每个键的处置（RUNTIME_SLOT / RETIRED / 声明）必须逐个测量，不能猜。39 个键 × 逐个测量 × 跨 9 个包，本身就不是一张卡的形状。

⇒ 本卡先要一个裁决，再谈拆分与派发。⛔ 在裁决之前不派。

⭐ 但好消息是：它已经被门看住了

PR #7805（卡 #7753）落地的 scripts/check-handler-key-read-sites.mjs 把这 39 行放进 KNOWN_UNDECLARED_READS，每一行都点名本卡，且一行的读点消失时门会红。⇒ 这不是一份会腐烂的名单：它不能悄悄变短，也不能在缺陷已消失时继续存在。

⇒ 所以本卡不急：新增的第 40 个同类缺口会被门当场挡下，存量的 39 个被钉在案上等裁决。

给裁决者的三条读数（都来自 #7805 的实现，⛔ 不必重测）

1. 门的两个总体都是派生的：arm 来自 packages/types/src/zod 里每一个 type: z.literal(...)（成员沿 .extend() 基类并解析对象展开求并），读点来自每一个真实的 ComponentRegistry.register 调用，外加该注册把同一份文档交给的那些组件。
2. main 上的普查读数：106 个 arm、216 个注册（120 个有 arm）、62 个可达 handler 读点、62 个已判、0 个因未解析展开而悬空、39 个由台账豁免；arm 成员 3071 个。
3. 本卡这 39 个分布：data-table ×7、tree-view、button、icon、detail ×2、object-form ×5 / form ×4、object-grid + grid、object-kanban ×3、list-view ×5 / list ×5、object-gallery ×2、object-view。⚠️ 注意 object-form/form、list-view/list、object-grid/grid 这三组成对出现 —— 那正是问题 1（基类型 vs 注册关系）的具体形状。

Refs: objectui#7753（门的卡）· PR #7805（门与全部读数）· objectui#6124（台账的裁定）· objectui#7104（同类先例 AlertDialogSchema.onAction）· objectui#7664（事故本身）

---

Generated by Claude Code