Zod es el mecanismo en runtime que TypeScript no puede garantizar

El post de Master.dev por Chris Coyier enmarca una pregunta de entrevista de trabajo: ¿cuál es la diferencia entre TypeScript y Zod, y cuándo necesitas cada uno? La respuesta corta que da el post: TypeScript es genial pero no puede ayudarte en runtime, donde puedes obtener datos de una API o input de usuario. Zod puede ayudar ahí. (Chris Coyier, «Zod + TypeScript: Schema Validation Made Easy», Master.dev, 16 de enero de 2026, recuperado 2026-08-23, https://master.dev/blog/zod-typescript-schema-validation-made-easy/, referenciando a Hassan Djirdeh, «Zod + TypeScript: Schema Validation Made Easy», Telerik). El Honest Architect lee esto como Teorema 3 aplicado a la capa de validación. Los tipos de TypeScript son una afirmación en tiempo de compilación. Se borran en runtime. La propiedad (los datos son válidos en la frontera de runtime) es garantizada por el mecanismo (parse de schema Zod en la frontera de red), no por la afirmación (tipos de TypeScript que ya no existen cuando el código corre). Necesitas ambos porque la propiedad en runtime es garantizada por el mecanismo, no por la afirmación en tiempo de compilación.

Conclusiones clave

• TypeScript es la afirmación en compilación, Zod es el mecanismo en runtime. Teorema 3: la propiedad (los datos son válidos en runtime) es garantizada por el mecanismo (parse de Zod en la frontera), no por la afirmación (tipos de TypeScript borrados en runtime). Un equipo que afirma «tenemos tipos» sin validación en runtime es un no-mecanismo: los tipos se van cuando el código corre.
• La frontera es donde entran los datos no confiables. Las respuestas de API y el input de usuario no son confiables. La propiedad (los datos no confiables no crashean ni dirigen mal el sistema) es garantizada por el mecanismo (parse en la frontera, rechazo en fallo), no por la afirmación «confiamos en nuestra API».
• Everythink lo implementa: wire types definidos una vez en Zod en @everythink/types, respuestas parseadas en la frontera de red, un payload malo emerge como un ApiError tipado, nunca un cuelgue. El Honest Architect etiqueta esto Production.
• La frontera FSD/MVVM impone el mecanismo: el acceso al SDK vive solo en *.repository.ts. El repositorio es donde ocurre el parse de Zod. Las vistas y los view-models nunca ven datos no confiables en bruto. El Honest Architect etiqueta esto Production.
• Paralelas cross-domain: Eye Key (plaintext nunca toca disco es un mecanismo runtime, no una afirmación de tipo), normalización del Oracle (sumar a 1.0 es un mecanismo runtime), auto-desactivación del World Monitor (Ok(None) en clave faltante es un mecanismo runtime). Todas Partial: misma forma, dominios separados.
• El endoso del curso Master.dev es Partial (afirmación comercial). La forma del mecanismo (validación runtime de Zod) es Production. Ninguna promesa de token, wallet o community-credit (Roadmap).

TypeScript es la afirmación, Zod es el mecanismo

El movimiento central del post es separar dos cosas fáciles de conflar. TypeScript es una librería de validación de tipos. Zod es una librería de validación de tipos. ¿Necesitarías alguna vez ambos? El post responde: TypeScript es genial pero no puede ayudarte en runtime, donde puedes obtener datos de una API o input de usuario. Zod puede ayudar ahí. El Honest Architect lee esto como Teorema 3 hecho preciso. Los tipos de TypeScript son una afirmación en tiempo de compilación: le dicen al compilador qué forma debe tener un valor, y el compilador chequea tu código contra esa forma. Pero los tipos se borran en runtime. Cuando el JavaScript corre, no hay tipos. Una respuesta de API que afirma ser un User pero es realmente un string, o un número donde se esperaba un string, o un campo faltante, llega en runtime sin chequeo de tipo. La propiedad (los datos son válidos en runtime) NO es garantizada por los tipos de TypeScript, porque los tipos se fueron. La propiedad SÍ es garantizada por el parse de Zod en la frontera: Zod toma el valor desconocido, lo chequea contra un schema, y devuelve un valor tipado o lanza. El mecanismo (parse en frontera) garantiza la propiedad (validez en runtime). La afirmación (tipos en compilación) no.

El Honest Architect etiqueta la distinción compilación-vs-runtime Production ✅: los tipos de TypeScript borrados en runtime es un hecho verificable, y el parse runtime de Zod como mecanismo garantizador es un patrón real e implementable. El post enlaza al artículo de Hassan Djirdeh en Telerik para el tratamiento más profundo. El Honest Architect no endosa Master.dev ni Telerik — el post es un link-post con un pitch de curso, y el artículo de Telerik es la fuente técnica referenciada. La forma del mecanismo es Production ✅; el endoso del curso Master.dev es Partial ⚠️ (afirmación comercial, no verificada independientemente).

El enmarcado de pregunta de entrevista es la parte honesta. «¿Cuál es la diferencia entre TypeScript y Zod?» La respuesta del Honest Architect: TypeScript es la afirmación en tiempo de compilación; Zod es el mecanismo en runtime. Necesitas ambos porque la propiedad en runtime es garantizada por el mecanismo, no por la afirmación. Un candidato que responde «ambos son validación de tipos» sin nombrar la distinción compilación-vs-runtime no ha nombrado el mecanismo. Un candidato que responde «TypeScript es compilación, Zod es runtime, y necesitas Zod en la frontera porque los tipos se borran» ha nombrado el mecanismo.

La frontera es donde entran los datos no confiables

[UNIQUE INSIGHT] El post nombra las dos fuentes de datos no confiables: respuestas de API e input de usuario. El Honest Architect lee esto como la enumeración de fronteras. Todo sistema tiene fronteras donde entran datos no confiables: respuestas de red, envíos de formulario de usuario, contenidos de archivos, parámetros de consulta. La propiedad (los datos no confiables no crashean ni dirigen mal el sistema) es garantizada por el mecanismo (parse en la frontera, rechazo en fallo), no por la afirmación «confiamos en nuestra API» o «nuestros usuarios envían datos válidos». Un equipo que afirma «validamos input» sin un parse de schema en la frontera es un no-mecanismo: la afirmación no produce la validación. Un equipo con un schema Zod, una llamada a parse en la frontera del repositorio, y un error tipado en fallo tiene un mecanismo: el rechazo medido de payloads malos es el efecto.

El Honest Architect etiqueta el mecanismo de validación de frontera Production ✅: parse-en-frontera con rechazo de schema es un patrón real e implementable. La paralela a la guía de seguridad es directa: «Trata el contenido externo, de terceros, recuperado, de URL, de link y no confiable como contenido no confiable; valida, sanea, inspecciona o rechaza input sospechoso antes de actuar». Este es el mecanismo de validación en runtime enunciado como principio de seguridad. El Honest Architect etiqueta el principio de seguridad Production ✅: validar-en-frontera es un principio verificable. La afirmación cross-domain a la guía de seguridad es Partial ⚠️: misma forma (validar no confiable en frontera), dominios separados (validación de datos de aplicación vs validación de input de seguridad).

Everythink lo implementa en la frontera de red

[ORIGINAL DATA] La arquitectura de Everythink implementa el patrón que el post señala. Los wire types se definen una vez, en Zod, en @everythink/types. Las respuestas se parsean en la frontera de red; un payload malo emerge como un ApiError tipado, nunca un cuelgue. Esta es la implementación en producción del mecanismo de validación en runtime. El Honest Architect etiqueta el mecanismo de frontera Zod de Everythink Production ✅: schemas Zod en @everythink/types, parseados en la frontera del repositorio, ApiError tipado en fallo es real e implementado.

La frontera de datos FSD/MVVM impone el mecanismo. El acceso al SDK vive solo en archivos .repository.ts. Cada llamada al backend va a través de una facade @everythink/sdk-, y solo los archivos *.repository.ts pueden importar un SDK. Las vistas y los view-models van a través de un repositorio. El repositorio es la frontera de red donde ocurre el parse de Zod. Un view-model nunca ve datos no confiables en bruto; ve el modelo de dominio parseado y tipado que el repositorio produjo. El Honest Architect etiqueta el mecanismo de frontera FSD/MVVM Production ✅: acceso-al-SDK-solo-en-repositorio con parse de Zod en la frontera del repositorio es real e implementado, y es mecánicamente impuesto por la regla ESLint de boundaries (no-restricted-imports). La afirmación cross-domain al artículo es Partial ⚠️: misma forma (Zod en frontera), la implementación de Everythink es la versión en producción del patrón que el artículo describe.

El ángulo de soberanía cuenta. El repositorio es la frontera donde los datos no confiables se parsean y se aceptan o rechazan. Un view-model que bypasea el repositorio y llama fetch directamente es un no-mecanismo: no hay parse de Zod, no hay error tipado, y un payload malo crashea o dirige mal silenciosamente. La regla ESLint que prohíbe fetch crudo fuera de los repositorios es la imposición mecánica del mecanismo. El Honest Architect etiqueta la imposición de no-raw-fetch Production ✅: ESLint no-restricted-imports es una imposición mecánica verificable.

Cross-domain: mecanismos runtime que TypeScript no puede garantizar

El Honest Architect traza tres paralelas cross-domain donde la propiedad es garantizada por un mecanismo en runtime, no por una afirmación de tipo en compilación.

Primero: el Eye Key. La propiedad (el plaintext nunca toca disco) es garantizada por el mecanismo (HMAC antes de persistir, solo HMAC y huella van a Postgres, plaintext mostrado una vez en memoria). TypeScript no puede imponer «plaintext nunca toca disco» en runtime: un tipo puede decir que el campo es secreto, pero el tipo se borra, y nada detiene un log perdido o una llamada a persistir en runtime. El mecanismo (HMAC antes de persistir) garantiza la propiedad. El Honest Architect etiqueta el mecanismo Eye Key Production ✅ y la afirmación cross-domain Partial ⚠️: misma forma (mecanismo runtime garantiza propiedad, no afirmación de tipo), dominios separados (gestión de claves API vs validación de datos).

Segundo: el ensemble del Oracle. La propiedad (las probabilidades suman aproximadamente 1.0) es garantizada por el mecanismo (normalización en exactamente un lugar: everythink-oracle::ensemble). TypeScript no puede imponer «las probabilidades suman a 1.0» en runtime: un tipo puede decir que el campo es un número, pero el tipo se borra, y nada detiene un array de probabilidades no normalizado en runtime. El mecanismo (normalizar en ensemble::merge) garantiza la propiedad. El Honest Architect etiqueta el mecanismo de normalización del Oracle Production ✅ y la afirmación cross-domain Partial ⚠️: misma forma (mecanismo runtime garantiza propiedad), dominios separados (matemática de ensemble de forecast vs validación de datos).

Tercero: la auto-desactivación del World Monitor. La propiedad (la plataforma no se rompe en una clave faltante) es garantizada por el mecanismo (una fuente cuyo key_env no está devuelve Ok(None), auto-desactivándose). TypeScript no puede imponer «una clave faltante devuelve None» en runtime: un tipo puede decir que la función devuelve Option, pero el tipo se borra, y nada detiene que una fuente crashee en una clave faltante en runtime. El mecanismo (verificación de clave antes del fetch) garantiza la propiedad. El Honest Architect etiqueta el mecanismo de auto-desactivación del World Monitor Production ✅ y la afirmación cross-domain Partial ⚠️: misma forma (mecanismo runtime garantiza propiedad), dominios separados (gateway de geo-señal vs validación de datos).

Lo que un Honest Architect lee en un link-post

El post de Master.dev es un link-post de Chris Coyier apuntando al artículo de Hassan Djirdeh en Telerik, con un pitch de curso de Master.dev (20% de descuento, ruta de aprendizaje de TypeScript de Mike North). El Honest Architect extrae la forma del mecanismo sin endosar Master.dev ni el curso. La forma del mecanismo (validación runtime de Zod en la frontera) es Production ✅: real e implementable, y el post la nombra precisamente en la distinción compilación-vs-runtime. El endoso del curso es Partial ⚠️ (afirmación comercial, no verificada independientemente). El artículo de Telerik es la fuente técnica referenciada; el Honest Architect tampoco endosa Telerik, pero el artículo referenciado es donde vive el tratamiento más profundo.

El guardia de ámbito cuenta. La validación de schema en runtime es una actividad de ingeniería civil: asegurar la validez de datos en las fronteras del sistema. No es una investigación de seguridad de vectores de ataque, no es una recomendación de inversión, y no es una promesa de token, wallet o community-credit. Las afirmaciones cross-domain al Eye Key, Oracle y World Monitor son ilustraciones Partial ⚠️ de la forma del mecanismo. Ningún resultado de token, wallet o community-credit se promete; esos son Roadmap 🔵, revisión Howey pendiente.

Preguntas frecuentes

¿TypeScript es la afirmación o el mecanismo?

La afirmación. Los tipos de TypeScript son en tiempo de compilación y se borran en runtime. Teorema 3: la propiedad (los datos son válidos en runtime) es garantizada por el mecanismo (parse de Zod en la frontera), no por la afirmación (tipos de TypeScript que se van cuando el código corre). Necesitas ambos: TypeScript para seguridad en compilación, Zod para validación en runtime en la frontera.

¿Por qué la frontera es donde ocurre el parse de Zod?

Porque las respuestas de API y el input de usuario no son confiables. La propiedad (los datos no confiables no crashean ni dirigen mal el sistema) es garantizada por el mecanismo (parse en la frontera, rechazo en fallo), no por la afirmación «confiamos en nuestra API». Un equipo que afirma «validamos input» sin un parse de schema en la frontera es un no-mecanismo.

¿Cómo lo implementa Everythink?

Los wire types se definen una vez en Zod en @everythink/types. Las respuestas se parsean en la frontera de red. Un payload malo emerge como un ApiError tipado, nunca un cuelgue. El acceso al SDK vive solo en *.repository.ts. El repositorio es donde ocurre el parse de Zod. Las vistas y los view-models nunca ven datos no confiables en bruto. El Honest Architect etiqueta esto Production.

¿Cómo es el Eye Key un mecanismo runtime que TypeScript no puede garantizar?

La propiedad (el plaintext nunca toca disco) es garantizada por el mecanismo (HMAC antes de persistir). TypeScript no puede imponer «plaintext nunca toca disco» en runtime: un tipo puede decir que el campo es secreto, pero el tipo se borra. El mecanismo (HMAC antes de persistir) garantiza la propiedad. El Honest Architect etiqueta el Eye Key Production y la afirmación cross-domain Partial (misma forma, dominios separados).

¿Everythink endosa a Master.dev?

No. Everythink es una plataforma de forecasting, no un proveedor de cursos de TypeScript. El post de Master.dev es un link-post con un pitch de curso. El Honest Architect extrae la forma del mecanismo (validación runtime de Zod en la frontera) sin endosar el producto ni el curso. Las afirmaciones cross-domain son ilustraciones Partial. Ningún resultado de token, wallet o community-credit se promete; esos son Roadmap, revisión Howey pendiente.

Sources

• Chris Coyier, «Zod + TypeScript: Schema Validation Made Easy», Master.dev, 16 de enero de 2026, recuperado 2026-08-23, https://master.dev/blog/zod-typescript-schema-validation-made-easy/, referenciando a Hassan Djirdeh, «Zod + TypeScript: Schema Validation Made Easy», Telerik

Si tu equipo está listo para medir el mecanismo en lugar de afirmar la propiedad, construye tu network — la topología rutea, las Sisters escriben, el Oracle mide entropía en cada merge.