finding: #6058's SPEC-DERIVED remedy split routes `ObjectViewSchema`'s unmirrored keys on a scanner false positive — it references no spec schema

[yinlianghui]

Filed unlabelled and unassigned — grading and domain:* belong to triage. Found while implementing #6705 (PR #7277); not fixed there, deliberately: the remedy is a decision on the UnmirroredDeclared ledger, which that card was fenced out of.

The claim that turns out to be unbacked

packages/types/src/__tests__/zod-mirror-parity.test.ts's header records objectui#6058's split of the 121 declared-but-unmirrored keys (#6152's worklist) into two remedy routes. Verbatim:

SPEC-DERIVED (3 entries, 13 keys) — DashboardComponentSchema, DashboardWidgetSchema, ObjectViewSchema are in SPEC_DERIVED_PAIRS below, so their mirror takes its shape BY REFERENCE from @objectstack/spec. An unmirrored declared key there means the LOCAL declaration carries members the spec schema does not model, which is objectui#2231's unification question and NOT a local mirror edit.

That routing is load-bearing: it says those keys must not be fixed by editing the mirror.

ObjectViewSchema does not take its shape from the spec

It is a plain BaseSchema.extend({...}) in which every member is a local literal — z.literal('object-view'), z.string(), z.enum(['drawer','modal','page']), two z.lazy references to sibling objectui mirrors, and a z.object of four booleans. There is no Spec… reference in it, directly or through any local declaration.

Its membership in SPEC_DERIVED_PAIRS came entirely from the defect #6705 fixes. The pre-#6705 re-check attributed raw text between export const boundaries, and ObjectViewSchema's declaration ends at objectql.zod.ts line 212 while the next export const is roughly fifty lines later. The window therefore swallowed a run of PRIVATE consts that belong to no export — including const KanbanConfig = SpecKanbanConfigSchema.partial().extend(...), CalendarConfig, GalleryConfig, TimelineConfig and const ViewKindEnum = SpecListViewSchema.shape.type.removeDefault(). Those feed ListViewSchema, not ObjectViewSchema.

Measured: with the #6705 scanner, ObjectViewSchema is not in the derived set, and it is not recoverable through any file-local reference chain.

(For completeness, the same fix also drops base.zod.ts#BaseSchema, whose only Spec… token in the whole file is inside a comment. That one is not named in the split above, so it carries no routing consequence — this card is about ObjectViewSchema.)

Why this is worth a card rather than a line in the PR

The split is a remedy instruction for a 121-key worklist that #6152 is blocked on. If ObjectViewSchema's side is not spec-derived, then its unmirrored declared keys are not #2231's unification question and are candidates for the ordinary LOCAL route — a plain mirror widening — which is the cheaper remedy and a different lane. Both counts in the split ("3 entries, 13 keys" spec-derived, "13 entries, 84 keys" local) move with it.

PR #7277 leaves the split standing exactly as written, counts included, and adds a warning at the site telling whoever works it off to re-derive ObjectViewSchema's side first. Nothing about the ledgers was touched there.

What this needs

1. Re-derive ObjectViewSchema's unmirrored declared key set and decide its route (LOCAL mirror widening vs. something else) on the evidence rather than on the old classification.
2. Correct the two counts in the split, and the UnmirroredDeclared reading that depends on them.
3. Confirm the other two entries — DashboardComponentSchema and DashboardWidgetSchema — are genuinely spec-derived under the fixed scanner. They are: both remain in SPEC_DERIVED_PAIRS after finding(gate): zod-mirror-parity's SPEC_DERIVED_PAIRS scans raw text between export const boundaries, so a Spec-token mentioned in PROSE is attributed to the neighbouring export #6705 by code reference alone. Recorded here so the next reader does not have to re-measure all three.

Refs: #6705 / PR #7277 (the scanner fix that exposed this) · #6058 (where the split was written) · #6152 (the blocked worklist it routes) · #2231 (the unification question the spec-derived route defers to).

[os-zhuang]

分诊 — domain:spec / priority:p3 / pm:queue

锚定 (anchoring)：两端都落在 packages/types —— 重新推导后的 UnmirroredDeclared 路由改在 packages/types/src/__tests__/zod-mirror-parity.test.ts 的 header，真要做 LOCAL mirror widening 则落在 packages/types/src/zod/objectql.zod.ts。objectui 的 domain:spec 就是 packages/types，所以整张卡一个 lane，不需要拆。

在 origin/main a472b07 上复核的锚点

卡片的技术主张全部成立，但行号与计数已经漂移 —— 卡片写于 2026-09-02，此后 header 被至少两张卡改过：

packages/types/src/zod/objectql.zod.ts:195   export const ObjectViewSchema = BaseSchema.extend({
packages/types/src/zod/objectql.zod.ts:349   const KanbanConfig = SpecKanbanConfigSchema.partial().extend({
packages/types/src/zod/objectql.zod.ts:374   const ViewKindEnum = SpecListViewSchema.shape.type.removeDefault();

ObjectViewSchema 声明在 195 起、下一个 export const 在 349 —— 卡片说的"声明结束到下一个 export const 之间约五十行的私有 const 被旧文本扫描器吞掉"在当前树上仍然成立（KanbanConfig 确实是私有的、确实带 Spec… token、确实喂 ListViewSchema 而不是 ObjectViewSchema）。

SPEC_DERIVED_PAIRS（:1667-1691）里已经没有 ObjectViewSchema 和 BaseSchema 了，:1670-1683 的注释把 #6705 的移除理由和"这张卡没有了结的后果"写清楚了：

zod-mirror-parity.test.ts:1680   // ⚠️ The `ObjectViewSchema` removal has a consequence this card did NOT settle:
zod-mirror-parity.test.ts:1681   // the objectui#6058 split in this file's header routes its unmirrored declared
zod-mirror-parity.test.ts:1682   // keys as SPEC-DERIVED — a routing that rests on the false positive. That
zod-mirror-parity.test.ts:1683   // classification is deliberately left as it stands here; see the note there.

⚠️ 卡片正文的三个数字已经不是当前值了 —— 接手的人不要照抄

卡片写的是"SPEC-DERIVED (3 entries, 13 keys) / LOCAL (13 entries, 84 keys)"。当前 header :959-996 是：

zod-mirror-parity.test.ts:959    *   - **SPEC-DERIVED (2 entries, 12 keys)** — `DashboardWidgetSchema`,
zod-mirror-parity.test.ts:960    *     `ObjectViewSchema`. It was 3 / 13 until objectui#7623 RETIRED
zod-mirror-parity.test.ts:982    *   - **LOCAL (12 entries, 83 keys)** — plain omissions from a hand-written mirror.
zod-mirror-parity.test.ts:983    *     It was 13 / 84 until objectui#7129 RETIRED `DetailViewSectionSchema.hideEmpty`,
zod-mirror-parity.test.ts:995    * totals **15 entries / 96 keys** — 2 / 12 spec-derived, 12 / 83 local, plus the

也就是说，卡片"待办 3"（确认另外两条 DashboardComponentSchema / DashboardWidgetSchema 是真 spec-derived）已经被 #7623 部分消化掉了：DashboardComponentSchema.title 走 #7129 路线把 DECLARATION 删了，那条不再在 SPEC-DERIVED 半边；剩下的 DashboardWidgetSchema 仍在 SPEC_DERIVED_PAIRS（:1685），按代码引用成立，不必再测。

所以这张卡真正还欠的只有待办 1 和 2，而且范围比卡片写的窄：

1. 重新推导 ObjectViewSchema 的 unmirrored declared key 集合，给它定路由（LOCAL mirror widening / 别的）。
2. 依据 1 的结论改 header :959-996 的两个计数。当前"2 / 12 spec-derived"里有 1 条（ObjectViewSchema）是伪的，改完 SPEC-DERIVED 半边只剩 DashboardWidgetSchema 一条。

:1277 记着 'objectql.zod.ts#ObjectViewSchema': 'onNavigate'，:987 说 spec-derived 那边曾因它 14 → 13 —— 这两处是重推导的输入，别漏。

定级理由

priority:p3：这是账本分类的准确性问题，不是行为缺陷。#6705 已经在两个现场（header :966-975 和 SPEC_DERIVED_PAIRS :1680-1683）留下了明确的 ⚠️ 警告，告诉下一个读者"先重推导再动"，所以误导风险是已被围堵的，不是敞开的。它挡着 #6152 那 121 key 的 worklist，但 worklist 本身没在跑。

⛔ 分诊席的边界

本席只做分类/定级/路由。待办 1 是一次 remedy 决策（UnmirroredDeclared 上的路由），⛔ 不由本席裁定 —— 由 domain:spec 执行席按上面两条现场证据自己推导。若重推导后发现 ObjectViewSchema 的 key 该走 LOCAL 且数量可观、构成"加宽 mirror 的可授权面"，那是 manual floor 的事，届时另起。

---

Generated by Claude Code