CÓMO FUNCIONA

De una petición inicial a una iteración cerrada, validada y con evidencia.

SPEC-IA transforma una petición inicial en requisitos, contexto, backlog, validación, ejecución, pruebas y cierre. Todo queda conectado en un ciclo trazable.

FASES

Cada fase del sistema

FASE

SPEC

La intención se convierte en verdad funcional. spec.md define requisitos, reglas y criterios; context.md añade el marco técnico sin inventar comportamiento.

Entrada
Documentos de análisis, briefings, decisiones de producto, reportes de bugs, historias de usuario, peticiones de nuevas funcionalidades o código legacy
Salida
Documento con RF, RB, RNF y CA versionados
Evidencia
Especificación y contexto técnico trazables
Bloqueo posible
Si una decisión es ambigua, abre o mantiene un GAP, lo que genera unas especificaciones con la menor ambigüedad posible
spec.md 
SPEC
│
├── QUÉ QUEREMOS
│   └── Alcance del producto
│   └── Reglas de negocio
│   └── Requisitos funcionales
│   └── Requisitos no funcionales
│   └── Criterios de aceptación
│
├── QUÉ NO VAMOS A HACER
│   └── Fuera de alcance
│
└── QUÉ FALTA POR DECIDIR
    └── SPEC-GAPS
context.md 
CONTEXT
│
├── ESTADO ACTUAL
│   └── Qué hay ahora
│
├── ARQUITECTURA
│   └── Cómo está organizado y qué tecnologías usa
│
├── TESTING
│   └── Cómo se valida técnicamente
│
└── GAPS
    └── Qué falta saber o decidir
FASE

BACKLOG

backlog.md traduce la verdad funcional en trabajo pequeño, priorizado y verificable. Cada tarea declara origen, dependencias, aceptación y evidencia esperada.

Entrada
Requisitos activos y contexto técnico aprobado
Salida
Tareas pequeñas, priorizadas y vinculadas a los requisitos que las originan, con estado, dependencias y evidencia esperada.
Evidencia
Dependencias y trazabilidad inversa
backlog.md 
BACKLOG
│
├── QUÉ HAY QUE HACER
│   └── Tareas
│
├── CÓMO SE AGRUPA
│   └── Épicas
│
├── EN QUÉ ORDEN
│   └── Prioridades y dependencias
│
├── EN QUÉ ESTADO ESTÁ
│   └── Todo / En progreso / Done / Bloqueado
│
└── DE DÓNDE VIENE
    └── Trazabilidad con SPEC / CONTEXT / CONTENT / DESIGN
GATE

VALIDATOR

Antes de planificar, el Validator hace de control de coherencia. Revisa que lo que pide el backlog salga de una necesidad real, que el contexto técnico no contradiga la especificación, que las dependencias están listas y que nadie tenga que inventar una decisión que todavía falta.

Decisión
VALID permite continuar. VALID_WITH_WARNINGS permite avanzar dejando riesgos claros. INVALID detiene la iteración hasta corregir la incoherencia.
Evidencia
Un informe simple: qué artefactos se revisaron, qué checks pasaron, qué avisos o errores hay y por qué se puede planificar o no.
RF citado por TASK - PASS Referencia CONTEXT existe - PASS Dependencias resueltas - PASS Tarea inventada: no detectada - PASS

BUILD - TEST - CLOSE

La IA ejecuta. El sistema gobierna.

FASE

BUILD

El Orchestrator elige una porción pequeña y trazable. El Developer implementa solo ese alcance, con el contexto técnico y sin inventar requisitos, copy ni interfaz.

ORCHESTRATOR -> DEVELOPER
GATE

TEST

El Tester valida contra el alcance planificado, los criterios de aceptación y la evidencia. Si falta prueba fiable, puede aprobar con warnings, fallar o bloquear.

TESTER - PASS / FAIL / BLOCKED
CIERRE

CLOSE

El cierre sincroniza el resultado real: tarea, evidencia, backlog y épica. Una épica solo queda DONE si todas sus tareas hijas también lo están.

CLOSE -> BACKLOG ACTUALIZADO

GAPS

Las decisiones pendientes no se pierden.

Cuando una decisión no está clara, SPEC-IA no la inventa: la convierte en un GAP explícito. Las skills SDD ayudan a analizar el impacto, comparar opciones y cerrar la decisión en el artefacto correcto, sin rellenar el proyecto con suposiciones.

SPEC-GAP-003 - falta regla funcional CONTEXT-GAP-002 - falta decisión técnica

SPEC-IA

LA IA EJECUTA. EL SISTEMA GOBIERNA.

Ver el piloto Evaluar la madurez