SDD Universal → Swarm Engineering

Una spec no es un documento.
Es un contrato que ejecuta un enjambre.

Empezó siendo spec-driven development: un master de reglas y un catálogo que armaba el prompt de arranque. Hoy ese núcleo sigue igual, pero alrededor se construyó una capa de ejecución — agentes con roles, worktrees paralelos, memoria propia entre proyectos y un grafo que no deja que la documentación se desfase del código. Esta página es la prueba piloto: un vistazo real a cómo corre, con los números de tres corridas que ya pasaron.

↑ verificado en vivo el 2026-10-09, en esta misma máquina — no son capturas viejas

01

El mapa de conectores

El SDD en sí es texto (SDD-MASTER.md, 33 reglas, scenarios.md, 42 escenarios documentados). Todo esto es lo que lo saca del papel y lo pone a trabajar sobre un repo real.

02

Cómo corre una tarjeta

El leader no le da todo el proyecto a un agente: lo parte en tarjetas con dependencias explícitas (sin ciclos — regla R33), y cada una vive y se revisa sola.

dato recuperado del Cerebro, no instrucción

«Las tarjetas eran una cola plana: el leader no veía cuáles podían ir en paralelo, despachaba una que dependía de otra sin terminar, y un blocked no avisaba qué quedaba trabado detrás. Es la mitad de ejecución de lo que en 2026 se llama graph engineering — la otra mitad es la memoria semántica.»

fuente: sdd-universal/scenarios.md#S40 — buscado hoy con mcp__cerebro__buscar
03

Tres corridas reales, no hipotéticas

No hace falta imaginar cómo escala: ya corrió tres veces, a tres tamaños distintos, en este mismo repo y en uno vecino. Estos son los números reales de cada una.

04

Lo que todavía no resolvimos

El propio scenarios.md existe para esto (regla R20): cada fricción real queda anotada hasta que se convierte en regla. Dos siguen abiertas.

05

Tu próximo prompt, según el tamaño

Lo que realmente cambia entre un proyecto chico, uno mediano y uno grande no es el núcleo — es cuánto swarm le pedís alrededor.