Etapa 5 — Pruebas y publicación

Input: desarrollo desplegado en stage (output de Etapa 4).
Proceso (modelo stage / pro, decisión 2026-05-24):
1. QA en stage — fase única que absorbe lo que antes vivía repartido entre los entornos QA, PRE y la batería previa a PRO:
  - Verificación de cobertura del implementador: antes de ejecutar su propia batería, el QA verifica que Backend y Frontend han entregado sus tests de HU (CAL-048 + CAL-013). Si no los han entregado, bloquea D-4 inmediatamente — no continúa con el resto de la fase.
  - Verificación de coherencia stack tecnica.md ↔ stage (decisión 2026-05-27, formalización de G-arnés-6): el QA compara el stack declarado en tecnica.md vigente del proyecto con el efectivamente desplegado en stage (framework principal con su versión mayor, proveedor de hosting, BD si aplica). Si hay desviación de proveedor de hosting o versión mayor del framework sin ADR correspondiente en proyectos/<slug>/adr/ (ARQ-022 extendida), bloquea D-4 inmediatamente con el formato de CAL-049. El equipo abre el ADR (o sanea el stack a lo declarado) antes de continuar. Desviaciones menores (parche del framework, sub-versión de BD) no exigen ADR — solo nota en el acta de pruebas si afectan a resultado de tests.
  - Consulta del CI remoto tecnica.md ↔ GitHub Actions (decisión 2026-05-29, CAL-050): antes de la batería propia, el QA consulta el estado del CI remoto del commit exacto que se promociona. CI rojo bloquea D-4 con el formato de CAL-049, salvo saneo a verde o ADR que justifique el rojo (típicamente fallo de tooling/infra del pipeline ajeno al producto). El resultado del CI se registra en el acta. Motivo: O-arnés-2 — D-4/D-5 de oficina-agentica v1.0.0 se firmaron sobre un CI 100% rojo no consultado.
  - Batería exhaustiva propia del QA: e2e de flujos críticos, contrato de APIs, exploratorio, carga si aplica, experiencia real. No se emite veredicto APROBADO sin esta batería completa.
  - Suite de regresión completa (CAL-031).
  - Exploratorio del QA (CAL-041).
  - Pruebas de carga representativas (CAL-009) cuando el proyecto las exija.
  - Validación de experiencia real (CAL-042) con datos representativos.
  - Si hay bugs → vuelven al equipo de implementación. No se promociona con bugs conocidos (CAL-002).
  - Si la cobertura es insuficiente o el QA no puede ejecutar su batería por cualquier motivo → bloqueo explícito con el formato de CAL-049 (§0 del acta, cabecera ⛔, flujos sin cubrir listados, criterio de desbloqueo). Aceptar la brecha como DEU en §5 y emitir APROBADO no es una opción válida.
  - Si batería completa y sin bloqueos → veredicto QA explícito (CAL-030) firmado en acta-pruebas-stage.md.
2. Validación del Stakeholder en stage: el PO comparte la URL accesible de stage + acta funcional resumida; el Stakeholder firma S-3 autorizando la promoción a pro.
3. Promoción a pro: SRE despliega; QA ejecuta smoke tests no invasivos (sin escritura en disco, sin efectos secundarios sobre clientes — CAL-010, CAL-032). Se abre la ventana de observación en SigNoz con duración declarada.
  - Si la ventana está limpia → desarrollo cerrado.
  - Si aparecen anomalías → rollback (ARQ-012) y retroceso a Etapa 4 o reapertura del veredicto QA según severidad.
Output canónico (propuesta #1 retrospectiva piloto vocab-1000, 2026-05-23; actualizado por decisión 2026-05-24 sobre entornos): artefactos persistentes en proyectos/<proyecto>/etapa-5/, equivalentes en cadencia a los de etapa 4:
- acta-pruebas-stage.md (propietario QA) — material del gate D-4 (cierre de calidad sobre stage): suite de regresión ejecutada con resultados, exploratorio realizado, pruebas de carga representativas (CAL-009) cuando aplican con sus umbrales operativos verificados, validación de experiencia real (CAL-042), bugs detectados con severidad/prioridad, inventario de scope HU implementadas vs planificadas (CAL-045), veredicto QA explícito (CAL-030).
- acta-despliegue-pro.md (propietario SRE + QA) — material del gate D-5 (cierre PRO operativo): smoke tests no invasivos ejecutados (CAL-010, CAL-032), ventana de observación abierta en SigNoz con duración declarada y resultado al cerrarla, URL de producción, commit/tag desplegado, evidencias de rollback verificado (ARQ-012). Frontmatter incluye version_producto: <MAJOR.MINOR.PATCH> (ARQ-027) — primera firma de gate D-5 del proyecto lleva 1.0.0; sub-ciclos MINOR posteriores bumpean a 1.1.0, 1.2.0, etc.; MAJOR (2.0.0) arranca con proyecto nuevo o reuso del actual según decida el titular del arnés. El SRE además aplica el tag git correspondiente (git tag v1.X.Y && git push --tags) sobre el repo del producto al firmar el gate.
- Render PDF + HTML de cada acta subido a Drive etapa-5-pruebas/ como snapshot inmutable.
Gate: validación humana en cada salto — D-4 (veredicto QA cierra stage), S-3 (Stakeholder autoriza promoción stage→pro), D-5 (cierre PRO operativo tras ventana de observación).
Retroceso: a Etapa 4 si aparecen bugs en stage que el equipo no puede resolver en ciclo corto, o si la ventana de observación de pro detecta anomalías que obligan a rollback.

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 S-3

Si al revisar el paquete S-3 (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 firma S-3 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