Out-of-scope finding from #5343. That card removed the fabricated ObjectSchema.create() / Field.text() builder pair from content/docs/guide/building-crud-app.md and rewrote the object metadata as the plain document a data source serves. Annotating that document with ObjectSchemaMetadata — the type @object-ui/types exports for exactly this shape — was not possible, and this is why. Filed unassigned, not claiming. ⛔ Widening the type is a contract change and is deliberately not done under #5343.
Fact (origin/main = bdf8cf76e)
ObjectSchemaMetadata (packages/types/dist/field-types.d.ts:715) declares: name, label, description, fields, extends, triggers, primary_key, indexes, relationships, name_field, soft_delete, audit_trail, version, editMode, managedBy, cache.
Three keys a real object definition carries are absent, and each is read by shipped runtime code:
| key |
read at |
list_views / listViews |
packages/app-shell/src/views/ObjectView.tsx:1178,1194,1208; packages/app-shell/src/views/InterfaceListPage.tsx:56; packages/app-shell/src/layout/AppHeader.tsx:501; packages/react/src/hooks/useElementDataSource.ts:104; packages/app-shell/src/providers/MetadataProvider.tsx:420 |
titleFormat |
the ADR-0079 object-level display-name resolver — packages/plugin-kanban/src/ObjectKanban.tsx:275,295 names the order objectDef.titleFormat → displayNameField → … |
icon |
authored on objects and edited by the metadata-admin object inspector (packages/app-shell/src/views/metadata-admin/inspectors/ObjectDefaultInspector.tsx:94) |
The gap is invisible at the DataSource boundary because DataSource.getObjectSchema(objectName) returns Promise< any > (packages/types/dist/data.d.ts:428), so nothing forces the served document through the declared type. It becomes visible the moment a document is annotated: an excess-property error on keys the renderer then happily reads.
Why it is worth a decision rather than a quiet widening
Three readings, and they are not equivalent:
ObjectSchemaMetadata is meant to be the client-side type of the whole object document → it under-declares, and the missing keys should be added with the semantics the runtime already implements (which also settles list_views vs listViews, currently accepted as both at every read site).- It is deliberately narrower than the served document (a fields-and-identity subset) → then the doc/type story needs saying out loud, because today the name promises the whole thing.
- The object document belongs to
@objectstack/spec and objectui should re-export or align rather than keep a hand-written second copy — the same layer split objectui#3074 applied to PageNodeSchema. Note list_views does not appear anywhere in @objectstack/spec 17.0.0's dist/ either.
Under #5343 the guide keeps the document as an untyped literal and types only its fields record against the real FieldMetadata union, which is honest under any of the three readings.
Searched for duplicates
ObjectSchemaMetadata, list_views declaration, object metadata type missing keys over open issues: zero relevant hits. #5321 and #4605 are adjacent declaration-gap cards on different types.
Generated by Claude Code
Out-of-scope finding from #5343. That card removed the fabricated
ObjectSchema.create()/Field.text()builder pair fromcontent/docs/guide/building-crud-app.mdand rewrote the object metadata as the plain document a data source serves. Annotating that document withObjectSchemaMetadata— the type@object-ui/typesexports for exactly this shape — was not possible, and this is why. Filed unassigned, not claiming. ⛔ Widening the type is a contract change and is deliberately not done under #5343.Fact (
origin/main=bdf8cf76e)ObjectSchemaMetadata(packages/types/dist/field-types.d.ts:715) declares:name,label,description,fields,extends,triggers,primary_key,indexes,relationships,name_field,soft_delete,audit_trail,version,editMode,managedBy,cache.Three keys a real object definition carries are absent, and each is read by shipped runtime code:
list_views/listViewspackages/app-shell/src/views/ObjectView.tsx:1178,1194,1208;packages/app-shell/src/views/InterfaceListPage.tsx:56;packages/app-shell/src/layout/AppHeader.tsx:501;packages/react/src/hooks/useElementDataSource.ts:104;packages/app-shell/src/providers/MetadataProvider.tsx:420titleFormatpackages/plugin-kanban/src/ObjectKanban.tsx:275,295names the orderobjectDef.titleFormat→displayNameField→ …iconpackages/app-shell/src/views/metadata-admin/inspectors/ObjectDefaultInspector.tsx:94)The gap is invisible at the DataSource boundary because
DataSource.getObjectSchema(objectName)returnsPromise< any >(packages/types/dist/data.d.ts:428), so nothing forces the served document through the declared type. It becomes visible the moment a document is annotated: an excess-property error on keys the renderer then happily reads.Why it is worth a decision rather than a quiet widening
Three readings, and they are not equivalent:
ObjectSchemaMetadatais meant to be the client-side type of the whole object document → it under-declares, and the missing keys should be added with the semantics the runtime already implements (which also settleslist_viewsvslistViews, currently accepted as both at every read site).@objectstack/specand objectui should re-export or align rather than keep a hand-written second copy — the same layer split objectui#3074 applied toPageNodeSchema. Notelist_viewsdoes not appear anywhere in@objectstack/spec17.0.0'sdist/either.Under #5343 the guide keeps the document as an untyped literal and types only its
fieldsrecord against the realFieldMetadataunion, which is honest under any of the three readings.Searched for duplicates
ObjectSchemaMetadata,list_views declaration,object metadata type missing keysover open issues: zero relevant hits. #5321 and #4605 are adjacent declaration-gap cards on different types.Generated by Claude Code