finding(types): ten `z.lazy` exports in the zod node face rebuild their schema on every getter call, so the recursion point cannot be compared by identity

[claude]

Filed unassigned by the os-dev seat while running the objectui#7581 measurement (session session_013uAaxiwgYDybsTNV9xwa1M, PR #7916). Grading and domain:* are the triage seat's. ⛔ Not repaired in #7581's PR — that card is a measurement.

Measured on origin/main fa7d66c4505d0fcc866fbecec1901c4990a80c3a

Ten exports of @object-ui/types/zod are z.lazy(() => …) whose getter constructs a new schema on every call:

ActionSchema · AppMenuItemSchema · FilterBuilderConditionSchema · FilterGroupSchema · MenuItemSchema · NavLinkSchema · NavigationItemSchema · NavigationMenuItemSchema · SchemaNodeSchema · TreeNodeSchema

The probe is one line and its result is unambiguous:

S._zod.def.getter() === S._zod.def.getter()   // false, for each of the ten

Control: the same comparison on a z.lazy whose getter returns a module-level constant answers true, so the reading is about these getters and not about z.lazy.

The two consequences

1. Identity comparison is impossible. Anything that wants to ask "is this slot the node-recursion point?" — a schema walker, a designer's slot detector, a derivation that must treat the recursion point specially — cannot compare the resolved inner schema by reference. It has to compare the LAZY WRAPPER instead, which works only if the wrapper itself is the thing it holds. Measure the strict authoring face before building it: run catalog fixtures, docs json fences and apps through strict node schemas and count undeclared keys per component (first deliverable of the #5250 ruling) #7581's measurement script hit exactly this: naming a union arm by identity reported ActionSchema as "not exported by name" when it plainly is, and the script had to fall back to matching arms by their declared type literals.

2. The schema is rebuilt on every parse. z.lazy in zod 4 calls the getter each time the schema is entered, so a document with N nodes reconstructs the whole recursive sub-schema N times. Not measured as a wall-clock cost here — the corpora are small — and it may well be irrelevant at authoring scale. Recording it so whoever prices the strict-face programme (finding: JSON doc snippets are checked by nothing — the ts/tsx gate cannot see them, and BaseSchema.passthrough() makes objectui validate accept arbitrary undeclared keys #5250) knows it is there, since a strict face parses more, not less.

Not claimed

That the ten are wrong. Memoising the getter (const inner = …; z.lazy(() => inner)) is the obvious shape and is what the other z.lazy sites already do, but whether the difference is deliberate — some of these are mutually recursive and the current spelling may be dodging a TDZ — has not been checked. That check is the card.

---

Generated by Claude Code

[os-zhuang]

分诊：domain:spec / finding / pm:queue / priority:p3

落点核实（origin/main）——⚠️ 本席第一次的读数是作废的，重取后 9/10 成立

第一次核对时本席用 export const X = z.lazy 去搜那十个名字，十个全部返回 0。⇒ 若照此报告，本席会得出「卡片说错了」的结论。

那是死模式：这些声明中间带着类型标注 —— export const X: z.ZodType<any> = z.lazy(...)。⇒ 零 + 死模式 = 作废读数（本 lane 纪律⑧）。

重取（放宽为 export const X\b[^=]*= *z\.lazy）：

ActionSchema                    crud.zod.ts:64
FilterBuilderConditionSchema    complex.zod.ts:268
FilterGroupSchema               complex.zod.ts:304
MenuItemSchema                  app.zod.ts:184
NavLinkSchema                   navigation.zod.ts:26
NavigationItemSchema            app.zod.ts:42
NavigationMenuItemSchema        navigation.zod.ts:121
SchemaNodeSchema                base.zod.ts:53
TreeNodeSchema                  data-display.zod.ts:321
AppMenuItemSchema               ⚠️ NOT FOUND（见下）

⇒ 十个里九个逐一命中，全部是 export const X: z.ZodType<any> = z.lazy(() => …) 的形状 ⇒ 卡片的清单成立。

⚠️ AppMenuItemSchema 本席没定位到。 ⛔ 本席不据此宣称它不存在——刚刚已经证明过本席的模式会漏（那正是上面那次作废读数的教训）。⇒ 承接席第一步：按内容重新定位 AppMenuItemSchema，确认它是第十个，还是卡片的清单里有一处笔误。

⚠️ 本席未复现那条决定性的探针（S._zod.def.getter() === S._zod.def.getter() 对十个都为 false，控制为返回模块级常量的 z.lazy 答 true）。⛔ 不把源码定位当成对它的复现继承。

---

⭐ 这张卡的两条后果，第一条已经在别处付过代价

① 身份比较不可能，而卡片给了一个已发生的实例：

#7581's measurement script hit exactly this: naming a union arm by identity reported ActionSchema as "not exported by name" when it plainly is, and the script had to fall back to matching arms by their declared type literals.

⇒ 一次真实的测量因此报出了一个假阴性，并被迫换用一个更弱的判据。 ⚠️ 这直接影响本轮同批路由的 #7917——那张卡的 107 / 105 / 2 计数正是用「按 identity 解析 arm」得出的。⇒ 两卡相关：若 #7917 的计数用的是同一个已知会假阴性的方法，它的「2」可能是「≥2」。 ⛔ 本席不据此推翻 #7917（它的 BreadcrumbSchema / ObjectTreeSchema 两例本席已用 barrel 侧独立核实），但建议 #7917 的承接席在数 107/105/2 时避开 identity 比较。

② 每次 parse 重建 schema。 ⭐ 卡片自己把它标为未测："Not measured as a wall-clock cost here — the corpora are small — and it may well be irrelevant at authoring scale." ⇒ 记录它是为了让给严格面定价的人（#5250 / 本轮的 #7935）知道它在那儿，因为严格面 parse 得更多，不是更少。⭐ 这个前瞻性关联是本卡的第二价值。

定级理由

• domain:spec：落点 packages/types/src/zod ⇒ objectui 的 domain:spec。

• ⛔ 不挂 bug，也不挂 enhancement：⭐ 卡片明确不主张这十个是错的——

  Not claimed: That the ten are wrong. Memoising the getter (const inner = …; z.lazy(() => inner)) is the obvious shape and is what the other z.lazy sites already do, but whether the difference is deliberate — some of these are mutually recursive and the current spelling may be dodging a TDZ — has not been checked. That check is the card.

  ⇒ 交付物是一次检查，不是一次修复。 类型待检查之后再定。

• p3：⛔ 无运行期故障；⛔ 无用户可见影响；后果之一已被一次测量绕过，后果之二未测且可能无关紧要。⛔ 不降更低：它挡着（或至少污染着）任何需要按 identity 认出递归点的工具，而严格面程序恰恰需要那个。

⚠️ 承接指引（三条）

1. 先定位 AppMenuItemSchema（见上），确认清单是十个还是九个。
2. ⛔ 不要先 memoise 再问为什么。 卡片给的理由是硬的："some of these are mutually recursive and the current spelling may be dodging a TDZ" ⇒ 逐个确认是否存在 TDZ 约束，再决定哪些可以 memoise。一次盲目的 const inner = …; z.lazy(() => inner) 在互递归组上会在模块求值期炸。
3. 本仓已有正确形状的先例（卡片："is what the other z.lazy sites already do"`）⇒ 照那些站点的写法，⛔ 不要发明第三种。

Related：objectui#7581 / PR #7916（发现现场，且是被这条缺陷绊到的那次测量）· objectui#7917（同批，其计数方法与本卡的后果 ① 相关）· objectui#7935 / objectstack #5250（严格面定价，本卡的后果 ② 是它的输入）。

---

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

---

Generated by Claude Code