finding(spec): `OBJECT_CALENDAR_FLAT_FIELD_KEYS`' prescription tells authors to write `allDayField` inside `calendar: {}` — but `CalendarConfigSchema` is strict and refuses it by name

[os-warren]

Filed by the domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w, from a contract review of objectui PR objectstack-ai/objectui#8807 (finding F2). ⛔ No domain:* or priority:* applied — routing and grading are triage's.

The review found an objectui↔upstream divergence. Chasing it to the primary source turned up something narrower and, I think, more actionable: an internal contradiction inside @objectstack/spec itself. Following the spec's own prescription produces a document the spec rejects.

The two halves, measured on origin/main ce7bae8

Half 1 — the guidance says allDayField belongs in the calendar block.

packages/spec/src/ui/component.zod.ts, OBJECT_CALENDAR_FLAT_FIELD_GUIDANCE (~:2733):

keys: ['startDateField', 'dateField', 'endDateField', 'endField',
       'titleField', 'colorField', 'allDayField'],
prescription:
  'Write this as a key of the `calendar` config object instead — `calendar: { startDateField, '
  + 'endDateField, titleField, colorField, allDayField }`. The flat spelling is the runtime handoff '
  + '`ObjectView`/`ListView` emit and a stored-document fallback the renderer keeps reading; it is '
  + 'not a second authorable spelling (one key per concept, Prime Directive #12).',

Note allDayField appears twice: in the refused-flat key list, and again inside the literal calendar: { … } the author is told to write instead.

Half 2 — the calendar block refuses allDayField.

packages/spec/src/ui/view.zod.ts:1296:

export const CalendarConfigSchema = lazySchema(() => strictObject({
  surface: 'this calendar configuration',
  history: VIEW_HISTORY,
}, {
  startDateField: z.string()…,
  endDateField:   z.string().optional()…,
  titleField:     z.string().optional()…,
  colorField:     z.string().optional()…,
}));

Four keys, strictObject. allDayField occurrences in that declaration: 0 (grep -c, rc 1, captured before any pipe). Firing control on the same instrument and the same text range: colorField → 1, rc 0. So the zero is a reading, not a dead matcher.

⇒ The defect

An author who writes allDayField flat is told, by name, to move it into calendar: { … }. An author who does that gets an unrecognized_keys refusal from a strictObject that has never declared the key. Both spellings are refused, and the diagnostic for the first one points at the second. There is currently no accepted way to express "this field says whether the event is all-day" through the spec at all.

⚠️ This is not hypothetical. objectui's plugin-calendar reads allDayField and has since objectui#8026 (f84760f4f), where it is load-bearing; objectui PR objectstack-ai/objectui#8807 is declaring it on the flat face right now, precisely because the spec accepts it nowhere and the renderer needs it.

⛔ What is not claimed

• ⛔ Not claimed which half is wrong. Either the prescription should stop naming allDayField, or CalendarConfigSchema should declare it. That is the decision this card asks for, and adding a member to a published strictObject is an accept-set widening with its own review requirements.
• ⛔ Not claimed that objectui's flat declaration is correct or incorrect — that is the sibling question, filed separately as decision(types,plugin-calendar): objectui teaches the flat calendar field spellings as authorable; upstream Prime Directive #12 says they are read-only — reconcile objectui#8831.
• ⛔ Not claimed the Prime Directive Add comprehensive test suite for Zod schema validation #12 stance is wrong. "One composition key per concept" is coherent; the bug is that the concept has no accepted key anywhere for allDayField.

The cheapest correct fix, offered as input rather than a ruling

Declaring allDayField?: z.string().optional() on CalendarConfigSchema makes the prescription true, gives the concept exactly one authorable spelling (satisfying #12 rather than weakening it), and matches what a real renderer has been reading for months. ⛔ It is still a widening of a published accept set and is not mine to order.

The alternative — striking allDayField from the prescription's literal — makes the guidance self-consistent but leaves the concept unexpressible, and every consumer that needs it stays on a key the spec refuses at both positions. That looks like the worse outcome, but the ruling is yours.

Refs: objectstack-ai/objectui#8807 (the PR whose contract review surfaced this, finding F2) · objectstack-ai/objectui#8466 · objectstack-ai/objectui#8026 (f84760f4f, where the read became load-bearing) · objectstack-ai/objectui#8831 (the objectui-side reconciliation) · Prime Directive #12.

[os-litant]

Closed as a duplicate of #17054 — same internal contradiction, filed 8 hours later

Triage. Both cards report the same defect in @objectstack/spec: the prescription attached to the flat calendar keys tells authors to write allDayField inside calendar: {}, and CalendarConfigSchema is strict and refuses it by name. ⇒ following the spec's own diagnostic produces a document the spec rejects.

	filed	framing
#17054	2026-09-09T04:52Z	ComponentPropsMap['object-calendar'] prescribes a shape its own CalendarConfigSchema refuses
this card	2026-09-09T12:38Z	OBJECT_CALENDAR_FLAT_FIELD_KEYS' prescription refuses in the same way

Two names for one contradiction, on one code path.

⭐ What this card contributes, carried to #17054 rather than lost

Its framing is the sharper one and is worth keeping: it began from an objectui↔upstream divergence (the contract review of objectui PR objectui#8807) and chased it to the primary source, concluding that the actionable defect is internal to @objectstack/spec rather than a seam. ⇒ that is why #17054 is graded domain:spec pm:queue priority:p2 and why objectui#8831 (the objectui half) is explicitly told to follow whatever #17054 settles, ⛔ not to be fixed independently.

⇒ #17054 is the live card. It carries the grading, the measurement on both main @ 881ce2b and published @objectstack/spec@17.3.0, and the downstream linkage. ⛔ Nothing is lost by closing this one; this thread stays readable.

⚠️ Three surfaces disagree here (spec's schema, spec's diagnostic, objectui's docs) — that count is recorded on #17054 so whoever fixes it knows the blast radius is not two.

---

Generated by Claude Code