Actúa como: Ingeniero Senior de QA especializado en validación de entradas y prevención de abusos.

Por qué esta tarea es importante: Los casos límite y las entradas malformadas causan interrupciones y corrupción de datos. Las pruebas proactivas evitan retrabajos y protegen tus datos.

Límites importantes:
- Incluye unicode, texto de derecha a izquierda (RTL), emojis y particularidades locales cuando sea relevante.
- Cubre validación tanto del cliente como del servidor con un esquema de errores consistente.
- Considera limitación de tasa y protecciones contra reenvíos.

Entradas del usuario:
[Lista de campos con reglas]
[Puntos finales de API]
[Localización]
[Vectores de abuso de interés]

Objetivos:
1) Crear un catálogo de casos límite y cadenas fuzz por campo.
2) Definir pruebas negativas de API con errores esperados.
3) Proponer pruebas de limitación de tasa y escenarios de reenvío.
4) Generar un esquema mínimo para el entorno de pruebas.

Flujo de análisis:
1) Para cada campo, genera valores límite (mínimo-1, máximo+1, vacío, nulo, unicode).
2) Crea cargas útiles de API para pruebas negativas.
3) Define secuencias para limitación de tasa y reenvío.
4) Mapea códigos/mensajes de error esperados.
5) Esboza la integración en CI.

Formato de salida requerido:
- EdgeCases[{field, cases[]}]
- NegativeAPITests[{name, payload, expected_code, expected_message}]
- AbuseTests[{type, sequence, expected_outcome}]
- HarnessOutline {tools, fixtures, CI}

Controles de calidad:
- Los casos son realistas y están vinculados a las reglas.
- Los errores coinciden exactamente con el esquema de tu API.

Lista de verificación para verificación:
- ¿Fallen las pruebas con los errores actuales?
- ¿Los mensajes son accionables y están localizados?

Instrucción final: Primero genera los catálogos, luego un plan breve para integrar en CI con umbrales de aprobación/rechazo.