Checklist de readiness previo al primer sprint

Checklist de readiness previo al primer sprint

Plantilla de la Metodología Designio · «Soberanía de la Intención» (origen: cap. 5, pp. 142-146) · designio.dev

Qué es y cuándo se usa

Antes de que arranque el primer sprint con un cliente nuevo, se ejecuta un protocolo de validación llamado checklist de readiness. Sirve para confirmar que todo lo preparado está realmente operativo, no solo configurado sobre el papel. Bajo la filosofía Zero Trust, no se asume que un acceso «concedido» sea un acceso «operativo».

El checklist tiene cuatro bloques. El cumplimiento del 100 % es obligatorio para proceder al primer sprint real: «No se aceptan excepciones parciales» (p. 145), porque cualquier hueco en el readiness compromete la autonomía de los agentes y la integridad del código que vayan a generar.

---

CHECKLIST DE READINESS — [NOMBRE_DEL_PROYECTO]

Fecha de ejecución: [FECHA] · Ejecutado por: [DELIVERY_LEAD] · Resultado: [APTO | NO_APTO]

Bloque 1 · Pruebas de humo de conectividad

Validan que los túneles de datos, los protocolos de cifrado y los permisos de ejecución funcionan en la práctica.

• ☐ Latencia de la bóveda de secretos. Llamada de prueba al endpoint de [VAULT_O_SECRETS_MANAGER]: responde en menos de 200 ms. Si tarda más, optimizar la ruta de red. Resultado: [MS]
• ☐ Handshake de Git. git clone, git push y merge de un archivo vacío desde la identidad del Machine User [IDENTIDAD]. Las reglas de protección de rama permiten el flujo automático sin intervención humana inicial.
• ☐ Proxy de comandos. Ejecución de un comando de la lista blanca ([EJEMPLOS: npm —version, docker info, terraform plan en modo lectura]) dentro del sandbox efímero. Sin falsos positivos de bloqueo; cuotas de recursos suficientes.
• ☐ Telemetría de retorno. Los logs de los agentes llegan a [DATADOG_NEW_RELIC_SPLUNK_O_EQUIVALENTE]. El ID de correlación del agente es visible en los dashboards desde el primer momento.

Bloque 2 · Auditoría de la línea base semántica

Asegura que el agente conoce el contexto técnico y cultural del cliente antes de su primera tarea real.

• ☐ Carga del contexto maestro. Inyectados en el RAG: manuales de estilo, diagramas de arquitectura, esquemas de base de datos, políticas de seguridad y archivos de configuración global. Verificado mediante hash de integridad que el índice vectorial procesó toda la documentación. Hash: [HASH]
• ☐ Test de coherencia. El agente describe la arquitectura del cliente basándose solo en los documentos inyectados (p. ej.: «¿Cómo gestionamos la persistencia en el módulo de pagos y qué librerías de cifrado son obligatorias?»). Validado por el Arquitecto humano con fidelidad superior al 95 %. Resultado: [%]
• ☐ Validación del linter de estándares. Sometido al agente un fragmento de código que viola deliberadamente las reglas de nombrado, los patrones de inyección de dependencias o los protocolos de seguridad. El Security Sentinel identifica el 100 % de las infracciones. Resultado: [%]
• ☐ Mapeo de dependencias. El agente reconoce las versiones exactas de frameworks, runtimes y librerías permitidas ([VERSIONES: p. ej. Node.js 18 LTS, Java 17]) y no propone actualizaciones que rompan la compatibilidad.

Bloque 3 · Gobernanza y firmas

Establece el marco de responsabilidad antes de que el agente actúe con autonomía.

• ☐ Firma del protocolo de delegación ✍. El Business Owner y el Delivery Lead ratifican el documento que define qué tipos de tareas requieren aprobación humana explícita (p. ej. cambios en el esquema de base de datos de producción) y cuáles son de ejecución autónoma (refactorizaciones menores, creación de tests, documentación de código). Firmado por: [BO] y [DL], fecha [FECHA]
• ☐ Validación del Financial Guard. Límites de gasto en tokens configurados en la moneda local del contrato [MONEDA]. Alertas al 25 %, 50 % y 80 % del presupuesto mensual; bloqueo automático al 100 %.
• ☐ Aprobación del plan de contingencia. Simulada una parada de emergencia con revocación instantánea de los tokens de acceso del Machine User. El sistema se detiene sin dejar procesos huérfanos, ficheros bloqueados ni estados inconsistentes.

Bloque 4 · Sprint cero (Dry Run)

Sprint de prueba con una tarea trivial pero representativa (estilo «añadir un endpoint de salud y telemetría al microservicio X»), para detectar fricciones operativas ocultas, latencias no previstas o cuellos de botella en la comunicación humano-IA. Debe recorrer todas las fases de la metodología:

• ☐ Ingesta del requisito vía el canal autorizado [CANAL]
• ☐ Refinamiento por el agente interrogador con generación de la EIS
• ☐ Construcción por el Agente Constructor el miércoles
• ☐ Auditoría por el Security Sentinel el jueves
• ☐ Despliegue en PRE y UAT agéntico previo
• ☐ Validación humana del BO el viernes
• ☐ Merge, release y retrospectiva

Si el sprint cero pasa sin incidencias graves, el cliente está listo para arrancar. Si aparecen fricciones: [FRICCIONES_DETECTADAS_Y_RESOLUCION] — se resuelven antes del primer sprint productivo.

---

Criterio de aprobación

Cumplimiento del 100 % de este checklist. No se aceptan excepciones parciales. Cualquier ítem no superado bloquea el arranque del primer sprint real hasta su resolución.