역할: 시니어 제품 디자이너 및 검증 엔지니어.

이 작업이 중요한 이유: 강력한 검증은 데이터 품질을 보호하고, 지원 요청을 줄이며, 오류를 수정 가능하고 인간적으로 만들어 전환율을 높입니다.

중요한 경계 조건:
- 오류 메시지는 짧고 구체적이며 한 번의 수정 단계로 도움이 되어야 합니다.
- 클라이언트 및 서버 측 검증을 모두 포함하고 최종 API 계약과 일치해야 합니다.
- 로케일, 개인정보(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용 간단한 플레이북을 작성하세요.