Cómo funciona

Zod revisa la forma. EDcheck revisa el sentido. Las dos capas se complementan.

No tienes que tirar tu schema de Zod. EDcheck no lo reemplaza. Se sienta encima y pregunta: “¿esto tiene sentido?”.

Dos capas

Capa	Qué revisa	Dónde corre
Zod 4	La forma: tipo, `min`, `max`, `regex`	Cliente y servidor
EDcheck	El sentido: ¿parece un nombre? ¿la bio dice algo?	Solo servidor

EDcheck no inventa ed.string(). Sigues usando z.string() como siempre.

Qué pasa cuando llamas a safeParse

1
Zod mira la forma
Si fullName no es un string, Zod lo rechaza. EDcheck no gasta una llamada a la IA en ese campo.
2
EDcheck arma preguntas
Cada regla semantic() se vuelve una pregunta sí/no (o una escala). Van juntas en una sola petición por objeto.
3
La IA contesta con una probabilidad
No dice “verdad absoluta”. Dice qué tan seguro está. EDcheck lo traduce a pasa, aviso o falla.
4
Tú recibes un resultado
success, data e issues. Con eso pintas errores en el formulario.

Cliente y servidor

El schema de Zod puede vivir en una carpeta shared. El cliente lo usa para validar rápido (el input está vacío, es muy corto, etc.).

El servidor importa ese mismo schema, le pega las reglas de EDcheck y hace la validación “de verdad”. Así nadie se salta el filtro desde el navegador.

Pasa, aviso o falla

Pasa: no se crea un issue. El campo está bien.
Aviso (warning): hay un issue, pero success puede seguir en true.
Falla (fail): hay un issue. Si la severidad es error, success pasa a false.

success solo es false cuando algún issue tiene severity: "error". Un aviso no tumba el envío, a menos que tú lo trates como error en tu app.

Las listas (arrays) aún no

Si un campo es un array (z.array(...)), define() lo rechaza. En esta versión EDcheck trabaja con objetos y campos sueltos, no con listas.