Uh oh!
There was an error while loading. Please reload this page.
docs(plugin-form): fix pattern.value Type column to RegExp-only - #5267
Merged
os-support-ai merged 1 commit intoAug 18, 2026
Merged
Conversation
content/docs/plugins/plugin-form.mdx line 108's `validation` rule table typed `pattern.value` as `string | RegExp` in the Type column, while the Notes cell in the same row already stated the RegExp-only rule correctly. `string` was removed from `FieldValidationRules.pattern` by #5099 and the zod face (`FieldConstraintsSchema.pattern.value`) was aligned by #5186 / PR5230. Fix the one cell to `{ value: RegExp; message: string }`; Notes cell needs no change. Fixes#5249
os-support-ai
marked this pull request as ready for review
August 18, 2026 23:14
Uh oh!
There was an error while loading. Please reload this page.
os-support-ai
deleted the
claude/issue-5249-plugin-form-pattern-value-type-cell
branch
August 18, 2026 23:15
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#5249
What
content/docs/plugins/plugin-form.mdxline 108, in thevalidationrule table, typed thepatternrule's Type column as{ value: string | RegExp; message: string }while the Notes cell in the same row already correctly said hand-authored schemas must pass a RegExp. Fixed the Type column to{ value: RegExp; message: string }. The Notes cell was already correct and needed no change.Contract verified on
origin/main@bc2922a8before editingpackages/types/src/form.ts—FieldValidationRules.pattern:No
stringin the union — narrowed by #5099 (maintainer ruling 2026-08-18, documented inline: react-hook-form's field validator appliespatternonly whenvalue instanceof RegExp, so a string here type-checked and validated nothing).packages/types/src/zod/form.zod.ts—FieldConstraintsSchema.pattern.value:Also RegExp-only — aligned by #5186 / PR5230, same file's header comment confirms this closed the earlier "flat scalar dialect" gap (#5186).
Both declarations confirm
stringno longer belongs in that cell — premise holds, the doc was the only side of the contradiction still stale.Scan of the rest of the
validationtable (as requested in the issue)Checked every other row's Type cell against the current
FieldValidationRulesinterface (packages/types/src/form.ts) — all match exactly, no other cell needed a change:required— docstring | boolean== interfacerequired?: string | boolean✓minLength/maxLength— doc{ value: number; message: string }== interface ✓min/max— doc{ value: number; message: string }== interface ✓validate— doc(value) => boolean | string | Promise<boolean | string>is an abbreviation of the interface's(value: string | number | boolean | null | undefined) => boolean | string | Promise<boolean | string>(param type omitted for brevity in the doc) — not a contradiction, left as-is per the issue's one-cell-class scopeGate-coverage claim in the issue/triage — checked, partially inaccurate
The issue/triage comment says this file "has only
plaintextfences, so … no shipped gate reads it." Verified this directly and it's not quite right:content/docs/plugins/plugin-form.mdxhas 5plaintext, 2json, 1bash, and 2typescriptfences (lines 277, 406) — not "only plaintext".scripts/check-doc-snippet-types.mjstreatstypescriptas a TS fence language (TS_FENCE_LANGUAGES = new Set(['ts', 'tsx', 'typescript'])), and the file is not listed in that script'sUNGATED_DOCSexclusion table — so by the script's own "default is covered" rule, this file's 2typescriptblocks are compiled bycheck:doc-snippetstoday.This doesn't affect this PR: the edit is confined to prose inside a Markdown table cell, outside any fenced block, so it cannot change that gate's outcome for this file (the two
typescriptblocks are byte-for-byte unchanged). Flagging the inaccuracy since the issue asked to verify the claim rather than trust it.scripts/check-doc-component-types.mjs(thetype:literal checker, the gate that genuinely runs unfiltered on every docs-only PR) does read this file, and passed locally.Tests / local gates run
At commit
fb63d159e:check:doc-snippets(node scripts/check-doc-snippet-types.mjs) needs a multi-packageturbo build(--filter=@object-ui/typesetc.) behind the shared/tmp/os-heavy-verify.lock, which stayed contended (another agent'svitest run packages/app-shell/held it through two ~180s queue attempts). Not run locally for that reason — see reasoning above for why this specific diff cannot change its outcome; CI (doc-snippet-types.yml) runs it definitively on this PR.Scope
Touches only
content/docs/plugins/plugin-form.mdx(one cell). Does not touchcontent/docs/blocks/forms.mdx(sibling card #5229's file),docs/adr/**,.claude/**,skills/**,AGENTS.md, orCLAUDE.md. No released packagesrc/touched — no changeset needed (verified bycheck-changeset-presence.mjsabove).Generated by Claude Code