Skip to content

finding(spec): element:record_picker.filter's docblock says the four object-* blocks declare filter as z.unknown() — measured 0 of 4; all four declare z.array(ViewFilterRuleSchema) #17475

Description

@os-bill

Found while implementing #17166 two lines below this docblock (PR #17473); ⛔ deliberately not fixed there — different key, different carrier, and #17166's claim fenced it out. ⛔ No domain:* or priority:* applied — routing and grading are triage's.

The claim

packages/spec/src/ui/component.zod.ts, the filter docblock on ElementRecordPickerPropsSchema (anchor by content, Filter rules narrowing which records the picker offers; ⛔ not by line, the block moves):

the four object-* blocks declare filter as z.unknown(), no orthography at all

The measurement, on origin/main fd62a66

grep -n '^ filter:' packages/spec/src/ui/component.zod.ts — 7 hits, and every one of them is the array form:

1122:  filter: z.array(ViewFilterRuleSchema).optional().describe('Additional filter criteria for related records'),
1853:  filter: z.array(ViewFilterRuleSchema).optional()
2223:  filter: z.array(ViewFilterRuleSchema).optional()
2484:  filter: z.array(ViewFilterRuleSchema).optional()
2698:  filter: z.array(ViewFilterRuleSchema).optional()
2766:  filter: z.array(ViewFilterRuleSchema).optional()
2876:  filter: z.array(ViewFilterRuleSchema).optional()

Controls, both on the same instrument and the same file:

  • darkgrep -c 'filter: z.unknown()' reads 0. There is no filter key anywhere in this file declared z.unknown().
  • litgrep -c 'z.unknown()' reads a non-zero count (the file has plenty of z.unknown() keys, exportOptions among them), so the dark zero is a fact about the pairing filter + z.unknown(), not a matcher that finds nothing.

⇒ The parenthetical is false. It even cites the change that falsified it: the sentence ends — #15449, and #15449 is what moved all four object-* blocks onto z.array(ViewFilterRuleSchema). The citation was kept while the claim it introduced was not updated.

Why this is not a nit

The four object-* blocks are strictObjects and their filter is z.array(ViewFilterRuleSchema). So the sentence tells an author — often an AI author, ADR-0033 — that filter on an object-* block accepts anything, when the record form it invites ({ field: { $eq: ... } }, the MongoDB-style shape this very docblock says the picker moved OFF) is refused at parse. That is prose steering an author into metadata the runtime rejects, in the one place that says what the sibling doors accept.

It is also the mirror image of #17166, which is the reason it was noticed: there the prose was the whole account of a z.unknown() key and was short; here the prose describes keys that are no longer z.unknown() at all and says they have "no orthography at all".

What a fix would be

Correct the parenthetical to say what the four blocks declare today (z.array(ViewFilterRuleSchema), the same one filter orthography the rest of the sentence is about), keeping the #15449 citation, which is accurate as provenance. ⛔ No schema change: nothing about any declaration moves, and no accept set is touched.

Editing a docblock is not a .describe() and does not regenerate content/docs/references/**; a fixer should verify that on their own tree rather than inherit it from here.

Refs: #15449 (the change that falsified the claim) · #14406 (the convergence this docblock records) · #17166 / PR #17473 (where it was found).


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions