Ultima fase del bot de reservas: conecta la maquina de conversacion ya
existente (whatsapp-bot.ts) con la WhatsApp Business Cloud API.
- src/lib/whatsapp.ts: traduce RespuestaBot -> payloads de Meta (texto e
interactive/button, con los limites de 3 botones / 20 chars / 4096 chars),
aplana el payload del webhook y valida X-Hub-Signature-256 en tiempo
constante.
- src/app/api/whatsapp/webhook/route.ts: GET de verificacion y POST de
mensajes. Valida la firma sobre el cuerpo crudo, deduplica por message id
(Meta reintenta) y siempre devuelve 200 para no entrar en loop de retries.
- scripts/test-whatsapp-envio.ts (npm run test:envio): 30 asserts sobre la
capa Meta con fetch stubbeado, sin DB ni credenciales.
- docs/whatsapp.md con el alta en el panel de Meta y las 4 env vars.
Falta solo cargar las credenciales de Meta en el .env de produccion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- lib/turnos.ts: crearTurno() compartido (valida servicio/jefe/slot); cliente/turnos POST lo reutiliza
- lib/telefono.ts: normalización de teléfono (E.164 sin '+') para matchear el wa_id
- lib/whatsapp-bot.ts: procesarMensaje(telefono, texto), state machine completa:
identidad por teléfono + verificación por email registrado / alta nueva,
elegir mecánico (botones) -> trabajo (letras) -> horario (letras, con "más") -> confirmar,
crea turno sin auto/km; expiración 30min, "cancelar" global, manejo de inválidos y 409.
Devuelve objetos-respuesta (texto/botones) -> independiente de Meta (lo traduce F0).
- scripts/test-whatsapp-bot.ts + npm run test:bot: corre la máquina de estados con un
Prisma en memoria (sin DB ni Meta), ejercitando scheduling y crearTurno reales. 27/27 OK.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cuando el admin marca un turno como COMPLETADO escribe una fila
en el sheet con patente, km, auto, cliente, fecha y trabajo.
Auth via service account con JWT nativo (sin googleapis).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reemplaza Resend por nodemailer con Gmail SMTP. El to: ahora usa
el email real del cliente en lugar del hardcodeado de sandbox.
Variables de entorno: GMAIL_USER y GMAIL_APP_PASSWORD.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Páginas cliente: login magic link, registro, validación de token,
dashboard de autos, historial por auto y reserva de turnos con selector
de servicio + slots disponibles.
Páginas admin: login, dashboard de turnos del día con cambio de estado,
historial de autos (buscar cliente → auto → ver/cargar registros),
gestión de tipos de servicio y vista de clientes.
Middleware JWT para proteger rutas /cliente/* y /admin/*.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Estructura inicial con Next.js 14, PostgreSQL/Prisma 7, autenticación por
magic link (clientes) y JWT (admins), lógica de scheduling con 4 slots
paralelos y API routes completas para cliente y panel admin.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>