When adding validation logic that uses complex literals (especially RegExp), keep it consistent and maintainable:

• Don’t scatter regex literals inline across files/branches—move them to a shared constant block near other related regexes.
• If the regex is too complex to be readable/reviewable, extract it into a named helper (e.g., isValidIpv6) so the parsing/intent is clear.
• Reuse the centralized constant/helper everywhere in the module; avoid creating unused helpers.
• If eslint/linter requires suppression for regex style, prefer refactoring to satisfy the linter, and only use eslint-disable when behavior is unchanged and the suppression is clearly justified.

Example (centralizing a slug regex):

// Regex constants near other regexes
const slugRegex = /^[a-z0-9]+(?:-[a-z0-9]+)*$/;

export function isSlug(value: string): boolean {
  return slugRegex.test(value);
}

// Reuse in validation instead of repeating the literal
// if (check.kind === "slug") { ... slugRegex ... }

This improves readability, reduces review/merge churn, and makes future tweaks to validation patterns less error-prone.