QUALITY GATES

Quality Gates

7 GATES · 4 CAPAS

Validaciones obligatorias en cada fase del proceso. Ningún cambio avanza sin pasar el gate correspondiente.

Spec Gate

Specification LayerTech Lead + PO

Que el OpenSpec está completo y coherente antes de iniciar la implementación.

Checklist

✓proposal.md tiene motivación, alternativas y decisión documentada
✓design.md tiene arquitectura, modelo de datos y contratos API completos
✓tasks.md tiene tareas atómicas con criterios de done por tarea
✓specs/ tiene las especificaciones detalladas del feature
✓No hay referencias cruzadas rotas entre documentos
✓El PO revisó y aprobó el proposal.md

Evidencia requerida

docproposal.md aprobado con firma/fecha
docdesign.md revisado por Tech Lead
doctasks.md con estimaciones

Bloqueantes

✕proposal.md sin decisión documentada
✕design.md sin contrato API cuando el feature tiene endpoints
✕tasks.md sin criterios de done
✕Inconsistencias entre proposal y design

Architecture Gate

Specification LayerTech Lead

Que las decisiones de arquitectura son sólidas, consistentes con el sistema y no introducen deuda técnica innecesaria.

Checklist

✓La arquitectura es consistente con los patrones del sistema existente
✓El modelo de datos tiene tipos, índices y relaciones definidas
✓Las migraciones de base de datos están documentadas
✓Los endpoints tienen request/response/errores completos
✓Los edge cases de integración están cubiertos
✓No hay componentes nuevos sin justificación

Evidencia requerida

docarquitectura.md con diagrama
docmodelo_datos.md con DDL o definición de entidades
doccontrato_api.md completo

Bloqueantes

✕Cambios al modelo de datos sin estrategia de migración
✕Nuevos servicios sin documentar su integración
✕Contratos API sin manejo de errores
✕Dependencias externas sin evaluación de riesgo

Security Gate

Quality LayerTech Lead + Security reviewer

Que el feature no introduce vulnerabilidades de seguridad ni expone datos sensibles.

Checklist

✓Los endpoints tienen autenticación y autorización definidas
✓No se exponen datos sensibles en responses ni logs
✓Las entradas del usuario son validadas y sanitizadas
✓No hay secretos hardcodeados en el código
✓Los permisos por rol están correctamente implementados
✓Las queries a base de datos usan parámetros (no interpolación)

Evidencia requerida

docRevisión de seguridad documentada
docLista de endpoints con su nivel de acceso
docReporte de análisis estático si aplica

Bloqueantes

✕Endpoints sin autenticación en rutas protegidas
✕PII expuesta en logs o responses
✕SQL/NoSQL injection posible
✕Secretos en código fuente

Testing Gate

Quality LayerQA Agent + Tech Lead

Que el feature tiene cobertura de pruebas suficiente para los flujos críticos y criterios de aceptación.

Checklist

✓Todos los criterios de aceptación tienen al menos un caso de prueba
✓Los happy paths están cubiertos con tests automatizados
✓Los casos de error y edge cases tienen tests
✓Los tests de integración cubren las llamadas a servicios externos
✓No hay tests que pasen por coincidencia (flaky tests)
✓El plan de pruebas está diligenciado y ejecutado

Evidencia requerida

docplan_pruebas.md ejecutado
docreporte_pruebas.md con resultados
docCobertura de código (si aplica al proyecto)

Bloqueantes

✕Criterios de aceptación sin caso de prueba
✕Tests fallando en CI
✕Happy path sin test automatizado
✕Reporte de pruebas vacío o sin evidencia

Code Review Gate

Quality LayerCode Review Agent + 1 peer developer

Que el código implementado es correcto, legible, y consistente con las especificaciones y estándares del proyecto.

Checklist

✓El código implementa lo que describe el design.md
✓No hay lógica de negocio hardcodeada sin referencia a especificación
✓El código sigue los patrones y convenciones del proyecto
✓No hay código muerto ni imports no usados
✓Los errores se manejan correctamente y se loggean apropiadamente
✓El checklist_pr.md está completamente diligenciado

Evidencia requerida

docchecklist_pr.md completo
docAprobación de al menos 1 reviewer
docCI pasando

Bloqueantes

✕Blocking comments sin resolver
✕CI fallando
✕Código que no implementa lo especificado en design.md
✕checklist_pr.md incompleto

UAT Gate

Quality LayerPO + Usuario representativo

Que el feature funciona correctamente desde la perspectiva del usuario final o PO en ambiente staging.

Checklist

✓El feature está desplegado en staging y accesible
✓El PO validó los flujos principales contra los criterios de aceptación
✓Los usuarios representativos probaron los casos de uso del día a día
✓Los bugs encontrados en UAT están documentados y priorizados
✓Los bugs bloqueantes están resueltos antes del release
✓La evidencia de UAT está documentada

Evidencia requerida

docevidencia_uat.md con capturas o videos
docAprobación explícita del PO
docLista de bugs encontrados y su estado

Bloqueantes

✕PO no ha validado el feature
✕Bugs bloqueantes sin resolver
✕Feature no desplegado en staging
✕Criterios de aceptación sin validar en ambiente real

Release Gate

Delivery LayerTech Lead + Release Agent

Que el feature está listo para ir a producción con toda la evidencia, documentación y plan de rollback.

Checklist

✓Todos los gates anteriores están aprobados
✓Las release notes están escritas y aprobadas por el PO
✓El CHANGELOG está actualizado
✓El plan de rollback está documentado
✓Las variables de entorno de producción están configuradas
✓El equipo de soporte está informado del cambio
✓La validación post-deploy tiene un checklist definido

Evidencia requerida

docrelease_notes.md aprobado
docCHANGELOG actualizado
docchecklist_pr.md con todos los gates marcados
docPlan de rollback documentado

Bloqueantes

✕Cualquier gate anterior sin aprobar
✕release_notes.md sin aprobación del PO
✕Sin plan de rollback para features de alto riesgo
✕Variables de entorno de producción sin verificar