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

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.

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

RN-008 depende de PA-007: el JWT valida la identidad y el servicio /me entrega 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.

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).

Requerimientos y casos de uso

Plan de pruebas y escenarios

Ambientes

Ciclos, ejecución y evidencia

Bugs y bloqueos

Observabilidad y reportes

Condiciones

1. ▲¹ 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.

1. ▲² 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.

1. ▲³ 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.

1. ▲⁴ 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:

6. Roles de la fuente que no existen en el MVP

El documento de Notion define seis roles. Se reducen a cuatro:

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.