Gates y validaciones
5. Gates humanos firmados
Lista cerrada de gates del ciclo donde un humano firma para autorizar el paso. Todos requieren ARQ-026 (render PDF + HTML + Drive antes de pedir firma — ver directrices/arquitectura.md).
5.1. Gates duros del Stakeholder (3)
| # | Momento | Output que firma | Vehículo de la firma |
|---|---|---|---|
| S-1 | Cierre Etapa 1 | requerimiento-funcional-mvp.md | Correo del PO con PDF+HTML adjuntos / enlaces Drive |
| S-2 | Sub-gate 4.2 (validación visual) | Styleguide navegable + screenshots + acta-diseno.md | Correo del PO con PDF+HTML + URL del mockup interactivo |
| S-3 | Promoción funcional stage→pro | URL de stage accesible + acta funcional resumida | Correo del PO con URL stage + PDF+HTML del acta funcional |
Sin firma del Stakeholder, el ciclo no avanza. Retrocesos por rechazo del Stakeholder:
- S-1 rechazado → reapertura de Etapa 1 (PO ↔ Stakeholder).
- S-2 rechazado → vuelta a UX/UI dentro de Etapa 4.1 (iteración del prototipo, no se retrocede a Etapa 2).
- S-3 rechazado → posterga la promoción a
pro. El trabajo de QA/SRE no se pierde; el equipo ajusta sobrestagelo que el Stakeholder rechazó y se reabre el ciclo con un nuevo veredicto QA.
5.2. Gates duros del Director (7)
| # | Momento | Output que firma | Vehículo de la firma |
|---|---|---|---|
| D-1 | Cierre Etapa 2 (kickoff) | 6 piezas: funcional.md v2, tecnica.md, ux.md, arbol-contenidos.md, diagrama-flujos.md, acta-kickoff.md | Anotación en repo + render Drive |
| D-2 | Cierre Etapa 3 (refinamiento) | hu.md + acta-refinamiento.md | Anotación en repo + render Drive |
| D-3 | Etapa 4.7 (cierre formal de fases) | cumplimiento-plan.md + acta etapa 4 | Anotación en repo + render Drive |
| D-4 | Etapa 5 — veredicto QA sobre stage (cierre de calidad pre-promoción) | acta-pruebas-stage.md | Anotación en repo + render Drive |
| D-5 | Etapa 5 — gate cierre pro operativo | acta-despliegue-pro.md (tras ventana de observación) | Anotación en repo + render Drive |
| D-6 | Etapa 6.4 (triaje retrospectiva) | retrospectiva.md §0-§3 + acta-retro.md borrador | Anotación en repo + render Drive |
| D-7 | Etapa 6.6 (cierre formal del proyecto) | acta-retro.md v1 + sección “Cambios aplicados” en retrospectiva.md | Anotación en repo + render Drive |
Sin firma del Director, el ciclo no avanza. Si el Director detecta gap bloqueante, vuelve al agente con propiedad del output afectado.
5.3. Conteo total y aspiración
Total: 3 gates del Stakeholder + 7 gates del Director = 10 gates humanos firmados en un ciclo completo sin retrocesos.
A esos se añaden mini-gates que se activan solo cuando hace falta: aprobar excepciones a reglas firmes de las directrices, aprobar ADRs irreversibles, revisar propuestas que un agente eleva cuando se atasca o detecta ambigüedad.
Aspiración: a medida que el sistema gane confianza, los gates del Director se relajan o se sustituyen por validación automática contra criterios objetivos. Los gates del Stakeholder permanecen — son la frontera del arnés con su cliente.
Qué pasa cuando un gate se rechaza {#rechazo}
Un gate rechazado no es un fracaso: es información que el ciclo absorbe para retroceder al punto exacto donde la pieza afectada se reabre. El arnés está diseñado para que el rechazo sea barato — el trabajo ya hecho no se pierde, solo se reabre lo necesario.
Por convención del arnés, un gate del Stakeholder rechazado afecta al producto (qué se construye); un gate del Director rechazado afecta al cumplimiento del flujo (cómo se construye). Los retrocesos son simétricos a esa frontera: los gates del Stakeholder pueden mandar al ciclo hasta etapas tempranas (Etapa 1 si lo que se rechaza es el requerimiento funcional); los gates del Director normalmente reabren la pieza concreta dentro de la propia etapa.
La tabla siguiente recoge fila por fila los 10 gates del ciclo, qué etapa reabre cada rechazo, qué documento queda invalidado y qué agente lo regenera.
| Gate | Etapa a la que retrocede el ciclo | Documento invalidado | Agente que regenera |
|---|---|---|---|
| S-1 — Cierre Etapa 1 | Reapertura de Etapa 1 (Q&A entre PO y Stakeholder) | requerimiento-funcional-mvp.md (vuelve a pendiente-firma) | PO — conduce nuevo turno de Q&A, refina el funcional y vuelve a someter a firma |
| D-1 — Cierre Etapa 2 (kickoff) | Reapertura del turno del agente cuyo output bloqueó dentro de la Etapa 2 | acta-kickoff.md + la pieza canónica afectada (funcional.md, tecnica.md, ux.md, arbol-contenidos.md o diagrama-flujos.md) | PO / Arquitecto / UX — el dueño de la pieza afectada la regenera; el Director reabre el kickoff hasta que cierre |
| D-2 — Cierre Etapa 3 (refinamiento) | Reapertura de Etapa 3 | hu.md + acta-refinamiento.md (vuelven a pendiente-firma) | PO — refina las HU y los criterios de aceptación según el motivo del rechazo |
| S-2 — Sub-gate 4.2 (validación visual del Stakeholder) | Vuelta a UX/UI dentro de Etapa 4.1 — no retrocede a Etapas 2 ni 3 | acta-diseno.md + la styleguide vigente de la iteración rechazada | UX — itera la styleguide y el mockup; el Backend y el SRE no retroceden ante un rechazo de S-2 |
| D-3 — Etapa 4.7 (cierre formal de fases) | Reapertura de la fase Pendiente / ❌ del cumplimiento-plan.md que detonó el rechazo | cumplimiento-plan.md cerrado | Ejecutor de la fase afectada (Backend / Frontend / SRE / UX / PO) — completa o sanea la fase + Director actualiza el plan |
D-4 — Etapa 5 (veredicto QA sobre stage) | Vuelta a corrección sobre stage por el ejecutor del bug detectado | acta-pruebas-stage.md (vuelve a pendiente-firma o se bloquea con CAL-049) | Backend / Frontend corrigen los bugs en stage; QA re-evalúa con nueva versión del acta |
S-3 — Promoción funcional stage→pro | Posterga la promoción a pro. El trabajo de QA y SRE no se pierde; el equipo ajusta sobre stage lo que el Stakeholder rechazó | Versión vigente del acta funcional resumida que acompaña al correo S-3 | PO + ejecutor del cambio ajustan sobre stage; QA emite nuevo D-4; PO vuelve a someter S-3 al Stakeholder |
D-5 — Cierre pro operativo | Rollback inmediato sobre pro con git revert (ARQ-012). El pro previo se mantiene; la nueva versión queda bloqueada hasta que se sanee | acta-despliegue-pro.md de la versión rechazada | SRE ejecuta rollback, redacta acta-rollback-*.md con causa raíz, bumpea versión PATCH y reabre el ciclo de despliegue tras corrección |
| D-6 — Etapa 6.4 (triaje retrospectiva) | Reapertura del triaje de la retrospectiva | Versión borrador del acta-retro.md y secciones §0-§3 de retrospectiva.md | Director con apoyo del equipo del proyecto — re-triaje de propuestas y nueva firma |
| D-7 — Etapa 6.6 (cierre formal del proyecto) | Reapertura del cierre formal hasta que la sección “Cambios aplicados” de retrospectiva.md esté consolidada con la trazabilidad esperada | acta-retro.md v1 + sección “Cambios aplicados” de retrospectiva.md | Director consolida los cambios derivados de la retrospectiva sobre el arnés y vuelve a someter a firma |
Cómo se notifica un rechazo. Los gates del Director rechazados se anotan en director/log.md con motivo concreto + cross-ref al memory.md del proyecto; el daemon del Director despierta al agente con propiedad del output afectado depositando un nuevo encargo en director/inbox/. Los gates del Stakeholder rechazados llegan por correo al PO; el PO procesa la respuesta, registra el rechazo en el memory.md del proyecto y abre el turno de regeneración con el agente que corresponda.
Cuándo un rechazo escala al titular del arnés. Si el motivo del rechazo descubre un gap del propio arnés (una regla firme que falta, una pieza canónica mal calibrada, una directriz que estorba o no cubre el caso), se anota como gap numerado en el memory.md global del arnés con el prefijo G-arnés-N. La conversión a regla firme la decide el titular en sesión interactiva — no se aplica en caliente sobre el proyecto rechazado.