Documentación · Roles
Qué puede decidir cada nivel sin pedir permiso
Este proyecto lo desarrolla una sola persona. Eso hace tentador declarar que los niveles de autoridad «no aplican», y sería falso: aplican, solo que no separan personas sino tipos de decisión. La pregunta que responde esta página no es «¿quién es el jefe?», sino «¿qué puede hacer cada nivel sin pedir permiso, y qué no puede hacer aunque tenga el acceso técnico para hacerlo?».
El reparto actividad por actividad está en la matriz RACI, que usa estos mismos tres niveles como columnas.
La premisa: la separación está en el código, no en la buena voluntad
En una organización, los niveles de autoridad se sostienen porque distintas personas ocupan distintos cargos. Aquí no hay a quién delegar, así que la frontera tuvo que quedar escrita en un lugar que no dependa del criterio de quien programa a las 2 a. m.:
- Publicar es una decisión reservada. Ninguna automatización ni asistente dispara un despliegue: la regla está escrita en las instrucciones del repositorio y el flujo de trabajo la respeta.
- Revertir es una decisión automática. El pipeline comprueba la salud del despliegue y ejecuta el rollback sin consultar a nadie, porque esperar cuesta tiempo de caída.
- Ejecutar no incluye publicar ni destruir. Las migraciones son aditivas por política y los secretos solo se revelan por un endpoint bajo sesión administrada.
Los tres niveles
El ancho de cada franja es su proporción real dentro de la figura: arriba se decide poco y pesa mucho; abajo se hace casi todo el trabajo y se autoriza casi nada.
Estratégico
Aprueba recursos y salidaEl dueño del producto (Mike). Frente a un encargo de cliente, el cliente comparte este nivel dentro del alcance contratado: aprueba alcance y presupuesto, no la implementación.
Decide sin pedir permiso
- Qué sale a producción y cuándo: el deploy es una decisión humana reservada, ninguna automatización publica por su cuenta.
- Qué recursos se contratan y se pagan: dominio, proyecto de Vercel, Turso, pasarela de pagos, canal de alertas.
- Quién tiene acceso al panel de control (allowlist de logins) y quién recibe credenciales del portal.
- Qué requisito entra al alcance y cuándo pasa de «planeado» a «implementado», y qué iteración se cierra.
- Los compromisos públicos de servicio: objetivos de nivel de servicio y precios publicados.
No puede: Saltarse las compuertas que él mismo definió sin dejar rastro: el pipeline corre igual, el health check post-deploy corre igual y el rollback automático se dispara igual sobre un deploy aprobado.
Táctico
Coordina y activa rollbackLa cadena de entrega: el pipeline de integración continua, los crons externos y el middleware de seguridad. Cuando la automatización no alcanza (un incidente que exige criterio), lo ocupa la misma persona con otro sombrero: el de operador de guardia.
Decide sin pedir permiso
- Si una versión desplegada se queda o se revierte: comprueba la salud del despliegue y ejecuta el rollback sin pedir permiso.
- El orden y las precondiciones del trabajo: el deploy no se verifica si antes no pasaron pruebas y build.
- Si un request se bloquea, se limita o pasa: clasificador de amenazas, límite de tasa durable y lista de bloqueo.
- Cuándo notificar y a quién: alertas push cuando hay rollback, incidente o anomalía de seguridad.
- Cuándo corre el trabajo periódico: chequeos de monitores, consolidados y alertas.
No puede: Publicar una versión nueva. Solo puede confirmar la que ya fue aprobada o devolver el sistema a la anterior - avanzar es del nivel estratégico, retroceder es suyo.
Operativo
Ejecuta, prueba y reportaEl desarrollo diario: quien escribe el código (con asistencia de un agente) y los sensores del sistema que registran lo que pasa.
Decide sin pedir permiso
- Cómo se implementa un requisito ya aprobado: diseño de módulos, estructura de datos, algoritmos.
- Qué pruebas cubren cada cambio y en qué nivel (unitaria, integración, extremo a extremo, accesibilidad, seguridad).
- Qué se registra como evento observable y con qué detalle, dentro de la política de datos públicos agregados.
- Qué se documenta en /docs y qué cifras se publican - siempre leídas del dato tipado, nunca escritas a mano.
No puede: Publicar en producción, eliminar una columna del esquema, ni exponer secretos: las migraciones son aditivas por política y los secretos solo se revelan por un endpoint bajo sesión administrada.
Dónde está el límite (y qué no se puede afirmar)
La separación de niveles no es separación de personas. Una misma persona ocupa los tres, y eso significa que ninguna de estas fronteras protege contra el escenario que un organigrama real sí cubre: el de alguien que decide saltársela deliberadamente. Lo que sí protegen es contra el error, la prisa y el olvido, que son las causas de la inmensa mayoría de los incidentes. Afirmar más que eso sería vender un control que no existe.
Lo que sí se puede afirmar. Que la autorización de publicar está separada de la capacidad de programar; que revertir no requiere una persona despierta; que destruir datos exige una decisión explícita y deja rastro; y que un cliente no puede ver los datos de otro aunque manipule el identificador que envía - eso último no es una política, es una prueba (tests/portal-isolation.test.ts).