decision(plugin-calendar): a record with no value in the declared date field is silently placed on today — and the `isNaN` guard beside it structurally cannot catch that

[os-sam]

Filed by the domain:ui seat (session session_013hfmP9hoMd3dJwTh85J4yB) on behalf of PR #7062, whose body states this was "Filed separately". It was not — the implementing agent's dedupe channel was rate-limited, so it declined to file blind and handed the finding back. This is that filing, re-measured against origin/main at 592acafbe.

⚠️ This is layer 3 of the chain already described in #7029's body. It is filed as its own card, not as a duplicate, because #7029's ruled deliverable closes a different trigger — see "What #7062 leaves" below. If a reviewer judges it belongs inside #7029 after all, close this as a duplicate; the seat would rather over-file than leave a landed PR pointing at a card that does not exist.

Measured

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

start: startDate ? new Date(startDate) : new Date(),

A record with no value at the configured startDateField is given the current moment as its event start, and then renders as an ordinary event indistinguishable from a real one.

⭐ The guard six lines below cannot catch it, by construction

:451:

}).filter(event => !isNaN(event.start.getTime())); // Filter out invalid dates

That filter exists to drop unusable dates. It cannot fire here: new Date() with no argument is always a valid Date, so the fallback at :445 produces exactly the one value the guard is guaranteed to pass. The absent-value case is converted into a well-formed lie before the check that would have caught it.

Note the asymmetry two lines away — end: endDate ? new Date(endDate) : undefined falls back to undefined, which is honest. Only start fabricates. (allDay: !endDate then infers all-day from the missing end; adjacent, and probably fine, but it means one absent field silently changes two rendered properties.)

What #7062 leaves

Before #7062, this fired for views that declared no calendar config at all — the invented 'due_date' binding meant every record missed its field, which is how nine hotcrm records piled onto today's cell.

After #7062, the fabricated bindings are gone and the refusal screen catches the unconfigured view. The hole that remains is narrower and genuinely different: a view that correctly declares startDateField, over records where some rows have no value in that field. Those rows silently collect on today, mixed in with correctly placed ones — arguably harder to notice than the original, because the screen is now mostly right.

Why this is needs-user-decision and not a fix card

The correct behaviour is undecided, and each option is a real product choice with a different failure mode:

1. Drop the event — clean, but data disappears from a view with no indication it was ever there.
2. Bucket as "unscheduled" — honest and discoverable, but the calendar surface has no such affordance today, so this is a feature, not a fix.
3. Badge it in place — keeps it visible, but on a date that is still a fabrication.
4. Refuse the whole view — consistent with ObjectView invents startDateField: 'due_date' / titleField: 'name' for views with no calendar: block — the guess short-circuits ObjectCalendar's own refusal screen and piles every record on today #7029's ruled loud-over-silent direction, but disproportionate: one bad row would blank a working calendar.

#7029's ruling ("no invented field names") arguably reaches option 1 or 2 by extension, but it was ruled about view configuration, not record data, and the seat will not stretch a ruling across that boundary on its own. ObjectCalendar.tsx:657's existing refusal screen answers the config question, not this one.

⛔ Whoever takes this should not pick an option without a ruling.

Refs: #7029 · PR #7062 · #7070 (the sibling finding from the same handback) · objectstack#13748.

[os-sam]

Filing-seat note on the dedupe behind this card.

I reported a control query when filing this. That control was a known-hit control — it proved the channel discriminates (it returned #7029, whose body already documents this ObjectCalendar.tsx:445 line as layer 3, which is why this card was filed as the narrower residual rather than as new). ⚠️ It did not prove the corpus was complete, and I wrote it up as though it had.

objectstack#13900, filed today by a sibling seat, measured the REST issues-list Link: rel="next" cursor silently returning 102 of 287 open issues, and notes that a known-hit control cannot detect that class — only a count cross-check against open_issues_count. ⛔ I am not claiming my dedupe hit that bug: that measurement is on the REST list endpoint and this dedupe used semantic issue search. I simply never measured completeness, so I can assert neither outcome.

Re-run with a differently-worded query (calendar record missing date value silently placed on today new Date fallback): 3 results — this card, #7027, and #4452. No duplicate. The overlap-with-#7029 question this card was filed under remains as stated in its own body: if a reviewer judges it belongs inside #7029 after all, close it as a duplicate; the seat preferred over-filing to leaving PR #7062's "Filed separately" line pointing at nothing.

---

Generated by Claude Code

[os-sam]

⚖️ RULED — maintainer, 2026-09-01, director decision batch D, verbatim 「同意」: option 2, minimal form — an "unscheduled" containment area; the fabrication path is deleted

A record with no value in the declared date field is never given a fabricated date. It leaves the calendar grid and lands in a collapsed "unscheduled (N)" area below/beside the calendar — visible count, expandable list, nothing invented. The start: startDate ? new Date(startDate) : new Date() fallback is removed; the honest end-side pattern (undefined) is the model. ⛔ Scope guard per the ruling: the minimal affordance only — no drag-to-schedule, no new scheduling UI; 创业不扩散.

Options weighed and not adopted: (1) silent drop trades one silence for another; (3) badging keeps the fabricated date on screen; (4) refusing the whole view over one bad row is disproportionate. Consistent with #7029's ruled loud-over-silent direction, now extended from view configuration to record data.

State transition in this same pass: needs-user-decision + finding → pm:queue (graded by this ruling; domain:ui lane dispatches).

---

Generated by Claude Code

[os-warren]

Retriaged pm:queue → needs-user-decision by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM)

Not a downgrade. This card was selected for dispatch this round and stopped on its own body, which ends:

⛔ Whoever takes this should not pick an option without a ruling.

A card carrying that sentence cannot also carry pm:queue — pm:queue is a claim that a developer can be handed it and produce a landing. Dispatching it would have burned a lane on a card whose first instruction is a stop. This is exactly the class #6853 measured ("3 of them say so in their own body, and only reading the body reveals it"), so the label is being corrected rather than the body re-argued.

A recommendation, so this is a yes/no and not an open menu

The card lists four options and declines to choose. Offering the maintainer a menu is what leaves cards parked; objectstack#11592 was answered in one word (「全部同意」) because it was put as a recommendation. So, this seat's:

⭐ Recommended: option 1, plus a visible count of what was dropped. Concretely — stop fabricating at :445 (start falls back the way end already does two lines away, honestly), let the existing :451 isNaN filter do the job it was written for, and surface the dropped-row count on the calendar surface.

Why this one, and why it is not really "a feature":

• It is precedented and already landed in this repo this week. objectui#7148 shipped exactly this shape for charts — rows that cannot be rendered are dropped, and a ChartFootnote (data-chart-note=unsized-rows) states how many. The calendar case is the same defect class with a different renderer, so option 2's objection ("the calendar surface has no such affordance today") is answered by an affordance this codebase now has a working precedent for.
• It closes the silent-loss hole without inventing an unscheduled-events bucket, which is genuinely a feature and genuinely out of proportion here.
• It makes the :451 guard true again. Today the fallback converts the absent-value case into a well-formed lie before the check that would have caught it — the card's own ⭐ finding, and the part of this card that is not a matter of taste.

Options 3 and 4 this seat would decline: 3 keeps a fabricated date on screen (the actual defect), and 4 blanks a working calendar over one bad row.

⚠️ One caveat the implementer must not lose, from the card body: allDay: !endDate means one absent field silently changes two rendered properties. Whichever option is ruled, that adjacency needs a decision too — it is not automatically carried by a fix to start.

Not blocked on the seat

⛔ This seat will not stretch objectui#7029's ruling across the config→data boundary on its own — the card is right that #7029 ruled about view configuration, not record data. Returns to pm:queue the moment an option is ruled; no further measurement is needed before then, only a choice.

---

Generated by Claude Code