Un permiso no es un rango. Un permiso no es un admin.
En los bots de Discord y guild managers clásicos, tienes la opción entre miembro, moderador y admin. Tres niveles, cero finura. Game Org ofrece una rejilla de permisos técnicos atómicos: cada acción sensible tiene su propio permiso, asignable por separado, sin que tengas que darlo todo para delegar una parte.
- Decenas de permisos atómicos, no tres rangos — «Puede validar un ascenso a oficial», «Puede crear un evento secreto», «Puede editar las formaciones de su sección», «Puede gestionar los permisos de los miembros». Cada acción sensible tiene su permiso dedicado, asignable a quien tú quieras
- Cascada lógica, no explosión combinatoria — el permiso Admin de la orga lo engloba todo, Admin de formaciones engloba todas las acciones de formación, Admin de eventos cubre todos los tipos de eventos. Configuras la cima de la cascada, el resto sigue — sin necesidad de marcar treinta casillas
- Ámbitos explícitos — global, su sección o sus propios contenidos. Un jefe de sección puede editar las formaciones de su sección sin ver las de las demás. Un contribuidor de misiones puede editar sus misiones, no las del vecino
- Cero rol comodín — nada de «moderador majo que aun así puede hacerlo todo porque se confía en él». La confianza no se codifica, los permisos sí
Proponer no es validar.
La mayoría de las herramientas funcionan con la lógica «si puedes ejecutar la acción, puedes lanzarla tú solo». Game Org separa sistemáticamente el permiso de proponer del permiso de validar. Un oficial puede sugerir un ascenso sin firmarlo — decide un oficial superior. La jerarquía está cableada, no es implícita.
- En los ascensos, dos permisos sistemáticamente separados — RH puede proponer y RH puede validar, para cada uno de los 4 niveles de rango. Un suboficial puede estar autorizado a proponer un oficial sin poder validarlo. Ocho permisos RH atómicos, no un botón de admin que lo abre todo
- Misma lógica del lado de la formación — un miembro realiza su formación, pero un permiso dedicado Validar las formaciones de su sección es necesario para confirmar el éxito. El miembro no se entrega a sí mismo su propio certificado
- Rechazo obligatoriamente motivado — si una propuesta es rechazada, el solicitante recibe el motivo. No hay mensajes que se esfumen, ni «te rechazo pero no te digo por qué»
- Imposible autopromocionarse, imposible desbloquear la excepción «solo por esta vez» en un vocal a la una de la madrugada. El flujo es una protección contra la fatiga de decisión
Tu orga no es un catálogo público.
Algunas herramientas gaming conocidas — catálogos de flota, wikis comunitarios, registros abiertos — están construidas para ser indexadas por Google y scrapeadas por los rivales. Las composiciones de tus tripulaciones, tus asignaciones, tu roster táctico: expuestos al mundo. Game Org hace lo contrario: tu orga no tiene ninguna página pública por defecto.
- Ninguna URL pública para tu flota, tus efectivos, tus eventos, tus formaciones. Nada adivinable desde fuera. Un outsider que pruebe /orgs/tu-nombre cae en un login, no en tu roster
- Contraste directo con Fleetyards y similares — están concebidos como escaparates, Game Org como una caja fuerte. Dos filosofías opuestas, una elección según lo que consideres una ventaja competitiva
- El contenido público de tu orga es cero por defecto. Ningún opt-out que entender, ninguna casilla que desmarcar en un ajuste oscuro. Eres invisible mientras no decidas lo contrario
- Tus competidores no ven nada — ni tus composiciones de misión, ni tus eventos próximos, ni quién asciende en tu orga. Saben que existes, no saben lo que haces
Cada orga, un silo. Cero derrame lateral.
El servidor Game Org filtra sistemáticamente los datos por identificador de orga. Cada petición está ligada a una sola orga — un usuario autenticado en la orga A no verá nunca los datos de la orga B, aunque sea miembro de ambas en Discord. No hay un panel global Game Org que agregue tus datos con los de tus rivales.
- Estanqueidad por tenant — un miembro que pertenece a varias orgas alterna de una a otra, nunca en paralelo. Misma lógica que dos servidores Discord distintos: estás en uno o en otro, nunca en los dos al mismo tiempo
- Sin superposición de permisos — tus permisos Admin de la orga en una orga no dan ningún acceso a otra. Cada orga gestiona sus propios permisos, sus propios rangos, su propia jerarquía
- En cada consulta el servidor verifica en qué orga estás antes de devolver el menor dato. La verificación es sistemática, no opcional, no eludible con una URL pirateada. Imposible que un dato de otra orga llegue a ti por error
- Sin plantilla de configuración compartida que filtre — tú configuras tu orga, tu rejilla es tuya, tus etiquetas son tuyas. Nada cruza la frontera, ni siquiera tu estructura organizativa
Sin cuenta, sin contraseña, sin credenciales que robar.
Cada vez que una herramienta te pide una contraseña, creas una superficie de ataque. Una contraseña reutilizada en otro sitio, un phishing que cuela, una base de logins que filtra — y tu orga queda comprometida por un error que ni siquiera es tuyo. Game Org no tiene cuenta local: la autenticación pasa por Discord, la fuente de verdad de identidad que tus miembros ya usan.
- Sin contraseña Game Org que gestionar, por tanto nada que olvidar, nada que resetear, nada que robar. Sin base local de logins que proteger a nivel de infraestructura
- Acceso atado a Discord — cuando un miembro es retirado de tu orga (baja External desde el módulo RH), sus accesos Game Org caen automáticamente vía la propagación Discord
- Sin sesiones huérfanas arrastrándose seis meses después de la marcha de un oficial. Sin ex-miembro que conserve un token olvidado en una pestaña de un PC viejo
- Si Discord bloquea una cuenta (violación de TOS, cuenta comprometida), Game Org lo refleja. Un único login, una única fuente de verdad de identidad, ninguna divergencia que vigilar
FAQ
Preguntas frecuentes
¿Qué impide concretamente a un oficial autopromocionarse?
La separación RH puede proponer / RH puede validar. Proponer un ascenso y validarlo son dos permisos separados, asignados a escalones jerárquicos diferentes. Un suboficial puede proponer un oficial, no tiene derecho a validar — ese permiso está reservado al escalón superior. Si un oficial intenta autopromocionarse, la acción pasa a la cola de un oficial superior que acepta o rechaza con motivo obligatorio. Los Admins de la orga, que técnicamente tienen la cascada completa, dejan huella en el activity feed de RH en cada decisión — ni siquiera ellos pueden actuar en silencio.
¿Puede otra orga ver mis datos?
No. Cada petición está delimitada a nivel de servidor por el identificador de orga. Un usuario autenticado en la orga A que intentara acceder a un recurso de la orga B recibiría un rechazo, no un dato por error. Un miembro que pertenece a varias orgas alterna entre ellas, nunca en paralelo: está en una o en otra, como en dos servidores Discord distintos. Sin vista global que agregue, sin plantilla compartida que filtre, sin permisos que crucen la frontera. Tus rivales pueden ser clientes de Game Org igual que tú, nunca verán tus composiciones.
¿Qué pasa si un miembro deja Discord o si tu orga lo retira?
Dos casos. Si abandona Discord por sí mismo (o si su cuenta queda bloqueada), su acceso Game Org cae en la siguiente verificación de identidad — ya no es autenticable. Si tu orga lo retira vía el módulo RH (baja External), la propagación Discord retira automáticamente el rol de miembro: sin acceso a los canales internos, sin acceso a los espacios Game Org vinculados a ese rol. Su historial queda archivado del lado Game Org para auditoría, pero ya no puede consultar ni modificar nada. Si algún día vuelve a postularse vía el módulo Reclutamiento, su antiguo dossier reaparece con el flag «Sospechoso».
¿Puede Game Org impedir una fuga voluntaria (copia-pega, captura)?
Honestamente: no. Ninguna herramienta SaaS puede impedir que un usuario legítimo haga una captura de pantalla de lo que ve legítimamente — en el peor caso no quedarás más expuesto que con una captura de tu Discord. Lo que Game Org puede hacer es minimizar lo que cada usuario ve legítimamente. El principio de menor privilegio tomado en serio: un reclutador con únicamente el permiso Ver candidaturas no ve el resto. Un miembro de una sección no tiene acceso a las misiones de las otras secciones. Cuanto menor sea la superficie expuesta a cada rol, menos lejos llegará una fuga potencial. Game Org no promete lo imposible, reduce el perímetro de lo posible.
¿Cómo saber, en cualquier momento, quién tiene qué permisos en mi orga?
El módulo Gestión de permisos, accesible a los Admins de la orga en vista completa, y a los jefes de sección en versión restringida (que gestionan solo los permisos de sus propios miembros). En dos clics ves quién puede hacer qué, sobre qué módulo — sin tener que rebuscar en diez pantallas distintas ni reconstruir una tabla a mano. Un nuevo staff que toma un puesto puede auditar en cinco minutos los permisos vigentes desde su toma de posesión, sin esperar a topar con una acción bloqueada para entender quién puede qué. Los ascensos, pases a reserva y exclusiones RH se trazan además en el activity feed de RH — el resto de las modificaciones de permisos se consultan directamente en el módulo Gestión de permisos.
¿Cómo protege Game Org los datos a nivel técnico?
Arquitectura compartimentada: backend aplicativo separado de la base de datos, acceso a la BD únicamente vía la API interna — sin exposición directa. Todos los flujos de usuario pasan por SSL/TLS, sin excepción. Cada petición API está autenticada y delimitada por identificador de orga antes de llegar a la capa de datos. La arquitectura está pensada para multi-tenant estricto y escalado. No comunicamos públicamente sobre la localización física de los servidores ni sobre detalles de bajo nivel de infraestructura — estos elementos evolucionan con la plataforma.