Qué Pinta Salta
Agenda cultural automatizada de Salta Capital. Sitio en producción: quepintasalta.com.ar
Estructura (monorepo, npm workspaces + Turborepo): el sitio está en apps/web/; packages/db tiene los tipos generados de Supabase, packages/core la lógica de dominio compartida con la app y packages/config el tsconfig base. supabase/, .github/, docs/ y scripts/db/ siguen en la raíz. En este README, las rutas de código (lib/…, app/…, components/…) son relativas a apps/web/. Los comandos npm run … se corren desde la raíz.
Descripción y problema que resuelve
La oferta de eventos de Salta Capital está fragmentada entre ticketeras que no se hablan entre sí (NorteTicket, EntradaUno, AlPogo, el portal provincial Vamos Salta) y, sobre todo, entre historias y posteos de Instagram de boliches y productores independientes, donde la información vive como imagen y texto libre — no como dato.
El resultado para el usuario es que no existe un único lugar donde ver qué hay para hacer esta noche, y para los organizadores, que su evento aparece disperso o directamente no aparece.
Qué Pinta Salta resuelve eso con un pipeline de ingesta multi-fuente que:
- Extrae eventos de cuatro ticketeras (tres vía API JSON, una vía scraping HTML) y de cuentas de Instagram monitoreadas a través de Apify.
- Estructura los flyers de Instagram con Gemini 3.5 Flash-Lite como extractor multimodal: la imagen del flyer más el caption entran, y sale un JSON con título, fecha, hora, precio, lugar, categoría y artistas, validado contra un
responseSchema estricto.
- Deduplica eventos que aparecen en varias fuentes usando similitud de títulos (Jaccard con normalización y stop words, umbral 0.65) acotada a mismo venue y mismo día calendario. Cuando hay match, no crea un duplicado: fusiona los links de compra en un array
ticket_sources y se queda con el precio más bajo y la mejor imagen.
- Decide con un filtro determinista en TypeScript — no con la IA — si un evento se auto-publica o cae a revisión humana en un panel admin.
El punto de diseño importante es el número 4: el modelo extrae, pero no publica. La compuerta es código, y es auditable.
Arquitectura
flowchart TB
subgraph FUENTES["Fuentes de datos"]
NT["NorteTicket<br/>HTML + Cheerio"]
VS["Vamos Salta<br/>API EntradaUno Salta"]
EU["EntradaUno<br/>JSON en CDN S3"]
AP["AlPogo<br/>API POST getEvents2"]
IG["Instagram<br/>cuentas monitoreadas"]
CIN["Cinemark Alto Noa<br/>y Cine Ópera"]
end
subgraph INGESTA["Ingesta"]
CRON1["Vercel Cron 08:00<br/>GET /api/cron/scrape"]
SA["Server Action<br/>triggerSourceScrape<br/>panel /admin/scrape"]
CRON2["Vercel Cron 00:00 V-S-D-L<br/>GET /api/cron/instagram"]
APIFY["Actor Apify<br/>instagram-post-scraper<br/>polling hasta SUCCEEDED"]
WH["POST /api/webhooks/apify<br/>entrada alternativa"]
CINAPI["GET /api/scrape-cinemas"]
end
subgraph AI["Extracción multimodal"]
STORE["Descarga de imagen y<br/>re-upload a Supabase Storage<br/>bucket flyers_ig"]
FLY[("instagram_flyers<br/>ai_status = PENDING")]
BATCH["POST /api/ai/process-flyers<br/>lote de hasta 10"]
GEM["Gemini 3.5 Flash-Lite<br/>imagen + caption -> JSON<br/>responseSchema estricto"]
end
subgraph NORM["Normalización y decisión"]
CAT["inferCategorySlug<br/>keywords + aliases de BD"]
VEN["upsertVenue<br/>resolución de lugar"]
TZ["saltaWallClockToUtcISO<br/>hora de Salta -> instante UTC"]
GATE{"¿título + fecha +<br/>hora + lugar?"}
DEDUP["upsertEventWithDeduplication<br/>similitud 0.65, mismo venue y día<br/>fusiona ticket_sources"]
end
subgraph DB["Supabase Postgres con RLS"]
EVP[("events<br/>status = PUBLISHED")]
EVD[("events<br/>status = DRAFT")]
EVPEND[("events<br/>status = PENDING")]
MOV[("cinema_movies")]
end
subgraph APP["Next.js App Router"]
REV["/admin/revision<br/>split-screen flyer vs formulario"]
PEND["/admin/pendientes<br/>aprobación de envíos"]
WEB["Home, /buscar, /evento/id,<br/>/cines, /favoritos, /radar"]
MAIL["Radar por email<br/>Resend"]
end
NT --> CRON1
VS --> SA
EU --> CRON1
AP --> CRON1
NT --> SA
EU --> SA
AP --> SA
CIN --> CINAPI
IG --> APIFY
CRON2 --> APIFY
APIFY --> STORE
WH --> STORE
STORE --> FLY
FLY --> BATCH
BATCH --> GEM
GEM --> GATE
CRON1 --> CAT
SA --> CAT
CAT --> VEN
VEN --> TZ
TZ --> DEDUP
GATE -->|"sí"| TZ
GATE -->|"no"| EVD
GEM -.->|"error de IA o imagen rota"| EVD
DEDUP --> EVP
CINAPI --> MOV
EVD --> REV
REV -->|aprobar| EVP
EVPEND --> PEND
PEND -->|aprobar| EVP
EVP --> WEB
MOV --> WEB
EVP --> MAIL
Notas sobre el flujo real
- Solo Instagram pasa por Gemini. Las otras cuatro fuentes devuelven datos ya estructurados (JSON de API en Vamos Salta, EntradaUno y AlPogo; DOM parseado con Cheerio en NorteTicket) y se normalizan con código determinista. No hay LLM en esa ruta.
- Existen dos rutas de ingesta para las ticketeras: el cron diario usa los providers de
app/api/cron/scrape/providers/, y el panel admin usa los scrapers de lib/scraper/ mediante Server Actions. La diferencia práctica es que la ruta manual además visita la página de detalle de cada evento, así que trae descripción real y clasifica mejor; el cron se queda con lo que hay en el listado.
- La clasificación tiene tres niveles de prioridad: alias definidos por un admin en la tabla
aliases (override manual), inferencia por keywords de inferCategorySlug, y fallback a espectaculos. El campo classification_source deja registro de cuál ganó.
- Los flyers de Instagram tienen TTL de 14 días:
archiveExpiredFlyers corre al final del cron de scraping y los pasa a ARCHIVED.
- Si Gemini falla (timeout, imagen ilegible, error de API), el pipeline no descarta el flyer: crea un evento
DRAFT con título Revisar: Flyer de @cuenta, marca el flyer como FAILED y lo deja en la cola de revisión humana con el caption original como descripción.
Manejo de horarios
events.start_date es timestamptz y guarda el instante UTC real. Las fuentes, en cambio, publican la hora de pared de Salta sin zona (2026-08-07T21:00:00), igual que los <input type="datetime-local"> de los formularios. La conversión entre ambos mundos vive en lib/date-format.ts y es obligatoria en los dos sentidos:
- Al escribir:
saltaWallClockToUtcISO(). Es idempotente — si el valor ya trae Z u offset explícito, lo respeta.
- Al leer:
formatEventDate / formatEventTime / formatSaltaDayKey / formatSaltaClock, todas ancladas a America/Argentina/Salta.
La única excepción es instagram_flyers.published_at, que Apify entrega como instante UTC real y no se convierte. Cuando Gemini no logra extraer la fecha del flyer, ese valor se usa como start_date tal cual.
Nunca hay que hacer start_date.split('T')[0] ni toISOString().split('T')[0] para obtener el día: devuelven el día UTC y corren la fecha en cualquier evento de la noche. Para eso está formatSaltaDayKey().
Deduplicación de eventos
El mismo evento entra por varias fuentes a la vez y sin dedup queda como N filas con datos contradictorios. La clave de agrupación es título normalizado + día calendario de Salta (lib/scraper/dedup-key.ts): sin diacríticos, en minúsculas, sin sufijo de ciudad ("EN SALTA", "Salta 2026", "Salta Capital") y con los espacios colapsados. El venue no entra en la clave, pero sí en la decisión: dos filas con la misma clave se fusionan solo si el venue es compatible (el mismo venue canónico, o a una le falta). Así, dos boliches con "Fiesta de fin de semana" el mismo sábado siguen siendo dos eventos. Los grupos de misma clave con venues distintos aparecen en el dry-run como "NO SE FUSIONAN" para revisarlos a mano.
Cuando dos registros coinciden pero difieren en un campo, gana la fuente de mayor prioridad (lib/scraper/source-priority.ts):
| Tramo | Peso | Fuentes | Por qué |
|---|
| Ticketera oficial | 400 | norteticket, entradauno, alpogo, … | Vende la entrada: si el evento se mudó de sala o cambió de horario, su dato tiene que estar bien o no cobra |
| Portal provincial | 300 | vamos | Agenda oficial, confiable pero copiada a mano y lenta para los cambios |
| Carga manual | 200 | formulario de admin/colaborador | Puede ser más precisa que cualquier scraper, pero nadie vuelve a editarla |
| Instagram | 100 | instagram-ai | Máxima cobertura, mínima precisión: el lugar sale del handle y el horario lo leyó Gemini de una imagen |
El merge no pisa datos: une todos los links de compra en ticket_sources, completa los campos vacíos, y guarda cada variante descartada — con su motivo y su fuente — en events.merge_audit. price_min se agrega al mínimo positivo en vez de resolverse por prioridad (es "lo más barato que se consigue", no un dato en disputa), el slug nunca cambia porque la URL ya está publicada, y el status no se toca salvo para promover un DRAFT que una ticketera confirmó.
La dedup se aplica en la ingesta, en upsertEventWithDeduplication(), que es el único punto de escritura de las tres rutas automáticas (cron, panel admin, Instagram). El job de limpieza es sólo para lo que ya está en la base:
npm run dedup:events # dry-run desde hoy: reporta qué fusionaría
npm run dedup:events -- --include-past # dry-run sobre todo el histórico
npm run dedup:events -- --apply # ejecuta las fusiones
npm run dedup:check # chequeo de la lógica sobre fixtures, sin base
El dry-run es el default y no escribe nada: imprime el total de fusiones, quién sobrevive en cada grupo y qué conflicto se resuelve cómo. Lo mismo está expuesto en GET /api/admin/dedup (dry-run) y POST /api/admin/dedup con { "apply": true }. Al aplicar, las filas absorbidas se borran recién después de dejar su snapshot JSON completo en el merge_audit del sobreviviente, y los favoritos se repuntan.
El filtro determinista
En lib/ai/process-flyer-ai.ts, después de la extracción:
const hasTitle = !!extractedData.title && extractedData.title.trim().length > 0
const hasDate = !!extractedData.date && /^\d{4}-\d{2}-\d{2}$/.test(extractedData.date)
const hasTime = !!extractedData.start_time && /^\d{2}:\d{2}$/.test(extractedData.start_time)
const hasVenue = !!venueName && venueName !== 'Lugar no especificado'
const qualifiesForAutoPublish = !!(hasTitle && hasDate && hasTime && hasVenue)
const eventStatus = qualifiesForAutoPublish ? 'PUBLISHED' : 'DRAFT'
Los cuatro campos son obligatorios y se validan por forma, no por confianza del modelo. Además, si la fecha extraída es anterior a hoy en America/Argentina/Salta, el flyer se marca SKIPPED y no genera evento.
Estado de las fuentes
| Fuente | Método de extracción | Pasa por Gemini | Estado |
|---|
| Vamos Salta | API REST de EntradaUno Salta (/v1/api/v2/Cartelera), JSON estructurado | No | Activo |
| EntradaUno | JSON estático en CDN S3, filtrado por idProvincia = 16 | No | Activo |
| AlPogo | API POST getEvents2, JSON estructurado | No | Activo |
| Instagram (Apify) | Actor apify~instagram-post-scraper + Gemini 3.5 Flash-Lite | Sí | Activo |
| Cines | Scraping HTML de Cinemark Alto Noa y Cine Ópera | No | Activo |
| NorteTicket | Scraping HTML con Cheerio | No | Activo |
Nota sobre el parseo de NorteTicket
Los selectores del DOM de NorteTicket viven en un solo lugar, parseAllEventsFromHtml en lib/scraper/parsers.ts, y tanto el cron como la ruta manual del panel admin los consumen desde ahí. Si NorteTicket cambia su HTML, se toca un archivo y no dos.
El provider del cron lanza en vez de devolver un array vacío cuando la fuente no responde o cuando el HTML deja de matchear el selector div#boxEvent. El job usa Promise.allSettled, así que una fuente caída no frena a las otras, pero el error queda en el campo sourceErrors de la respuesta y success pasa a false. Ese comportamiento es deliberado: la falla anterior de esta fuente fue invisible durante meses justamente porque el catch se tragaba el error y el cron reportaba success: true con cero eventos.
Stack técnico
| Capa | Tecnología | Notas |
|---|
| Framework | Next.js 16 (App Router) | Server Components, Server Actions, rutas interceptadas (@modal) para modales de evento y flyer |
| UI | React 19 | |
| Estilos | Tailwind CSS 4 | Modo oscuro por clase vía next-themes, default dark |
| Componentes | Radix UI + shadcn/ui | Set completo en components/ui/ |
| Animaciones | Framer Motion 12 | |
| Base de datos | Supabase (PostgreSQL) | RLS activo en todas las tablas de dominio |
| Auth | Supabase Auth | Email/password y Google OAuth; middleware refresca la sesión en cada request |
| Storage | Supabase Storage | Bucket flyers_ig para re-upload de imágenes de Instagram (máx. 5 MB) |
| IA | Gemini 3.5 Flash-Lite vía @google/genai | temperature: 0.1, responseMimeType: application/json, responseSchema con enum de categorías |
| Scraping | Cheerio 1.2, Puppeteer 25 | Cheerio para HTML estático, Puppeteer disponible para carteleras de cine |
| Scraping externo | Apify | Actor apify~instagram-post-scraper, disparado por cron con polling (timeout 3 min) o recibido por webhook |
| Email | Resend | Newsletter del Radar |
| Validación | Zod 3 + React Hook Form | |
| Analítica | Vercel Analytics + Google Tag Manager | |
| Hosting y cron | Vercel | apps/web/vercel.json define los cron jobs (Root Directory de Vercel: apps/web) |
| Lenguaje | TypeScript 5.7 | |
Modelo de datos
Tablas principales: events, venues, categories, aliases, profiles, user_favorites, instagram_accounts, instagram_flyers, cinema_movies, scrape_sources, scrape_runs, y las tablas del Radar (user_radar_settings, user_followed_categories, user_followed_venues, user_followed_instagram_accounts).
data_migrations es una tabla auxiliar: registra las migraciones que modifican datos (no esquema) para que reaplicarlas sea idempotente.
Enums relevantes:
UserRole: USER | ADMIN | COLLABORATOREventStatus: DRAFT | PUBLISHED | CANCELLED | PAST | PENDINGai_status de flyers: PENDING | PROCESSED | FAILED | SKIPPED
RLS está habilitado en todas ellas. El patrón general es lectura pública de contenido publicado, escritura restringida a ADMIN o al dueño de la fila, y una migración dedicada (20260623_prevent_role_tampering.sql) que impide que un usuario se escale el propio role.
Cron jobs
| Path | Schedule | Qué hace |
|---|
/api/cron/scrape | 0 8 * * * | Corre los tres providers de ticketeras en paralelo (allSettled), hace upsert con deduplicación y archiva flyers de Instagram vencidos |
/api/cron/instagram | 0 0 * * 0,1,5,6 | Dispara el actor de Apify sobre las cuentas activas, espera el run y persiste los flyers nuevos. Informa las cuentas de las que Apify no trajo nada (no_items) |
/api/scrape-cinemas | 0 13 * * * | Cartelera de Cinemark y Cine Ópera |
Los tres validan Authorization: Bearer ${CRON_SECRET}. /api/ai/process-flyers (POST y GET) acepta Bearer ${CRON_SECRET} o Bearer ${APIFY_WEBHOOK_SECRET}, y /api/webhooks/apify el header x-apify-webhook-secret. Todos fallan cerrado (lib/api-auth.ts): si la variable no está definida responden 401, y ninguno acepta el secreto por ?secret=.
GitHub Actions (procesos que no entran en Vercel Hobby)
Hobby permite un disparo por cron por día, así que lo que necesita más frecuencia, o que no entra en vercel.json, corre en .github/workflows/. Si un workflow programado falla, GitHub le manda un mail a quien lo creó (o a quien cambió después su cron), siempre que tenga activadas las notificaciones de Actions (Settings → Notifications → Actions en la cuenta de GitHub).
| Workflow | Cuándo | Qué hace | Falla si |
|---|
ai-queue.yml | cada 6 h | POST /api/ai/process-flyers?limit=5 en loop hasta vaciar la cola o 10 llamadas | error HTTP o algún flyer con success: false |
radar-newsletter.yml | jueves 21:00 UTC (18:00 Salta) | GET /api/cron/radar-newsletter | error HTTP o stats.errors > 0 |
recurrentes.yml | lunes 09:00 UTC (06:00 Salta) | GET /api/cron/recurrentes: genera las fechas futuras de peñas (14 días) y museos (7 días); idempotente, se puede correr a mano | error HTTP o algún ítem con error |
health.yml | todos los días 15:00 UTC (12:00 Salta) | GET /api/cron/health | algún proceso pasó su umbral (respuesta 503) |
Bitácora de corridas. Cada proceso programado (ticketeras, instagram, cines, cola de IA, newsletter) deja una fila en job_runs al empezar y la cierra al terminar, con estado (SUCCESS, PARTIAL, FAILED, SKIPPED), origen (vercel-cron, github-actions o manual), duración, ítems y errores (lib/job-runs.ts). Se ve en /admin/scrape, sección "Procesos automáticos".
/api/cron/health mide cada proceso por su última corrida sana en job_runs (vista job_last_runs) y, si todavía no tiene historial, por el rastro que deja en la base: ticketeras (último updated_at de eventos de entradauno/norteticket/alpogo/vamos, máx. 36 h), cines (cinema_movies.updated_at, 36 h), Instagram (instagram_flyers.fetched_at, 100 h, porque su cron no corre de martes a jueves) y cola de IA (antigüedad del flyer pendiente más viejo, 36 h; con la cola vacía da OK).
Secrets que hay que cargar a mano en GitHub (repo → Settings → Secrets and variables → Actions):
CRON_SECRET (secret, obligatorio): el mismo valor que CRON_SECRET en Vercel. En Vercel es de tipo sensitive y no se puede volver a leer: si no lo tenés guardado, generá uno nuevo (openssl rand -hex 32), cargalo en los dos lados y redeployá Vercel.SITE_URL (variable, opcional): por defecto https://www.quepintasalta.com.ar.
Ojo: radar-newsletter.yml se puede correr a mano (workflow_dispatch), pero no hay registro de envíos y cada corrida vuelve a mandar el mail a todos.
Funcionalidades
Todo lo listado acá está implementado y activo en el código.
Descubrimiento
- Home con carrusel de destacados, filas por categoría y filtros por categoría, lugar, fecha y precio.
- Búsqueda en
/buscar.
- Detalle de evento con rutas interceptadas: el mismo contenido se abre como modal desde la grilla o como página completa en
/evento/[id], con URL compartible en ambos casos.
- Cartelera de cines en
/cines, con normalización de títulos que colapsa las variantes de formato (2D, 3D, XD, doblada, subtitulada) en una sola ficha con todas sus funciones.
- Multi-ticketera: cuando el mismo evento se scrapea de varias fuentes, la ficha muestra todos los links de compra desde
ticket_sources.
Cuenta y personalización
- Registro y login con email/password o Google OAuth.
- Favoritos por usuario, persistidos en
user_favorites con RLS por dueño.
- Compartir agenda por WhatsApp: desde
/favoritos se arma un mensaje con la lista de eventos guardados y un link a cada uno, y se abre el share nativo de WhatsApp. También hay compartir individual desde cada tarjeta.
- Radar por email: suscripción por categoría, por lugar y por cuenta de Instagram, con frecuencia configurable (semanal, quincenal, mensual o desactivado). El envío usa Resend con plantilla HTML propia.
- Modo oscuro con
next-themes, default oscuro y respeto por la preferencia del sistema.
- Carga de eventos por usuarios autenticados en
/nuevo-evento, con gestión propia en /mis-eventos y aprobación por admin en /admin/pendientes.
Panel administrativo
/admin/revision: revisión de borradores en layout split-screen — el flyer original de Instagram fijo a un lado, el formulario editable con lo que extrajo Gemini al otro, más el JSON crudo de ai_metadata para auditar la extracción. Publicar o descartar en un click./admin/scrape: ejecución manual de cada fuente con historial de corridas en scrape_runs (estado, insertados, omitidos, errores, quién la disparó)./admin/clasificacion: clasificación manual de eventos sin categoría./admin/aliases: mapeo de alias a categorías y lugares, que tiene prioridad sobre la inferencia automática./admin/instagram: alta y baja de cuentas monitoreadas, con venue, categoría y URL de Maps por defecto para cada una./admin/users: gestión de roles.
Monetización directa
- Botón de contacto por WhatsApp para anunciantes en el footer y en los slots publicitarios, con mensaje pre-cargado. El número sale de
NEXT_PUBLIC_CONTACT_WHATSAPP.
- Marcado de eventos como
is_commercial y is_featured para priorización en home.
SEO
sitemap.ts y robots.ts dinámicos, Open Graph y Twitter Cards, metadata por evento.
Roadmap
- Google AdSense. El componente
AdSenseBanner, /ads.txt y el interruptor NEXT_PUBLIC_ADS_ENABLED ya existen; hoy está apagado. Para prenderlo faltan los bloques de anuncios: los slots que se pasan (home-middle-banner, event-detail-bottom-banner) son nombres, y data-ad-slot tiene que ser el ID numérico de cada bloque creado en AdSense. Con un slot no numérico el componente muestra el CTA de WhatsApp.
- Analítica de datos para campañas publicitarias. No hay registro de vistas: la tabla
event_views se borró en el Sprint 0 de seguridad porque estaba sin RLS y ningún código la usaba. Falta definir cómo medir (sin guardar IPs en una tabla pública) y el dashboard: métricas por categoría, por venue y por franja horaria, para vender espacios con números en la mano.
- Rol de colaborador / RRPP para boliches. La base ya está mergeada —
COLLABORATOR en UserRole, PENDING en EventStatus, campos contact_type y contact_value en profiles, y el circuito /nuevo-evento → /mis-eventos → /admin/pendientes. Falta el onboarding específico para RRPP, los permisos diferenciados por local y las métricas propias de cada colaborador.
- Geocodificación de venues.
venues tiene columnas latitude, longitude y google_maps_url que ningún scraper completa, y lib/scraper/venue-enrichment.ts quedó como stub sin usar.
- Expansión a otras provincias: Qué Pinta Mendoza y Qué Pinta Córdoba, reutilizando el pipeline con fuentes y configuración por provincia.
Desarrollo local
npm install
Variables de entorno en apps/web/.env.local:
# Supabase
NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_ANON_KEY=
SUPABASE_SERVICE_ROLE_KEY=
# IA y scraping externo
GEMINI_API_KEY=
APIFY_API_TOKEN=
APIFY_WEBHOOK_SECRET=
# Cron
CRON_SECRET=
# Email
RESEND_API_KEY=
RESEND_FROM_EMAIL=
# Contacto y publicidad
NEXT_PUBLIC_CONTACT_WHATSAPP=
NEXT_PUBLIC_ADS_ENABLED=false # interruptor de monetización: anuncios + donaciones
NEXT_PUBLIC_ADSENSE_CLIENT_ID= # solo se usa con NEXT_PUBLIC_ADS_ENABLED=true
NEXT_PUBLIC_ADS_ENABLED (lib/config/monetization.ts) solo prende con true; si falta, queda apagado. Apagado no se carga el script de AdSense, no se renderizan los slots ni el cartel de "Anunciá", la CSP no incluye dominios de anuncios (next.config.mjs) y se ocultan las donaciones de Mercado Pago. Se lee en el build: cambiarla en Vercel exige redeployar. /ads.txt (public/ads.txt) se publica siempre.
Base de datos y esquema
El esquema está versionado en supabase/migrations/ y arranca con un baseline (20261002160000_baseline.sql) que es un volcado verificado del esquema de producción. Las migraciones anteriores están en supabase/migrations_legacy/ solo como historia (ver su README). Las migraciones nuevas van en supabase/migrations/ con versión posterior al baseline; el CI las aplica sobre una base vacía en cada push.
Base local (requiere Docker):
npx supabase start # levanta Postgres 17 + auth + storage y aplica las migraciones
npx supabase db reset # vuelve a aplicar todas las migraciones desde cero
npx supabase stop
Base local con los datos de producción, para probar migraciones contra datos reales:
bash scripts/db/load-prod-data.sh # baja los datos de prod y los carga (resetea la base local)
bash scripts/db/load-prod-data.sh --reuse # vuelve a cargar el último dump sin bajarlo
Lee POSTGRES_URL_NON_POOLING de apps/web/.env.local y solo lee de prod. Baja el schema public completo y, de auth, solo users e identities. El dump tiene emails de usuarios: queda en supabase/.data-dumps/, que está en .gitignore; no lo commitees ni lo compartas. Conexión local: postgresql://postgres:[email protected]:54322/postgres.
Otros comandos:
npm run db:types # regenera packages/db/src/database.types.ts desde la base local
npm run typecheck
bash scripts/db/check-drift.sh # compara prod contra lo que reconstruyen las migraciones; falla si difieren
Los tipos de la app (lib/types.ts) derivan de packages/db/src/database.types.ts (@qps/db). Si una migración cambia el esquema, regenerá los tipos y commitealos en el mismo cambio: el CI falla si no coinciden.
npm run dev
Ejecución manual de scrapers:
npx tsx apps/web/lib/scraper/vamos-scraper.ts
Los scrapers también se pueden disparar desde /admin/scrape con una cuenta ADMIN, que es la vía recomendada porque registra la corrida en scrape_runs.
Autor
Mauro Alejandro Lizárraga
