Identidad y autenticación

La decisión

• Transporte a Toteat: una sola cuenta de servicio para el box, con permisos plenos, para que Toteat nunca bloquee una acción.
• Atribución: la lleva nuestro registro. Como todo viaja con la cuenta de servicio, Toteat ya no distingue una persona de otra: quién abrió, quién marchó y quién anuló se decide y se guarda aquí (AuditLog, y el nombre que muestra la comanda). A quien además existe en Toteat se le siguen estampando su iu y su iul, pero eso ya no es lo que sostiene la atribución.
• Operadores: autenticación propia con PIN sobre una sesión de dispositivo. Cambiar de mesero es un tap, nunca un logout/login de Toteat.
• Permisos: los hace cumplir nuestra UI con un modelo de roles limpio (mesero, barra, jefa de servicio, admin), por encima de Toteat.

Esto resuelve el dolor del “desloguéate para cobrar” sin perder la atribución que Toteat necesita. La cuenta de servicio es el único set de credenciales contra Toteat; el operador nunca toca el login de Toteat.

Qué guardamos en nuestro backend

Guardar	Para qué
Operator: nombre, correo, rol, contraseña y PIN (hash), permisos, hidden_in_picker, toteat_user_id opcional	identificar a la persona, permisos y atribución
Device: las tablets (token de dispositivo)	confianza del dispositivo, sin relogin constante
AuditLog: quién, qué, cuándo, resultado	accountability propia y el objetivo de “nadie le pide ayuda a Julián”
Sesión de la cuenta de servicio (caché del token)	hablar con Toteat, con auto-relogin
Caché de salón y catálogo (memoria o Redis)	velocidad y lecturas en modo degradado

hidden_in_picker saca a alguien de la lista de caritas con la que el salón elige quién autoriza, sin quitarle nada: sigue activa, sigue entrando y su PIN sigue autorizando. Es para quien está en el sistema pero no trabaja el turno (la administradora, un socio), de modo que no se le atribuya una marcha por error. Dar de baja sí quita el acceso. Ninguna de las dos puede dejar la lista vacía: el salón se quedaría sin poder autorizar lo que esté configurado “por operador”.

Qué NO guardamos

Menú, productos, órdenes, facturas ni datos fiscales. Eso es de Toteat. Solo se referencia por id y se cachea en tránsito.

El flujo

1. La tablet mantiene una sesión de dispositivo persistente con nuestro backend.
2. El operador se identifica con su PIN (por acción o por sesión corta).
3. Para escribir en Toteat, el backend usa la sesión de la cuenta de servicio y estampa el iu del operador en el payload.
4. Toteat emite y registra; nosotros además dejamos el registro en nuestra auditoría.

Usuarios: el equipo es nuestro

El mesero ya no necesita existir en Toteat. La administradora lo registra desde el POS (Ajustes, Equipo): nombre, correo, rol, permisos y una contraseña temporal. Esa persona vive solo en nuestra base, y Toteat la ve siempre como la cuenta de servicio.

El registro queda a medias a propósito, y lo termina su dueña:

1. La administradora registra y le dicta la contraseña temporal.
2. Esa persona entra con correo y contraseña. Como todavía no tiene PIN, la app la lleva derecho al onboarding y no la deja hacer nada más.
3. Crea su PIN. Ahí queda completo, y con ese PIN autoriza sus acciones.

Su PIN no lo sabe nadie más, ni quien la registró. Por eso no hay forma de ponerle el PIN a otra persona: solo de borrárselo, y entonces lo vuelve a crear al entrar. Lo que sí se le puede reponer es la contraseña, que es lo único que se reparte.

Y como esa contraseña se la dictó alguien más, cualquiera puede cambiar la suya desde Mi cuenta, pidiéndole la actual. Sin eso, la temporal se quedaría para siempre y la seguiría sabiendo quien la registró.

• Quien venía de Toteat conserva su toteat_user_id y su iul, que se siguen estampando. A los nuevos no se les inventa ninguno.
• Nunca hubo sync de dos vías y sigue sin haberlo. La importación desde la lista de meseros de Toteat (import_waiters) queda como ayuda de arranque, no como el camino normal.

Permisos

• La cuenta de servicio tiene permisos plenos en Toteat, así no bloquea.
• Nuestra UI decide quién puede anular, cobrar, mover ítems, juntar mesas, etc.
• El control fino vive en nuestro modelo de roles, no en el enredo de permisos de Toteat.

Pendientes y riesgos

• Verificar el iu estampado: hay que confirmar que Toteat respeta un iu enviado por el cliente bajo la cuenta de servicio. Se prueba en la ingeniería inversa de la primera escritura (abrir mesa o agregar ítem). Si Toteat no lo respeta, habría que pasar a sesiones por operador (más complejo).
• Refresco de sesión (~16h): el cliente re-loguea solo con las credenciales de la cuenta de servicio, que viven en .envs/.production del box, nunca en el repo.
• Seguridad del PIN: hash, intentos limitados. Los PIN viven solo en nuestro backend.