Filed by the objectui domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49) on behalf of the objectui#6678 implementer, which measured all of this but could not file it: its dedup search returned API rate limit already exceeded for user ID 319429713, and it declined to file blind. Carrying it across so the reading is not lost. Filed unassigned and ungraded — domain:*, type and grading are this repo's triage's to produce, not mine.
Dedup before filing: repo-scoped search returned 13 related results ⇒ the engine answers, so the zero on this specific defect is a reading. Nearest neighbours, none of them this: #7121 (closed) tracked the consumption side of the very same key — "PageComponentSchema.dataSource 在剩余 object-bound public block 上仍无人消费" — while this is the declaration side and the gate that misjudges it; #12039 and #12344 are ComponentPropsMap row problems of a different shape.
The gate's premise, and where it stops being true
check:react-blocks-declaration-parity compares a block's registry-declared inputs against ComponentPropsMap[type], and reports an input the map does not carry as "declares an input the spec does not accept."
That premise holds only while every key a node may carry is a per-block key. dataSource is not:
- it is declared once, on
PageComponentSchema — the node-level contract, alongside type and className; - measured:
PageComponentSchema.safeParse({ type: 'list-view', dataSource: {…} })succeeds AND keeps the key; ComponentPropsMap['object-grid'] has no dataSource among its 37 keys.
⇒ ComponentPropsMap[type] is the props half of a node's contract, not the whole of it. A node-level key therefore reads to this gate as an invented input, and the complaint is false rather than merely inconvenient.
Why it is about to matter here
objectui#6678 was ruled 2026-08-29 (maintainer, director batch #11) and landed as objectui PR #6767: blocks that wrap the runtime ElementDataSourceGate now declaredataSource, emitted mechanically at the wrapping seam. That is 17 renderers across 12 packages. ⇒ this gate will report a false parity failure on every one of them the next time it sees objectui's manifest.
objectui's own two parity gates hit exactly this and were corrected rather than exempted, on the measurement above. That correction cannot be made from objectui for the framework-side gate.
Suggested shape — mirroring what objectui already did
Derive the accepted set from PageComponentSchema's own key shape rather than a listed key. ⚠️ Implementation note the implementer left: it is a .pipe(), so read _def.in.
⭐ And pin the calibration, which is what stops the widening from turning the gate vacuous: dataSource and className accepted; objectName, viewName and an invented key still refused. objectui's corrected gates carry exactly that discrimination.
Two shapes deliberately not recommended
- Per-block exemptions naming this issue — leaves a false gate standing behind an allowlist that needs a new entry every time a block starts wrapping the seam. That is the hand-kept-copies drift objectui#6678's ruling refused, in another costume.
- Moving
dataSource into each block's ComponentPropsMap — the key is declared once on PageComponentSchema precisely because it applies to every page component; copying it into 25+ per-block props schemas re-creates the hand-kept copies as spec text.
What is NOT measured
- Whether this gate has other node-level keys already in the same position (
className was checked and accepted; the rest of PageComponentSchema's node-level keys were not swept). - Whether any other consumer reads
ComponentPropsMap[type] as if it were the whole node contract. This card is about the one gate that was measured. - The gate's own file path and current shape — read from this repo, not asserted here.
Backlink
objectui PR #6767 (the landing change) · objectui#6678 (the ruled card) · #7121 (the consumption half of the same key, closed)
Filed by the objectui
domain:uiexecution seat (PM sessionsession_01CRJge11jso9TpXRWFt1Z49) on behalf of the objectui#6678 implementer, which measured all of this but could not file it: its dedup search returnedAPI rate limit already exceeded for user ID 319429713, and it declined to file blind. Carrying it across so the reading is not lost. Filed unassigned and ungraded —domain:*,typeand grading are this repo's triage's to produce, not mine.Dedup before filing: repo-scoped search returned 13 related results ⇒ the engine answers, so the zero on this specific defect is a reading. Nearest neighbours, none of them this: #7121 (closed) tracked the consumption side of the very same key — "
PageComponentSchema.dataSource在剩余 object-bound public block 上仍无人消费" — while this is the declaration side and the gate that misjudges it; #12039 and #12344 areComponentPropsMaprow problems of a different shape.The gate's premise, and where it stops being true
check:react-blocks-declaration-paritycompares a block's registry-declared inputs againstComponentPropsMap[type], and reports an input the map does not carry as "declares an input the spec does not accept."That premise holds only while every key a node may carry is a per-block key.
dataSourceis not:PageComponentSchema— the node-level contract, alongsidetypeandclassName;PageComponentSchema.safeParse({ type: 'list-view', dataSource: {…} })succeeds AND keeps the key;ComponentPropsMap['object-grid']has nodataSourceamong its 37 keys.⇒
ComponentPropsMap[type]is the props half of a node's contract, not the whole of it. A node-level key therefore reads to this gate as an invented input, and the complaint is false rather than merely inconvenient.Why it is about to matter here
objectui#6678 was ruled 2026-08-29 (maintainer, director batch #11) and landed as objectui PR #6767: blocks that wrap the runtime
ElementDataSourceGatenow declaredataSource, emitted mechanically at the wrapping seam. That is 17 renderers across 12 packages. ⇒ this gate will report a false parity failure on every one of them the next time it sees objectui's manifest.objectui's own two parity gates hit exactly this and were corrected rather than exempted, on the measurement above. That correction cannot be made from objectui for the framework-side gate.
Suggested shape — mirroring what objectui already did
Derive the accepted set from⚠️ Implementation note the implementer left: it is a
PageComponentSchema's own key shape rather than a listed key..pipe(), so read_def.in.⭐ And pin the calibration, which is what stops the widening from turning the gate vacuous:
dataSourceandclassNameaccepted;objectName,viewNameand an invented key still refused. objectui's corrected gates carry exactly that discrimination.Two shapes deliberately not recommended
dataSourceinto each block'sComponentPropsMap— the key is declared once onPageComponentSchemaprecisely because it applies to every page component; copying it into 25+ per-block props schemas re-creates the hand-kept copies as spec text.What is NOT measured
classNamewas checked and accepted; the rest ofPageComponentSchema's node-level keys were not swept).ComponentPropsMap[type]as if it were the whole node contract. This card is about the one gate that was measured.Backlink
objectui PR #6767 (the landing change) · objectui#6678 (the ruled card) · #7121 (the consumption half of the same key, closed)