# Plan de implementación de games2

## Base ejecutable actual

- Proyecto Go con API, capa de servidor y catálogo de publicación interna; sin juegos fingidos.
- Frontend Svelte independiente que consulta el catálogo real y representa carga, fallo y lista vacía.
- Bootstrap de capacidades: únicamente catálogo. Salud de proceso y readiness acotado a esta fase.
- Prototipo visual no aprobado y selector español/inglés; negociación de idioma en el catálogo. La identidad visual y el sistema de tokens se definirán después. La cobertura de idiomas de juegos y flujos futuros se rige por [localización](platform/localization.md).
- Contratos y políticas de v2 copiados bajo `docs/`; su implementación permanece pendiente.
- [Modelos compartidos](platform/shared-data-models.md) con fuente JSON Schema, DTOs TypeScript/Go/Dart y fixtures: primitivas, mensajes, errores y catálogo. La ficha de catálogo Go/Svelte usa el tipo generado; adaptadores de error y validadores de red aún pendientes.

## Próximos cortes verticales

Aplicar los hallazgos de la [revisión del 6 de octubre](platform/review-2026-10-06.md) al concretar los contratos: mando con generación y transferencia segura, operaciones consultables, fuente temporal única, cierre con ingresos duraderos y límites de incidentes/IA. Las correcciones son documentales, no capacidades habilitadas.

1. **Persistencia y contratos:** PostgreSQL, migraciones nuevas, repositorios dentro de una unidad de trabajo, API/esquemas verificables y pruebas de integración. Desde este corte aplicar las [invariantes de preparación para escalar](platform/capacity-and-scaling.md#2-prepararla-desde-el-primer-juego-sin-pagar-el-clúster-ahora): estado duradero, límites y métricas, sin autoridad en memoria de un proceso. `/ready` pasará a exigir base y esquema compatibles cuando se active esa dependencia.
2. **Motor propio en Go:** interfaz de reglas equivalente al SDK documentado, perfil de paquete Go versionado, resultados, azar determinista, proyecciones por jugador, recibos y outbox. Preparar el [perfil de jugadores virtuales](game-engine/virtual-player-profile.md): soporte e instrucciones en las propiedades del paquete, controladores humano/IA por asiento, esquemas ejecutables y decisiones duraderas. Conecta 4 como primer juego propio real y primer ensayo de agente; habilitarlo solo tras comprobar privacidad, límites, fallos y recuperación. No publicarlo solo por existir una ficha.
3. **Información privada y azar:** Hundido y Brisca como pruebas de vistas ocultas, acciones independientes, barajas y reproducibilidad. Conservar fixtures de resultados y privacidad.
4. **Identidad y protección:** credenciales recuperables, sesiones, edad, tutela, permisos de sala, invitaciones, bloqueo/reporte y administración. Abrir cada capacidad solo con sus proveedores, procedimientos y pruebas.
5. **Tiempo real y clientes:** binding WebSocket versionado, negociación, auth, reconexión, cursores y recibos; frontend de sala/partida con móvil y accesibilidad probados. Aplicar el [perfil común web/Flutter](platform/client-communication-profile.md): esquemas/fixtures neutrales, SDK TypeScript/Dart, runtime/renderer negociado, autenticación inicial por ticket y sesión nativa con permisos comunes. Primero cliente web; app independiente Flutter **solo de controles** después, con mandos registrados/declarativos, QR/enlaces y recuperación verificados. Tableros y vistas completas siguen en la web; probar el paso Flutter → `Mobil` web con autenticación, transferencia de mando y recibos conservados. El cliente recupera la partida tras reinicio y no depende del nodo anterior ni de ejecutar bundles web en Flutter.
6. **Perfil multidispositivo por juego:** esquemas y fixtures del [contrato v2](game-engine/multi-device-profile.md) para `TVBoard`, `Desktop` y `Mobil`, tres proyecciones negociadas por suscripción, vínculos comunes/personales, mesa por QR sin invitaciones y enlace de mando tras invitación en Smart TV. Este último exige cambio a móvil completo conservando plaza/recibos. AirConsole sigue como referencia de controles por fase y simulador. Probar privacidad, protección, revocación/reconexión, TV/HDMI y gesto más botón/teclado; el gesto nunca decide el azar. Materializar el [perfil temporal](game-engine/synchronization-profile.md): reloj/época, preparación, ingresos duraderos y recogida de rondas; primer quiz por acierto sin ventaja de llegada. Compensación de reacción/empates solo tras ensayos con jitter, asimetría, fraude temporal y cambio de presentación.
7. **Operación y capacidad:** backups/restauración con supresiones, observabilidad externa del proxy y del backend, pruebas de carga, despliegue reversible y migración desde v1 con una sola autoridad por sala. Ensayar el [objetivo propuesto de 100.000 jugadores simultáneos](platform/capacity-and-scaling.md) por escalones y fallos; publicar solo la capacidad demostrada con hardware, coste y márgenes documentados.

Dentro del corte multidispositivo, contemplar también **TV no smart con dispositivo HDMI** según la [matriz de acceso](game-engine/multi-device-profile.md#televisores-y-dispositivos-externos): verificar primero web/HDMI y Fire TV con Silk; planificar receptor Cast propio y apps de TV para Google TV/Android TV/Fire TV en entregas específicas. Distinguir Chromecast clásico, Chromecast con Google TV y duplicación de pestaña. Probar vínculos públicos, QR, mando/foco, suspensión/cambio de sesión y demora real de pantalla. El alcance decidido es **2D, incluida perspectiva, con sprites y animaciones sencillas**, sin Three.js, motor 3D, iluminación o efectos avanzados. Tras cuestionar el peso de Phaser, el usuario pide comparar Konva con Motion y su motor propio de `vicen`: evaluar primero una presentación DOM con ese motor, concretando exportaciones/puerto DOM/presets y evaluando la nueva función propuesta `springTimed`, con timestamps/acumulador y pasos físicos constantes, sin modificar `spring` ni sus consumidores actuales. La función no está implementada; probar cadencias variables, cancelación, inversión y movimiento reducido antes de integrarla. Probar tablero/cartas y controlador de fotogramas si hace falta; comparar con Konva solo si se justifica Canvas. Medir bundle comprimido, primer dibujo, memoria, fluidez y reposo antes de decidir; Phaser queda como alternativa y su editor se evalúa por separado. Adaptar la solución al coordinador visual propio y conservar Svelte para interfaz/controles y Go para reglas/resultados. La integración sigue pendiente, sin aprobación implícita por la demo PixiJS. WebGL no se exige globalmente: probar perspectiva, secuencias, límites, cancelación y movimiento reducido sin WebGL. El renderer Cast directo debe funcionar sin WebGL y comprobarse en dispositivos reales; Canvas o DOM por sí solos no prueban compatibilidad de navegador.

## Criterio para cada hito

Cada entrega incluye una ruta visible, su comportamiento de error y permisos, cobertura en `es` y `en`, pruebas que cubran el riesgo propio, instrucciones de operación y una comprobación contra los documentos de contrato. Las capacidades no implementadas permanecen desactivadas en `bootstrap` y sin controles de interfaz que sugieran que funcionan.

La primera fase no requiere conexión a la base de datos ni proveedor externo. El trabajo posterior debe mantener los valores de producto de [políticas](platform/product-policies.md), la [API/eventos](platform/api-and-events.md) y el [formato de juegos](game-engine/format-and-protocol.md), actualizando esos documentos cuando una decisión de implementación cambie un contrato.