6.0 KiB
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.