# Juegoland — games2 Proyecto independiente para la nueva plataforma de juegos. El frontend está en Svelte 5 y TypeScript; la API y el servidor de dominio están en Go. La carpeta no importa archivos de `games`, usa puertos propios y no modifica su despliegue. Para continuar el trabajo en otro proyecto de Codex, leer el [handoff del 6 de octubre de 2026](docs/HANDOFF-2026-10-06.md) antes de cambiar el árbol de trabajo. **Estado actual:** base ejecutable. El catálogo está conectado desde el navegador a la API Go y empieza vacío porque ningún juego está instalado/publicado en este proyecto. Salas, cuentas, chat, motor, PostgreSQL y tiempo real aún no están habilitados. `/ready` describe expresamente esta fase como `foundation`; no acredita preparación para producción. ## Requisitos - Go 1.26 o superior. - Node.js 24 o superior y npm. ## Desarrollo En una terminal, desde la raíz de `games2`: ```powershell go run ./cmd/games2 ``` La API escucha por defecto en `127.0.0.1:8082`. Se puede elegir otro puerto con `GAMES2_API_ADDR`. Para usar otro puerto hay que actualizar también el destino del proxy de desarrollo en `frontend/vite.config.ts`. En otra terminal: ```powershell cd frontend npm ci npm run dev ``` Abre `http://127.0.0.1:4174`. El frontend consulta `/api/v2/catalog` a través del proxy local hacia Go. En producción, un proxy HTTPS servirá el frontend estático y enviará `/api` al backend; esta configuración aún no está desplegada. Las herramientas para validar contratos del motor y modelos compartidos tienen dependencias propias en la raíz del proyecto: ```powershell npm ci npm run contracts:check ``` Comprobar: ```powershell go test ./... npm run contracts:check cd frontend npm run check npm run build ``` Rutas de la primera fase: `GET /live`, `GET /ready`, `GET /api/v2/bootstrap` y `GET /api/v2/catalog`. Las dos últimas devuelven `requestId` y `data`; el catálogo devuelve `items: []` y `nextCursor: null` hasta la primera publicación. No hay rutas de creación o publicación de juegos para usuarios. ## Estructura ```text cmd/games2/ arranque y apagado del proceso Go internal/api/httpapi/ entrega HTTP y contratos de respuesta internal/server/ casos de uso y capacidades habilitadas internal/domain/catalog/ lectura de juegos publicados internal/domain/ identidad, seguridad, salas, chat y moderación internal/engine/ núcleo del motor propio internal/games/ reglas Go propias publicadas internamente internal/infra/ PostgreSQL y proveedores externos internal/jobs/ plazos y outbox frontend/ aplicación Svelte 5 y Vite contracts/ índice de contratos ejecutables db/migrations/ futuras migraciones PostgreSQL deploy/ futuro despliegue independiente docs/platform/ políticas y arquitectura de producto docs/game-engine/ formato, esquemas y ejemplos del motor propio docs/ROADMAP.md próximos hitos y criterios de aceptación ``` El directorio `docs/` contiene una copia de los contratos y propuestas de v2 para trabajar sin depender de archivos de la aplicación anterior. Documentan el destino; las funciones no disponibles siguen marcadas como pendientes. La [arquitectura](docs/platform/architecture.md), las [políticas](docs/platform/product-policies.md), la [política de idiomas](docs/platform/localization.md), el [perfil multidispositivo por juego](docs/game-engine/multi-device-profile.md), el [objetivo de capacidad](docs/platform/capacity-and-scaling.md) y el [plan de implementación](docs/ROADMAP.md) indican los límites de esta primera fase. La [exploración visual](docs/platform/visual-design.md) no está aprobada; la identidad y los tokens quedan por definir. La portada inicial es un prototipo visual no aprobado con selector de español/inglés. El catálogo envía `Accept-Language`; el servidor responde con `Content-Language` y marca el idioma real de cada ficha. Los juegos publicados, sus reglas y recursos aún deberán cumplir la política de traducción antes de aparecer en el catálogo. El [perfil propuesto de jugadores virtuales](docs/game-engine/virtual-player-profile.md) permite preparar plazas controladas por agentes IA: cada juego debe declarar esa opción en sus propiedades e incluir las instrucciones versionadas del agente. El motor conserva la validación de reglas y el servidor limita el agente a la información de su asiento. No hay jugadores IA implementados ni soporte de este perfil en los esquemas v1 actuales. El [perfil multidispositivo](docs/game-engine/multi-device-profile.md) propone `TVBoard` (TV pública + mando móvil), `Desktop` y `Mobil` (estado autorizado + controles). Distingue mesas por QR sin invitaciones y TV personal tras invitación, con cambio a móvil completo. El [perfil de sincronización](docs/game-engine/synchronization-profile.md) recoge técnicas de la industria y propone reloj/rondas, acierto en ventana y compensación experimental con empates; aún sin runtime ni esquemas v2 ejecutables. El [perfil común de comunicación](docs/platform/client-communication-profile.md) prepara mandos web y una app Flutter posterior **solo de controles**, con las mismas acciones y proyección `player-controller`. Tableros y vistas completas se representan en la web; el paso a móvil completo desde Flutter abre `Mobil` web conservando jugador y recibos. Propone HTTPS/WSS, SDK TypeScript/Dart, acceso y controles por runtime, QR y recuperación; sigue siendo diseño, sin app nativa ni binding nuevo implementados. Los [modelos compartidos](docs/platform/shared-data-models.md) tienen fuente JSON Schema y DTOs generados para TypeScript, Go y Dart bajo `contracts/shared/`. Incluyen un núcleo común de error, mensajes, correlación y catálogo. `npm run contracts:generate` actualiza tipos; `contracts:check` comprueba deriva, fixtures y relaciones. Go/Dart verifican lectura y serialización del mismo JSON. Los validadores/adaptadores de errores de red se incorporan en los siguientes cortes.