Etapa 5 — Pruebas y publicación
(Sección Etapa 5 pendiente de regeneración — fuente del arnés sin marcador ### Etapa 5 ni ## Etapa 5 detectable.)
Flujos alternativos
El QA bloquea el veredicto D-4 por cobertura insuficiente
Si al validar el producto sobre el entorno de validación (stage) el QA detecta que la cobertura de tests es insuficiente para emitir veredicto APROBADO, bloquea D-4 con formato obligatorio en §0 del acta-pruebas-stage.md (regla CAL-049): un encabezado destacado, los flujos sin cobertura suficiente, el motivo del bloqueo y el criterio de desbloqueo. Enterrar la brecha en una sección de deudas y emitir APROBADO es anti-patrón explícito. El Stakeholder no puede firmar S-3 con D-4 bloqueado.
El CI remoto está en rojo al consultar antes del veredicto D-4
Antes de emitir veredicto, el QA consulta el estado del CI remoto del commit exacto que se promociona a producción (regla CAL-050). Si el CI está en rojo, bloquea D-4 con el mismo formato que cobertura insuficiente, salvo que el rojo se sanee a verde antes del veredicto o exista un ADR que documente por qué el rojo es aceptable (típicamente: fallo de tooling del pipeline sin relación con el comportamiento del producto).
El Stakeholder rechaza la promoción al firmar firma-promocion-pro
Si al revisar el paquete de promoción (acta del QA, screenshots de la batería, URL del entorno de validación) el Stakeholder rechaza la promoción a producción, el arnés vuelve a Etapa 4 con la lista de observaciones del Stakeholder convertida en encargos a los agentes ejecutores correspondientes. Cuando se subsanan, se vuelve a abrir el ciclo de validación QA en stage con nuevo D-4 y nuevo intento de S-3.
Regresión bloqueante detectada en producción tras la promoción
En la ventana de observación posterior a la promoción (regla CAL-032), el QA mantiene presencia continua sobre métricas y errores reales. Si detecta una regresión que viola CAL-002 o CAL-005, dispara el procedimiento estándar de bug crítico (Issue con plantilla obligatoria + test de regresión + fix + verificación QA) y, si la severidad lo exige, el SRE ejecuta rollback a la versión anterior según el procedimiento firmado en arquitectura.md.
Documentación generada en esta etapa
| Artefacto | Propietario | Tipo |
|---|---|---|
etapa-5/acta-pruebas-stage.md | QA | Markdown |
etapa-5/correos/s3-*.txt | PO (correo al Stakeholder solicitando la firma de promoción y respuesta) | Texto plano |
etapa-5/renders/acta-pruebas-stage.{pdf,html} (si se decide entregar a Stakeholder) | QA o Director | PDF + HTML |
Etiqueta SemVer en el repo del producto (v<MAJOR>.<MINOR>.<PATCH>) | SRE en la promoción | Tag de Git |
etapa-5/acta-publicacion.md | SRE | Markdown |
Issues de GitHub con label bug y label post-pro (si surgen) | Quien detecta | Issue templado |
proyectos/<slug>/memory.md (entradas de bloqueo, veredicto, promoción) | QA, SRE, Director | Markdown |