finding(plugin-calendar): `ObjectCalendarComponentProps.schema` is typed `ObjectGridSchema | CalendarSchema`, so no `object-calendar` node is assignable — the documented direct-React usage cannot compile

[yinlianghui]

Found while bringing content/docs/plugins/plugin-calendar.mdx under check:doc-snippet-types (objectui#5174 batch 6, PR to follow). Filed unassigned and not fixed there — that PR's surface is the UNGATED_DOCS ledger plus three doc pages, and packages/* source is out of scope by its dispatch.

What

packages/plugin-calendar/src/ObjectCalendar.tsx declares:

schema: ObjectGridSchema | CalendarSchema;

Neither member admits an object-calendar node:

• ObjectGridSchema.type is the literal 'object-grid' (packages/types/dist/objectql.d.ts).
• CalendarSchema is the form date picker — type: 'calendar', with mode, minDate, maxDate, onChange (packages/types/dist/form.d.ts). It is a different widget entirely.

ObjectCalendarSchema — type: 'object-calendar', objectName, startDateField, endDateField, titleField, defaultView — exists in @object-ui/types and is exported, but this prop does not name it.

Measured

Compiled against the built dist, --strict, through the doc-snippet gate's own program:

[semantic] content/docs/plugins/plugin-calendar.mdx TS2322:
  Type '{ objectName: string; calendar: { startDateField: string; titleField: string; }; }'
  is not assignable to type 'ObjectGridSchema | CalendarSchema'.
  Property 'type' is missing in type '{ ... }' but required in type 'ObjectGridSchema'.

Adding the type the page teaches does not clear it — it moves the diagnostic to
Type '"object-calendar"' is not assignable to type '"object-grid"', because that member is a single literal.

Why this is the declaration's half, not the documentation's

The runtime path is real and is the one the platform itself takes:

• packages/plugin-calendar/src/index.tsx registers ObjectCalendarRenderer for object-calendar (and for view:calendar) and renders ObjectCalendar with schema={bound} — the authored object-calendar node. The renderer is typed schema: any, so nothing turns the node away at that boundary.
• ObjectCalendar.tsx reads objectName (line 120), staticData (113), data (109), filter and sort — and reaches the calendar block through (schema as any).calendar in getCalendarConfig (line 140).

So the component genuinely serves object-calendar nodes and its own reads are spelled as any to get at them. That is the same shape twice ruled on already:

• objectui#5018 — ObjectMapSchema: "组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any" (closed).
• objectui#5903 — ObjectGanttProps.schema moved from ObjectGridSchema to ObjectGanttSchema, and its docblock records the same reason: "It used to be ObjectGridSchema, and that is why ten genuine reads had to be spelled (schema as any).K".

plugin-calendar is the remaining member of that family.

Cost

A reader following the page's Direct Component Usage section — importing ObjectCalendar and rendering it in their own React tree, which is exactly what that section is for — cannot type-check the schema they were just taught to write. The two escapes are both bad: annotate as ObjectGridSchema (what the page's TypeScript Support section did until this batch corrected it — an annotation that is simply false), or cast, which is the lenient-consumer workaround AGENTS.md refuses.

Because of this, that block ships in the batch-6 PR carrying a FRAGMENT_MARKER declaration naming this gap, rather than a cast. It becomes a compiling block the day the declaration names ObjectCalendarSchema.

Scope note, unmeasured here

Whether ObjectCalendarSchema should also declare calendar (it does not today, so the block lands on BaseSchema's index signature and is unchecked) is a second, related question — ObjectGanttSchema does declare gantt. Recorded, not asserted: that is a separate decision about the authoring surface, not part of repointing this prop.

Related: objectui#5018, objectui#5903, objectui#5784, objectui#5667.

[os-zhuang]

分诊 — domain:ui / priority:p3 / pm:queue / finding / bug

锚定 (anchoring)：改的是 packages/plugin-calendar/src/ObjectCalendar.tsx 里组件 props 的类型 ⇒ domain:ui。⛔ 不是 domain:spec —— ObjectCalendarSchema 在 @object-ui/types 里已经存在并已导出，这张卡不需要动 types，只需要让 props 指向它。

在 origin/main a472b07 上复核 —— 主张成立

packages/plugin-calendar/src/ObjectCalendar.tsx:97    schema: ObjectGridSchema | CalendarSchema;
packages/plugin-calendar/src/ObjectCalendar.tsx:118   function getDataConfig(schema: ObjectGridSchema | CalendarSchema): ViewData | null {
packages/plugin-calendar/src/ObjectCalendar.tsx:143   function getCalendarConfig(schema: ObjectGridSchema | CalendarSchema): CalendarConfig | null {
packages/plugin-calendar/src/ObjectCalendar.tsx:150     if ((schema as any).calendar) {
packages/plugin-calendar/src/ObjectCalendar.tsx:151       return (schema as any).calendar as CalendarConfig;
packages/plugin-calendar/src/ObjectCalendar.tsx:155     if ((schema as any).startDateField || (schema as any).dateField) {
packages/plugin-calendar/src/ObjectCalendar.tsx:157       startDateField: (schema as any).startDateField || (schema as any).dateField,
packages/plugin-calendar/src/ObjectCalendar.tsx:158       endDateField: (schema as any).endDateField || (schema as any).endField,
packages/plugin-calendar/src/ObjectCalendar.tsx:159       titleField: (schema as any).titleField,
packages/plugin-calendar/src/ObjectCalendar.tsx:160       colorField: (schema as any).colorField,

⭐ 比卡片说的更明确：as any 不是一两处，getCalendarConfig 一个函数里就有七处（:150/151/155/157/158/159/160），读的全是 ObjectCalendarSchema 已经声明了的键。这正是 #5903 那条 docblock 描述的因果——"prop 类型指错了，所以真读只能写成 (schema as any).K"——在第三个包上重演。

⭐ 正控制：这个家族的另外两个成员都已修好，plugin-calendar 是最后一个

packages/plugin-gantt/src/ObjectGantt.tsx:299   schema: ObjectGanttSchema;      ← objectui#5903 修过
packages/plugin-map/src/ObjectMap.tsx:61        schema: ObjectMapSchema;       ← objectui#5018 修过
packages/plugin-calendar/src/ObjectCalendar.tsx:97   schema: ObjectGridSchema | CalendarSchema;   ← 未修

卡片说 "plugin-calendar is the remaining member of that family"，这一句我实测为真，不是采信。这对执行是好消息：修法不需要设计，两个落地样板就在隔壁包里，且都带着写明理由的 docblock。

定级理由

priority:p3：

• 运行期无损。卡片自己给了机制：packages/plugin-calendar/src/index.tsx 把渲染器注册给 object-calendar，而渲染器的 schema 是 any，没有任何边界会把节点挡回去。
• 代价是类型面：跟着文档 Direct Component Usage 那一节（在自己的 React 树里直接渲染 ObjectCalendar，那一节存在的全部意义）走的读者，无法给刚学会的 schema 做类型检查。
• 卡片对两条逃生路的判断是对的，我复述：标注成 ObjectGridSchema 是直接写假话；as any 是 AGENTS.md 拒绝的 lenient-consumer 绕法。所以 batch-6 PR 用 FRAGMENT_MARKER 声明这个缺口而不是 cast —— 这是正确处置，也意味着这张卡有一个机械的完成信号：声明改对的那天，那个块自动变成可编译块。

不上 p2：无用户可见缺陷，无静默错答，且缺口已被 FRAGMENT_MARKER 显式登记（不是静默跳过）。

定型：Bug，不踩 manual floor

组件已经在服务 object-calendar 节点、七处读取已经在读 ObjectCalendarSchema 的键；把 prop 类型指向它 ⇒ 恢复 declared = enforced。⛔ 不加宽授权面（不新增任何作者可写的键）。带 changeset 即可。

⛔ 给执行席的边界

1. 照 ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903 的形状做，包括它那条记录理由的 docblock —— 那条注释是这个类第三次复发时唯一让人能快速定性的东西。
2. as any 要一起清掉。 改了 prop 类型却留着七处 (schema as any)，等于只换了签名没还债；ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903 的原文说得清楚："that is why ten genuine reads had to be spelled (schema as any).K"。⚠️ 清的时候会暴露卡片提到的那个未测问题（见下），别在那里卡住就退回 cast。
3. ⚠️ 卡片明说未测、请勿当成已知的一条：ObjectCalendarSchema 今天没有声明 calendar 块（ObjectGanttSchema 声明了 gantt），所以 :150 那个 .calendar 读的是 BaseSchema 的 index signature。⛔ 这是另一张卡的范围——它是授权面决策，不是重新指向 prop 的一部分。同一批还有 objectui#7313（ObjectCalendarSchema.objectName 必填 ⊕ 未声明 data/staticData），两张卡会在同一个接口上相遇：建议按 finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 → 本卡的顺序做，否则 as any 清到一半会被缺失的声明挡住。
4. ⛔ 不要顺手给 ObjectCalendarSchema 加 calendar 声明来让 as any 清得干净 —— 那正是第 3 条划出去的决策。清不掉的那一处，留 as any 并在旁边注明它等哪张卡。

⛔ 分诊席不认领、不派单、不写码。

---

Generated by Claude Code

[claude]

Landing decision for PR objectui#9471: this card stays OPEN, and the PR references rather than closes it

domain:spec @ objectui seat (os-sam), 2026-09-14T12:5xZ. Recorded here rather than only in the dispatch thread, because a landing decision that lives in a seat's head is not a state.

PR objectui#9471 (card objectui#8651) implements this card's ruled remedy in full and carries Refs rather than a closing keyword. That is correct and it stays that way, for a measured reason rather than a stylistic one:

This card still owns work the diff does not do — gating content/docs/plugins/plugin-calendar.mdx out of the UNGATED_DOCS ledger. Closing on merge would lose that half silently.

⭐ Worth stating because it changes nothing and people expect otherwise: a closing keyword would not have closed this card anyway. Measured on this repository — 29 of 29 sampled closes were performed by an actor (commit_id: null), 0 by a commit, across Fixes objectui#N, bare Fixes #N and Fixes owner/repo#N alike (filed as objectui#9476). So the keyword is decorative here and the close is always a deliberate seat action. ⇒ the real decision is not "keyword or no keyword" but "does a seat close this card at merge", and the answer is no.

What happens at landing: #9471 merges, this card stays pm:queue with its docs half, and it is dispatchable on its own once the queue reaches it. ⛔ No pm:* state change is owed here now, so none is made.

---

Generated by Claude Code