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:
- dark —
grep -c 'filter: z.unknown()' reads 0. There is no filter key anywhere in this file declared z.unknown().
- lit —
grep -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
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:*orpriority:*applied — routing and grading are triage's.The claim
packages/spec/src/ui/component.zod.ts, thefilterdocblock onElementRecordPickerPropsSchema(anchor by content,Filter rules narrowing which records the picker offers; ⛔ not by line, the block moves):The measurement, on
origin/mainfd62a66grep -n '^ filter:' packages/spec/src/ui/component.zod.ts— 7 hits, and every one of them is the array form:Controls, both on the same instrument and the same file:
grep -c 'filter: z.unknown()'reads 0. There is nofilterkey anywhere in this file declaredz.unknown().grep -c 'z.unknown()'reads a non-zero count (the file has plenty ofz.unknown()keys,exportOptionsamong them), so the dark zero is a fact about the pairingfilter+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 fourobject-*blocks ontoz.array(ViewFilterRuleSchema). The citation was kept while the claim it introduced was not updated.Why this is not a nit
The four
object-*blocks arestrictObjects and theirfilterisz.array(ViewFilterRuleSchema). So the sentence tells an author — often an AI author, ADR-0033 — thatfilteron anobject-*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 longerz.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#15449citation, 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 regeneratecontent/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