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).
⚠️ Cambio de gobierno del 2026-09-04 — el Stakeholder firma el cierre de CADA etapa
Hasta esta fecha el Stakeholder firmaba tres veces (
S-1,S-2,S-3) y el resto de cierres de etapa los firmaba el Director en solitario. Decisión de el titular del arnés del 2026-09-04: al terminar cada etapa se le presentan los outputs y se le pide firma; sin ella no arranca la etapa siguiente.Qué se busca: control humano etapa por etapa, por correo. El ciclo se vuelve más lento y más gobernable — y es coherente con la fase: la §5.4 aspira a relajar gates cuando el sistema gane confianza, y el arnés está todavía probando que la tiene.
Los gates pasan a nombrarse por lo que son, no por un código:
firma-etapa-1…firma-etapa-5,firma-visual,firma-promocion-pro. La equivalencia con los códigos antiguos está en §5.5, y los artefactos históricos que citanS-1/S-2/S-3no se reescriben: siguen siendo válidos.
5.1. Gates del Stakeholder (7) — uno por cierre de etapa, más dos sub-gates
| Gate | Momento | Qué se le presenta | Vehículo de la firma |
|---|---|---|---|
firma-etapa-1 | Cierre Etapa 1 | requerimiento-funcional-mvp.md | Correo del PO con PDF+HTML adjuntos / enlaces Drive |
firma-etapa-2 | Cierre Etapa 2, tras D-1 | Las 6 piezas del kickoff + resumen ejecutivo del stack | Correo del PO con PDF+HTML + enlaces Drive |
firma-etapa-3 | Cierre Etapa 3, tras D-2 | hu.md + acta-refinamiento.md | Correo del PO con PDF+HTML + enlaces Drive |
firma-visual | Sub-gate 4.2 (validación visual) | Styleguide navegable + screenshots + acta-diseno.md | Correo del PO con PDF+HTML + URL del mockup interactivo |
firma-etapa-4 | Cierre Etapa 4, tras D-3 | cumplimiento-plan.md + acta de etapa 4 + URL del producto en stage | Correo del PO con PDF+HTML + URL de stage |
firma-promocion-pro | Promoción funcional stage→pro, tras D-4 | URL de stage accesible + acta funcional resumida | Correo del PO con URL stage + PDF+HTML del acta funcional |
firma-etapa-5 | Cierre Etapa 5, tras D-5 | acta-despliegue-pro.md, URL de producción y resultado de la ventana de observación | Correo del PO con PDF+HTML + URL de producción |
Sin firma del Stakeholder, el ciclo no avanza. El estado del agente que espera es esperando_humano.
La Etapa 6 (retrospectiva) no lleva firma del Stakeholder: evalúa al arnés, no al producto. Cierra con D-6 y D-7, que ya son firmas humanas.
Retrocesos por rechazo del Stakeholder:
firma-etapa-1rechazada → reapertura de Etapa 1 (PO ↔ Stakeholder).firma-etapa-2rechazada → según lo que rechace: reapertura del kickoff (Etapa 2) o, si toca los requerimientos, retroceso a Etapa 1.firma-etapa-3rechazada → vuelta al refinamiento (Etapa 3) con el motivo del rechazo como entrada.firma-visualrechazada → vuelta a UX/UI dentro de Etapa 4.1 (iteración del prototipo, no se retrocede a Etapa 2).firma-etapa-4rechazada → vuelta a la sub-etapa de implementación afectada, sin repetir la etapa entera.firma-promocion-prorechazada → posterga la promoción apro. El trabajo de QA/SRE no se pierde; el equipo ajusta sobrestagelo rechazado y se reabre con un nuevo veredicto QA.firma-etapa-5rechazada → el SRE evalúa rollback (ARQ-012) y el Director reabre la etapa con el motivo.
5.2. Gates del Director (7) — dejan de cerrar la etapa, la habilitan
Los gates del Director no cambian de nombre ni de contenido, pero sí de función: ya no cierran la etapa, sino que acreditan que está completa y es coherente, y con eso habilitan que el PO la presente al Stakeholder.
| # | 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, no se presenta nada al Stakeholder. Si detecta un gap bloqueante, vuelve al agente con propiedad del output afectado. El Director nunca firma un gate del Stakeholder ni lo da por firmado: eso es usurpación de rol y está prohibido en su contrato.
5.3. Protocolo de cierre de etapa — los seis pasos
Vale para las etapas 2, 3, 4 y 5 (la Etapa 1 tiene el suyo, más antiguo, en ciclo.md.d/etapa-1-necesidad.md; el efecto es el mismo).
- Los agentes producen los outputs de la etapa y los dejan en el repo del proyecto.
- El Director verifica y firma su gate
D-n: están todas las piezas, son coherentes entre sí y cumplen las directrices. Si falta algo, devuelve al agente dueño y la etapa no cierra. - El Director encarga al PO la presentación: encargo
presentar-cierre-etapacon la etapa, el gate del Director ya firmado y la lista de outputs. - El PO prepara y envía el paquete al Stakeholder: renders PDF+HTML (ARQ-026), enlaces, un resumen de qué se ha hecho en la etapa y qué decisiones lleva dentro, y petición explícita de firma nombrando el gate (
firma-etapa-n). Quedaesperando_humano. - El Stakeholder responde por correo: firma o rechaza con motivo. La respuesta al buzón operativo del arnés es lo que reactiva el ciclo.
- Si firma → el PO lo registra en su fichero propio
etapa-n/firma-etapa-n.md(gate: firma-etapa-n,gate_estado: firmado; desde el 2026-09-16, para no alojar dos gates en un mismo frontmatter), avisa al Director y arranca la etapa siguiente. Si rechaza → el PO traslada el motivo al Director, que abre el retroceso que corresponda según §5.1.
El PO es siempre la cara del arnés ante el Stakeholder. Ningún otro agente le escribe para pedirle una firma.
Reglas transversales (2026-09-16). Todo el ciclo se rige además por
agentes/comun/reglas-transversales.md, que el motor añade al contrato de cada agente: proporcionalidad (los umbrales que no dijo el Stakeholder son derivados y revisables), el Stakeholder es el cliente (ni tester ni enrutador), sin cita del contrato no hay rechazo ni bloqueo, verificar antes de afirmar y solo el titular del arnés toca el motor. Nacen de la retro de la prueba de salida nº 4.
5.4. Conteo total y aspiración
Total: 7 gates del Stakeholder + 7 gates del Director = 14 gates humanos firmados en un ciclo completo sin retrocesos (antes del 2026-09-04 eran 10).
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. El aumento de 10 a 14 es deliberado y reversible: responde a que el arnés está en cuarentena y su autonomía aún no está acreditada.
5.5. Equivalencia con la nomenclatura anterior
Los artefactos, actas y encargos anteriores al 2026-09-04 usan los códigos antiguos. No se reescriben: siguen siendo válidos y esta tabla es su traducción.
| Nombre actual | Código anterior | Nota |
|---|---|---|
firma-etapa-1 | S-1 | Mismo gate, mismo momento |
firma-etapa-2 | — | Nuevo. Absorbe la entrega blanda B-1, que pasa de informativa a gate duro |
firma-etapa-3 | — | Nuevo |
firma-visual | S-2 | Mismo gate, mismo momento (sub-gate 4.2) |
firma-etapa-4 | — | Nuevo |
firma-promocion-pro | S-3 | Mismo gate, mismo momento |
firma-etapa-5 | — | Nuevo. Absorbe la entrega blanda B-2, que pasa de informativa a gate duro |
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). Desde el 2026-09-04 los dos se encadenan en cada cierre de etapa: el Director firma primero para acreditar que la etapa está completa, y solo entonces el PO se la presenta al Stakeholder para que firme el paso a la siguiente. 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 catorce 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 |
|---|---|---|---|
firma-etapa-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 — 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 |
firma-etapa-2 — Cierre Etapa 2 | Según lo rechazado: reapertura del kickoff, o retroceso a Etapa 1 si toca los requerimientos | Las 6 piezas del kickoff (vuelven a pendiente-firma) | PO traslada el motivo al Director, que reabre la etapa con el dueño de la pieza afectada |
| D-2 — Etapa 3 (refinamiento) | Reapertura de Etapa 3 | hu.md + acta-refinamiento.md | PO — refina las HU y los criterios de aceptación según el motivo del rechazo |
firma-etapa-3 — Cierre Etapa 3 | Vuelta al refinamiento con el motivo del rechazo como entrada | hu.md + acta-refinamiento.md (vuelven a pendiente-firma) | PO — reabre el refinamiento; el equipo ejecutor vuelve a retar las HU afectadas |
firma-visual — Sub-gate 4.2 (validación visual) | 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; Backend y SRE no retroceden ante este rechazo |
| 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 |
firma-etapa-4 — Cierre Etapa 4 | Vuelta a la sub-etapa afectada, no a la etapa entera | Acta de etapa 4 + cumplimiento-plan.md (vuelven a pendiente-firma) | El ejecutor de la sub-etapa señalada — el Director acota el retrabajo a lo rechazado |
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 |
firma-promocion-pro — Promoción stage→pro | Posterga la promoción. El trabajo de QA y SRE no se pierde; el equipo ajusta sobre stage lo rechazado | Versión vigente del acta funcional resumida que acompaña al correo de promoción | PO + ejecutor del cambio ajustan sobre stage; QA emite nuevo D-4; PO vuelve a someter la promoción |
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 |
firma-etapa-5 — Cierre Etapa 5 | El SRE evalúa rollback (ARQ-012) y el Director reabre la etapa con el motivo | acta-despliegue-pro.md (vuelve a pendiente-firma) | SRE con apoyo de QA — sanean lo señalado en producción antes de volver a pedir firma |
| 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 |
La Etapa 6 no lleva firma del Stakeholder: evalúa al arnés, no al producto. Cierra con
D-6yD-7, que ya son firmas humanas.
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.