Class (b), a contract violation with a measured public door. Reach: the page compile, the save gate's input. ⛔ Not a claim. Filed bare for triage to grade, route and order.
Raised as an out_of_scope_findings entry by the os-dev run on objectui#11605 (PR objectui#11612, head 582982e), reported to the domain:ui seat 1 PM (session_01FjqrwXPfSMkSfkKYDSRkN2). The seat ran the dedupe below; the measurement is the dev's.
The shape
- The spec row
ComponentPropsMap['record:related_list'].columns is optional.
- The binding supplies it from a named view. The renderer's binding map (
RECORD_RELATED_LIST_DATA_SOURCE in RecordRelatedListRenderer) maps columns: true, so a dataSource binding that names a view lands that view's columns on the node.
- The registration still declares
columns required. So the page compile refuses a node the row and the renderer accept.
Measured at 582982e: a record:related_list node with objectName, relationshipField and a dataSource binding naming object task and view open_tasks, with no columns, compiles ok: false: missing-required-prop naming columns.
Why it was not moved in objectui#11605
objectui#11605 is the objectName family's closing card, under triage's ruling (a) (5978738288): a registration drops required: true where the spec row or the binding contract waives the key. columns differs from objectName in two ways the dev could not settle inside that claim:
- The binding supplies
columns only through a named view, never through its object. So a binding that names an object but no view still leaves the node without columns.
- The neither-columns runtime answer was not measured: what the related list draws with no authored columns and no view.
PR objectui#11612's enumeration pin over the shipped sdui.manifest.json ledgers exactly this row (record:related_list.columns), with a reason. This card is that ledger row's carrier. When it closes, the ledger row goes.
What a repair has to decide (for triage)
- Does
columns drop required, following ruling (a)? Or is "a view supplies it" too narrow a waiver, given that a binding without a view supplies nothing?
- If it drops: what does the related list show with neither authored columns nor a view? A blank or a throw would need the visible hint objectui#11605's members gained (
ElementDataSourceGate's requiresObject pattern, or a columns analogue).
- Either way, the enumeration pin's ledger row is removed or rewritten in the same change.
Dedupe
MCP search_issues, scoped to objectstack-ai/objectui:
Dedupe words: record:related_list columns required, missing-required-prop columns related_list view, registration required vs spec row optional columns.
Related: objectui#11605 (family closing card, objectName), objectui#11569 (childObject, the family's first member).
Generated by Claude Code
Class (b), a contract violation with a measured public door. Reach: the page compile, the save gate's input. ⛔ Not a claim. Filed bare for triage to grade, route and order.
Raised as an
out_of_scope_findingsentry by theos-devrun on objectui#11605 (PR objectui#11612, head582982e), reported to thedomain:uiseat 1 PM (session_01FjqrwXPfSMkSfkKYDSRkN2). The seat ran the dedupe below; the measurement is the dev's.The shape
ComponentPropsMap['record:related_list'].columnsis optional.RECORD_RELATED_LIST_DATA_SOURCEinRecordRelatedListRenderer) mapscolumns: true, so adataSourcebinding that names a view lands that view's columns on the node.columnsrequired. So the page compile refuses a node the row and the renderer accept.Measured at
582982e: arecord:related_listnode withobjectName,relationshipFieldand adataSourcebinding naming objecttaskand viewopen_tasks, with nocolumns, compilesok: false:missing-required-propnamingcolumns.Why it was not moved in objectui#11605
objectui#11605 is the
objectNamefamily's closing card, under triage's ruling (a) (5978738288): a registration dropsrequired: truewhere the spec row or the binding contract waives the key.columnsdiffers fromobjectNamein two ways the dev could not settle inside that claim:columnsonly through a named view, never through its object. So a binding that names an object but no view still leaves the node without columns.PR objectui#11612's enumeration pin over the shipped
sdui.manifest.jsonledgers exactly this row (record:related_list.columns), with a reason. This card is that ledger row's carrier. When it closes, the ledger row goes.What a repair has to decide (for triage)
columnsdroprequired, following ruling (a)? Or is "a view supplies it" too narrow a waiver, given that a binding without a view supplies nothing?ElementDataSourceGate'srequiresObjectpattern, or a columns analogue).Dedupe
MCP
search_issues, scoped to objectstack-ai/objectui:ListView's$selectview-binding arm has nomapentry, so a map list view's location field never reaches the projection and its rows arrive without coordinates on a backend that honours$select#10370, plugin-view:ObjectViewhonours a spec-shaped named list view (ObjectListViewSchema) — the renderer half that #7928's option A requires beforelistViewsis mirrored by reference #8254).Dedupe words:
record:related_list columns required,missing-required-prop columns related_list view,registration required vs spec row optional columns.Related: objectui#11605 (family closing card,
objectName), objectui#11569 (childObject, the family's first member).Generated by Claude Code