@@ -1,5 +1,5 @@
 ---
-"@objectstack/spec": minor
+"@objectstack/spec": patch
 ---
 
 fix(spec): state the row-cap guard `ElementDataSourceGate` implements, and record where the per-kind view `limit` actually lands (#19228)
@@ -9,13 +9,6 @@ to the same values before and after. ⛔ No `.default()` moves, ⛔ no precedenc
 of the per-kind view `limit`, a view's `pagination.pageSize` and a component's flat `limit`
 should win is the open half of #19228 and is not answered here.
 
-⚠️ **Why `minor` when nothing behavioural moved.** `check-changeset-no-major`'s LEVEL axis
-(#16055 / #16776) requires a PR that declares `Clause-②: yes` to grade at least one package
-whose published source it moves `minor` or above, and this PR carries that declaration. The bump
-is therefore the gate's floor, ⛔ not a description of a behaviour change: no key is added,
-removed or renamed, no export moves, and every document that parsed before parses to the same
-value after. Upgrading gains corrected published prose and nothing else.
-
 ## What the published text said, and what the consumer does
 
 `ObjectKanbanPropsSchema.limit` told authors that a bound view's `pagination.pageSize`
@@ -29,20 +22,28 @@ it. The view half is likewise not `pagination.pageSize` alone: `savedViewLimit`
 (`core/src/data-scope/element-data-source.ts:237-241`). The describe now states the guard as
 implemented.
 
-## Where the per-kind view `limit` lands
+## Where the per-kind VIEW `limit` lands
+
+⚠️ Two different keys are easy to confuse here, so each statement names its face. The **view
+face** is a `ListViewSchema` document's `kanban` / `gallery` / `timeline` block — that is where
+this key lives. The **element face** is a page component node's own flat `limit`, declared in
+`component.zod.ts`, and that is the key every renderer actually reads. An adapter turns the
+first into the second.
 
 The adapters spread a view's per-kind block FLAT onto the node they generate — `...restKanban`
 (`plugin-list/src/ListView.tsx:2979`, `plugin-view/src/ObjectView.tsx:1638`; neither destructure
-strips `limit`) and `...(viewOptions.timeline || {})` / `...(viewOptions.gallery || {})`
-(`ObjectView.tsx:1725` / `:1697`). So a view's `kanban.limit` or `timeline.limit` — including the
-100 the applied default materializes — becomes the flat `limit` that `ObjectKanban.tsx:553` and
-`ObjectTimeline.tsx:279` read. The `$top` it would govern is not issued on either adapter route
-today, because both hosts hand rows down as a React `data` prop and both children short-circuit
-their own fetch; ⛔ that is a statement about the query, not about the key being unread.
-
-**Gallery is the exception**, and only gallery: the block is spread flat by `ObjectView.tsx:1697`
-and `ObjectGallery.tsx` contains no `limit` at all.
-
-⚠️ For authors: `timeline.limit` inside an `object-timeline` node's `timeline` block reaches the
-rail on one adapter route and not on the other. Write the flat `limit` beside it when you mean
-the row cap.
+strips `limit`) and `...(viewOptions.gallery || {})` / `...(viewOptions.timeline || {})`
+(`ObjectView.tsx:1697` / `:1725`). So a view's `kanban.limit` — including the 100 the applied
+default materializes — becomes the node's flat `limit`, which `ObjectKanban.tsx:553` reads. A
+view's `timeline.limit` is route-dependent: `plugin-view` flattens it and `ObjectTimeline.tsx:279`
+reads it, while `plugin-list` forwards the block nested, where nothing does. A view's
+`gallery.limit` is flattened too and read by nobody — `ObjectGallery.tsx` contains no `limit` at
+all.
+
+Where it is read, the `$top` it would govern is still not issued on either adapter route today,
+because both hosts hand rows down as a React `data` prop and both children short-circuit their
+own fetch; ⛔ that is a statement about the query, not about the key being unread.
+
+⚠️ For authors of an `object-timeline` NODE: a `limit` written inside that node's own `timeline`
+block is read by no renderer on any route — the rail is capped by the flat `limit` beside it,
+which is also the only one a bound `dataSource` lowers into. Write the flat one.
@@ -803,7 +803,7 @@ View filter rule
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
 | **objectName** | `string` | optional | Object this timeline binds to. Optional because the component-level `dataSource` binding can supply the object instead — this block registers through `ElementDataSourceGate`, which lowers the binding onto this key before the renderer sees the node |
-| **timeline** | `{ startDateField: string; endDateField?: string; titleField: string; groupByField?: string; … }` | optional | Timeline configuration, the author face — the same block `ListViewSchema.timeline` declares: `{ startDateField, endDateField, titleField, groupByField, colorField, scale, limit }`. The flat top-level spellings beside it are the runtime handoff, not a second authoring spelling. ⚠️ `limit` is the one member whose effect depends on which adapter rendered the node: one spreads this block flat, so it becomes the flat `limit` beside this key, and one forwards it nested, where nothing reads it. Write the flat `limit` when you mean the row cap for the rail |
+| **timeline** | `{ startDateField: string; endDateField?: string; titleField: string; groupByField?: string; … }` | optional | Timeline configuration, the author face — the same block `ListViewSchema.timeline` declares: `{ startDateField, endDateField, titleField, groupByField, colorField, scale, limit }`. The flat top-level spellings beside it are the runtime handoff, not a second authoring spelling. ⚠️ `limit` is the one member of this block NO renderer reads on any route: the rail is capped by the FLAT `limit` beside this key, which is also the only one a bound `dataSource` lowers into. A `limit` written inside this block is accepted, defaulted to 100, and never read |
 | **filter** | `{ field: string; operator: Enum<'equals' \| 'not_equals' \| 'contains' \| 'not_contains' \| 'icontains' \| …>; value?: string \| number \| boolean \| null \| (string \| number)[] }[]` | optional | Base query filter — the ViewFilterRule array form `[{ field, operator, value }, ...]`, the one filter orthography every `filter` door in this map shares; lowered to the wire `$filter`. The MongoDB-style record form is refused — see migration `element-data-source-and-object-block-filter-rule-array` |
 | **sort** | `{ field: string; order: Enum<'asc' \| 'desc'> }[]` | optional | Row order for the fetched entries — the SortItem array form `[{ field, order }, ...]`, the one sort orthography every declared `sort` door on this platform shares; lowered to the wire `$orderby`. The legacy string clause (`name desc`) is refused — see migration `object-block-sort-item-array` |
 | **limit** | `integer` | optional | Maximum number of records loaded onto the rail (row cap); lowered to the query's top-level `$top` (renderer default 100). A timeline renders one rail with no pagination control, so this is the author's window rather than a page size |
 
@@ -3833,12 +3833,13 @@ describe('row caps on the object-bound blocks — what #19228 recorded', () => {
 
   it('materializes the NESTED `timeline.limit` on a node whose flat `limit` stays absent', () => {
     // The shape the record is about: one strictObject, two authorable row
-    // caps, and an applied default on the nested one. ⚠️ Where that 100 then
-    // GOES is route-dependent and is deliberately not asserted here: at the
-    // pin `ObjectView.tsx:1725` spreads the block FLAT (so it becomes the flat
-    // `limit` the rail reads) while `ListView.tsx:3084` forwards it nested (so
-    // nothing reads it). This pin is about the PARSE, which is the only half a
-    // schema owns.
+    // caps, and an applied default on the nested one. ⚠️ Faces, because this
+    // card keeps confusing them: the NESTED key asserted below is the ELEMENT
+    // face, and at the pin no renderer reads it on any route. The
+    // route-dependent one is a VIEW document's `timeline.limit`, a different
+    // key on a different document, which `ObjectView.tsx:1725` flattens onto
+    // a generated node's FLAT `limit`. Neither is asserted here: this pin is
+    // about the PARSE, which is the only half a schema owns.
     const result = timeline.safeParse({
       objectName: 'task',
       timeline: { startDateField: 'start_date', titleField: 'name' },
 
@@ -3113,8 +3113,12 @@ export const ObjectKanbanPropsSchema = lazySchema(() => strictObject({
    * ⛔ This note reports the guard; it picks no precedence.
    *
    * ⚠️ It takes a THIRD door, and missing it is what the at-tier review of
-   * #19533 caught. The ADAPTERS spread the view's kanban block FLAT onto the
-   * generated node — `plugin-list/src/ListView.tsx:2979` and
+   * #19533 caught. Stated with its faces named, because that is where this
+   * card keeps going wrong: `kanban.limit` is a VIEW-FACE key (a member of a
+   * `ListViewSchema` document's `kanban` block) and THIS `limit` is the
+   * ELEMENT-FACE key on the node; the third door is the one that turns the
+   * first into the second. The ADAPTERS spread the view's kanban block FLAT
+   * onto the generated node — `plugin-list/src/ListView.tsx:2979` and
    * `plugin-view/src/ObjectView.tsx:1638`, both `...restKanban`, and neither
    * destructure (`ListView.tsx:2952`, `ObjectView.tsx:1579`) strips `limit`.
    * So a view's `kanban.limit`, INCLUDING the 100 its applied default
@@ -3983,10 +3987,10 @@ const OBJECT_TIMELINE_FLAT_CONFIG_GUIDANCE: readonly KeySetGuidance[] = [
  * the header names: `:407`, the fetch's one top-level `$top`, through
  * `resolveRowLimit(schema.limit, DEFAULT_TIMELINE_LIMIT)` with the default
  * `100` at `:29` and the refused-cap diagnostic at `:279`. ⚠️ It is this FLAT
- * key that is read, and the nested `timeline` block REACHES it: the
- * `plugin-view` adapter spreads that block flat at `ObjectView.tsx:1725`
- * (`plugin-list` forwards it nested instead). See the `timeline` door below),
- * `items` (`:170`, `:247`, `:299`,
+ * key that is read — this node's own nested `timeline.limit` is not, on any
+ * route. What reaches this flat key is a VIEW document's `timeline.limit`,
+ * flattened onto the generated node by `ObjectView.tsx:1725`; see the
+ * `timeline` door below), `items` (`:170`, `:247`, `:299`,
  * `:480` — the authored pass-through that short-circuits the object query),
  * `data` (`:171`, `:247`, `:254`, `:256` — the pre-fetched record source,
  * read off REACT PROPS rather than `schema`; the door's own docblock carries
@@ -4016,18 +4020,41 @@ const OBJECT_TIMELINE_FLAT_CONFIG_GUIDANCE: readonly KeySetGuidance[] = [
  * strictObject, beside the flat `limit` below — two authorable row caps on one
  * node, and the nested one carries an APPLIED default, so every parsed node
  * with a `timeline` block materializes `timeline.limit: 100` (#19228).
- * Measured at the pin `87af769e9`, 2026-09-21T08:05Z, the two adapter routes
- * DISAGREE about that key and both readings are needed:
- *  - `plugin-view/src/ObjectView.tsx:1725` spreads the whole block FLAT
- *    (`...(viewOptions.timeline || {})`), so `timeline.limit` becomes the flat
- *    `limit` that `ObjectTimeline.tsx:279` reads and `:407` would lower.
- *  - `plugin-list/src/ListView.tsx:3062-3117` forwards it NESTED (`:3084`) and
- *    hoists only `startDateField` / `endDateField` / `titleField` /
- *    `groupByField` / `colorField` / `scale` — `limit` is not among them, so
- *    on that route it stays nested and nothing reads it.
- * ⛔ So 「inert」 is route-dependent and was stated flatly here before the
- * at-tier review of #19533 measured the spread. Recorded, not repaired: which
- * key should carry a timeline's row cap is the open half of #19228.
+ *
+ * ⛔ THE TWO ARE ON DIFFERENT FACES, and #19228 has now gone wrong on that
+ * boundary in both directions — once putting a view-face fact on the element
+ * key, once the reverse. So each statement names its face first. Measured at
+ * the pin `87af769e9`, 2026-09-21T09:15Z:
+ *  - **ELEMENT FACE — THIS node's own nested `timeline.limit`: read on NO
+ *    route.** `ObjectTimeline` binds `timelineConfig = schema.timeline`
+ *    (`ObjectTimeline.tsx:262`) and reads exactly eight members off it —
+ *    `startDateField`, `dateField`, `titleField`, `endDateField`,
+ *    `groupByField`, `colorField`, `metaFields` (`:520`, through an `as any`
+ *    cast, which is why a `timelineConfig?.x` sweep alone under-counts) and
+ *    `scale`. `limit` is not among them, and NO spread of a node's own
+ *    `timeline` block exists anywhere in objectui (0 hits; lit control, same
+ *    shape, the view-block spreads `...mergedTimeline` /
+ *    `...(viewOptions.timeline || {})`, which do fire). The
+ *    `ElementDataSourceGate` mapping is `limit: 'limit'`
+ *    (`plugin-timeline/src/index.tsx:333`) — FLAT, so it never touches the
+ *    nested key either.
+ *  - **VIEW FACE — a `ListViewSchema` document's `timeline.limit`: that is
+ *    the route-dependent one**, and it is a different key on a different
+ *    document. `ObjectView.tsx:1725` flattens the view block onto the node it
+ *    returns (which then carries no `timeline` block at all), so the value
+ *    arrives as this node's FLAT `limit` and is read; `ListView.tsx:3084`
+ *    forwards it nested instead, where nothing reads it. Recorded on
+ *    `rowLimitKey` in `view.zod.ts`, which is where that key lives.
+ *
+ * ⚠️ Flagged, not fixed — a THIRD route neither the card nor the first two
+ * reviews described: a hand-authored `object-timeline` node reaching
+ * `ObjectTimeline` through `SchemaRenderer` with no adapter in between. Its
+ * nested `timeline.limit` is unread there too (it is the same element-face
+ * key as the first bullet), and that route is the one an AUTHOR face is
+ * written for — so it is the route the open question most concerns.
+ *
+ * ⛔ Recorded, not repaired: which key should carry a timeline's row cap is
+ * the open half of #19228.
  * `mapping` stays `z.unknown()`: its contract
  * (`TimelineMappingSchema`) still lives in objectui, which is the
  * `object-calendar.calendar` posture this section's header prescribes for
@@ -4051,7 +4078,7 @@ export const ObjectTimelinePropsSchema = lazySchema(() => strictObject({
   objectName: z.string().optional()
     .describe('Object this timeline binds to. Optional because the component-level `dataSource` binding can supply the object instead — this block registers through `ElementDataSourceGate`, which lowers the binding onto this key before the renderer sees the node'),
   timeline: TimelineConfigSchema.optional()
-    .describe('Timeline configuration, the author face — the same block `ListViewSchema.timeline` declares: { startDateField, endDateField, titleField, groupByField, colorField, scale, limit }. The flat top-level spellings beside it are the runtime handoff, not a second authoring spelling. ⚠️ `limit` is the one member whose effect depends on which adapter rendered the node: one spreads this block flat, so it becomes the flat `limit` beside this key, and one forwards it nested, where nothing reads it. Write the flat `limit` when you mean the row cap for the rail'),
+    .describe('Timeline configuration, the author face — the same block `ListViewSchema.timeline` declares: { startDateField, endDateField, titleField, groupByField, colorField, scale, limit }. The flat top-level spellings beside it are the runtime handoff, not a second authoring spelling. ⚠️ `limit` is the one member of this block NO renderer reads on any route: the rail is capped by the FLAT `limit` beside this key, which is also the only one a bound `dataSource` lowers into. A `limit` written inside this block is accepted, defaulted to 100, and never read'),
   /** Base query filter — the family's one `ViewFilterRule` array orthography (#15449). */
   filter: z.array(ViewFilterRuleSchema, {
     error: ruleArrayFilterError({