Por qué existe Eidos

El problema

Pregúntale a un equipo qué está construyendo y obtendrás cuatro respuestas, ninguna escrita en un solo sitio.

El ticket que describía la funcionalidad se cerró hace dieciocho meses, y su descripción se escribió para justificar un sprint, no para describir un producto. La página del wiki fue exacta la semana en que se escribió. La decisión sobre por qué no se cubre un caso se tomó de palabra, y la única persona que la recuerda se fue. El código te dice qué hace la cosa hoy, pero no qué se supone que es, ni cuáles de sus comportamientos actuales son promesas y cuáles accidentes.

Así que la respuesta honesta a «¿qué se supone que es esta cosa?» es una reunión.

Por qué los tickets no pueden sostenerlo

El instinto es echar mano del gestor de tareas, porque es donde ya vive el equipo. No funciona, y la razón es estructural, no cultural.

Una tarea describe trabajo. Tiene principio y fin, una persona asignada, una estimación y un estado que va de abierto a cerrado. Todo su propósito es dejar de ser relevante. Cuando el trabajo se entrega, el ticket está hecho, y todo lo que casualmente registraba sobre el producto caduca en ese mismo instante, porque ya nadie lo vigila.

Un Blueprint describe la cosa. No tiene final. Se escribe antes de que empiece el trabajo, se corrige mientras el trabajo ocurre y sigue siendo la descripción exacta mucho después. Su exactitud no está atada a un estado.

Esta es la razón de que Eidos prohíba de plano los campos de seguimiento de trabajo. Nada de sprint, estimate ni assignee. En el momento en que los añades, un Blueprint se convierte en una tarea y empieza a pudrirse en el mismo calendario. Conecta con tu gestor de tareas mediante un enlace.

Qué hace Eidos al respecto

Mantiene la respuesta autorizada a «qué es esta cosa» como markdown versionado, en el repositorio, revisado en pull requests junto al código que describe.

Esa elección de ubicación hace casi todo el trabajo:

Está junto al código, así que está delante de la gente que si no adivinaría.
Está en git, así que cada cambio tiene autor, fecha, diff y motivo, y Eidos se apoya en ese historial en lugar de inventarse su propio registro de auditoría.
Se revisa en PRs, así que un cambio en lo que el producto es recibe el mismo escrutinio que un cambio en lo que hace.
Es markdown plano, así que una persona lo lee en un editor, en una página web o en un vault de Obsidian, y un agente de código lee exactamente el mismo archivo.

Ese último punto no es incidental. Que humanos y agentes lean dos fuentes de verdad distintas es como empieza la deriva. Aquí leen el mismo archivo.

El bucle que se da la razón a sí mismo

Esta es la razón de que el estándar esté construido como está, y vale la pena decirla sin rodeos.

Una spec existe para ser un control sobre el código. Es la declaración independiente de qué se supone que es la cosa, y todo su valor está en que viene de un sitio distinto de la implementación.

Ahora deja que un agente escriba las dos.

Escribe la spec. Escribe código que satisface la spec. Cuando se le pregunta si el código está bien, comprueba el código contra la spec que él mismo escribió. Todo concuerda. Todas las revisiones pasan. No se ha verificado nada: tienes dos artefactos que se corroboran mutuamente, y ninguno se midió jamás contra la intención de nadie.

El fallo es silencioso, que es lo que lo hace caro. Una spec generada no parece generada. Tiene un párrafo de intención, criterios de aceptación plausibles y una sección de no-objetivos con tres entradas razonables, y ningún autor. Se lee como algo zanjado cuando nadie ha decidido nada, y carga con la autoridad de estar escrita, versionada y revisada en un pull request.

Seis meses después alguien construye contra AC4, y la respuesta honesta a «¿quién decidió esto?» es nadie.

Así que la decisión humana no es un detalle bonito en Eidos, ni una etapa que automatizar cuando mejore el tooling. Es el elemento estructural entero. Una spec vale exactamente tanta intención humana como se puso en ella, y una spec sin ninguna es peor que no tener spec, porque la versión que había en la cabeza de alguien al menos se sabía poco fiable.

Cuándo no usar Eidos

El corolario es tajante, y es más útil que otra funcionalidad:

Eso no es una crítica a trabajar así. Para un prototipo, algo desechable o una cosa cuyo único requisito es que funcione, es la decisión correcta, y la respuesta honesta es que una capa de specs sería teatro.

Eidos es para el caso en que alguien responde por lo que es la cosa. Donde una persona tiene que dar la cara por una decisión de alcance, defender una frontera o explicar dentro de un año por qué no cubre un caso que alguien da por supuesto. Si no hay nadie en ese asiento, el estándar no tiene nada a lo que agarrarse.

Qué no es

No es un generador de documentación. Nada se deriva de tu código. Un Blueprint lo escribe una persona que decidió algo.

No es una plantilla que rellenas. El estándar lo dice sin rodeos: si un Blueprint se lee como una plantilla rellenada, remodélalo hasta que se lea como algo que escribió alguien. El shape es un andamio para un documento vivo, no un formulario.

No es un producto que un agente escribe por ti. La persona escribe; el agente facilita. Consulta Trabajar con agentes: esto es una restricción de diseño, no una limitación esperando a levantarse.

No es un esquema rígido. Eidos no nombra ninguna colección, ningún shape y ninguna sección. Define la maquinaria (colecciones, shapes, flavors, propiedades) y tu Framework nombra todo lo demás. Un Framework que no se parece a ninguna de las semillas distribuidas está funcionando como debe.

Quién lo sostiene

Una persona: el Framework Owner. Sostiene la intención, el alcance y las decisiones.

Esta es la parte menos técnica y más estructural de Eidos. Una raíz sin dueño se convierte en un wiki con mejor formato: todo el mundo edita, nadie decide, y la sección de no-objetivos se vacía en silencio porque decir que no es la parte que requiere autoridad.

Inicio rápido: pon una raíz en disco.
Framework y Blueprint: las dos palabras sobre las que gira todo el estándar.