Files

Carlos Narro 89166857e7 Doc despliegue: añade notas de integración para Simón (GETs, a pulir)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-08 17:28:41 +02:00

3.7 KiB

Raw Blame History

Despliegue — Luisa (bot WhatsApp) + image-worker

Los tres servicios de Reformix corren unidos en el mismo VPS (Dokploy personal, panel.carlosnarro.com, proyecto Reformix / entorno production). Build por Dockerfile desde Gitea (carlos/reformix-hackaton, rama main, autodeploy en push).

Servicios

Servicio	App en Dokploy	Repo (buildPath)	Dominio	Puerto
App principal	`reformix-b2c` (`lzHDAuPuubbJu94OrkNS_`)	`/mvp/b2c`	`reformix.dv3.com.es`	3000
Bot WhatsApp (Luisa)	`reformix-bot` (`wY4F14fyEslU-4za_JIbi`)	`/mvp/Whatsapp-bot`	`reformix-bot.dv3.com.es`	3001 (webhooks)
Worker de renders	`reformix-worker` (`sMQd9zwoyV14q1vm8Vs8U`)	`/mvp/image-worker`	`reformix-worker.dv3.com.es`	3001

El bot escucha la app NestJS en 3000 y los webhooks entrantes en 3001 (/whatsapp-start, /whatsapp-pdf). El dominio público enruta al 3001. Sesión de WhatsApp persistida en un volumen montado en /app/auth_info_baileys.

Webhooks configurados en reformix-b2c

WHATSAPP_START_WEBHOOK_URL = https://reformix-bot.dv3.com.es/whatsapp-start
WHATSAPP_WEBHOOK_URL       = https://reformix-bot.dv3.com.es/whatsapp-pdf
PERFIL_WEBHOOK_URL         = https://reformix-worker.dv3.com.es/perfil-completo

El bot y el worker llaman de vuelta a la API de b2c con API_BASE_URL/REFORMIX_API_URL = https://reformix.dv3.com.es y Authorization: Bearer <FUNNEL_API_KEY> (la misma de b2c, ya puesta).

Pasos manuales pendientes (no automatizables)

OPENROUTER_API_KEY — está vacía en reformix-bot y reformix-worker. Pégala en el env de ambas apps (panel de Dokploy → app → Environment) y redeploy de ambas. Sin ella el bot no genera respuestas y el worker no genera renders.
Vincular WhatsApp (QR) — abre los logs de reformix-bot en Dokploy: Baileys imprime un QR en ASCII. Escanéalo con el WhatsApp del número del negocio. La sesión queda persistida en el volumen (sobrevive redeploys). Sin restricción de número (ALLOWED_NUMBER no está configurada): el bot conversa con cualquiera que le escriba.

Verificación (estado a 08-jun-2026)

Builds Docker de bot y worker: OK a la primera. Certs Let's Encrypt emitidos (TLS válido).
GET https://reformix.dv3.com.es/ → 200 · POST …/perfil-completo (worker) → 400 (vivo) · POST …/whatsapp-start (bot) → 200 (vivo).
Tras poner la OPENROUTER_API_KEY + escanear el QR, el flujo queda end-to-end: lead elige WhatsApp → iniciarWhatsapp → bot conversa y puebla la BD por los EPs → perfilCompleto → worker genera renders → ingesta finalizar → PDF + email + entrega por WhatsApp.

Operación

Redeploy: push a main (autodeploy Gitea) o POST /api/application.deploy {applicationId}.
Los GET que el bot consume (GET /api/leads/:id, GET /api/leads/:id/conversacion) viven en mvp/b2c. Smoke test de los EPs del bot: mvp/b2c/api-docs/smoke-bot-eps.mjs.

Notas de integración para Simón (menores, a pulir)

Los 2 GET que usa tu api-client y no existían en la API ya están añadidos y desplegados: GET /api/leads/:id (estado del lead) y GET /api/leads/:id/conversacion (historial). Ya responden.
En POST /perfil mandas nombre, pero la API no actualiza ese campo (lo ignora). Si quieres poder cambiar el nombre del lead desde el bot, lo hablamos.
No estás enviando calidadGlobal (basica/media/premium), que usa el motor de presupuesto. Si Luisa lo puede extraer, mándalo en POST /perfil.
Contrato completo de los EPs (campos, enums, ejemplos): mvp/b2c/api-docs/README.md.

3.7 KiB Raw Blame History