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 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:

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:

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:

npm ci
npm run contracts:check

Comprobar:

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

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, las políticas, la política de idiomas, el perfil multidispositivo por juego, el objetivo de capacidad y el plan de implementación indican los límites de esta primera fase. La exploración visual 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 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 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 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 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 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.