⚽ FULBO90

¿Cuánto sabés de fulbo? — 90 minutos no alcanzan para todo lo que sabés.

Desafíos diarios de conocimiento futbolístico con foco en el fútbol argentino y CONMEBOL. El nombre, eslóganes, colores y voz de la marca están centralizados en lib/config/brand.ts y lib/config/copy.ts.

MVP: Grid Sudamericano, El 11, ¿Quién es? e Impostor, con desafío diario (igual para todos, cambia a las 00:00 de Buenos Aires), modo infinito, estadísticas locales, compartir resultados y panel /admin.

Puesta en marcha

npm install
npm run dev          # http://localhost:3000

Sin base de datos la app funciona igual: usa los datos de /data (modo estático, admin de sólo lectura).

Con PostgreSQL (Neon) en desarrollo

1. En Neon creá un proyecto y un branch dev (el branch principal queda para producción).
2. Copiá .env.example a .env y completá, con las URLs del branch dev:
   • DATABASE_URL: conexión pooled (con -pooler), la usa la app.
   • DATABASE_URL_UNPOOLED (o DIRECT_URL): conexión directa, la usan migraciones y seed.
   • APP_SECRET: 32+ caracteres aleatorios (firma de partidas).
3. npm run db:deploy → aplica las migraciones versionadas de prisma/migrations.
4. npm run db:seed → carga jugadores, clubes, títulos, DTs y partidos desde /data.
5. npm run daily:generate → precarga y verifica los diarios de los próximos 30 días y las reservas.
6. npm run admin:create -- --email [email protected] --password "una-clave-larga" → primer administrador.

Producción: GitHub → Vercel + Neon

1. Subí el repo a GitHub e importalo en Vercel.
2. Conectá la integración Neon ⇄ Vercel (o cargá a mano las variables) apuntando al branch principal de Neon. La integración crea DATABASE_URL y DATABASE_URL_UNPOOLED; también puede crear un branch por cada Preview Deployment.
3. En Vercel → Settings → Environment Variables agregá APP_SECRET, CRON_SECRET, ADMIN_EMAILS (opcional) y NEXT_PUBLIC_SITE_URL.
4. Cada deploy corre vercel-build: prisma generate && prisma migrate deploy && next build. Las migraciones se aplican solas y nunca se usa db push en producción.
5. La primera vez, con las variables de producción en tu terminal: npm run db:seed y npm run admin:create -- ….
6. vercel.json programa el cron /api/cron/daily (02:00 UTC = 23:00 Argentina) que mantiene el calendario completo. La primera carga de 30 días conviene hacerla con npm run daily:generate (desde lejos de la región de Neon tarda varios minutos); después el cron sólo agrega un día por juego.

Cambios de schema: editá prisma/schema.prisma, corré npm run db:migrate -- --name descripcion contra el branch dev y commiteá la carpeta de migración generada. Producción la aplica en el próximo deploy.

Scripts

Script	Qué hace
npm test	Tests del motor, tickets, generadores, validadores y scheduler
npm run test:slow	Sostenibilidad del calendario (90 días por juego, ~4 min)
npm run data:check	Verifica integridad del seed (referencias, años, títulos vs. palmarés de clubes)
npm run typecheck / npm run lint	Tipos y lint
npm run db:migrate	Crea una migración nueva (desarrollo)
npm run db:deploy / db:status	Aplica / muestra el estado de las migraciones
npm run db:seed	Seed idempotente (-- --reset reemplaza relaciones del seed; bloqueado en producción sin --force-production)
npm run daily:generate	Corre el motor a mano: completa el calendario y las reservas (-- --from 2026-11-01, -- --backfill)
npm run admin:create	Crea o promueve un administrador

Producción: decisiones de arquitectura

• Datos sólo en el servidor. Prisma vive en lib/database/* (marcado server-only); los componentes cliente hablan únicamente con server actions y route handlers. Las credenciales nunca llegan al navegador.
• Prisma Client único por proceso (lib/database/prisma.ts) con el adapter de Neon sobre la conexión pooled.
• Validación de respuestas en el backend. Cada respuesta se evalúa con el motor de condiciones contra las relaciones del jugador.
• Intentos y duplicados controlados por el servidor, sin estado en memoria. Cada partida lleva un ticket firmado con HMAC (lib/game-engine/tickets.ts) con intentos, celdas resueltas y jugadores usados; el servidor lo valida y lo devuelve actualizado. El cliente no puede alterarlo, y funciona en funciones serverless sin memoria compartida ni escrituras en Neon por cada jugada de un invitado. Las respuestas correctas sólo se revelan con el ticket cerrado.
• Resultados. Invitados: localStorage. Usuarios autenticados: UserGameResult en Neon, calculado desde el ticket (no desde números del cliente) y único por usuario y desafío.
• Autenticación propia: email + contraseña (scrypt), sesiones en Neon con token hasheado en cookie httpOnly. Admin: el proxy hace un chequeo optimista y el rol ADMIN se verifica en el servidor en el layout, en cada página y en cada server action.
• Desafíos diarios verificados. lib/game-engine/daily-generator.ts genera con el mismo seed que el fallback en tiempo real, comprueba que cada consigna tenga respuestas correctas (y que la grilla tenga 9 respuestas distintas) y guarda Challenge, ChallengeCondition, ChallengeAnswer y DailyChallenge. No hay generación por IA.
• Fecha del desafío: siempre America/Argentina/Buenos_Aires (lib/game-engine/daily.ts).
• Índices: trigram GIN sobre Player.normalizedName (búsqueda difusa en /api/jugadores), PlayerClub(clubId, playerId), PlayerCompetitionAchievement(competitionId, clubId), DailyChallenge(date) y (date, gameId), UserGameResult(gameId, dailyDate) y (userId, challengeKey).
• Cachés, no dependencias: el índice en memoria del grafo futbolístico se recarga desde Neon (TTL de 5 minutos o al editar en el admin); perderlo sólo cuesta una consulta.

This is the beginning of the README. Read the rest at the original. Read the full README ↗