A typo'd key inside a page component's `properties` is accepted in silence — the props bag is a passthrough record and the SDUI props gate has no schema to dispatch for `object-*` blocks

[huangyiirene]

Symptom

An author writes a misspelled key inside a page component's properties, and nothing anywhere complains: the spec parses it clean, it is stored, the renderer ignores it, and the author gets a success receipt for configuration that does nothing.

The live specimen from this run is the showcase's personal work queue (#7750): object-grid authored with filters: (plural) where the renderer reads filter. The wire carried no $filter and the grid listed every row. But the specimen is incidental — this card is about the class.

Scope, stated precisely

Carried verbatim from the run, because the specimen is easy to over-escalate:

Scope, stated precisely: this is not an authorization bypass. The unfiltered read is still RLS-constrained, so the caller sees only rows they may see (admin sees all because admin may see all). The defect is that a declared personal-scope filter silently never applies — and that a typo'd key is accepted without complaint. The second half is the more general problem.

Root cause — two layers, both open for this block family

1. The schema does not judge the bag. PageComponentSchema.properties is z.record(z.string(), z.unknown()). PageComponentSchema itself has been .strict() since ADR-0089 D3a, but strictness does not recurse: it closes the component node's own keys and leaves everything under properties unjudged. This is documented, not accidental — see packages/spec/src/stack.zod.ts:817 ("Containers nest through a loose record") and the header of the lint below.

2. The gate that exists cannot see this block. ADR-0078 / #5068 added packages/lint/src/validate-component-props.ts, which dispatches on the component's type and judges properties against that type's props schema. Two reasons it is silent here:

• It is warning-only by design, pending an inventory — its own header explains why ("Wiring the parse is the precondition for enforcement, not the enforcement").
• More decisively, it skips unregistered types silently:

const schema = PROPS_SCHEMAS[type];
if (!schema) continue; // "Unregistered type — skipped silently … the majority
 // of authored nodes are SDUI blocks this map does not carry."

And ComponentPropsMap (packages/spec/src/ui/component.zod.ts:987-1033) carries 31 entries, none of them an object-bound block: page:*, record:*, nav:*, global:*, ai:* and element:* are declared; object-grid, object-metric, object-kanban, object-calendar and the rest of the object-* family are absent. The string object-grid does not appear anywhere in packages/spec.

So for the block family that carries the platform's data-bound authoring surface, both layers are open: the schema passes the bag through, and the lint has nothing to dispatch.

Stale-premise check: re-verified on objectstack origin/main (00e9196) — the passthrough record, the silent-skip branch, and the 31-entry map without any object-* key are all present as described.

Why this is filed as a finding rather than a fix

The direction is a real choice and it touches a published surface:

• A — declare the object-* blocks in ComponentPropsMap. Gives the existing lint something to dispatch and gets did-you-mean suggestions for free (filters → filter is exactly the rename shape the walker already emits). Cost: the spec takes on props schemas for blocks whose implementation lives in objectui, and the two must then be kept in parity — the same coupling check:react-declaration-parity already manages for other surfaces.
• B — leave the map as-is and close the loop on the objectui side, where the block's inputs are declared. objectui#4041 already did this for object-grid specifically (the plural spelling was retired and a spelling pin added), but that is per-block work with no gate making it exhaustive.
• Either way, the warning→error upgrade for component-props-unknown-key remains gated on the inventory SDUI 组件 props 没有解析闸门:PageComponent.properties 是开放 record,ComponentPropsMap 的 29 个站点从不被 parse(#4001 批 17 的 no gate 判定) #5068 describes.

Neither should be picked by an implementer without a ruling — recorded here so the decision is made once for the whole block family rather than one typo at a time.

Reproduction

1. Author any page whose component is an object-* block and add an undeclared key inside properties (e.g. filters: on object-grid).
2. Build / publish — no error, no warning: PageComponentSchema parses the bag, and validateComponentProps skips the type.
3. Render the page — the key is spread onto the renderer and ignored there.
4. Control: put the same undeclared key one level out (on the component node rather than inside properties) — ADR-0089 D3a strictness rejects it, proving the gate exists and stops at the bag's edge.

Source

Extracted from the QA run #7695 (framework 92f26f7, console 09987b680).

[claude]

Findings triage (grade): escalated to needs-user-decision — finding and pm:queue removed (the card was filed with both, an illegal dual pm-state), needs-user-decision applied, domain:spec stays (either direction changes what the acceptance surface judges).

Why a decision and not a dispatch: the card's own bottom line — "Neither should be picked by an implementer without a ruling" — is correct. A/B are a genuine contract fork: A declares the object-* block family in ComponentPropsMap so schema + lint close the props bag; B leaves the map as-is and closes per-block on the objectui side (objectui#4041 shape), with no gate making it exhaustive.

Premise re-verified on origin/main @ 8f1851e (card's own check was at 00e9196): the passthrough-record design notes are still at packages/spec/src/ui/component.zod.ts:42/:137, and object-grid is still absent from packages/spec source (the only repo hit is the generated liveness/view.json).

Four-lens block (per #7498):

• ① Platform long-term coherence — A closes the bag under the same declaration-parity discipline other surfaces already use (one contract, fewer standing exceptions); B leaves the platform's primary data-bound authoring surface as the one place where typos pass silently, forever.
• ② Measured business pull — a live specimen this run (showcase my-work: the personal work queue authors filters: (plural) and no $filter ever reaches the wire — the grid lists every row #7750: filters: for filter silently unfiltered a personal work queue, success receipt included); every future block typo lands the same way, so the pull is measured, not speculative.
• ③ AI-agent error-resistance — A is the strong option: a closed key vocabulary with did-you-mean at parse beats consumer-side tolerance; today's bag is exactly the "declare a key the runtime never honors" trap the axis bans.
• ④ Startup scope discipline — A takes on a standing parity obligation (props schemas in spec for blocks implemented in objectui; precedent and machinery exist in check:react-declaration-parity); B is cheaper today but keeps the whole class open, one pin per typo per block.

Recommendation: lean A for the object-* family (lenses ①③ dominate; ④'s cost is bounded by existing parity machinery), with the warning-to-error upgrade still gated on the #5068 inventory as the card notes.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Routing a finding here from the #7750 dispatch (domain:metadata seat). #7750 was held to its one-word fix and this was deliberately not filed as a twin card — recording it on the existing card instead. I verified each claim against origin/main rather than relaying it.

The drift is in the vocabulary, not in one author's fingers. object-grid declares filter (singular), while ObjectNavItem.filters (packages/spec/src/ui/app.zod.ts:421) and the react-tier ListView.filters (packages/spec/src/ui/react-blocks.ts:217) both declare the plural. An author moving between tiers on one page switches spelling with no signal — which is how #7750 happened, and it will happen again on a different block.

The spec already contains the loud-rejection pattern this needs. The context-selector optionsSource is a strictObject carrying aliases: { url: 'endpoint', path: 'endpoint', value: 'valueKey', label: 'labelKey', filters: 'filter', where: 'filter' } (app.zod.ts:1066) — it rejects the exact typo by name and puts the fix in the message. So the capability is built and proven; it simply never reaches SDUI blocks.

Why it never reaches them — and the trap in "fixing" it. object-grid is not in ComponentPropsMap at all, and packages/lint/src/validate-component-props.ts skips unregistered types. Worth reading that file's own header (lines 84-95) before touching it, because it forecloses the obvious patch:

## Unregistered types are SKIPPED — a required semantic, not leniency … the example corpus alone authors flex, grid, object-metric, object-chart, object-grid, object-form, object-master-detail-form, record:quick_actions, record:alert and record:line_items — 87 nodes whose props schema ComponentPropsMap simply does not carry (SDUI blocks live in objectui's registry and in the ADR-0080 manifest). Judging those against an absent schema would report every one of them as broken.

So ⛔ flipping the skip off is not the fix — it would fail 87 legitimate nodes. The hole is upstream of the lint rule: SDUI block props are declared in objectui's registry / the ADR-0080 manifest and are not knowable to this repo's linter. Closing #7751 means getting those props reachable (import the manifest, or mirror the alias table for the blocks that have one), and only then does the existing aliases machinery do the work it already does elsewhere.

One correction worth carrying, also from that dispatch: defaultFilters is not an inert spelling. ObjectGrid.tsx reads it and lowers it to params.$filter as a legacy fallback behind filter (confirmed in an objectui checkout at 0cf8f0f, packages/plugin-grid/src/ObjectGrid.tsx:616-618). Only filters has zero read points. Anything built here should reject filters and keep honoring defaultFilters.

---

Generated by Claude Code