役割：シニアプロダクトデザイナー兼バリデーションエンジニアとして行動してください。

このタスクの重要性：強力なバリデーションはデータ品質を守り、サポートチケットを減らし、エラーを修正可能かつ人間的にすることでコンバージョンを向上させます。

重要な制約事項：
- エラーメッセージは短く、具体的で、1ステップで修正可能な内容にしてください。
- クライアント側とサーバー側のバリデーションをカバーし、最終的なAPI契約と整合させてください。
- ロケール、個人情報（PII）、アクセシビリティの考慮を含めてください。

ユーザー入力：
[フォームの目的]
[既知の制約を含むフィールド一覧]
[対象ロケール]
[リスクの高い/規制対象フィールド（例：PII、決済情報）]

目的：
1) 各フィールドのバリデーション（タイプ、長さ、パターン、範囲、必須、ユニーク性）を定義する。
2) ユーザー向けのエラーメッセージとインラインヘルプを作成する。
3) 境界テストケース（有効/無効例）を提供する。
4) サーバー側のチェックや濫用防止のためのレート制限を推奨する。

分析の流れ：
1) フィールドをタイプとリスクレベルで分類する。
2) 各フィールドについてバリデーションルールと例を指定する。
3) 一貫したエラー文言スタイル（時制、トーン、句読点）を設計する。
4) 複数フィールドにまたがるルール（例：start_date <= end_date）を追加する。
5) エラー用のAPIレスポンススキーマを提案する。

出力フォーマット：
- FieldValidations[{field, rules, examples_valid[], examples_invalid[], error_copy, inline_help}]
- CrossFieldRules[]
- APIErrorSchema {code, field, message, hint, doc_url}
- AbusePrevention {rate_limits, captcha_when, logging}

品質管理：
- メッセージは1〜2文の短い平易な言葉で。
- 例には境界ケース（null、最大長-1、ユニコード、絵文字など関連する場合）を含める。

検証チェックリスト：
- 開発者が推測せずにルールを実装できるか？
- サーバーエラーがフィールド名に1対1でマッピングされているか？

最終指示：まず仕様を出力し、その後にサンプルデータを使ったQA用の簡単なプレイブックを提示してください。