Spec Kit: de intención comprobable a aceptación trazable
Arquitectura de Spec Kit: intención, precedencia de plantillas y órdenes instaladas
Distingue los artefactos de funcionalidad, la resolución de plantillas en ejecución y los archivos de instrucciones de cada integración.
Qué aprenderás
- Separar intención de producto e instrucciones del proceso
- Selección e instalación ocurren en momentos distintos
- Elegir componentes por responsabilidad
Antes de empezar
- Conceptos básicos de requisitos, Git y pruebas
- Distinguir desarrollo local y despliegue de aplicación
Trazar una funcionalidad desde intención hasta evidencia y separar contratos de comportamiento verificado.
Conclusiones clave
- La intención de la funcionalidad no es la plantilla del proceso.
- Resolver plantillas difiere de instalar órdenes.
- La configuración efectiva importa más que la presencia del paquete.
Separar intención de producto e instrucciones del proceso
La especificación, el plan y las tareas describen qué se construye. Plantillas e instrucciones describen cómo producir y evaluar ese material. La constitución aporta restricciones. Mezclar esas capas dificulta el diagnóstico: cambiar una plantilla no valida retroactivamente las especificaciones existentes.
Por ejemplo, un requisito de privacidad pertenece a la intención y a los principios pertinentes. Un preset puede exigir una sección de privacidad en futuros documentos, pero tener esa sección no impone el comportamiento en ejecución. Revisa tanto el contenido como su implementación necesaria.
Selección e instalación ocurren en momentos distintos
El README ordena la precedencia como overrides locales, presets, extensiones y plantillas centrales. Indica resolución de plantillas en ejecución, pero aplicación de órdenes de extensiones y presets a directorios del agente durante instalación. Eso explica por qué editar un archivo no siempre cambia una orden ya instalada.
No deduzcas todo el algoritmo de composición de ese resumen. La entrada Python inspeccionada delega la resolución en auxiliares comunes y procesa contenido o errores. No ejecutamos ni auditamos el motor completo de precedencia y composición en esta revisión.
Elegir componentes por responsabilidad
Las extensiones añaden capacidades; los presets personalizan material existente; los bundles agrupan componentes para un rol. Un override local puede resolver un ajuste de un solo proyecto. Cada capa adicional exige registrar configuración efectiva y procedencia de las instrucciones, no únicamente paquetes instalados.
Ante un resultado inesperado, identifica el artefacto generado, la plantilla efectiva, la orden instalada y la integración antes de cambiar algo. Una plantilla central más reciente no necesariamente vence a un override intencionado; reinstalar a ciegas puede ocultar la causa.
Cómo elegir
| Criterio | Opción A | Opción B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Pasos de implementación
- 1
Localiza artefacto y restricciones.
- 2
Identifica overrides y personalizaciones instaladas.
- 3
Inspecciona la orden efectiva de la integración.
- 4
Registra la plantilla realmente utilizada.
Ejemplo para copiar
{
"diagnostico": true,
"artefacto": "spec.md",
"prioridadDocumentada": [
"proyecto",
"presets",
"extensiones",
"núcleo"
],
"fuenteEfectiva": null,
"ordenActualizadaComprobada": false,
"resolverCompletoProbado": false
}Preguntas frecuentes
¿Editar la plantilla central siempre cambia el resultado?
No necesariamente; puede haber un override de mayor prioridad.
¿Se probó el resolver completo?
No. Se inspeccionó la entrada y el contrato del README, no todo el motor.
Fuentes
- Spec Kit / README.mdFuente verificada 2026-09-14
- Spec Kit / scripts/python/resolve_template.pyFuente verificada 2026-09-14
- Spec Kit / templates/commands/converge.mdFuente verificada 2026-09-14