Chatbot
Plataforma con un único chatbot configurable. Contexto: constitution.md, roadmap.md, specs/.
Desarrollo local
Requisitos: Node 22.9 o superior (npm run db:migrate usa --env-file-if-exists, que existe desde esa versión) y
Docker, para la base de datos.
npm install
docker compose up -d # PostgreSQL 17 en localhost:5432
cp .env.example .env.local # y completar ENCRYPTION_KEY con: openssl rand -base64 32
npm run db:migrate # aplica las migraciones de ./drizzle
npm run dev # http://localhost:3000
La app no arranca si falta DATABASE_URL o si ENCRYPTION_KEY no es de 32 bytes en base64.
Si el puerto 5432 ya está ocupado por otro PostgreSQL, cambia el puerto en docker-compose.yml
(por ejemplo "55432:5432") y ajusta el puerto en DATABASE_URL.
Para que el chatbot responda hay que cargar un proveedor (OpenAI u OpenRouter), un modelo y una API key en la
pantalla «Tu chatbot». Eso se guarda cifrado en la base, no en .env.local. Sin eso la plataforma funciona, pero el
chat no contesta.
Variable opcional: AGENDA_TIME_ZONE es la zona horaria de las citas (006). Por defecto, America/Bogota.
Agendamiento con Google (opcional, feature 006)
Sin estas variables todo funciona, pero el chatbot dice que no puede agendar citas. Para habilitarlo:
- En Google Cloud, crea un proyecto y habilita la API de Google Calendar.
- Configura la pantalla de consentimiento (en modo prueba basta, agregando la cuenta del negocio como usuario de prueba).
- Crea credenciales de tipo ID de cliente de OAuth → Aplicación web, con este URI de redirección autorizado:
http://localhost:3000/api/google/callback
- Copia el id y el secreto en
.env.local (GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, GOOGLE_REDIRECT_URI).
Después, en «Tu chatbot» → «Agendamiento de citas», conecta la cuenta y define el horario de atención.
Los permisos que se piden son los mínimos: crear eventos (calendar.events) y consultar disponibilidad
(calendar.freebusy). El permiso se guarda cifrado, igual que la API key.
Despliegue (Vercel + Supabase)
Variables de entorno en Vercel, solo en Production (las cadenas salen del botón «Connect» de Supabase):
DATABASE_URL — Transaction pooler (puerto 6543): la usa la app.DATABASE_MIGRATION_URL — Session pooler (puerto 5432): la usan las migraciones, que Supabase recomienda correr por la conexión directa o por este pooler, no por el de transacciones.ENCRYPTION_KEY — una nueva, distinta de la local. Si se pierde, hay que volver a cargar la API key y reconectar Google.
npm run build aplica las migraciones después de compilar, solo cuando VERCEL_ENV=production. Si fallan, el despliegue
no sale. Mientras corre el build, la versión anterior sigue atendiendo con el esquema nuevo: un cambio que borre o
renombre columnas se hace en dos despliegues.
Scripts
npm test — Vitest (unitarios e integración; requiere la base levantada)npm run lint, npm run typecheck, npm run buildnpm run db:generate — genera una migración a partir de lib/schema.ts
Para comprobar que quedó bien montado, con la base levantada:
npm test && npm run lint && npm run typecheck && npm run build
