Found while fixing #5229 (the same defect class in content/docs/blocks/forms.mdx). Filed unassigned, not claiming — #5229's PR is scoped to content/docs/blocks/forms.mdx and deliberately does not touch this file.
What
content/docs/plugins/plugin-form.mdx line 108, in the validation rule table written by #5118:
| `pattern` | `{ value: string \| RegExp; message: string }` | hand-authored schemas must pass a **RegExp**: … |
The Type column says string | RegExp. The public contract says otherwise — packages/types/src/form.ts:
pattern?: { value: RegExp; message: string};string was removed from that union by #5099 and the zod face was aligned to match by #5186 / PR5230, whose FieldConstraintsSchema.pattern.value is z.custom<RegExp>((v) => v instanceof RegExp, …).
Why it is worth a card rather than a shrug
The row contradicts itself: the Notes cell in the very same row already states the rule correctly ("hand-authored schemas must pass a RegExp"). So the table tells a reader who scans the Type column one thing and a reader who reads the Notes column another. The Type column is the half a reader copies from.
This is the same failure mode #5118 closed on this file (a documented validation spelling that no declaration has), just narrowed to one cell that the #5118 pass left behind — understandably, since at the time of #5118 the union still had string in it on the zod face.
Fix direction
One cell: { value: RegExp; message: string }. The Notes cell needs no change — it is already correct and already explains the metadata route (buildValidationRules in @object-ui/fields) for authors who have only a string.
Verification available
Docs-only and this file has only plaintext fences, so — as measured in #5229 — no shipped gate reads it. The reference is the contract itself: packages/types/src/form.ts (FieldValidationRules.pattern) and packages/types/src/zod/form.zod.ts (FieldConstraintsSchema.pattern).
Related: #5099 (the narrowing), #5186 / PR5230 (the zod alignment), #5118 (the pass that wrote this table), #5229 (same class, different file).
Found while fixing #5229 (the same defect class in
content/docs/blocks/forms.mdx). Filed unassigned, not claiming — #5229's PR is scoped tocontent/docs/blocks/forms.mdxand deliberately does not touch this file.What
content/docs/plugins/plugin-form.mdxline 108, in thevalidationrule table written by #5118:The Type column says
string | RegExp. The public contract says otherwise —packages/types/src/form.ts:stringwas removed from that union by #5099 and the zod face was aligned to match by #5186 / PR5230, whoseFieldConstraintsSchema.pattern.valueisz.custom<RegExp>((v) => v instanceof RegExp, …).Why it is worth a card rather than a shrug
The row contradicts itself: the Notes cell in the very same row already states the rule correctly ("hand-authored schemas must pass a RegExp"). So the table tells a reader who scans the Type column one thing and a reader who reads the Notes column another. The Type column is the half a reader copies from.
This is the same failure mode #5118 closed on this file (a documented
validationspelling that no declaration has), just narrowed to one cell that the #5118 pass left behind — understandably, since at the time of #5118 the union still hadstringin it on the zod face.Fix direction
One cell:
{ value: RegExp; message: string }. The Notes cell needs no change — it is already correct and already explains the metadata route (buildValidationRulesin@object-ui/fields) for authors who have only a string.Verification available
Docs-only and this file has only
plaintextfences, so — as measured in #5229 — no shipped gate reads it. The reference is the contract itself:packages/types/src/form.ts(FieldValidationRules.pattern) andpackages/types/src/zod/form.zod.ts(FieldConstraintsSchema.pattern).Related: #5099 (the narrowing), #5186 / PR5230 (the zod alignment), #5118 (the pass that wrote this table), #5229 (same class, different file).