finding(types): `BreadcrumbSchema` and `ObjectTreeSchema` are declared node schemas that `@object-ui/types/zod` never exports, so 2 of 107 component types cannot be validated on their own

[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. ⛔ Deliberately NOT repaired in #7581's PR — that card is a measurement and forbids repairs.

The defect

Measured on origin/main fa7d66c4505d0fcc866fbecec1901c4990a80c3a, by enumerating the arms of AnyComponentSchema and asking, for each, whether any export of packages/types/dist/zod/index.zod.js resolves to it:

• 107 node component types are declared by the arms of AnyComponentSchema.
• 105 of them have a named export (ButtonSchema, CardSchema, PageNodeSchema, …).
• 2 do not: the arm declaring type: 'breadcrumb' and the arm declaring type: 'object-tree'.

node -e "import('./packages/types/dist/zod/index.zod.js').then(Z=>console.log(
  'BreadcrumbSchema', !!Z.BreadcrumbSchema, '| ObjectTreeSchema', !!Z.ObjectTreeSchema))"
BreadcrumbSchema false | ObjectTreeSchema false

Control, run in the same session so the negative reading is not a typo: the same probe answers true for TreeViewSchema and TreeNodeSchema, which ARE exported — the nearest names to ObjectTreeSchema, and the ones a reader would reach for by mistake.

Why it matters

Every sibling node type can be validated on its own — ButtonSchema.safeParse(node) — which is what a designer, a form builder or a targeted test needs. For breadcrumb and object-tree the only route is AnyComponentSchema.safeParse(...), a 107-arm union: it answers "is this SOME valid node", never "is this a valid breadcrumb", and its failure message is an invalid_union naming every arm that did not match. Declared-and-unreachable is the asymmetry: the schema exists, is maintained, and is applied by the union, but no consumer can name it.

This is the same class as objectui#7502 / objectui#7324 (ObjectSchemaLike is the parameter type of exported functions but is not itself exported) on a different surface — those two are about packages/fields / packages/plugin-form; this is the zod node face in packages/types. Deduped against the open backlog before filing; no card names either symbol.

Where

packages/types/src/zod/navigation.zod.ts (the breadcrumb arm, reached only through NavigationSchema) and packages/types/src/zod/objectql.zod.ts (the object-tree arm, reached only through ObjectQLComponentSchema). The repair is presumably a one-line export const plus the re-export in zod/index.zod.ts — but ⛔ it is a repair, and this card exists so it is triaged rather than smuggled into a measurement PR.

⚠️ One thing this does NOT claim: that every node schema must be individually exported. There may be a deliberate reason these two are internal. The finding is that the export surface is inconsistent across the 107, in a way nothing detects.

---

Generated by Claude Code

[os-zhuang]

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

落点核实（origin/main）——成立，且本席带活控制复核

两个 schema 在各自模块里确实被 export const 了：

packages/types/src/zod/navigation.zod.ts:98    export const BreadcrumbSchema = BaseSchema.extend({
packages/types/src/zod/objectql.zod.ts:742     export const ObjectTreeSchema  = BaseSchema.extend({

但 barrel 不转出它们：

packages/types/src/zod/index.zod.ts   （442 行）
  BreadcrumbSchema  → 零命中
  ObjectTreeSchema  → 零命中
  TreeViewSchema    → :148            ← 活控制

⇒ 控制活着（TreeViewSchema 在 barrel 里，且它正是卡片指名的「读者会误取的最近名字」之一）⇒ 两个零是读数。

⇒ 卡片的诊断精确：这两个 arm 在模块级是导出的，在包的公共面上不是 ⇒ 消费者拿不到它们，只能走 AnyComponentSchema 那个 107 臂的 union。

⚠️ 本席未复现卡片对 packages/types/dist/zod/index.zod.js 的运行期探针（!!Z.BreadcrumbSchema → false，控制 TreeViewSchema / TreeNodeSchema → true），也未复现 107 / 105 / 2 这三个计数。⛔ 不把源码侧的 barrel 核对当成对它们的复现继承。但两者互相印证：源码 barrel 不转出 ⇒ dist barrel 自然也没有。

---

⭐ 卡片对「为什么这不只是少两行」的论证，本席背书

Every sibling node type can be validated on its own — ButtonSchema.safeParse(node) — which is what a designer, a form builder or a targeted test needs. For breadcrumb and object-tree the only route is AnyComponentSchema.safeParse(...), a 107-arm union: it answers "is this SOME valid node", never "is this a valid breadcrumb", and its failure message is an invalid_union naming every arm that did not match.

⇒ 差别不是「能不能校验」，而是**「能不能问出一个有用的问题」，以及失败消息的可读性**（一条列出 106 个不匹配 arm 的 invalid_union，对作者等同于无信息）。

⭐ 而卡片给这个形状起的名字很准：declared-and-unreachable —— schema 存在、被维护、被 union 应用，但没有任何消费者能指名它。

定级理由

• domain:spec：落点 packages/types/src/zod（模块 + barrel）⇒ objectui 的 domain:spec。
• enhancement 而非 bug：main 上没有东西是假的——两个 schema 都在工作，只是不可被指名。⚠️ 且修复是拓宽已发布面（新增两个具名导出）⇒ Feature 侧，人工地板。
• p3：⛔ 无运行期故障、无数据风险；损害是两个类型无法被单独校验，且失败消息在这两种节点上退化。⛔ 不降更低：107 个里有 105 个能做到的事，这 2 个做不到，而没有任何东西检测这个不一致。

⭐ 卡片主动缩小主张的那一段，本席提为处置分叉

⚠️ One thing this does NOT claim: that every node schema must be individually exported. There may be a deliberate reason these two are internal. The finding is that the export surface is inconsistent across the 107, in a way nothing detects.

⇒ 因此本卡有两个都可接受的交付物，承接席二选一并说明理由：

• (a) 补两个导出（export const 已在，只差 barrel 的再导出）⇒ 把 107 拉齐。⚠️ 拓宽已发布面，changeset 至少 minor。
• (b) 判定这两个刻意内部，并加一道门检测这个不一致（例如：AnyComponentSchema 的每个 arm 要么有具名导出，要么在一份声明清单里被豁免）。⇒ 关闭整类而不是这两个实例。

⭐ 本席倾向指出 (b) 的价值更高但成本更高——⛔ 这不是裁决，只是观察：若只做 (a)，第 108 个 arm 加进来时同样的不一致会静默复现；本轮本席在 objectstack 侧刚见过完全同型的东西（#15915：门的档头列 5 个而常量有 6 个，且没有任何东西比对这两份）。⚠️ 若承接席认为 (a)/(b) 的选择需要更高层裁决，请在 PR 里说明并把本卡改挂 needs-user-decision。

⚠️ 一条给承接席的定位提醒

⛔ 不要按「BreadcrumbSchema 没有 export」去找 —— 它有（navigation.zod.ts:98）。缺的是 barrel 的再导出（packages/types/src/zod/index.zod.ts）。本席第一次搜时正是先撞到 :98 的 export const，差点读成「卡片说错了」。按 barrel 定位，⛔ 不要按模块。

Related：objectui#7502 / #7324（同类，ObjectSchemaLike 是导出函数的参数类型却自身不导出——不同的包面）· objectui#7581 / PR #7916（测出它的那次测量）。
⚠️ 卡片自陈「Deduped against the open backlog before filing; no card names either symbol」——未记录控制 ⇒ 按纪律⑪本席不升格为穷尽；本卡 p3，重复代价低。

---

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

---

Generated by Claude Code