feat(types)!: the object-calendar element's calendar container follows the @objectstack/spec 17.7.0 slot by reference (objectui#6152, round 9)

.changeset/6152-object-calendar-container-strict.md

@@ -0,0 +1,31 @@
+---
+'@object-ui/types': minor
+---
+
+feat(types)!: the `object-calendar` element's `calendar` container is the `@objectstack/spec` 17.7.0 slot by reference, and its `.passthrough()` is gone (objectui#6152, round 9)
+
+Clause-②: no
+
+**Narrowed (breaking).** `@objectstack/spec` 17.7.0 types `ComponentPropsMap['object-calendar'].calendar`
+as a strict copy of the list view's calendar block: `startDateField` required, `endDateField`,
+`titleField`, `colorField` and `allDayField` optional, and any other key refused with
+`unrecognized_keys`. `@object-ui/types` kept the container as the list view block `.partial()` plus
+`.passthrough()`, so it accepted two things the spec refuses. It now takes the row's own member by
+reference, on the zod `ObjectCalendarSchema` and, through the derived `ObjectCalendarBlockConfig`,
+on the TypeScript interface:
+
+- A key outside the five, inside the block, is refused. That includes `calendar.defaultView`:
+  `ObjectCalendar` reads the view mode from the node's own `defaultView` and never from the block,
+  so write `defaultView: 'week'` on the node.
+- A block without `startDateField` is refused at `calendar.startDateField`. `ObjectCalendar`
+  returns the block whole, so such a block mounted a calendar that placed no event.
+- `ObjectCalendarBlockConfig` no longer has an index signature, and its `startDateField` is
+  required, so a typed literal with either shape is now a compile error.
+
+The retired `calendar.dateField` / `calendar.endField` keep their by-name refusal (objectui#8355),
+which names the key to write instead. A census pin in this package's tests re-derives, on every
+run, that each `object-calendar` container authored in this repository's examples, docs and
+READMEs parses on the narrowed container.
+
+What did not move: the list view's own `calendar` block, which keeps `.passthrough()` and
+`defaultView`, and the renderers' reads.

content/docs/plugins/plugin-calendar.mdx

@@ -312,18 +312,20 @@ before the spec declared it; the spec declares it since `@objectstack/spec`
 never declares it draws exactly as before, with the all-day flag inferred from
 the absence of an end date.
 
-Nor is a sixth key rejected on the way in. Both published faces of
-`ObjectCalendarSchema` declare the `calendar` container (objectui#8651), with
-the five keys above as its members. Their values are checked, so
-`calendar: { startDateField: 42 }` is refused, and the retired `dateField` /
-`endField` are refused by name (objectui#8355). The container keeps
-`.passthrough()`, though, so any other key you write inside it still parses and
-reaches the renderer unexamined. `@objectstack/spec` does not judge it there
-either: on an `object-calendar` node it declares the `calendar` key but not that
-key's shape. On the list-view path the container is objectui's own mirror of
-`CalendarConfigSchema`, kept `.passthrough()` in the same way, while the spec's
-own list-view block is strict. Annotating the block `CalendarConfig` is what
-narrows it to the spec's five.
+On an `object-calendar` node, a sixth key is rejected on the way in. Both
+published faces of `ObjectCalendarSchema` declare the `calendar` container
+(objectui#8651), and since objectui#6152 that container is `@objectstack/spec`'s
+own `object-calendar` slot, taken by reference: strict, with the five keys above
+as its members and `startDateField` required. A key outside the five is refused
+with the spec's `unrecognized_keys` diagnostic, as the spec refuses it there;
+that includes `defaultView`, which the renderer reads from the node itself, not
+from this block. Values are checked too, so `calendar: { startDateField: 42 }` is
+refused. The retired `dateField` / `endField` are refused by name
+(objectui#8355), and the message names the key to write instead. On the list-view
+path the container is a different contract: objectui's own mirror of
+`CalendarConfigSchema`, still `.passthrough()`, while the spec's own list-view
+block is strict. Annotating that block `CalendarConfig` is what narrows it to the
+spec's five.
 
 ## Configuration
 

packages/plugin-calendar/README.md

@@ -310,9 +310,9 @@ import type { ObjectCalendarSchema } from '@object-ui/types';
 // `calendar: { titleField: 42 }` are both compile errors, and
 // `check:doc-snippets` re-runs that check on every commit. Top-level key NAMES
 // are checked too since objectui#8347 removed `BaseSchema`'s `[key: string]: any`,
-// but NOT inside the `calendar` block, which is open (its type is inferred from
-// a `.passthrough()` schema), so a misspelt key there still compiles clean. Read
-// the `calendar` block as type-checked values, never as a guarded key set.
+// and since objectui#6152 so are the key names inside the `calendar` block: its
+// type is the spec's strict `object-calendar` slot, so a misspelt key there, or
+// a block without `startDateField`, is a compile error as well as a parse error.
 const schema: ObjectCalendarSchema = {
   type: 'object-calendar',
   objectName: 'events',