Casos de uso

Eidos es para cualquiera que necesite un sistema de organización con adherencia: un lugar donde la definición de lo que estás construyendo se escribe una vez, se mantiene cierta y la lee cada persona y cada agente que trabaja en ello. La recompensa es velocidad. Cuando la definición se sostiene, nadie la vuelve a explicar, nadie discute de memoria, y a un agente se le puede señalar y confiar en que se mantendrá dentro.

Un producto de software

Un equipo que construye una app mantiene un Blueprint (el plano) por funcionalidad: qué es, por qué existe, qué cuenta como terminado, qué queda fuera del alcance. Cada spec nace del mismo template (la plantilla), lleva las mismas propiedades y se comprueba contra el Framework (el marco) que el equipo escribió. El trabajo ocurre en otro sitio, en un backlog de tareas que apuntan al Blueprint al que sirven, así que la definición nunca se llena de sprints y estimaciones.

Alguien que se incorpora lee la raíz y conoce el producto en una tarde.
Un agente de código ejecuta eidos instructions, lee el Blueprint que está implementando y escribe código que lo cumple, porque hay exactamente un lugar donde vive la respuesta.
Un product manager cambia la definición en el Blueprint, y el cambio es un commit que todos ven, con la discusión al lado.
Una release es una versión: un nombre para un commit de la raíz, de modo que lo prometido pueda leerse después exactamente como estaba.

La semilla de software → · Agentes →

Alguien que construye solo, con agentes

Una persona, varios agentes y un producto que crece más rápido que la memoria. La raíz es la memoria: cada sesión empieza leyendo los Blueprints que importan, cada cambio en la definición va a un archivo que leerá la siguiente sesión, y la comprobación avisa cuando un Blueprint se aleja del Framework. El navegador es donde la persona piensa, sobre un lienzo de bocetos que se promueven a Blueprints, y donde se le pregunta al agente, a través de Plato, con el Blueprint abierto como contexto.

Un estudio o una agencia

Un Framework es reutilizable. Un estudio escribe uno para el tipo de producto que construye, lo publica en el Registro y lo instala en el repositorio de cada nuevo cliente con un solo comando. A partir de ahí cada proyecto se lee igual, cada spec tiene la misma forma, y una persona que pasa de un cliente a otro nunca vuelve a aprender la estructura. El cliente da el visto bueno a Blueprints, no a una presentación, y el estado aprobado es una versión.

El Registro → · eidos install →

Un libro, un estudio, un cuerpo de trabajo

El mismo sistema sostiene cualquier cosa con partes que deban concordar. Un libro son capítulos y personajes que se mantienen coherentes a lo largo de un manuscrito; un programa de investigación son investigaciones que comparten un método y un vocabulary (vocabulario). Las semillas de ambos vienen con la CLI, y el Framework es tuyo para remodelarlo.

La semilla de libro → · La semilla de investigación →

Lo que obtienes en cualquier caso

Adherencia

Un Framework en .eidos/ contra el que se comprueba cada Blueprint. La deriva se informa, nunca se acepta en silencio.

Una sola fuente de verdad

Un archivo markdown por unidad del producto, en tu repositorio, tan cierto para lo planeado como para lo entregado.

Velocidad

El andamiaje, la validación, un índice, un navegador y el flujo con agentes son un solo comando. El pensamiento es tuyo; la mecánica no.

Utilidad para agentes

Una raíz que un agente puede leer, citar y no abandonar. La guía es un comando, no un prompt que alguien tenga que recordar.

Inicio rápidoInstala la CLI, crea una raíz, escribe tu primer Blueprint.

Por qué existe EidosEl problema que resuelve, y cuándo no usarlo.