Verificar preparación
Invoca como $check-readiness diff, $check-readiness pr <URL>, $check-readiness release o $check-readiness full.
Solo lectura por defecto. Reporta problemas y resoluciones concretas. Edita solo cuando el usuario pida explícitamente corregir o aplicar hallazgos; luego verifica el comportamiento afectado.
1. Elegir objetivo
| Modo | Objetivo | Criterio de finalización |
|---|---|---|
diff | Cambios staged, unstaged y untracked relevantes del repositorio actual, más los llamadores y pruebas afectadas. Valor predeterminado cuando los cambios son el objetivo. | Cada comportamiento cambiado y límite afectado contabilizado. |
pr <URL> | Diff del PR vinculado, base, conversación, comprobaciones y contexto afectado. | Cada comportamiento cambiado contabilizado; evidencia local o remota faltante nombrada. |
release | Repositorio actual y objetivo de despliegue nombrado, o el objetivo encontrado en la configuración del repositorio. | Cada flujo crítico y dependencia de lanzamiento tiene un estado. |
full | Repositorio actual en todas las superficies de backend y frontend aplicables. | Cada ruta principal, operación, límite de confianza, almacén de datos y ruta de ciclo de vida inventariada y evaluada. |
Usa el modo que el usuario nombre. Si no se nombra ninguno, infiere a partir de una URL de PR, cambios actuales o un lanzamiento indicado; de lo contrario, usa full. Registra el objetivo exacto, revisión o diff, entorno y rutas de validación disponibles antes de verificar. Si no se puede acceder a una URL de PR, reporta lo que está bloqueado; no sustituyas con un diff local no relacionado.
Severidad
Cada FAIL es bloqueante o de asesoramiento. Bloqueante: seguridad, authn/authz, pérdida o corrupción de datos, flujo crítico roto, manejo de pagos o webhooks no verificado, secretos filtrados, compilación o pruebas fallidas. Todo lo demás es de asesoramiento y no impide por sí solo READY. Cada habilidad de preparación enumera sus propias áreas bloqueantes.
Profundidad por modo
diff y pr: verifica solo el comportamiento que toca el cambio; marca el resto como N/A (no tocado) en una línea, no por verificación. Las comprobaciones de puerta de lanzamiento (Lighthouse, pruebas de humo en entorno desplegado, vistas previas compartidas) aplican solo a release y full, a menos que el cambio las afecte.
2. Recopilar evidencia
Para diff, inspecciona git status --short --branch, diffs staged y unstaged, y archivos untracked relevantes. Para pr, lee el PR vinculado y su diff, comprobaciones y discusión; usa un checkout local coincidente solo para pruebas cuando su revisión esté verificada. Para release y full, mapea la aplicación dentro del alcance antes de probar. Traza llamadores, efectos en datos, configuración, pruebas y dependencias de despliegue para cada área afectada.
Ejecuta backend-readiness cuando el código o comportamiento de backend esté en alcance. Ejecuta frontend-readiness cuando el código o comportamiento de frontend esté en alcance. Pasa el modo y objetivo seleccionados a cada uno; si ambos aplican, combina sus hallazgos. Para una revisión de cambios, aplica comprobaciones al comportamiento afectado. Para un lanzamiento, aplica comprobaciones a través de flujos críticos y el entorno objetivo. Para full, evalúa todas las comprobaciones aplicables en todo el repositorio. Marca cada comprobación aplicable como PASS, FAIL, BLOCKED o N/A; adjunta evidencia actual a cada PASS y una razón a cada N/A.
Usa fuente, pruebas automatizadas, tiempo de ejecución local, sandbox del proveedor y entorno desplegado como capas de evidencia distintas. Una compilación prueba una compilación. Registra credenciales, infraestructura o entornos no disponibles como BLOCKED, con la prueba exacta aún necesaria. Ejecuta comprobaciones enfocadas que puedan verificar el objetivo; no afirmes comportamiento de tiempo de ejecución o lanzamiento solo a partir de la fuente.
Completa cuando las comprobaciones aplicables tengan estados, las fallas tengan una causa y resolución, y cada afirmación de preparación coincida con su capa de evidencia.
3. Reportar y actuar
Reporta modo y objetivo, luego hallazgos ordenados por seguridad, pérdida de datos, corrección e impacto en el usuario. Cada hallazgo nombra ubicación o flujo, evidencia, consecuencia y la resolución concreta más pequeña. Incluye comprobaciones ejecutadas con resultados exactos, más elementos bloqueados o no verificados. Termina con READY, NOT READY o UNVERIFIED para el objetivo elegido: READY requiere que no haya fallas bloqueantes conocidas y evidencia para su puerta aplicable; UNVERIFIED significa que la evidencia faltante impide esa afirmación.
Usa esta plantilla:
Modo / objetivo: <modo, revisión o diff, entorno>
Hallazgos
| Severidad | Ubicación o flujo | Evidencia | Consecuencia | Resolución |
Comprobaciones ejecutadas
| Comando o prueba | Resultado |
Bloqueado / no verificado
- <elemento>: <prueba aún necesaria>
Veredicto: READY | NOT READY | UNVERIFIED
Mantén las ejecuciones de revisión como solo lectura. Si el usuario pide corregir hallazgos, aplica las correcciones solicitadas en el código afectado, ejecuta verificación enfocada y reporta riesgos restantes. No infieras autorización de edición a partir de una solicitud de verificación de preparación.
Completa cuando el informe distinga comportamiento verificado de brechas, o las correcciones solicitadas hayan sido aplicadas y verificadas.