Glosario
Cada término tiene un ancla estable derivada de su nombre (en minúsculas, sin tildes y con guiones), por ejemplo /referencia/glosario/#delta-spec. Úsala para enlazar desde otras páginas.
Conceptos de OpenSpec
Sección titulada «Conceptos de OpenSpec»Spec-Driven Development, desarrollo guiado por specs: una especificación estructurada guía la implementación del agente de IA.
Documento en openspec/specs/<dominio>/spec.md que describe el comportamiento actual del sistema. Es la fuente de verdad.
Requirement
Sección titulada «Requirement»Regla de comportamiento dentro de una spec, redactada con palabras normativas como SHALL o MUST.
Scenario
Sección titulada «Scenario»Caso concreto de un requirement, con la forma WHEN / THEN (y opcionalmente GIVEN). Cada scenario debe tener un test automatizado.
Carpeta en openspec/changes/<nombre>/ con una propuesta de cambio: proposal, delta specs, design y tasks.
Delta spec
Sección titulada «Delta spec»Fragmento de spec dentro de un change que marca requisitos como ADDED, MODIFIED o REMOVED respecto a la spec principal.
Proposal
Sección titulada «Proposal»Artefacto proposal.md de un change: intención, alcance, enfoque y enlace al ticket de origen.
Artefacto design.md de un change con las decisiones técnicas y las alternativas descartadas.
Artefacto tasks.md de un change: checklist de implementación que el agente marca al completar cada tarea.
Archive
Sección titulada «Archive»Operación que fusiona las delta specs en openspec/specs/ y mueve el change a openspec/changes/archive/.
Definición de qué artefactos tiene un change y en qué orden se generan. El schema por defecto es spec-driven.
Conjunto de workflows que openspec init genera como comandos de chat: el perfil core o uno personalizado con openspec config profile.
Repositorio OpenSpec independiente registrado en la máquina, útil para compartir specs entre varios repositorios.
Gobierno del cambio
Sección titulada «Gobierno del cambio»Spec-first
Sección titulada «Spec-first»La spec se escribe antes de implementar, pero después manda el código y la spec envejece. Ver Gobierno del cambio.
Spec-anchored
Sección titulada «Spec-anchored»La spec ratificada sigue siendo normativa tras implementar; la deriva se controla con revisión y tests. Es la posición de OpenSpec, que trabaja por changes.
Spec-as-source
Sección titulada «Spec-as-source»La salida generada no se edita: se cambia la spec y se regenera el código. Exige regeneración repetible y detectar ediciones manuales.
Comprobación ejecutable más política obligatoria más bloqueo efectivo; por ejemplo, la validación de specs, el build y los tests registrados como requisito para fusionar en main. Un hook local no es una verja.
Trinquete
Sección titulada «Trinquete»Regla que permite avanzar sin dejar que la calidad retroceda; por ejemplo, que la cobertura de escenarios de un dominio no baje entre changes.
Cierre calculado
Sección titulada «Cierre calculado»Un change se da por cerrado cuando el sistema lo deduce de artefactos y resultados (matriz de cobertura completa, CI en verde sobre el mismo commit, aprobaciones presentes), no porque el agente lo declare.
Entorno y equipo
Sección titulada «Entorno y equipo»Model Context Protocol: protocolo para que el agente de IA acceda a herramientas externas como Jira o Azure DevOps.
Instrucciones empaquetadas que el agente carga cuando la tarea encaja; openspec init genera una por cada comando de chat del perfil.
Brownfield
Sección titulada «Brownfield»Proyecto existente, frente a greenfield (proyecto desde cero). En OpenSpec solo se escriben specs de lo que se toca.