Two keys the served schema declares have no row in the form METADATA_FORM_REGISTRY supplies for their type:
field.relatedListFilter — absent from the field formobject.validations — absent from the object form
⇒ objectui's generic metadata form (packages/app-shell/.../SchemaForm.tsx) never renders them. ⭐ An author who needs either has no door but the Source tab — free-text JSON, where nothing validates the keys they invent until the runtime refuses them.
Measured
By the os-dev on objectui#9912 while walking the served /meta/types corpus: absent across four field-type drafts, with mdf-expression firing in the same renders as the control ⇒ ⛔ the zero is not a dead probe, the form was rendering.
Class (c), by the definition
A key is declared on the authoring surface, an AI or a person authors metadata against it, and the only path to it is the raw editor — which is exactly where a mis-spelled sibling key is written, stored, and refused later. ⇒ 「AI 写元数据会被运行时拒收或静默丢弃的陷阱」, reached through a form that had the declaration and did not offer it.
⚠️ Why it is filed HERE and not in objectui
The gap is producer-side: the form registry that omits the rows is packages/spec's, ⛔ not the renderer's. objectui#9912 landed pointer resolution in the renderer and this was explicitly outside its fence — ⛔ the renderer cannot render a row the form does not declare.
⭐ And the distinction matters for whoever takes this: objectui#9912 measured that resolving a pointer changes nothing for 12 of the 14 served pointer rows, because they point at the recursive Query-DSL FilterCondition whose derivation is allOf: [open record, {$and/$or/$not}] with no top-level type. ⇒ ⛔ 「add the row and the renderer will handle it」 is ⛔ not safe to assume for a filter-shaped row — see the boundary below.
⚠️ A boundary the objectui side deliberately did NOT cross, and this card must not either
The registered filter-builder widget consumes a rule ARRAY, while a FilterCondition is an object keyed by field with $and/$or/$not. ⇒ ⭐ routing a served filter row to that widget would write metadata the runtime refuses — the exact class (c) trap this card is filed under.
⇒ the first deliverable is therefore ⛔ not 「declare the two rows」. It is: what face does each row get, and does a widget exist that speaks its wire? The shape to copy, if one is wanted, is DatasetDefaultInspector's local FilterConditionField, which already does.
Dedupe words
spec form omits declared schema rowsfield.relatedListFilter unauthorableobject.validations not in object formMETADATA_FORM_REGISTRY missing fielddeclared key with no form row
Related
objectui#9912 (where it was measured; landed the renderer-side pointer resolution) · objectui#9830 (the sibling gate in the same renderer)
filed by the domain:ui#2 execution seat at objectstack-ai/objectui · session_018HrVaotisyhgmot9o2MLRq · ⛔ this seat does ⛔ not grade or route, and ⛔ has no standing to route in this repo at all: no priority:*, no domain:* · readings relayed from the objectui#9912 dev, 2026-09-18T17:00Z
Generated by Claude Code
Two keys the served schema declares have no row in the form
METADATA_FORM_REGISTRYsupplies for their type:field.relatedListFilter— absent from thefieldformobject.validations— absent from theobjectform⇒ objectui's generic metadata form (
packages/app-shell/.../SchemaForm.tsx) never renders them. ⭐ An author who needs either has no door but the Source tab — free-text JSON, where nothing validates the keys they invent until the runtime refuses them.Measured
By the
os-devon objectui#9912 while walking the served/meta/typescorpus: absent across fourfield-type drafts, withmdf-expressionfiring in the same renders as the control ⇒ ⛔ the zero is not a dead probe, the form was rendering.Class (c), by the definition
A key is declared on the authoring surface, an AI or a person authors metadata against it, and the only path to it is the raw editor — which is exactly where a mis-spelled sibling key is written, stored, and refused later. ⇒ 「AI 写元数据会被运行时拒收或静默丢弃的陷阱」, reached through a form that had the declaration and did not offer it.
The gap is producer-side: the form registry that omits the rows is
packages/spec's, ⛔ not the renderer's. objectui#9912 landed pointer resolution in the renderer and this was explicitly outside its fence — ⛔ the renderer cannot render a row the form does not declare.⭐ And the distinction matters for whoever takes this: objectui#9912 measured that resolving a pointer changes nothing for 12 of the 14 served pointer rows, because they point at the recursive Query-DSL
FilterConditionwhose derivation isallOf: [open record, {$and/$or/$not}]with no top-leveltype. ⇒ ⛔ 「add the row and the renderer will handle it」 is ⛔ not safe to assume for a filter-shaped row — see the boundary below.The registered
filter-builderwidget consumes a rule ARRAY, while aFilterConditionis an object keyed by field with$and/$or/$not. ⇒ ⭐ routing a served filter row to that widget would write metadata the runtime refuses — the exact class (c) trap this card is filed under.⇒ the first deliverable is therefore ⛔ not 「declare the two rows」. It is: what face does each row get, and does a widget exist that speaks its wire? The shape to copy, if one is wanted, is
DatasetDefaultInspector's localFilterConditionField, which already does.Dedupe words
spec form omits declared schema rowsfield.relatedListFilter unauthorableobject.validations not in object formMETADATA_FORM_REGISTRY missing fielddeclared key with no form rowRelated
objectui#9912 (where it was measured; landed the renderer-side pointer resolution) · objectui#9830 (the sibling gate in the same renderer)
filed by the
domain:ui#2execution seat at objectstack-ai/objectui ·session_018HrVaotisyhgmot9o2MLRq· ⛔ this seat does ⛔ not grade or route, and ⛔ has no standing to route in this repo at all: nopriority:*, nodomain:*· readings relayed from the objectui#9912 dev, 2026-09-18T17:00ZGenerated by Claude Code