Cómo funciona el sistema a nivel de componentes: frontend en Vercel, API en Railway, datos en Supabase, IA con Claude, alertas en Slack, correo con Resend y despliegues automatizados desde Git — sin exponer secretos ni lógica propietaria.
Git versiona el código y dispara los deploys. El frontend orquesta la experiencia de usuario; el backend ejecuta scrape, comparación, IA y notificaciones. Railway Cron dispara el ciclo diario.
| Capa | Tecnología | Rol |
|---|---|---|
| Frontend | Next.js en Vercel | UI, auth Supabase, llama al API |
| Backend | FastAPI en Railway | Scrape, comparación, IA, notificaciones, OAuth Slack |
| Datos | Supabase Postgres + Auth + Storage | Monitores, checks, eventos, baselines DOCX/PDF |
| Deploy | Git + GitHub | Control de versiones; push a main dispara deploy automático en Vercel y Railway |
Todo ocurre dentro de una sola aplicación Python en Railway. No hay workflow externo entre pasos.
El backend consulta el buscador público del BCR con los filtros del monitor y localiza el documento por código de referencia.
Obtiene la versión actual del documento normativo directamente del sitio del BCR.
Compara contra la última versión en Supabase Storage. Si el hash es idéntico, termina como “sin cambios”.
Si el archivo cambió, Anthropic API analiza ambas versiones y devuelve un resumen estructurado en español.
Persiste el resultado de la corrida, el evento de cambio y la nueva baseline si hubo modificaciones sustanciales.
Según la configuración del monitor: chat.postMessage en Slack y/o correo transaccional vía Resend.
API oficial de Anthropic desde el backend Python. Usos: comparación de documentos normativos y bot de Slack con tools (correr monitor, activar/desactivar, etc.).
Los tokens se registran por operación para control de costos. Los prompts y parámetros del modelo no se publican.
OAuth: /slack/install → callback → token guardado en slack_connections.
Alertas: chat.postMessage al canal configurado.
Bot: Event Subscriptions en POST /slack/events — patrón estándar Slack App + backend propio.
Schedule diario en Railway (ej. 14:00 UTC). No ejecuta Python suelto: hace una petición HTTP autenticada al propio API.
POST api.bcr-monitor.com/run. Recorre todos los monitores activos.
Dominio verificado bcr-monitor.com. Remitente: no-reply@bcr-monitor.com.
Correos transaccionales: monitor creado, cambios detectados, sin cambios. El frontend no envía correos — todo vía API REST de Resend desde el backend.
Postgres: monitores, checks, change_events, conexiones Slack, logs de tokens IA.
Auth: login del panel; cada monitor se asocia al user_id.
Storage: bucket baselines con versiones DOCX/PDF para comparar.
Wizard: POST /bcr/search → elegir documento → POST /monitors.
Dashboard, historial de checks, conexión Slack, run manual con POST /run/{id}.
No scrapea el BCR, no llama a Anthropic ni envía Slack/email directamente.
El código no se despliega a mano: Git es el punto de partida y Vercel y Railway publican cada versión estable automáticamente.
El código del frontend y del backend vive en repositorios Git en GitHub. Cada cambio queda versionado con historial, ramas y revisiones antes de llegar a producción.
Vercel está conectado al repo del frontend. Cada push a main dispara build de Next.js y publica la nueva versión del panel y las páginas públicas.
Railway está conectado al repo del backend. Cada push a main reconstruye la API FastAPI, la reinicia en producción y mantiene el cron diario en el mismo servicio.
La narrativa de IA está en el pitch; la landing tiene la demo. El panel autenticado es donde los equipos operan sus monitores.