Especificaciones antes que código

La regla del proyecto

Hay una regla que no se discute: no se implementa una fase hasta que su especificación está revisada y cerrada. Antes de escribir código, hay un documento que dice qué se hace, cómo se hace y cómo se sabe que está bien.

Cómo está organizado

El proyecto tiene nueve fases, de la 0 a la 8: fundamentos del servidor, modelo de datos, frontend público, migración de contenidos, LaIA, paneles de gestión, publicidad, newsletter y paso a producción. Cada fase tiene su especificación, con el modelo de datos campo a campo, los criterios de aceptación y los runbooks de operaciones.

Además, unas reglas globales se aplican a todo: no inventar datos, seguridad por defecto, analítica sin cookies, commits pequeños y claros.

Por qué vale la pena (sobre todo con agentes)

Las especificaciones son también lo que permite trabajar con agentes de IA. Hay un paquete en inglés pensado para ellos, con cada tarea numerada y sus criterios. El agente no improvisa: ejecuta la tarea y el resultado se comprueba contra la spec.

Un ejemplo real: la spec del design system (tarea T2.1) pedía 14 primitivas concretas. Cuando se terminaron, se contaron. Y cuando alguna no se parecía lo suficiente al HTML validado, se rehízo.

Más trabajo antes de empezar, mucho menos trabajo después.