Planificar antes de programar se volvió el estándar del mercado. Lo que ninguna herramienta entrega es lo que viene después del plan: verificación mecánica de que el proceso se siguió — contratos firmados por story, sensores ejecutables y evidencia en cada afirmación.
ENTREGADO COMO KIT .SDD/ DENTRO DE LOS DOS PRODUCTOS — LAUDO Y CREAR SPEC
Tres fuerzas convergieron entre 2025 y 2026 — y convirtieron la especificación gobernada de buena práctica en requisito.
Cuando una funcionalidad cuesta minutos de agente, el cuello de botella migra del teclado a la intención. Describir vagamente y aceptar lo que venga produce código plausible que se aleja de la intención y envejece mal.
Un agente que abre un repositorio necesita saber qué ya se decidió, qué está prohibido y cómo se prueba que algo está listo. Sin eso, cada sesión reinventa el proyecto.
Código escrito por IA en producción exige un rastro: de dónde vino cada cambio, qué evidencia lo sustentaba, quién lo aprobó. El SDD es la infraestructura de ese rastro.
Dentro del kit viaja código Python (stdlib pura — corre en cualquier máquina con python3) que convierte la gobernanza de recomendación en mecanismo.
18 reglas de integridad sobre el propio .sdd — story sin sección obligatoria, contrato excedido, afirmación presumida sin rastreo de validación. Un kit nuevo abre 100% verde.
El hook BLOQUEA a quien implementó de marcar como listo o llenar su propia evidencia de QA. No es "el agente debería" — es "el agente no puede".
El registry de sensores es dato ejecutable: cada uno con comando, criterio y bandera bloqueante. QA no aprueba una story sin exit 0.
El estado del proyecto se GENERA de los frontmatters de las stories — y la verificación acusa la edición manual.
El canon de calidad llega fijado por versión y hash, con verificación de cadena completa. Actualizar exige confirmación humana.
40 saboteadores, uno por regla de sensor — prueba mecánica de que cada sensor mira de verdad, no pasa por vacuidad.
El único juez no-determinístico (deriva spec×código) está cercado: rúbrica explícita, calibración ciega — sin calibración válida, sin veredicto.
Conversores bidireccionales Spec Kit / OpenSpec / Kiro, con pérdida documentada en cada archivo convertido. Entrada y salida sin encierro.
+ una Constitution de 25+1 artículos con enforcement mapeado en 24/26 — cada artículo señala el mecanismo que lo impone; los 2 sin mecanismo están marcados como decisión registrada, no como olvido.
En las dos primeras filas el mercado empató — todos escriben especificaciones. De la línea gruesa hacia abajo, estamos solos.
| Capacidad | Spec Kit | Kiro | OpenSpec | BMAD | Tessl | ArchGenerator |
|---|---|---|---|---|---|---|
| Especificación antes del código | ● | ● | ● | ● | ● | ● |
| Roles multi-agente | ◐ | — | — | ● | ◐ | ● 27 |
| Autoridad impuesta por mecanismo (hooks) | — | — | — | — | — | ● |
| Contratos de implementación firmados | — | — | — | — | — | ● |
| Sensores ejecutables con registry en datos | — | — | — | — | — | ● |
| Evidencia graduada por afirmación [A]/[P]/[Q] | — | — | — | — | — | ● |
| Proceso que se verifica a sí mismo (mutantes) | — | — | — | — | — | ● 40 |
| Canon versionado con hash | — | — | — | — | ◐ | ● 17 |
| Especificación nacida del diagnóstico del código real | — | — | — | — | — | ● |
| Interoperabilidad bidireccional entre formatos | — | — | — | — | — | ● |
| Open-source / comunidad | ● | ◐ | ● | ● | ◐ | — |
● SÍ · ◐ PARCIAL · — NO
La última fila es debilidad honesta: ellos tienen distribución y comunidad; nosotros tenemos profundidad — y hablamos con sus herramientas en las dos direcciones.
Todo competidor parte de una descripción en lenguaje natural. Nuestro kit nace de un diagnóstico del repositorio real — validado en producción en un repositorio público.
stories ejecutables — críticos con cláusula de hotfix y el guardrail que impide que el agente refactorice de paso
detalles de hallazgo con la evidencia del laudo transcrita, advisory por advisory
sensor de dependencias EJECUTABLE de fábrica — generado de los lockfiles reales del repositorio
hallazgos con evidencia presumida se vuelven preguntas: validar antes de corregir
El equipo del cliente — o el agente de código del cliente — abre el kit, corre el bootstrap y tiene orden de ataque, evidencia y criterio de listo. Sin una reunión de planificación.
Laudo → kit de remediación: stories priorizadas con hotfix primero, evidencia transcrita, gate de dependencias listo — y la cláusula que impide que el junior (o el agente) refactorice de paso.
Rastro completo por construcción: contrato firmado → evidencia citable → sensor verde → aprobación independiente impuesta por hook. Ninguna otra herramienta produce ese rastro.
El laudo señala, el kit ejecuta: la distancia entre el PDF y el backlog ejecutable es un clic. Una categoría que no existe entre los competidores — ninguno tiene motor de diagnóstico del cual partir.
Mientras el mercado compite por quién escribe la mejor especificación antes del código, ArchGenerator entrega la única que llega cargada de evidencia del código real, con un proceso que se verifica solo — y que además habla con las herramientas de los competidores en las dos direcciones.
La doctrina de calidad que lleva el kit no es caja negra: el registry sdd-canon es público, versionado, con hash por archivo y licencia declarada en cada regla.
17 dimensiones ancladas en estándares públicos (WCAG, CWE Top 25, OWASP, Well-Architected) + rulepack SAST de 291 reglas de 8 fuentes permisivas.
Quien ya usa Spec Kit, OpenSpec o Kiro entra y sale con pérdida declarada — sin encierro.
Actualizar el canon en el kit exige confirmación humana — un agente nunca pasa solo.
Un laudo de tu repositorio se convierte en un kit ejecutable — con las stories, los sensores y la evidencia de tu sistema, no de un ejemplo.