Accesos

El acceso a Auroria Factory se decide con dos piezas separadas, y separarlas es el punto:

• Un nivel de acceso dice qué puede hacer una persona. Es donde viven los permisos. Cada persona tiene exactamente uno.
• Un grupo dice en qué fases puede participar. Es identidad y audiencia. No concede ningún permiso. Una persona puede estar en tantos grupos como haga falta.

Los permisos son acumulativos: sumar permisos solo añade capacidades, nunca las resta. Y el principio más importante sigue siendo el de visibilidad:

Personas sin nivel. Cuando alguien entra y todavía no tiene nivel asignado, la plataforma lo lleva a una sala de espera con el mensaje «Tu acceso está siendo configurado». Ahí no puede hacer nada hasta que un administrador le asigne uno; en cuanto se lo asignas, entra automáticamente sin tener que volver a iniciar sesión. Es lo que le pasa a toda cuenta recién creada: dar de alta a una persona ya no concede acceso (ver Usuarios).

La pantalla de Accesos

Todo vive en Configuración → Accesos, la primera pestaña de la sección y la pantalla a la que Configuración te lleva por defecto. Requiere el permiso Administrar roles: sin él no verás la sección de Configuración en absoluto.

Son dos zonas: la matriz de acceso ocupa el centro y el panel de grupos vive a la derecha. Por debajo de pantallas anchas el panel se apila debajo de la matriz.

La matriz de acceso

Una fila por permiso y una columna por nivel. Las filas van agrupadas por módulo —Plataforma, Board, Dependencias, Estrategia, NewsRoom y Proyecto— y la primera columna, Privilegio, se queda fija al desplazarte en horizontal, igual que la cabecera al desplazarte en vertical.

Cada celda es un interruptor: ✓ concede el permiso en ese nivel, – no lo concede. Bajo el nombre de cada nivel aparece a cuántas personas afecta esa columna. La columna de tu propio nivel aparece resaltada.

Al pulsar Guardar, la plataforma te dice a cuántas personas vas a afectar antes de escribir nada: «Vas a cambiar los niveles Gestor (12), Admin (4). Afecta a 16 personas. ¿Continuar?». Al confirmar, cada persona ve el cambio en su siguiente petición; no hace falta que vuelva a entrar.

El botón Exportar descarga la matriz completa como matriz-de-acceso.csv, con el estado que tengas en pantalla (incluidos los cambios sin guardar).

Los cuatro avisos de la matriz

La matriz revisa el estado final de lo que tienes en pantalla y avisa de cuatro cosas. Los cuatro son avisos, no muros: puedes guardar igualmente.

El panel de Grupos

A la derecha, bajo el título Grupos, la lista de grupos con el nombre y el número de personas, y nada más. Al pie, Nuevo grupo abre un diálogo que pide Nombre (obligatorio, 100 caracteres) y Descripción (opcional, 500). No hay ningún campo de permisos, a propósito.

Dar acceso a una persona

El acceso de cada persona se concede en un solo sitio: su ficha, en Configuración → Usuarios, pulsando su nombre (o Accesos en el menú de la fila). El diálogo de Editar de un usuario ya no toca el acceso — solo identidad y pertenencia organizativa.

La ficha exige los permisos Administrar usuarios y Administrar roles.

Si solo cambias grupos, el panel lo aclara: «Los grupos no conceden ningún permiso: el acceso de la persona no varía».

Referencia de permisos

Aquí está el corazón de esta página: qué desbloquea cada casilla de la matriz. Para cada permiso verás qué aparece o se habilita, a qué nivel suele dársele, y de qué otros permisos depende. Los nombres son los que la matriz muestra, servidos por el catálogo del servidor.

Permisos de plataforma

Construir factorías · platform:build_factories

• Qué habilita: el ítem de menú Construir Factorías (sección Construcción) y Knowledge Base (sección Análisis); el listado de Factorías, el asistente para crear una factoría, el Sandbox de factoría, el registro de conexiones MCP, el editor y listado de conocimiento de cada factoría y la configuración de búsqueda avanzada. También destraba ajustes de agentes de QA dentro del Board.
• Piénsalo para: arquitectos y administradores que diseñan y mantienen las factorías.
• Depende de: nada. Es uno de los permisos que la plataforma trata como «de superadmin». La Knowledge Base del menú se controla con este permiso (no tiene uno propio).

Administrar roles · platform:manage_roles

• Qué habilita: la entrada Configuración del menú lateral (¡la llave de toda la sección!) y la pestaña Accesos: la matriz de permisos × niveles y el panel de grupos. También habilita escalar a un superadmin cuando una fase queda a la espera de una decisión, y es el segundo permiso que exige la ficha de acceso de una persona.
• Piénsalo para: administradores de la plataforma.
• Depende de: nada, pero es la puerta de entrada: como abre Configuración, cualquier otro permiso de esa sección (Usuarios, Ecosistemas, Centro de Ayuda, Catálogo de Board) solo se alcanza por el menú si la persona también tiene Administrar roles.

Administrar usuarios · platform:manage_users

• Qué habilita: la pestaña Usuarios dentro de Configuración, para ver y administrar las cuentas (alta, datos, estado) y abrir la ficha de acceso de cada persona.
• Piénsalo para: administradores.
• Depende de: vive dentro de Configuración, así que en la práctica se acompaña de Administrar roles para poder llegar a la pestaña.

Administrar equipos · platform:manage_teams

• Qué habilita: crear, editar y eliminar equipos y sus miembros.
• Piénsalo para: administradores que definen la estructura de equipos.
• Depende de: la pestaña Equipos de Configuración se muestra a cualquiera que pueda abrir Configuración, tenga o no este permiso. El control real de este permiso ocurre al guardar: sin él, la plataforma rechaza los cambios sobre equipos aunque veas la pantalla.

Administrar ecosistemas · platform:manage_ecosystems

• Qué habilita: la pestaña Ecosistemas dentro de Configuración, el catálogo de ecosistemas que luego usan las factorías y los proyectos.
• Piénsalo para: administradores.
• Depende de: vive dentro de Configuración (se acompaña de Administrar roles). No confundir con editar los ecosistemas de un proyecto concreto, que se controla con Crear proyectos.

Crear líneas de ensamblaje · platform:create_assembly_lines

• Qué habilita: el ítem de menú Líneas de ensamblaje (sección Construcción) y las acciones para crear y administrar líneas dentro de esa pantalla.
• Piénsalo para: arquitectos y administradores que encadenan factorías.
• Depende de: nada.

Crear proyectos · platform:create_projects

• Qué habilita: el botón Crear proyecto y el asistente de creación de proyectos; además, editar los ecosistemas de un proyecto desde su detalle.
• Piénsalo para: líderes de producto y quien arranca proyectos nuevos.
• Depende de: este permiso abre el botón y el asistente. Al confirmar la creación la plataforma valida además el permiso de proyecto Crear proyecto (project:create); son dos piezas distintas de la misma acción.

Ver métricas · platform:view_metrics

• Qué habilita: el ítem de menú Métricas (sección Análisis) y su tablero de indicadores, con sus cuatro pestañas (Plataforma, Proyectos, Mesa de Ayuda —si además gestionas soporte— y Board —si además ves ese módulo—). También deja leer cualquier análisis con IA de un indicador ya generado por otra persona.
• Piénsalo para: líderes de producto, dirección y cualquiera que haga seguimiento.
• Depende de: nada.

Generar análisis de métricas con IA · platform:analyze_metrics

• Qué habilita: el botón Generar análisis (o Regenerar análisis) sobre un indicador de Métricas, que dispara la lectura con IA de las cifras y sus fuentes. Sin este permiso, el botón de generar no aparece —solo la lectura de análisis ya generados—, porque generar uno consume tokens.
• Piénsalo para: quien decide gastar tokens en un análisis, no solo consultarlo.
• Depende de: Ver métricas. Es un prerrequisito declarado: la matriz avisa si marcas este permiso en un nivel que no concede Ver métricas.

Ver factorías · platform:view_factories

• Qué habilita: el ítem de menú Factorías y las sugerencias basadas en factorías que aparecen dentro del Board. Es el permiso más repartido: casi todos los perfiles lo tienen.
• Piénsalo para: prácticamente todos los perfiles; es el «permiso base» de acceso.
• Depende de: con solo este permiso ves la entrada Factorías en el menú, pero abrir el listado completo de factorías requiere hoy además Construir factorías; sin él, al entrar se te redirige a una pantalla de acceso denegado. La matriz lo avisa: Construir factorías declara Ver factorías como prerrequisito.

Gestionar el Centro de Ayuda · platform:manage_support

• Qué habilita: convierte al usuario en gestor del Centro de Ayuda. Aparece la pestaña Centro de Ayuda en Configuración (la bandeja de gestión de tickets); dentro del propio Centro de Ayuda cambia tu vista de «Mis solicitudes» a la bandeja de gestión, y el contador del menú pasa a mostrar los tickets abiertos de la bandeja en vez de tus solicitudes. También habilita una sección de soporte en el tablero de métricas y determina quién puede ser asignado como gestor de un ticket.
• Piénsalo para: el equipo de soporte o mesa de ayuda.
• Depende de: nada declarado. La bandeja vive en Configuración, así que en la práctica se acompaña de Administrar roles para llegar por el menú.

Gestionar las noticias del NewsRoom · newsroom:manage

• Qué habilita: la pestaña NewsRoom en Configuración, con todo su gestor de contenidos: crear, editar, programar, publicar y eliminar noticias, y administrar sus categorías.
• Piénsalo para: quien comunica producto — no exige darle nada más de Configuración.
• Depende de: nada. Es independiente del Centro de Ayuda y del resto de Configuración. Sin él no se ve la pestaña. Leer las noticias no requiere ningún permiso: el chip Novedades y el aviso al entrar los ve todo el mundo (ver Novedades).

Permisos de Board

En la matriz estas filas van bajo el encabezado Board. Todas necesitan Ver el módulo Board para servir de algo: sin él no hay ningún sitio donde ejercerlas, y así está declarado como prerrequisito.

Ver el módulo Board · backlog:view

• Qué habilita: el ítem de menú Board y todas sus pantallas (el Board, detalle de una tarjeta, Checkpoints, métricas del Board, archivados); comentar en las discusiones del Board; y la pestaña Catálogo de Board dentro de Configuración.
• Piénsalo para: cualquiera que participe en el Board.
• Depende de: nada. Es la base de todos los demás permisos de Board.

Ver los Boards de todos los equipos · backlog:view_all_teams

• Qué habilita: alcance global sobre el módulo: ver y actuar sobre los Boards de equipos a los que no perteneces. Sin él, cada persona solo tiene alcance sobre su propio equipo y la plataforma rechaza guardar cambios en equipos ajenos.
• Piénsalo para: administradores globales del Board o una PMO.
• Depende de: Ver el módulo Board.

Gestionar cards de equipo (nivel 1) · backlog:manage_level1

• Qué habilita: crear y editar las tarjetas de equipo (nivel 1): agregar hallazgos, administrar secciones, acciones del Board de nivel 1 y acciones en Scopes y discusión.
• Piénsalo para: líderes de equipo y dueños de Board.
• Depende de: Ver el módulo Board.

Gestionar Checkpoints de desarrollo (nivel 2) · backlog:manage_level2

• Qué habilita: crear y editar los Checkpoints de desarrollo (nivel 2): registrar bugs, crear subelementos y trabajar el kanban de Checkpoints y el panel de detalle.
• Piénsalo para: desarrolladores y QA que gestionan el trabajo técnico.
• Depende de: Ver el módulo Board.

Reabrir cards cerradas o archivadas · backlog:reopen

• Qué habilita: el botón Reabrir en la vista de archivados para devolver a la vida tarjetas cerradas.
• Piénsalo para: líderes que corrigen cierres prematuros.
• Depende de: Ver el módulo Board (y ver los archivados).

Configurar el catálogo global de Board · backlog:manage_catalog

• Qué habilita: crear y editar los tipos del catálogo global de Board en Configuración → Catálogo de Board.
• Piénsalo para: administradores del Board (permiso «de superadmin»).
• Depende de: exige también Ver el módulo Board. La pestaña se muestra con «Ver módulo de Board», pero editar el catálogo necesita este permiso; y sin «Ver módulo de Board» la pantalla del catálogo no carga aunque tengas este.

Activar tipos de Board por equipo · backlog:manage_team_backlogs

• Qué habilita: el botón Activar tipo y el enlace Ajustes de QA del equipo en la portada de Board de cada equipo, para encender qué tipos de Board usa un equipo.
• Piénsalo para: líderes de equipo.
• Depende de: Ver el módulo Board.

Diseñar planes y casos de prueba · backlog:qa_design

• Qué habilita: la barra de diseño de planes de prueba: crear un Nuevo caso, editar el plan y sus suites.
• Piénsalo para: analistas de QA y diseñadores de pruebas.
• Depende de: Ver el módulo Board. La pestaña de QA de un equipo requiere además Ver el módulo Board y Activar tipos de Board por equipo.

Ejecutar ciclos de prueba · backlog:qa_execute

• Qué habilita: ejecutar los ciclos de prueba y Cerrar ciclo cuando terminan.
• Piénsalo para: testers que ejecutan las pruebas diseñadas.
• Depende de: Ver el módulo Board.

Permisos del Mapa de dependencias

En la matriz van bajo el encabezado Dependencias. Todos necesitan Ver el mapa de dependencias para servir de algo, y así está declarado. El módulo se explica en Mapa de dependencias.

Ver el mapa de dependencias · dependencies:view

• Qué habilita: el ítem de menú Dependencias (sección Espacios) y sus cinco vistas — Seguimiento, Sin asignar, Kanban, QBR vivo y Grafo — en modo lectura sobre toda la organización (la transparencia del mapa es total; lo que restringen los demás permisos es la escritura).
• Piénsalo para: cualquiera que participe en la coordinación entre equipos.
• Depende de: nada. Es la base de los demás permisos de Dependencias.

Registrar dependencias · dependencies:register

• Qué habilita: el botón Registrar dependencia de la vista Seguimiento, para crear dependencias en dirección «requiero» (mi equipo pide).
• Piénsalo para: miembros de equipo que piden cosas a otros equipos.
• Depende de: Ver el mapa de dependencias.

Gestionar las dependencias de mi equipo · dependencies:manage

• Qué habilita: Asignármela en la bandeja Sin asignar; editar, mover de estado y arrastrar en el kanban las dependencias donde alguno de tus equipos pide o resuelve; y descartar/restaurar las que tu equipo solicitó. La pertenencia se valida en el servidor contra tus equipos reales, no contra la perspectiva elegida.
• Piénsalo para: los miembros del equipo que operan sus dependencias del día a día.
• Depende de: Ver el mapa de dependencias.

Asignar dependencias a cualquier equipo · dependencies:assign

• Qué habilita: el alcance de PM o líder: Asignar a equipo… en la bandeja, registrar en dirección «proveo» (a nombre de otro equipo) y editar, mover, descartar o restaurar cualquier dependencia sin restricción de equipo.
• Piénsalo para: PMs, líderes o una PMO que reparte el trabajo entre equipos.
• Depende de: Ver el mapa de dependencias.

Permisos de Estrategia

En la matriz van bajo el encabezado Estrategia. Todos necesitan Ver la estrategia y sus resultados para servir de algo, y así está declarado. El módulo se explica en Estrategia.

Ver la estrategia y sus resultados · strategy:view

• Qué habilita: el ítem de menú Estrategia (sección Análisis), la pantalla completa (KPIs, objetivos, resultados clave, histórico), la página Análisis IA en lectura y la tarjeta de análisis que aparece en el QBR del Mapa de dependencias.
• Piénsalo para: cualquiera que deba conocer los OKR de la organización.
• Depende de: nada. Es la base de los demás permisos de Estrategia.

Registrar check-ins de resultados clave · strategy:checkin

• Qué habilita: el botón Check-in de cada resultado clave, la única forma de actualizar su valor actual. Solo funciona con el período activo (un período en borrador o cerrado no admite check-ins).
• Piénsalo para: dueños de objetivos y quienes reportan el avance.
• Depende de: Ver la estrategia y sus resultados. Quien tiene Gestionar periodos, objetivos y vínculos también puede hacer check-ins sin esta casilla.

Gestionar periodos, objetivos y vínculos · strategy:manage

• Qué habilita: Gestionar período (crear, activar, cerrar, eliminar borradores), crear, editar y eliminar objetivos y resultados clave, Vincular iniciativa (lo que define qué proyectos son estratégicos y con qué peso) y escribir los Ajustes del módulo (la factoría por defecto del análisis). Incluye la capacidad de hacer check-ins.
• Piénsalo para: dirección o la PMO que administra la estrategia.
• Depende de: Ver la estrategia y sus resultados. El selector de factorías de los Ajustes requiere además Ver factorías; sin él, la factoría por defecto se muestra como dato fijo.

Ejecutar el análisis estratégico con IA · strategy:analyze

• Qué habilita: el botón Analizar con IA (en Estrategia, en el QBR y en la página Análisis IA), cancelar un análisis en curso (el candado es global: no hace falta ser quien lo lanzó) y resolver las sugerencias del informe. También permite leer los Ajustes del módulo.
• Piénsalo para: quienes conducen el QBR trimestral.
• Depende de: Ver la estrategia y sus resultados. Para aceptar una sugerencia hace falta además el permiso del módulo destino: las de impacto de una dependencia exigen Gestionar las dependencias de mi equipo o Asignar dependencias a cualquier equipo; las de vínculos y contribuciones exigen Gestionar periodos, objetivos y vínculos.

Permisos de proyecto

Se evalúan dentro de un proyecto y sus fases; en la matriz van bajo el encabezado Proyecto. Para que un nivel pueda trabajar en proyectos conviene que tenga, como mínimo, poder listar y leer proyectos (abajo); el resto se apoya en eso.

Ejecutar factoría · project:execute_factory

• Qué habilita: iniciar el trabajo de una fase — escribir el primer mensaje del chat de fase para arrancar la factoría. Sin él, la fase muestra «No tienes permiso para ejecutar fábricas en este proyecto».
• Piénsalo para: el equipo que opera las fases del proyecto.

Subir documentos · project:upload_documents

• Qué habilita: la zona Cargar documentos de una fase, para aportar insumos.
• Piénsalo para: colaboradores que suben material de apoyo.

Aprobar resultados · project:approve_output

• Qué habilita: los botones Aprobar output y Rechazar de una fase, aprobar y completar la fase, y borrar artefactos generados por la factoría.
• Piénsalo para: el dueño del proyecto o el revisor que valida entregables.

Ver todas las fases · project:view_all_phases

• Qué habilita: ver todas las fases del proyecto, no solo las asignadas a tu perfil. La plataforma lo comprueba al devolver las fases; no enciende un botón por sí solo.
• Piénsalo para: líderes y dueños que necesitan la foto completa del proyecto.

Administrar documentos · project:manage_documents

• Qué habilita: gestionar (incluido eliminar) los documentos de una fase.
• Piénsalo para: el dueño del proyecto o quien lleva la gestión documental.

Administrar estado del proyecto · project:manage_status

• Qué habilita: el menú de acciones de estado y la barra de estado del proyecto (activar, pausar, archivar…), incluido Activar proyecto cuando está radicado.
• Piénsalo para: el dueño o líder del proyecto.

Exportar proyecto · project:export

• Qué habilita: el botón Exportar ZIP con todos los artefactos del proyecto.
• Piénsalo para: quien entrega o archiva los resultados.

Listar proyectos · project:list

• Qué habilita: que el listado de Proyectos te devuelva proyectos. El ítem de menú Proyectos es visible para todos, pero sin este permiso la lista aparece vacía. También alimenta los desplegables de equipos y ecosistemas del asistente de creación.
• Piénsalo para: cualquier persona que deba ver proyectos. De fábrica lo tienen los cinco niveles, empezando por Observador.

Leer proyecto · project:read

• Qué habilita: abrir el detalle de un proyecto y sus fases. Sin él, aunque veas el proyecto en la lista, no puedes entrar en él.
• Piénsalo para: cualquier persona que deba trabajar dentro de un proyecto. De fábrica lo tienen los cinco niveles, empezando por Observador.

Crear proyecto · project:create

• Qué habilita: la creación efectiva del proyecto. Es la validación que acompaña al botón Crear proyecto (que se muestra con el permiso de plataforma Crear proyectos).
• Piénsalo para: quien realmente crea proyectos, junto con Crear proyectos. De fábrica lo tienen Business Owner y por encima.

Los cinco niveles de fábrica

La plataforma trae cinco niveles, y son de sistema: no se borran ni cambian de código. Lo que sí puedes cambiar —y es el trabajo normal de esta pantalla— es qué permisos concede cada uno, celda a celda.

Están anidados: cada nivel contiene todo lo del anterior y añade lo suyo. Ese anidamiento no es una regla del sistema, es cómo llegan sembrados; la matriz avisa si lo rompes.

La matriz completa, nivel a nivel

Este es el reparto de fábrica. Si alguien ha editado la matriz, lo que manda es la pantalla.

Prerrequisitos entre permisos

Son 26 parejas. La matriz avisa —no bloquea— si marcas el de la izquierda sin el de la derecha.

Preguntas frecuentes

Relación con otros módulos

• Usuarios — donde se abre la ficha de cada persona para darle su nivel y sus grupos.
• Líneas de ensamblaje — cada fase declara sus Grupos con acceso: ahí es donde un grupo sirve para algo.
• Equipos — la estructura organizativa, independiente de grupos y niveles.
• Centro de Ayuda — el permiso de gestión define quién administra la bandeja de tickets.
• NewsRoom — su permiso es independiente del resto de Configuración.
• Board — todo el módulo se enciende con «Ver el módulo Board».
• Mapa de dependencias y Estrategia — cada uno con sus cuatro permisos.
• Proyectos y Fases — donde actúan los permisos de proyecto.