Skip to content

docs(plugin-form): fix pattern.value Type column to RegExp-only - #5267

Merged
os-support-ai merged 1 commit into
mainfrom
claude/issue-5249-plugin-form-pattern-value-type-cell
Aug 18, 2026
Merged

docs(plugin-form): fix pattern.value Type column to RegExp-only#5267
os-support-ai merged 1 commit into
mainfrom
claude/issue-5249-plugin-form-pattern-value-type-cell

Conversation

@os-support-ai

Copy link
Copy Markdown
Collaborator

Fixes#5249

What

content/docs/plugins/plugin-form.mdx line 108, in the validation rule table, typed the pattern rule'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 @ bc2922a8 before editing

packages/types/src/form.tsFieldValidationRules.pattern:

pattern?: { value: RegExp; message: string};

No string in the union — narrowed by #5099 (maintainer ruling 2026-08-18, documented inline: react-hook-form's field validator applies pattern only when value instanceof RegExp, so a string here type-checked and validated nothing).

packages/types/src/zod/form.zod.tsFieldConstraintsSchema.pattern.value:

value: z.custom<RegExp>((v)=>vinstanceofRegExp,{message: 'pattern.value must be a compiled RegExp — react-hook-form runs `pattern` only when '+ ...
})

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 string no longer belongs in that cell — premise holds, the doc was the only side of the contradiction still stale.

Scan of the rest of the validation table (as requested in the issue)

Checked every other row's Type cell against the current FieldValidationRules interface (packages/types/src/form.ts) — all match exactly, no other cell needed a change:

  • required — doc string | boolean == interface required?: 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 scope

Gate-coverage claim in the issue/triage — checked, partially inaccurate

The issue/triage comment says this file "has only plaintext fences, so … no shipped gate reads it." Verified this directly and it's not quite right:

  • content/docs/plugins/plugin-form.mdx has 5 plaintext, 2 json, 1 bash, and 2 typescript fences (lines 277, 406) — not "only plaintext".
  • scripts/check-doc-snippet-types.mjs treats typescript as a TS fence language (TS_FENCE_LANGUAGES = new Set(['ts', 'tsx', 'typescript'])), and the file is not listed in that script's UNGATED_DOCS exclusion table — so by the script's own "default is covered" rule, this file's 2 typescript blocks are compiled by check:doc-snippets today.

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 typescript blocks 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 (the type: 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:

node scripts/check-control-bytes.mjs → ✅ OK (4661 tracked text files scanned)
node scripts/check-doc-component-types.mjs → ✅ Every documented component type is registered.
node scripts/check-doc-links.mjs → ✅ Links are valid across 13 scan roots.
node scripts/check-changeset-presence.mjs → ✅ No source of a released package changed; no changeset owed.

check:doc-snippets (node scripts/check-doc-snippet-types.mjs) needs a multi-package turbo build (--filter=@object-ui/types etc.) behind the shared /tmp/os-heavy-verify.lock, which stayed contended (another agent's vitest 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 touch content/docs/blocks/forms.mdx (sibling card #5229's file), docs/adr/**, .claude/**, skills/**, AGENTS.md, or CLAUDE.md. No released package src/ touched — no changeset needed (verified by check-changeset-presence.mjs above).


Generated by Claude Code

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
os-support-ai marked this pull request as ready for review August 18, 2026 23:14
@os-support-ai
os-support-ai added this pull request to the merge queueAug 18, 2026
Merged via the queue into main with commit 87d9202Aug 18, 2026
19 checks passed
@os-support-ai
os-support-ai deleted the claude/issue-5249-plugin-form-pattern-value-type-cell branch August 18, 2026 23:15
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants

@os-support-ai@claude