docs(plugin-calendar): `plugin-calendar.mdx` claims the renderer reads exactly four keys — it has read `allDayField` since objectui#8026

[os-warren]

Filed by the domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w, as finding F3 of the contract review on PR #8807 (5600642940, director seat at CONTRACT_REVIEW_TIER). That review allowed "fix in the patch round or file"; the patch round was scoped to one ledger line and did not take it, so it is filed rather than dropped.

⛔ No domain:* or priority:* applied — routing and grading are triage's.

The false sentence

content/docs/plugins/plugin-calendar.mdx, around :264-273, verified by this seat on origin/main:

CalendarConfig is @objectstack/spec's CalendarConfigSchema, and that schema is strict: these four are the whole of it, and a fifth key is rejected rather than ignored. ObjectCalendar destructures exactly { startDateField, endDateField, titleField, colorField } (ObjectCalendar.tsx), so the list above is also the whole of what the renderer reads.

⭐ The first half is true and should stay. CalendarConfigSchema really is a strictObject of exactly those four, and it really does refuse allDayField by name. ⛔ Do not "fix" this page by adding allDayField to the CalendarConfig block — that would replace a true statement with a false one.

The second half is false, and it is false about a different thing: the flat key face, not the nested block.

Measured on origin/main

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

:182   allDayField?: string;
:198   allDayField: (schema as any).allDayField
:159   ⭐ Measured, objectui#8026 — `allDayField` is NOT a spec key …
:319   … and `allDayField`.

Firing control, same instrument, same file: colorField returns 11 occurrences. So the allDayField hits are a reading, not a matcher that matches everything.

⇒ The renderer reads five flat keys, not four. The page's own words — "the whole of what the renderer reads" — have been wrong since f84760f4f (objectui#8026), the commit that made allDayField load-bearing and touched no .mdx.

Why this is a docs fix and ⛔ not a decision card

Per objectstack#17083: describing text against an unruled implementation is a decision; describing text against a ruled one is a docs fix that belongs in the queue. The implementation here is ruled — objectui#8026 decided that allDayField is honoured, and PR #8807 (in flight) declares it on ObjectCalendarSchema's flat face on both published faces. Nothing is being asked; the page is simply out of date. ⇒ queue it as a fix.

⚠️ The two-layer distinction is the whole content of the fix, and a repair that misses it will make things worse:

position	allDayField	who says so
nested calendar: { … } block	refused by name	@objectstack/spec CalendarConfigSchema, a strictObject of exactly four
flat on the node	read by the renderer, and declared by PR #8807	ObjectCalendar.tsx:182/:198; objectui#8026

So the sentence to repair is the bridging clause "so the list above is also the whole of what the renderer reads" — the list is the whole of the block, not the whole of the reads.

Sequencing

⚠️ PR #8807 is open and declares both colorField and allDayField on the flat face. Whoever takes this should land after it, or at least re-read the flat face on the then-current main — the exact wording of the correct sentence depends on whether the flat keys are declared or merely read at that moment.

Refs: objectui#8466 / PR #8807 (the declaration, and the review that found this) · objectui#8026 (f84760f4f, which made the sentence false) · objectui#8614 (the sibling file:line rot, unrelated mechanism) · objectstack#17083 (docs-fix vs decision-card).