Invitaciones y equipos: la invitación abre la puerta, y la credencial se va con la persona

Hasta agosto de 2026 este producto vendía asientos de equipo, los vigilaba de verdad y no tenía ninguna forma de invitar a nadie: la pantalla de ajustes decía que las invitaciones por correo llegarían en la fase siguiente. Sentar a un segundo piloto en un estudio era imposible. Lo que se construyó después no es una pantalla: son cuatro decisiones sobre quién entra, quién sale y qué se lleva.

Una sola mano escribe la pertenencia

La tabla de miembros la escribe la capa de autenticación y nadie más. La API de Python la lee —para pintar la lista y para resolver el papel de cada petición— y no la escribe nunca. Un endpoint de invitación allí sería un segundo escritor de la tabla que vigila el tope del plan, y ese tope dejaría de estar en el camino de nadie: se podría vaciar un asiento por un lado y llenarlo por el otro sin que la puerta se enterara.

Por eso el tope vive en los tres ganchos del complemento de organizaciones que escribe esas tablas, que son los tres únicos sitios donde puede nacer una fila de miembro en un estudio que ya existe. Y una invitación pendiente ocupa asiento: sin eso, dos plazas y un miembro dejan crear cinco invitaciones que pasan de una en una y fallan después en la cara de cuatro personas.

La invitación abre la puerta de la beta, y es revocable

Hay dos listas y no son la misma: la nuestra decide quién puede crear cuenta durante la beta cerrada, y la del cliente decide con quién trabaja. Sin cruzarlas, el invitado choca contra el alta y acaba en la pantalla de acceso limitado: el asiento se cobra y no lo puede ocupar nadie.

La condición está anclada a la invitación y tiene dos mitades, porque ninguna sola sirve:

• una invitación viva para esa dirección, que es lo que deja crear la cuenta y aceptar;
• o seguir siendo miembro del estudio que invitó, que es lo que deja seguir entrando después.

Con solo la primera, el acceso se caería en la misma transacción que acepta. Con solo la segunda quedaría abierto para siempre a cualquiera con cuenta, porque cada cuenta estrena su propia organización al darse de alta. Anclada así, sacar a alguien del estudio le vuelve a cerrar la puerta el mismo día.

Ni aceptar ni rechazar se hacen con un enlace. Los escáneres de muchos buzones abren todo lo que llega, y aquí un clic de robot mete a alguien en la organización de otro y le gasta una plaza; rechazar tampoco, porque lo que se pierde es una invitación que solo puede volver a mandar otra persona.

Pertenecer a dos estudios

Desde que un cliente puede invitar a su equipo hay cuentas con más de una organización, y durante un tiempo el estudio cambiaba solo: al aceptar, la sesión se movía al nuevo; al volver a entrar se devolvía el más antiguo, que es siempre el propio. Sin error y sin forma de elegir.

La preferencia se guarda en la cuenta y no se cree nunca: se cruza con la pertenencia en la misma consulta, porque entre dos inicios de sesión a esa persona la pueden haber sacado, y devolver un estudio que ya no es suyo deja todas las pantallas contestando un conflicto. Tampoco lleva clave foránea, a propósito: una clave haría creer que esa columna es una pertenencia, y es un recuerdo comprobado.

El selector se pinta junto al logotipo y solo con dos o más: un desplegable de un elemento en la cabecera de treinta y tres pantallas es ruido. Y aterriza en la portada del estudio, no en la página de la que se venía: casi toda dirección de dentro lleva el identificador de algo del otro estudio, así que volver a ella sería un 404 en el instante de cambiar de sitio, y eso se lee como «se ha borrado mi rodaje».

Bajar de plan no echa a nadie

Es una decisión escrita, no un descuido. Un estudio que baja de Estudio a Piloto con cuatro personas conserva las cuatro; lo que pierde es la posibilidad de sumar una quinta, y la cuenta se cuadra sola cuando alguien se va. Expulsar a un miembro es un acto con dueño —el del estudio—, y no una comparación numérica dentro de un webhook que elegiría por orden de alta.

Sacar a alguien no borra su trabajo

Los rodajes, los vuelos y los documentos cuelgan del estudio, y ninguna tabla del dominio apunta a una cuenta: la fila que desaparece no toca ni una. Eso es la decisión y no una casualidad — un estudio que pierde su libro de vuelo el día que se va un piloto no es una herramienta de cumplimiento.

La otra mitad hay que decirla: un registro firmado por alguien no se puede desfirmar. El piloto de un vuelo es una ficha del estudio, no una cuenta, y las trazas que sí llevan cuenta —quién subió un documento, quién puntuó una respuesta, quién invitó a quién— se quedan. Anonimizarlas sería reescribir el pasado para que cuadre con el presente.

Y al último que puede administrar no se le quita el papel: un estudio sin nadie en ese escalón no puede cobrar, ni invitar, ni cambiar su página, y no se repara desde dentro. Por eso tampoco puede salirse el único miembro, y la pantalla lo dice antes de pulsar.

La credencial que se va con la persona

Este era el agujero que nadie miraba. La sesión del navegador muere sola con la pertenencia y la puerta de la beta se cierra sola; la credencial de la extensión, no. La consulta llegaba a la tabla de miembros por un LEFT JOIN, la fila ausente llegaba como papel nulo, y el valor por defecto puesto para un papel ilegible readmitía a esa persona como miembro de pleno derecho.

O sea que el token que vive en el portátil de quien acaba de irse seguía entrando, y es la única credencial que uno se lleva físicamente. Se cierra con una palabra: LEFT JOIN pasa a JOIN. Sin lista que mantener, y comprobado que la prueba cae si alguien vuelve a escribirla.

---

<!-- ↑