Roles y permisos
Estado: Borrador · Última actualización: 2026-08-24 Deriva de: DEC-008, DEC-024, DEC-028, DEC-029 · Cubre: RF-001 a RF-008 · Reglas: RN-001 a RN-008
1. El principio que ordena todo
No existe un equipo QA dedicado. Los roles de esta plataforma no describen cargos: describen responsabilidades asignables. Una misma persona puede ser Developer en un proyecto y QA en otro, o ambas cosas en el mismo proyecto.
Consecuencia de diseño: el rol de proyecto no es un atributo del usuario, es un atributo de la relación entre un usuario y un proyecto.
Con una excepción deliberada: los roles de plataforma. Hay acciones que ocurren antes de que exista un proyecto —importarlo— o por encima de todos —administrar la plataforma—. Esas no pueden depender de un rol de proyecto que todavía no existe, así que se apoyan en un segundo nivel: los roles de plataforma (Admin y Product Manager), que sí son atributo del usuario y provienen de los permisos que entrega el servicio /me de identity.flagare, no de Argos QA (ver §2 y RN-085).
2. Los cuatro roles
| Rol | Qué representa | Quién lo ejerce en la práctica |
|---|---|---|
| Product Manager | Dueño del qué. Único validador humano de los artefactos funcionales. | El PM del proyecto. |
| QA | Dueño del cómo se prueba. Diseña el plan, gestiona ciclos, ejecuta y reporta. | Un developer con el sombrero puesto. |
| Developer | Ejecuta pruebas, corrige defectos, revisa evidencia. | El equipo de desarrollo. |
| Client | Observador externo. Solo lectura de reportes agregados de su propio proyecto. | Contraparte del cliente. |
Product Manager
Es el único rol que aprueba. Congela casos de uso y aprueba planes de prueba. Esta concentración es deliberada: con un solo validador humano, la aprobación no se diluye ni queda esperando a que alguien esté disponible.
QA
Es un sombrero, no un cargo. Se asigna a quien vaya a diseñar y conducir las pruebas de un proyecto, típicamente un developer. Tiene autoridad sobre el plan de pruebas, los ciclos, la evidencia, los bugs y los bloqueos — pero no aprueba casos de uso.
Developer
Puede ejecutar pruebas y reportar bugs sin necesidad del sombrero QA. La diferencia está en la gestión: un Developer ejecuta lo que existe; un QA crea escenarios, abre ciclos y decide el alcance de la prueba.
Client
Ve solo reportes de calidad agregados de su proyecto: cobertura, porcentaje de éxito, avance y conteo de bugs por severidad. No accede a casos de uso, escenarios, evidencia, detalle de bugs ni comentarios del equipo. La restricción es dura porque la evidencia puede contener capturas de sistemas internos y datos de terceros.
Roles de plataforma (Admin y Product Manager)
Por encima de los cuatro roles de proyecto existen dos roles de plataforma. Argos QA no los administra: son permisos que entrega el servicio /me de identity.flagare. El JWT solo valida la identidad; al iniciar sesión, Argos QA llama a /me y lee de ahí los permisos para autorizar. Su forma exacta depende de PA-007.
| Rol de plataforma | Qué habilita en Argos QA |
|---|---|
| Admin | Acceso total a Argos QA y a todos los proyectos. Superusuario interno. |
| Product Manager | Puede importar/crear un proyecto de QA desde Argos Operaciones. Al importarlo, queda automáticamente como Product Manager de ese proyecto. |
Un permiso de plataforma y un perfil de proyecto son cosas distintas: el permiso de plataforma (de identity.flagare) autoriza a entrar y crear; el perfil de proyecto (que administra Argos QA) define qué hace dentro de cada proyecto. El Admin no reemplaza a los roles de proyecto: los supera —actúa en cualquier proyecto sin tener rol asignado en él—. El Product Manager de plataforma solo habilita la importación; lo demás lo gobierna su rol de proyecto PM, que obtiene al importar.
3. Reglas de asignación
| ID | Regla |
|---|---|
| RN-001 | Los roles de proyecto se asignan por la dupla usuario + proyecto. No existe un rol de proyecto global. (Los roles de plataforma —RN-085— son un nivel aparte.) |
| RN-002 | Un usuario puede tener más de un rol en el mismo proyecto. Sus permisos son la unión de los permisos de cada rol. |
| RN-003 | Un usuario puede tener roles distintos en proyectos distintos. |
| RN-004 | Un usuario sin rol asignado en un proyecto no puede verlo ni saber que existe. |
| RN-005 | Todo proyecto debe tener al menos un Product Manager asignado. Sin él, los casos de uso no pueden congelarse ni los planes aprobarse. |
| RN-006 | El rol Client es excluyente: un usuario con rol Client en un proyecto no puede tener otro rol en ese mismo proyecto. |
| RN-007 | La asignación y revocación de roles la ejecuta el Product Manager del proyecto, y queda registrada en auditoría. |
| RN-008 | El JWT de identity.flagare valida la identidad del usuario; sus permisos de plataforma (Admin / Product Manager) los entrega el servicio /me, no el token; los roles de proyecto los administra Argos QA. |
RN-008 depende de PA-007: el JWT valida la identidad y el servicio/meentrega los permisos de plataforma; falta el contrato de/me(forma de la respuesta, nombres de rol) y cómo se concilian con los roles de proyecto que administra Argos QA.
4. Matriz de permisos
✔ permitido · — denegado · ▲ permitido con condición, detallada bajo la tabla.
Acciones de plataforma
Autorizadas por el rol de plataforma, no por un rol de proyecto (que aún no existe o no aplica). El Admin, además, puede ejecutar cualquier acción de las tablas de proyecto que siguen, sin tener rol asignado en el proyecto.
| Acción | Admin | PM de plataforma |
|---|---|---|
| Importar/crear un proyecto de QA desde Argos Operaciones | ✔ | ✔ |
| Acceder a cualquier proyecto sin rol asignado en él | ✔ | — |
La administración de los roles/permisos de plataforma no es una acción de Argos QA: vive en identity.flagare. Argos QA los consume del token, no los otorga ni los revoca.
Proyectos y miembros
Roles de proyecto. El importador queda como Product Manager del proyecto al crearlo (RN-005); antes de eso, la autorización para importar es de plataforma (tabla anterior).
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Ver el proyecto | ✔ | ✔ | ✔ | ▲¹ |
| Editar datos del proyecto | ✔ | — | — | — |
| Asignar y revocar roles | ✔ | — | — | — |
| Archivar el proyecto | ✔ | — | — | — |
| Reactivar un proyecto archivado | ✔ | — | — | — |
| Forzar re-sincronización con Argos Operaciones | ✔ | ✔ | — | — |
Requerimientos y casos de uso
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Cargar un requerimiento | ✔ | ✔ | ✔ | — |
| Lanzar el análisis de IA | ✔ | ✔ | ✔ | — |
| Generar casos de uso con IA | ✔ | ✔ | ✔ | — |
| Crear un caso de uso manualmente | ✔ | ✔ | ✔ | — |
| Editar un caso de uso no congelado | ✔ | ✔ | ✔ | — |
| Pasar un caso de uso a En revisión | ✔ | ✔ | ✔ | — |
| Validar un caso de uso (mover a Validado) | ✔ | ✔ | ✔ | — |
| Congelar un caso de uso | ✔ | — | — | — |
| Crear una versión nueva desde una congelada | ✔ | ✔ | ✔ | — |
| Marcar un caso de uso como Obsoleto | ✔ | — | — | — |
| Ver casos de uso | ✔ | ✔ | ✔ | — |
Plan de pruebas y escenarios
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Generar el plan de pruebas con IA | ✔ | ✔ | — | — |
| Crear o editar escenarios | ✔ | ✔ | ▲² | — |
| Definir criterios de aceptación | ✔ | ✔ | — | — |
| Priorizar escenarios | ✔ | ✔ | — | — |
| Aprobar el plan de pruebas | ✔ | — | — | — |
| Retirar un escenario | ✔ | ✔ | — | — |
| Ver el plan y la matriz de cobertura | ✔ | ✔ | ✔ | — |
Ambientes
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Registrar y editar un ambiente | ✔ | ✔ | ✔ | — |
| Declarar referencias a secretos | ✔ | ✔ | ✔ | — |
| Resolver el valor de un secreto desde el vault | — | ▲³ | ▲³ | — |
| Marcar el checklist de readiness | ✔ | ✔ | ✔ | — |
| Ver la configuración del ambiente | ✔ | ✔ | ✔ | — |
Ciclos, ejecución y evidencia
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Abrir un ciclo de QA | ✔ | ✔ | — | — |
| Definir el alcance del ciclo | ✔ | ✔ | — | — |
| Cerrar o reabrir un ciclo | ✔ | ✔ | — | — |
| Ejecutar un escenario dentro de un ciclo | ✔ | ✔ | ✔ | — |
| Ejecutar un escenario suelto | ✔ | ✔ | ✔ | — |
| Registrar resultado y evidencia | ✔ | ✔ | ✔ | — |
| Ver evidencia | ✔ | ✔ | ✔ | — |
| Descargar evidencia | ✔ | ✔ | ✔ | — |
Bugs y bloqueos
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Crear un bug | ✔ | ✔ | ✔ | — |
| Cambiar la severidad de un bug | ✔ | ✔ | — | — |
| Asignar un bug a un miembro | ✔ | ✔ | ✔ | — |
| Avanzar el estado de un bug | ✔ | ✔ | ✔ | — |
| Cerrar un bug | ✔ | ✔ | — | — |
| Reabrir un bug | ✔ | ✔ | ✔ | — |
| Crear y editar un bloqueo | ✔ | ✔ | ✔ | — |
| Resolver un bloqueo | ✔ | ✔ | ✔ | — |
| Descartar un bloqueo (no era real) | ✔ | ✔ | ✔ | — |
| Ver bugs y bloqueos | ✔ | ✔ | ✔ | — |
Observabilidad y reportes
| Acción | PM | QA | Dev | Client |
|---|---|---|---|---|
| Ver el dashboard completo del proyecto | ✔ | ✔ | ✔ | — |
| Ver el reporte agregado de calidad | ✔ | ✔ | ✔ | ✔ |
| Exportar el reporte formal de calidad | ✔ | ✔ | — | ▲⁴ |
| Ver métricas de consumo de IA y storage | ✔ | ✔ | — | — |
| Ver el registro de auditoría | ✔ | ✔ | — | — |
Condiciones
- ▲¹ Client — visibilidad del proyecto. Ve que el proyecto existe y su nombre, pero
su navegación se limita al reporte agregado. No accede a ninguna otra vista.
- ▲² Developer — escenarios. Puede proponer y editar escenarios en estado
Generado
o Requiere cambios. No puede crear escenarios en un plan ya aprobado ni modificar uno en estado Aprobado.
- ▲³ Resolución de secretos. Argos QA nunca almacena valores de secretos
(RN-026). La resolución la hace el usuario contra el vault con sus propias credenciales; la plataforma solo muestra la referencia. Depende de PA-008.
- ▲⁴ Client — exportación. Puede exportar únicamente el reporte agregado que ya ve
en pantalla, en el mismo nivel de detalle. Nunca el reporte interno.
5. Lo que ningún rol puede hacer
Restricciones absolutas, sin excepción por rol:
| ID | Restricción | Motivo |
|---|---|---|
| RN-009 | Nadie edita un caso de uso en estado Congelado. | Sostiene la línea base de trazabilidad. |
| RN-010 | Nadie elimina evidencia. Solo expira por política de retención. | La evidencia es el respaldo de la validación. |
| RN-011 | Nadie edita ni borra un registro de auditoría. | El log es append-only por definición. |
| RN-012 | Nadie almacena el valor de un secreto en Argos QA. | Superficie de riesgo inaceptable. |
| RN-013 | Nadie registra un resultado de ejecución sin evidencia. | Es la regla que separa "validado" de "dije que lo probé". |
| RN-014 | Nadie crea un proyecto que no exista en Argos Operaciones. | Argos Operaciones es la fuente de verdad. |
6. Roles de la fuente que no existen en el MVP
El documento de Notion define seis roles. Se reducen a cuatro:
| Rol descartado | Sus responsabilidades pasan a |
|---|---|
| QA Lead | QA. Diseño del plan, supervisión de ciclos y validación de cobertura. |
| Tech Lead | QA y Developer. No hay una aprobación técnica formal en el MVP. |
| Stakeholder | Product Manager, para lo interno. Client, para lo externo. |
Si en el futuro se contrata QA dedicado, el rol QA ya existe y basta con asignarlo a una persona distinta del developer. El modelo no cambia.