64 lines
3.7 KiB
Markdown
64 lines
3.7 KiB
Markdown
# 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
|
|
|
|
```ini
|
|
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)
|
|
|
|
1. **`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.
|
|
2. **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`](../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`](../mvp/b2c/api-docs/README.md).
|