Filed unassigned by the os-dev seat implementing #7712 (branch claude/issue-7712-kanban-calendar-filter-input). Measured on origin/main 9bfd618, installed @objectstack/spec 17.2.0. This is the NEGATIVE result of the per-key spec measurement #7712's seat comment asked for — and it is a defect in its own right, pointing the opposite way from #7712.
Measured — four faces say yes, the contract says no
Yes:
packages/plugin-kanban/src/ObjectKanban.tsx:364 — $top: schema.limit ?? DEFAULT_KANBAN_LIMIT, with schema.limit in the effect deps at :391.packages/plugin-kanban/src/index.tsx:407 — OBJECT_KANBAN_DATA_SOURCE maps limit: 'limit', and the docblock above it (:368-:385) records objectui#4025 deliberately wiring this key to a real top-level $top.packages/types/src/objectql.ts — ObjectKanbanSchema declares limit?: number.content/docs/plugins/plugin-kanban.mdx:151-:176 — a whole section, "Row cap (object-driven boards)", teaches it with a typed snippet (const board: ObjectKanbanSchema = { type: 'object-kanban', objectName: 'opportunity', groupBy: 'stage', limit: 250 }), plus a row in the Properties table at :107.
No:
ComponentPropsMap['object-kanban'] is a strict object whose keys are objectName, groupBy, columns, filter, data, cardTitle, titleField, cardFields, swimlaneField, grouping, quickAdd, coverImageField, conditionalFormatting. Measured at runtime: safeParse({ objectName: 'x', limit: 250 }) returns success: false with limit in unrecognized_keys — the same verdict the control key bogusProp draws on the same call.
⇒ An author who follows this repo's own documentation writes a node the platform's save gate refuses, and the html tier additionally reports unknown-prop on it (no registration declares it either). The failure is not "the key does nothing" — the renderer honours it; it is that the one place the document must pass through rejects it.
Why this is NOT resolved by declaring limit in the registration
That was the tempting move while fixing #7712, and it is wrong in a way worth recording: an inputs entry for a key the spec refuses would publish authoring surface the save gate cannot store, and it would put the manifest at odds with check:react-blocks-declaration-parity (which diffs manifest → spec). It is the same reason object-grid's four ruled non-author keys stay unpublished (see packages/plugin-grid/src/__tests__/gridNonAuthorKeys.test.tsx).
The decision this needs (contract-first, AGENTS.md #0.1)
The producer side is where this is settled, so it needs a maintainer/spec ruling rather than a renderer patch:
- A — the spec declares
limit on object-kanban (and the registration then publishes it). Matches four faces that already exist, including a documented section and a shipped @object-ui/types member; costs a spec change in objectstack.
- B —
limit is host-derived, not authoring surface: it arrives through the dataSource binding (its own limit, or the named view's pagination.pageSize), so the fix is to stop teaching it as an authored key — retire the docs section and the ObjectKanbanSchema member, keep the read. Costs a documented capability that has apparently worked in practice.
⛔ Not resolvable by a lenient fallback on either side; both routes are a decision about the contract.
Refs: #7712 · #4025 · objectstack#15449
Filed unassigned by the os-dev seat implementing #7712 (branch
claude/issue-7712-kanban-calendar-filter-input). Measured onorigin/main9bfd618, installed@objectstack/spec17.2.0. This is the NEGATIVE result of the per-key spec measurement #7712's seat comment asked for — and it is a defect in its own right, pointing the opposite way from #7712.Measured — four faces say yes, the contract says no
Yes:
packages/plugin-kanban/src/ObjectKanban.tsx:364—$top: schema.limit ?? DEFAULT_KANBAN_LIMIT, withschema.limitin the effect deps at:391.packages/plugin-kanban/src/index.tsx:407—OBJECT_KANBAN_DATA_SOURCEmapslimit: 'limit', and the docblock above it (:368-:385) records objectui#4025 deliberately wiring this key to a real top-level$top.packages/types/src/objectql.ts—ObjectKanbanSchemadeclareslimit?: number.content/docs/plugins/plugin-kanban.mdx:151-:176— a whole section, "Row cap (object-driven boards)", teaches it with a typed snippet (const board: ObjectKanbanSchema = { type: 'object-kanban', objectName: 'opportunity', groupBy: 'stage', limit: 250 }), plus a row in the Properties table at:107.No:
ComponentPropsMap['object-kanban']is a strict object whose keys areobjectName,groupBy,columns,filter,data,cardTitle,titleField,cardFields,swimlaneField,grouping,quickAdd,coverImageField,conditionalFormatting. Measured at runtime:safeParse({ objectName: 'x', limit: 250 })returnssuccess: falsewithlimitinunrecognized_keys— the same verdict the control keybogusPropdraws on the same call.⇒ An author who follows this repo's own documentation writes a node the platform's save gate refuses, and the html tier additionally reports
unknown-propon it (no registration declares it either). The failure is not "the key does nothing" — the renderer honours it; it is that the one place the document must pass through rejects it.Why this is NOT resolved by declaring
limitin the registrationThat was the tempting move while fixing #7712, and it is wrong in a way worth recording: an
inputsentry for a key the spec refuses would publish authoring surface the save gate cannot store, and it would put the manifest at odds withcheck:react-blocks-declaration-parity(which diffs manifest → spec). It is the same reasonobject-grid's four ruled non-author keys stay unpublished (seepackages/plugin-grid/src/__tests__/gridNonAuthorKeys.test.tsx).The decision this needs (contract-first, AGENTS.md #0.1)
The producer side is where this is settled, so it needs a maintainer/spec ruling rather than a renderer patch:
limitonobject-kanban(and the registration then publishes it). Matches four faces that already exist, including a documented section and a shipped@object-ui/typesmember; costs a spec change inobjectstack.limitis host-derived, not authoring surface: it arrives through thedataSourcebinding (its ownlimit, or the named view'spagination.pageSize), so the fix is to stop teaching it as an authored key — retire the docs section and theObjectKanbanSchemamember, keep the read. Costs a documented capability that has apparently worked in practice.⛔ Not resolvable by a lenient fallback on either side; both routes are a decision about the contract.
Refs: #7712 · #4025 · objectstack#15449