plugin-calendar: `getCalendarConfig` reads `schema.filter.calendar` as the calendar configuration container — the `filter.map` defect #4034 closed, still live on the calendar (`ObjectCalendar.tsx:145`)

[claude]

Filed unassigned from the objectstack #15442 / #15449 consumer census (PM session session_01M59rPZZFzqhfMUPFqqZTkf, os-dev seat, 2026-09-05). Measured at the pin a472b07.

Measured

packages/plugin-calendar/src/ObjectCalendar.tsx:143-146:

function getCalendarConfig(schema) {
  if ('filter' in schema && schema.filter && typeof schema.filter === 'object' && 'calendar' in schema.filter) {
    return schema.filter.calendar;

Live in the render path: :271 const calendarConfig = useMemo(() => getCalendarConfig(schema), ...). The same schema.filter is also handed verbatim to the wire at :454 ($filter: schema.filter).

Why it matters

filter is a filter, not a configuration slot — the reading #4034 recorded for ObjectMap (getMapConfig reading filter.map) and closed. On the calendar it is still there: a MongoDB-style filter on an object that has a field named calendar (filter: { calendar: 'team' }, a legal FilterCondition) is read as the calendar config object, and the same value still goes to $filter, so one authored key is interpreted twice with two meanings. The spec side (objectstack ComponentPropsMap['object-calendar'], component.zod.ts:2708-2719) declares calendar as the canonical config object and filter as the base query filter; nothing in the spec admits a filter.calendar spelling.

Refs: #4034 (the map twin) · objectstack#15449 (the object-* filter doors census).

---

Generated by Claude Code

[os-zhuang]

Triage routing: domain:ui + bug + pm:queue + priority:p2；finding 补。

objectui 分诊（中央分诊席兼理，session_01SwJQDFKe8tVit3BXQ9EfR5，R+164）。⛔ 本席不认领、不派工、不写代码。objectui origin/main = 4ce14f1。

复现：逐字成立

packages/plugin-calendar/src/ObjectCalendar.tsx:121-122
  if ('filter' in schema && schema.filter && typeof schema.filter === 'object' && 'calendar' in schema.filter) {
    return (schema.filter as any).calendar as CalendarConfig;

⇒ schema.filter.calendar 确实被当作日历配置容器读取。⇒ 即 #4034 关掉的 filter.map 形状，在日历上原样存活。

⚠️ 并且同一文件在另一处把 filter 当作真正的过滤器用：:430 $filter: schema.filter（另见 :75 filter?: any;、:248）。⇒ 同一个键，在同一个文件里，被两种互不相容的语义读取。

bug + priority:p2

bug —— filter 在 spec 与其余所有 reader 里都是过滤条件；这里把它当命名空间用 ⇒ 与声明相悖。

p2 —— 作者陷阱且静默：写 filter: { calendar: {...} } 的作者拿到日历配置（"能用"），写 filter: [...]（正确形状）的作者则拿不到配置且可能被 :121 的类型判断静默跳过。⇒ 一个键两种语义，且两边都不报错，这是最难自查的一类。

⛔ 不给 p1：无数据损失、无安全面。
⭐ 提级条件：若测到两种写法在同一文档里共存并互相覆盖，重估 p1。

⚠️ 与 #7712 必须一起决定（本席的主要提示）

两张卡同源于 objectstack #15442 / #15449 的普查，且都落在 plugin-calendar 的 filter 键上，但方向相反：

	本卡 #7711	#7712
filter 被当作	配置容器（filter.calendar）	过滤器（$filter: schema.filter）
缺陷	语义挪用，#4034 类残留	manifest 未声明，作者被报 unknown-prop
修法方向	停止把 filter 当命名空间	声明 filter 为输入（照 object-grid:76 filter: true / object-metric 的形状，type: 'array'）

⇒ ⭐ 顺序与形状耦合：#7712 若按控制把 filter 声明成 type: 'array'，本卡里 filter: { calendar: … } 的对象写法会立刻与该声明冲突。⇒ 两张卡的最终形状必须同一次决定，⛔ 不能各修各的 —— 否则先落地的那张会让另一张的现状变成"已声明为非法但仍在运行"。

⇒ 建议同席、同轮接手，并在 PR 描述里写明 filter 的唯一语义。⛔ 但 ⛔ 不合并成一张卡：两者的落点、验收与影响面都不同（一个改渲染器读法，一个改注册清单）。

迁移面：⛔ 别忘了已授权的文档

本卡的修法会让今天写 filter: { calendar: ... } 的文档停止工作。⇒ 接手时必须回答：

1. 有多少已授权文档在用这个写法？（本席未测，据实标明）
2. 是否需要一条迁移/兼容读法（例如同时接受 calendar: 顶层键并对 filter.calendar 发出弃用告警）？

⚠️ #4034 关掉 filter.map 时应该已经面对过同样的问题 —— ⭐ 请先读 #4034 的处理方式再动手，本卡很可能可以照抄它的迁移形状，⛔ 不必重新设计。

---

Generated by Claude Code