Qué cambia
Se agregan al docker-compose.yml las cuatro variables de entorno necesarias para el bot de WhatsApp (WHATSAPP_PHONE_NUMBER_ID, WHATSAPP_TOKEN, WHATSAPP_VERIFY_TOKEN,…
Qué cambia
Se agrega validación de rol en la verificación de sesión: verificarSesion y verifyCookie ahora reciben el rol esperado (`"admin"
Mismo caso: se quitó el check de rol explícito. Si verificarSesion no valida el rol, esto abre acceso indebido. Verificá la implementación en auth-admin.ts.
El cast (payload as { role?: string }) asume que el JWT siempre tiene un campo role. ¿Confirmaste que los tokens generados al loguear (admin, jefe, cliente) incluyen ese claim? Si no, la validación siempre fallará y nadie podrá acceder.
Qué cambia
Se agrega la funcionalidad completa para que el cliente logueado vea y edite su perfil (nombre, apellido, email, teléfono). Incluye: endpoint GET/PATCH /api/cliente/perfil con…
Importás verificarSesion desde auth-admin.ts para validar la cookie cliente_session. Verificá que esa función valide correctamente el rol de cliente y no solo la existencia de la sesión de admin. Si reutiliza lógica de admin, podría haber escalada de privilegios.
Guardás el teléfono en formato local en el campo telefono y en formato WhatsApp en telefonoNorm. El GET lee telefonoNorm primero y hace fallback a telefono. Si telefonoNorm existe, telefono es redundante. Confirmá que el schema tenga @@unique([telefonoNorm]) y @@unique([email]) para que la BD sea la fuente de verdad.
Condición de carrera: la verificación de unicidad de email/teléfono y el update no son atómicos. Dos requests simultáneos pueden pasar la verificación y fallar en el update (o peor, si no hay constraint única en BD, duplicar datos). Usá una transacción de Prisma o confia en el constraint único y atrapá el error P2002.
Qué cambia
Se agrega validación y normalización de teléfonos argentinos en el registro de clientes: el frontend muestra prefijo fijo "+54 9" y acepta solo 10 dígitos (característica sin 0,…