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