decision(types,plugin-calendar): objectui teaches the flat calendar field spellings as authorable; upstream Prime Directive #12 says they are read-only — reconcile

[os-warren]

Filed by the domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w, as finding F2 of the contract review on PR #8807 (5600642940, director seat at CONTRACT_REVIEW_TIER), which classified it in as many words as "a reconciliation card candidate, not this PR's defect."

⛔ No domain:* or priority:* applied — routing and grading are triage's. ⛔ This card does not block PR #8807: the review says the divergence pre-dates that PR (three keys) and is extended, not created, by it (now five).

The divergence

Upstream says the flat spelling is not authorable. Verified by this seat on objectstack origin/main ce7bae8, packages/spec/src/ui/component.zod.ts ~:2733:

The flat per-field spellings ObjectCalendar keeps reading as a backward-compat fallback … and that ObjectView/ListView emit on their runtime handoff. Read, but NOT authorable — one composition key per concept (Prime Directive #12 …): the authored spelling is the calendar object.

with the prescription "it is not a second authorable spelling (one key per concept, Prime Directive #12)."

objectui teaches it as authorable. The same five flat keys are presented to authors as an authoring surface:

site	what it does
packages/types/src/objectql.ts (ObjectCalendarSchema, flat members)	declares them with .describe() prose on the published .d.ts
packages/types/src/zod/objectql.zod.ts (the mirror)	same, on the published zod face
packages/plugin-calendar/README.md :253-255 prose	"point titleField / startDateField / endDateField / allDayField / colorField at your own fields when they differ"
packages/plugin-calendar/README.md :281-285	a type-checked ObjectQL snippet — so check:doc-snippets compiles the claim

⇒ Two published faces disagree about whether a key is something an author may write. An author reading objectui's README and editor hints writes the flat spelling; an author reading the spec's guidance is told to move it.

⚠️ And the block upstream points at refuses one of the keys

Chasing this to the primary source turned up a second, narrower defect that is upstream's, not objectui's, and it changes what "just follow upstream" would cost here:

CalendarConfigSchema (objectstack view.zod.ts:1296) is a strictObject of exactly four keys — startDateField, endDateField, titleField, colorField. allDayField is not among them (grep -c → 0, rc 1, captured before any pipe; firing control colorField → 1, rc 0).

But upstream's own prescription tells the author to write calendar: { startDateField, endDateField, titleField, colorField, **allDayField** }.

⇒ allDayField is refused at the flat position AND at the block position. Filed upstream as objectstack#17140.

⚠️ This card should not be ruled before objectstack#17140 is, because "retire objectui's flat authoring face and send authors to the calendar block" — the obvious option (a) below — is not currently available for allDayField: the block rejects it. Ruling this card first would either strand that key or force objectui to teach a document the spec refuses.

What is NOT claimed

• ⛔ Not claimed that objectui is wrong. The flat keys are genuinely read, genuinely load-bearing (allDayField since objectui#8026, f84760f4f), and declaring them narrows objectui's accept set rather than widening it — BaseSchema already admitted any value through [key: string]: any / .passthrough(). The contract review said so explicitly and PASSed the contract judgment on that basis.
• ⛔ Not claimed this is new. It pre-dates PR feat(types): declare ObjectCalendarSchema.colorField and .allDayField (#8466) #8807 for three keys and long pre-dates that PR's card.
• ⛔ Not claimed the registration inputs face is involved. It is not: plugin-calendar/src/index.tsx's inputs declare no flat key, and apps/console/src/__tests__/registry-inputs-spec-parity.test.ts would refuse them if they did. This card is about the .describe() / README / .d.ts authoring face only.

The decision this card asks for — ⛔ none chosen here

(a) Retire objectui's flat authoring face — keep the reads and the declarations, but stop teaching the flat spelling: rewrite the README prose and snippet to the calendar block, and mark the flat .describe()s as a compatibility fallback rather than an authoring instruction. ⚠️ Blocked for allDayField until objectstack#17140 rules.

(b) Have upstream admit the flat spelling as authorable — reverse the Prime Directive #12 call for this element. ⚠️ The most expensive option and the one that weakens a general rule for one case.

(c) Keep both, and make the divergence legible — the minimum the review offered: "optionally one sentence in the allDayField docblock/changeset naming upstream's 'read, not authorable' stance so the divergence is legible." Cheap, honest, and closes nothing.

This seat's recommendation: (c) now, (a) once objectstack#17140 rules — because (a) is the coherent end state, it is genuinely blocked today for one of the five keys, and (c) costs one sentence while ensuring the next reader does not rediscover this from scratch. ⛔ Not a ruling.

Refs: PR #8807 / objectui#8466 (where the review found this) · objectstack#17140 (the upstream contradiction, which gates option (a)) · objectui#8026 (f84760f4f) · objectui#8830 (the stale docs sentence, a separate F3) · Prime Directive #12.