# Checklist: Quality Gate para Specs

> **Propósito:** Validar que el spec está completo y no tiene ambigüedades antes de pasarlo a ingeniería. Si hay ítems sin marcar, el spec no está listo.
> **Cuándo usarlo:** Como quality gate obligatorio, justo antes de compartir cualquier spec con el equipo técnico.
> **Cómo usarlo:** Copia este archivo junto al spec a validar, marca cada criterio (☐ → ☑) leyendo el spec con ojos de escéptico, y registra el resultado final.

## Metadatos

- **Spec Reference:** [Link al spec a validar]
- **Revisor:** [Nombre]
- **Fecha:** [YYYY-MM-DD]
- **Resultado:** [PASA / NO PASA — corregir antes de enviar]

---

## Content Quality

- [ ] Sin detalles de implementación (lenguajes, frameworks, APIs específicas)
- [ ] Enfocado en valor de usuario y necesidades de negocio
- [ ] Escrito para stakeholders no técnicos (cualquier persona puede entenderlo)
- [ ] Todas las secciones obligatorias del template están completas
- [ ] El título describe el resultado, no la solución (ex. "El paciente agenda su cita", no "Calendario de citas")

---

## Requirement Completeness

- [ ] No hay marcadores `[NEEDS CLARIFICATION]`, `[PENDIENTE]` o `TBD` sin resolver
- [ ] Los requisitos funcionales son comprobables (pasa/falla, no "mejorar" o "optimizar")
- [ ] Los criterios de éxito son medibles (números, porcentajes, tiempos)
- [ ] Los casos borde están identificados (al menos 3)
- [ ] El alcance está claramente delimitado (sección "Lo que NO está incluido" completa)
- [ ] Las dependencias y suposiciones están identificadas

---

## Feature Readiness

- [ ] Todos los requisitos funcionales tienen criterios de aceptación claros
- [ ] Los escenarios de usuario cubren los flujos principales (P1, P2, P3)
- [ ] La feature cumple con los resultados medibles definidos en Criterios de Éxito
- [ ] Los Key Entities están identificados (qué datos se crean/modifican/eliminan)
- [ ] El spec pasa la prueba del LLM: un asistente de IA genera tareas coherentes sin alucinar

---

## Negocio / Stakeholder

- [ ] El problema está definido desde la perspectiva del usuario, no del sistema
- [ ] Hay una métrica de éxito vinculada a un KPI de negocio
- [ ] El costo de no hacer esto está identificado
- [ ] Hay una persona accountable que decide si esto se lanza o no

---

## Decisión Final

| Criterio | Estado |
|----------|--------|
| ¿Todos los ítems de Content Quality están marcados? | Sí / No |
| ¿Todos los ítems de Requirement Completeness están marcados? | Sí / No |
| ¿Todos los ítems de Feature Readiness están marcados? | Sí / No |
| **¿El spec pasa a la fase de Plan?** | **Sí / No** |

**Notas del revisor:**

[Espacio para observaciones, preguntas o cambios solicitados antes de aprobar]