--- canonical: https://gracialab.co/inside lang: es title: "Por dentro · GLab" description: "Mira cómo construimos y sostenemos GLab, capa por capa, con hechos que puedes revisar antes de confiarnos la tecnología de tu empresa." --- Por dentro # Antes de confiarle tu tecnología a alguien, mira cómo construye la suya. Una iniciativa puede fracasar antes de empezar por entender mal el problema y omitir planificación, arquitectura o diseño. Los sistemas desconectados frenan el trabajo, los datos imprecisos o tardíos demoran decisiones y la burocracia persiste cuando se desconoce otra forma de operar. Por eso mostramos nuestro sistema por dentro, capa por capa: qué resuelve cada una y cómo la sostenemos. ## Personas y agentes Tu equipo ya usa IA. Copia información en un chat, recibe una respuesta y el contexto queda en esa conversación. ### Qué está en juego Cuando la información queda aislada en conversaciones, el equipo repite trabajo y decide con un contexto incompleto. En GLab, un agente consulta en nombre de un usuario humano y dentro de sus permisos. ### Una situación que puedes reconocer #### Lo que alguien aprende queda en su chat personal. - **Lo que ocurre:** El equipo desconoce ese contexto y vuelve a resolver la misma pregunta. - **Cómo lo abordamos:** El usuario agente consulta la fuente de marca y GLab Platform con la autorización del usuario humano. #### La respuesta se apoya en una copia desactualizada. - **Lo que ocurre:** El asistente usa el documento pegado, aunque el original haya cambiado. - **Cómo lo abordamos:** Usuarios humanos y usuarios agentes consultan la misma información del sistema, con las mismas reglas de acceso. #### No sabes qué se compartió ni con qué asistente. - **Lo que ocurre:** Cada usuario decidió por su cuenta qué información de la empresa enviar. - **Cómo lo abordamos:** El permiso vincula usuario humano, aplicación y organización: cada conexión tiene identidad y acceso definidos. ### En nuestro sistema - El usuario humano autoriza la conexión en una pantalla que identifica la aplicación y el acceso solicitado. - Retirar su membresía impide que el agente vuelva a consultar esa organización. // contexto para nerds - `OAuth 2.1 · PKCE S256` Conexión de Claude Code y Codex CLI con consentimiento y permisos delegados por el usuario humano. - `CIMD` Identidad de aplicación por URL exacta en una lista permitida. - `RFC 8707 · RFC 9728` Una credencial por recurso de organización. - `RFC 7662` Introspección sin caché: emisor, audiencia, vigencia y permiso de lectura. - `Streamable HTTP` MCP conecta al usuario agente con herramientas mediante una credencial propia, separada de la sesión del usuario humano. - `readOnlyHint: true` Consultas con autorización explícita. El sistema registra los permisos concedidos y las credenciales emitidas. - `/admin ⇄ /o/{orgSlug}/mcp` Usuarios humanos y usuarios agentes comparten lectura y reglas de acceso. Una prueba mantiene esa correspondencia. Cada consulta vuelve a comprobar el permiso antes de responder. ## Una sola identidad Una misma identidad sostiene el acceso de cada usuario humano y los permisos que delega a su agente. ### Qué está en juego Resolver por separado el acceso de usuarios humanos y agentes añade gestiones cada vez que alguien se incorpora o se va. La autorización tiene que seguir al usuario en todo el sistema. ### Una situación que puedes reconocer #### Cada usuario consulta la IA desde su cuenta. - **Lo que ocurre:** El acceso a la información se resuelve conversación por conversación. - **Cómo lo abordamos:** El acceso al sistema y su delegación a un agente parten de la misma identidad. #### Un usuario se va y deja trabajo en sus chats. - **Lo que ocurre:** La información queda dispersa y el cierre de accesos se revisa aparte. - **Cómo lo abordamos:** La baja revoca el acceso del usuario humano y sus usuarios agentes en el sistema, vinculados a una misma membresía. #### Buscas un archivo para darle contexto a la IA. - **Lo que ocurre:** Usas una cuenta prestada porque el archivo está fuera de tu acceso. - **Cómo lo abordamos:** Cada usuario humano entra con su identidad y autoriza el acceso de su usuario agente. ### En nuestro sistema - El servicio de identidad permite entrar con Google o correo, sin crear una contraseña. - Las operaciones sensibles requieren una confirmación adicional del usuario humano. // contexto para nerds - `Better Auth` ID es el único emisor de sesiones. Platform las lee y el libro las verifica con ID. - `WebAuthn` Llaves de acceso con verificación de usuario en el dispositivo. - `emailOTP · HMAC` El código del correo queda ligado al navegador que lo solicitó. - `1 · 2_local` Los servicios críticos exigen un factor local de GLab. - `step-up ≤ 5 min` Las operaciones críticas requieren una confirmación reciente. La identidad tiene un solo emisor. Los usuarios humanos reciben sesiones y los usuarios agentes, autorización delegada. ## Servicios dedicados Un servicio debe sostener decisiones, datos y operación. Lo diseñamos para integrarse al conjunto y evolucionar con el negocio. ### Qué está en juego El acceso, el mantenimiento y el seguimiento acompañan toda la vida de una solución. Convertir ese trabajo en tareas automáticas y flujos repetibles permite concentrarse en lo que hace avanzar al negocio. ### Una situación que puedes reconocer #### Una función está lista para usarse. - **Lo que ocurre:** Sus accesos, su mantenimiento y su seguimiento quedan por resolver. - **Cómo lo abordamos:** Estamos construyendo servicios que integren accesos, mantenimiento y seguimiento, con reglas y responsables claros. #### Una falla obliga a reunir alertas de varios sistemas. - **Lo que ocurre:** Cada equipo revisa sus propias señales. Reconstruir lo ocurrido demora la decisión. - **Cómo lo abordamos:** Estamos construyendo una lectura común de la operación que conecte señales y dé contexto a cada decisión. #### Otro producto necesita aplicar las mismas reglas de marca. - **Lo que ocurre:** Vuelves a reunir las reglas de marca y las instrucciones. - **Cómo lo abordamos:** Una fuente de marca reúne diseño y reglas para el equipo y sus agentes. ### En nuestro sistema - Platform reúne una identidad, una fuente de marca y un mapa, con permisos por organización. - Estamos construyendo servicios complejos, integrados y agénticos, hechos para la operación de cada organización. // contexto para nerds - `SERVICE_SLUGS = ['ds', 'obs']` Diseño y observabilidad definen los primeros servicios que estamos construyendo para cada organización. - `/o/{orgSlug}/{service}` Controles de organización, membresía y servicio habilitado en el servidor. - `404` Organizaciones ajenas y servicios no habilitados no se revelan. - `CHECK (nivel_minimo in ('1', '2_local'))` La base restringe los niveles de seguridad admitidos. - `Una transacción` La organización, su administrador y sus servicios se crean juntos. La dirección une organización y servicio. Estamos construyendo sobre esa base una operación integrada, con acceso y seguridad propios. ## Base compartida Las aplicaciones crecen con coherencia cuando comparten piezas esenciales y mantienen visible cómo encajan. ### Qué está en juego La arquitectura define qué comparten las aplicaciones y cómo se relacionan. Hacer visibles esas decisiones permite aprovechar lo que ya funciona y saber qué probar cuando algo cambia. ### Una situación que puedes reconocer #### Tu empresa suma una aplicación. - **Lo que ocurre:** Repites el acceso y las reglas de marca del proyecto anterior. - **Cómo lo abordamos:** Identidad y marca conectan las aplicaciones desde una base compartida. #### Una pieza compartida necesita una corrección. - **Lo que ocurre:** Buscas qué productos conservan una copia y cuáles dependen de ella. - **Cómo lo abordamos:** Las dependencias declaradas determinan qué pruebas activa el cambio. #### Necesitas entender cómo encajan tus sistemas. - **Lo que ocurre:** Reúnes documentos dispersos y preguntas a distintas personas para reconstruir el conjunto. - **Cómo lo abordamos:** Usuarios humanos y agentes consultan un mapa del sistema según sus permisos. ### En nuestro sistema - Una base compartida de identidad y marca da coherencia a las aplicaciones y lleva cada mejora a las que la usan. - Cerca del 30 % del código de producto vive en paquetes compartidos. // contexto para nerds - `pnpm + Turborepo` Tareas con entradas, salidas y variables declaradas. - `workspace:*` Paquetes compartidos por interfaces públicas. Las aplicaciones no se importan entre sí. - `catalog:` Una versión para cada dependencia compartida. - `minimumReleaseAge` Espera de seguridad antes de adoptar versiones recién publicadas. - `turbo run --affected` Selecciona pruebas por dependencias e insumos declarados. Un cambio en la interfaz compartida activa pruebas en identidad y Platform, que la consumen. ## Calidad en cada capa Una solución debe ser útil y confiable. Elegimos las pruebas según lo que podría fallar y lo que ese fallo pondría en riesgo. ### Qué está en juego El software conecta decisiones, personas y datos. Verificar cada capa exige una estrategia: desde una regla de acceso hasta el recorrido que alguien necesita completar. ### Una situación que puedes reconocer #### La IA te entrega código que parece correcto. - **Lo que ocurre:** La explicación resulta convincente. Su funcionamiento aún está por comprobar. - **Cómo lo abordamos:** Cada cambio activa las pruebas de lo que afecta, antes de publicarse. #### Cambian los permisos de acceso. - **Lo que ocurre:** La nueva configuración parece razonable, pero nadie intenta acceder sin autorización. - **Cómo lo abordamos:** Las protecciones se prueban intentando también lo que deben impedir. #### Una prueba falla y luego pasa al repetirla. - **Lo que ocurre:** El segundo resultado da tranquilidad y el primer fallo queda sin explicar. - **Cómo lo abordamos:** Un fallo se conserva y se investiga. Un segundo intento exitoso no lo borra. ### En nuestro sistema - En la factoría agéntica, los ingenieros definen la arquitectura y el diseño. Los agentes escriben código bajo su dirección y revisión. - Cerca del 50 % de nuestro código son pruebas. // contexto para nerds - `pnpm test:change` Selecciona por alcance las pruebas y los recorridos afectados. Las guardas se comprueban con casos negativos o mutantes. - `pre-push` Exige un recibo completo y aprobado para el cambio, con el árbol limpio. También comprueba estilo y tipos. - `Playwright` Recorridos sobre la aplicación compilada. Accesibilidad con axe en identidad y libro. Rendimiento y estabilidad visual según TESTING.md. La evidencia acompaña al cambio desde las pruebas hasta su revisión y publicación. ## Lo que construimos habla por nosotros. La tecnología que creamos y seguimos desarrollando para GLab muestra lo que podemos construir. Hablemos de lo que debe ser posible en tu empresa. [Da el siguiente paso](https://gracialab.co/contact)