Exit Criteria: el Gate Review

El Context Phase no está completo cuando los documentos parecen pulidos. Está completo cuando los outputs del sistema (Agentes ejecutando Skills bajo Reglas) son reconocidos como correctos por los stakeholders que definieron el problema y la solución.

Gate 3 → 4: Condiciones de paso

• ✅ Los outputs de prueba (Agentes ejecutando Skills bajo Reglas) son reconocidos como correctos por stakeholders de las Fases 1 y 2. Pueden mirar el output y decir: "Sí, esto es una expresión fiel de lo que acordamos."
• ✅ Las Reglas pasan la regla de las tres lecturas: un Agente que lea solo el project-context.md puede responder: ¿Qué tecnologías uso? ¿Qué no puedo hacer? ¿Cuál es la convención para cualquier patrón recurrente?
• ✅ Cada Agente tiene los cinco elementos obligatorios: identidad, responsabilidades, límites, referencia a Reglas y protocolo ante gaps.
• ✅ Cada Skill pasa el test de autocontención: un Agente con el Skill + project-context.md puede completar la tarea sin preguntar nada.
• ✅ El PRD tiene trazabilidad total a los artefactos de las Fases 1 y 2. Cada sección traza al Problem Statement o al Solution Brief.
• ✅ El Architecture Document incluye ADRs y ha generado Reglas globales en el project-context.md.
• ✅ El QA Agent ha validado cada documento de la cadena: fidelidad a inputs, completitud, consistencia con Reglas.
• ❌ No se avanza si los outputs de prueba no son reconocidos como fieles al Problem Statement y al Solution Brief.
• ❌ No se avanza si hay Skills que dependen de contexto implícito no presente en las Reglas ni en el propio Skill.
• ❌ No se avanza si hay Reglas implícitas que no están en el project-context.md. Si el equipo "sabe" algo pero no está documentado, no existe para los Agentes.

Estos Exit Criteria existen porque el Context Phase es el último checkpoint antes de la construcción. Cada gap que pase este gate se convierte en Context Debt invisible durante la Fase 4: los Agentes toman decisiones confiadas basadas en información incompleta, produciendo outputs que parecen correctos pero no son fieles a lo que los stakeholders acordaron.

La pregunta de validación

La pregunta fundamental en el Gate Review no es "¿Los documentos están completos?", es "¿Los outputs son correctos?"

Esta distinción importa. Un project-context.md puede parecer exhaustivo, las Definiciones de Agentes pueden lucir bien estructuradas y los Skills pueden parecer detallados. Pero la única prueba real es ejecutar el sistema y evaluar lo que produce. Los documentos son el medio; los outputs son la evidencia.

La validación funciona así:

1. Seleccionar 3-5 Skills representativos que cubran diferentes áreas del proyecto.
2. Hacer que los Agentes correspondientes los ejecuten bajo las Reglas actuales.
3. Presentar los outputs a los stakeholders, las mismas personas que validaron el Problem Statement y el Solution Brief.
4. Preguntar: "¿Es esto reconocible como una expresión fiel de lo que acordamos?"
5. Si sí para todas las muestras: el sistema de contexto está validado.
6. Si no para alguna muestra: diagnosticar dónde está el fallo (Reglas, Agente, Skill o interacción) e iterar.

Después del gate: transición a la Fase 4

Cuando el equipo completa el Gate Review, el proyecto transiciona del diseño a la ejecución. Pero a diferencia de proyectos tradicionales, la fase de construcción no empieza con un briefing, empieza con un sistema operativo completo.

Cada Agente de desarrollo ya sabe:

• Qué tecnologías usar (Reglas, Sección 2)
• Qué convenciones seguir (Reglas, Sección 3)
• Qué está prohibido (Reglas, Sección 4)
• Qué decisiones se tomaron y por qué (Reglas, Sección 8)
• Qué hacer cuando falta información (Reglas, Sección 7)

Y cada Skill que ejecutarán contiene:

• Qué lograr (Objetivo)
• Qué necesitan saber (Contexto específico)
• Cómo saber que terminaron (Criterios de aceptación)
• Qué debe estar completo antes (Dependencias)
• Qué límites adicionales aplican (Restricciones)

Por esto, con un sistema de contexto bien diseñado, la construcción tiende a ser la fase de menor coste y menor fricción. El trabajo duro se hizo en las Fases 1-3. La Fase 4 es ejecución.

El contexto no se congela

Pasar el Gate Review no significa que el contexto se congele. Durante la Fase 4, el contexto continúa evolucionando:

• La construcción revela ambigüedades → se refinan Skills.
• Una decisión local durante un Skill debería ser global → nueva Regla.
• Un Agente necesita capacidades no previstas → se actualiza la definición del Agente.
• Una asunción activa se refuta → se ajustan las Reglas y los Skills afectados.

Cada cambio se documenta en el Decision Log. El sistema es vivo, pero cada mutación es deliberada y registrada.