Documentación · RACI
Quién ejecuta, y quién responde por el resultado
Las columnas son los tres niveles de autoridad, no tres cargos. Leerla así evita la trampa habitual de las matrices RACI de un proyecto pequeño: repartir letras entre nombres inventados. Aquí cada fila contesta algo comprobable:si esto sale mal, ¿de qué nivel es la culpa, y dónde en el repositorio está escrita esa frontera?
Los cuatro roles
Ejecuta la actividad.
Responde por el resultado. Solo puede haber uno por actividad.
Aporta criterio antes de decidir.
Recibe el avance o el resultado.
La matriz - 12 actividades
| Actividad | Estratégico | Táctico | Operativo | Por qué la aprobación cae ahí |
|---|---|---|---|---|
| Definir el alcance de una iteraciónsrc/data/iteraciones-portfolio.ts · docs/plan-*.md | AR | I | C | Comprometer alcance es comprometer tiempo y dinero propios. El nivel operativo aporta la estimación, pero no puede aprobar su propia carga de trabajo. |
| Desarrollar una funcionalidadsrc/lib/ · src/pages/ | A | I | R | La implementación es una decisión técnica delegada; lo que no se delega es dar por buena la funcionalidad terminada. |
| Ejecutar las pruebas (unitarias, e2e, accesibilidad, análisis estático)tests/ · e2e/ · workflows ci.yml, security.yml, a11y.yml, mutation.yml, dast.yml | I | AC | R | Quien ejecuta las pruebas no debería ser quien decide si un resultado en rojo se ignora: el pipeline consulta el resultado y corta por sí mismo. |
| Aprobar y disparar el despliegue a producciónRegla de deploys en CLAUDE.md · despliegue en Vercel disparado por el dueño | A | R | I | Es el punto de no retorno hacia usuarios reales. La aprobación es humana y reservada; la ejecución mecánica del despliegue ya es de la plataforma. |
| Verificar la salud del sistema después de desplegarPaso «Health check post-deploy» contra /api/health en .github/workflows/ci.yml | I | AR | C | Una comprobación automática e incondicional vale más que la atención de una persona justo después de publicar, que es cuando menos disponible está. |
| Revertir a la versión anterior (rollback)Paso «Rollback automático» + notificación ntfy en .github/workflows/ci.yml | A | R | I | Revertir se ejecuta sin esperar autorización porque el costo de esperar es tiempo de caída; la política que lo autoriza se aprobó antes, no durante el incidente. |
| Aplicar una migración de esquemadrizzle/ (generadas, nunca editadas a mano) · política de migraciones aditivas en CLAUDE.md | A | I | R | Una migración destructiva no tiene rollback barato: los datos ya no están. Por eso las migraciones son aditivas por política y eliminar una columna exige autorización explícita. |
| Gestionar secretos y variables de entornoBóveda cifrada AES-256-GCM en project_services.secrets · revelado solo bajo sesión administrada | AR | C | I | Un secreto filtrado no se corrige con un despliegue: hay que rotarlo en cada sistema que lo usa. El nivel operativo trabaja con los secretos, pero no los custodia. |
| Atender una alerta de seguridadsrc/lib/security/ (clasificador, límite de tasa, lista de bloqueo) · tabla security_events · alertas ntfy | A | R | C | La contención automática (limitar, bloquear) actúa en milisegundos; la decisión de escalar, avisar a un cliente o aceptar el riesgo sigue siendo humana. |
| Publicar cifras en /docs y /statussrc/data/ como fuente de verdad de /docs · /status proyecta monitor_checks, no cifras escritas a mano | A | I | R | Son afirmaciones públicas sobre el propio sistema. Se generan desde el dato tipado y las mediciones reales para que nadie pueda «ajustar» un número al escribir la página. |
| Cobrar a un cliente y conciliar el pagosrc/lib/payments.ts (createPaymentIdempotent, applyGatewayEvent) · src/lib/payments-state.ts | A | R | C | Es la única actividad donde un error mueve dinero de otra persona. La máquina de estados idempotente ejecuta; quién cobra, cuánto y a quién no se automatiza. |
| Dar acceso a un cliente a su información en el portalrequirePortalSession() en src/lib/portal/ · tests/portal-isolation.test.ts | A | C | R | Un fallo de aislamiento no degrada una función: expone los datos de un cliente a otro. El identificador de cliente nunca viene del request, sale siempre de la sesión. |
Las dos reglas
- Toda actividad tiene exactamente un Aprobador (A): si responden dos, no responde ninguno.
- Toda actividad tiene al menos un Responsable (R): sin ejecutor, la fila es una intención, no una asignación.
Un mismo nivel puede llevar A y R en la misma fila: aprobar y ejecutar no son incompatibles, son responsabilidades distintas que aquí suelen recaer en la misma persona. Lo que la regla prohíbe es que dos niveles distintos aprueben la misma actividad.
No son una convención declarada al pie de la tabla: tests/gobernanza.test.ts las comprueba sobre los datos que renderizan esta tabla, así que una fila con dos aprobadores o sin ejecutor rompe la integración continua antes de llegar a producción. Al escribirlas como prueba, cuatro de las 12 filas iniciales resultaron incumplirlas.