La especificación orienta.
El proceso verifica.
El Kit SDD conecta especificaciones con historias, contratos y verificaciones ejecutables. Ayuda a tus equipos y agentes de código a seguir lo acordado y a dejar evidencias de cada entrega.
KIT .SDD/ A PARTIR DE INFORMES COMPATIBLES O DE CREAR SPEC
Referencia del Kit SDD 3.1.0. Roles y dimensiones comprobados en el código. Resultados de mutación, aplicación de reglas y calibración documentados el 13/08/2026.
Por qué ahora
Tres fuerzas convergieron entre 2025 y 2026 — y convirtieron la especificación gobernada de buena práctica en requisito.
Generar código se volvió barato. Generar el código correcto, no.
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.
Los agentes necesitan memoria de proceso.
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.
La auditabilidad se volvió requisito de negocio.
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.
De la especificación a la verificación
El kit incluye herramientas en Python, basadas en la biblioteca estándar, para comprobar el proceso dentro del repositorio.
Verificaciones de integridad del propio .sdd: secciones obligatorias, límites de los contratos y trazabilidad de las afirmaciones que aún necesitan validación.
Cuando el entorno admite los hooks, se restringe que quien implementó apruebe su propio trabajo o complete las evidencias de QA. Los roles y sus límites quedan explícitos.
El registry de sensores es dato ejecutable: cada uno con comando, criterio y bandera bloqueante. QA no aprueba una historia de usuario sin exit 0.
El estado del proyecto se genera a partir de los metadatos de las historias. La verificación detecta cambios manuales en ese estado.
El canon de calidad llega fijado por versión y hash, con verificación de cadena completa. Actualizar exige confirmación humana.
40 fallos deliberados, uno por regla de sensor, comprueban que las verificaciones detecten los problemas para los que fueron diseñadas.
El evaluador que detecta desviaciones entre la especificación y el código sigue criterios explícitos y una calibración ciega. No puede emitir una evaluación sin una calibración válida.
Conversores bidireccionales para Spec Kit, OpenSpec y Kiro. Cada archivo convertido documenta la información que no se conserva, para poder cambiar de herramienta con conocimiento de los límites.
+ una Constitución de 25+1 artículos, con mecanismos de verificación identificados para 24/26. Cada artículo indica su mecanismo. Los dos restantes constan como decisiones documentadas.
Cómo evaluar un enfoque SDD
Además de escribir especificaciones, conviene preguntar cómo cada herramienta conecta contexto, implementación y verificación. Estos criterios orientan el Kit SDD de ArchGenerator.
| Qué evaluar | Cómo lo aborda ArchGenerator |
|---|---|
| Especificación antes del código | Especificaciones, criterios de aceptación y plan de ejecución antes de implementar. |
| Roles multi-agente | Roles separados para planificar, implementar, revisar y aprobar. |
| Autoridad impuesta por mecanismo (hooks) | Los hooks limitan las acciones según el rol responsable. |
| Contratos de implementación firmados | Cada historia tiene un contrato con alcance, entregables y verificaciones. |
| Sensores ejecutables con un registro estructurado | sensors.yaml registra comandos, criterios y condiciones de bloqueo. |
| Evidencia graduada por afirmación [A]/[P]/[Q] | Cada afirmación distingue entre evidencias, hipótesis y preguntas pendientes. |
| Proceso que se verifica a sí mismo (mutantes) | Las pruebas de mutación comprueban si los sensores detectan fallos introducidos deliberadamente. |
| Canon versionado con hash | canon.lock fija la versión y los hashes de las referencias de calidad. |
| Especificación nacida del diagnóstico del código real | Los hallazgos del repositorio se incorporan a las historias, evidencias y verificaciones. |
| Interoperabilidad bidireccional entre formatos | Importación y exportación para Spec Kit, OpenSpec y Kiro, con limitaciones de conversión documentadas. |
| Open-source / comunidad | El registro sdd-canon es público; la plataforma ArchGenerator es un producto comercial. |
El ecosistema sigue evolucionando. Comprueba las funciones disponibles en la versión que utiliza tu equipo y elige los mecanismos adecuados para tu contexto.
Explora también la documentación oficial de otros enfoques:
De los hallazgos del repositorio al trabajo ejecutable.
El kit también puede partir del diagnóstico de un repositorio real. Este ejemplo documentado conecta hallazgos de seguridad con historias y verificaciones de corrección.
historias ejecutables: las vulnerabilidades críticas incluyen una cláusula de corrección urgente y límites que evitan refactorizaciones fuera de alcance
detalles de cada hallazgo con sus evidencias y los avisos de seguridad correspondientes
sensor de dependencias listo para ejecutarse, generado a partir de los archivos de bloqueo del repositorio
los hallazgos basados en hipótesis se convierten en preguntas que deben validarse antes de corregir
Tu equipo o agente de código abre el kit, ejecuta la inicialización y recibe las prioridades de trabajo, las evidencias y los criterios de finalización.
Tres situaciones reales
"Heredé un sistema legado con decenas de vulnerabilidades y un equipo junior."
Informe → kit de remediación: historias de usuario 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.
"La auditoría preguntó cómo gobernamos el código generado por IA."
Contratos por historia, evidencias consultables, sensores ejecutables y revisión independiente: un registro del proceso que ayuda a responder a la auditoría.
"El consultor entregó el diagnóstico y se fue — ¿y ahora?"
El informe puede convertirse en un kit de implementación con prioridades, evidencias y criterios de aceptación. Tus equipos reciben un punto de partida para ejecutar las recomendaciones.
El Kit SDD conecta la especificación y las evidencias del código con un proceso verificable, conservando la interoperabilidad con las herramientas de tu equipo.
El canon es público
El canon de calidad del kit es público: sdd-canon es un registro versionado, con un hash por archivo y una licencia declarada para cada regla.
17 dimensiones de calidad basadas en referencias públicas (WCAG, CWE Top 25, OWASP, Well-Architected), con un conjunto versionado de reglas SAST de fuentes con licencias permisivas.
Los equipos que ya usan Spec Kit, OpenSpec o Kiro pueden importar y exportar contenido, con las pérdidas de información documentadas.
Actualizar el canon del kit requiere confirmación humana. Un agente no puede aprobar esa actualización por su cuenta.
Mira el kit nacer de tu propio código.
En los informes compatibles y con la función habilitada, las recomendaciones de tu repositorio pueden convertirse en un kit ejecutable, con historias de usuario, criterios y verificaciones basados en las evidencias del sistema.