pippygames/docs/platform/review-2026-10-06.md

Revisión de documentos nuevos — 6 de octubre de 2026

Resultado: la separación entre jugador, dispositivo, proyección y autoridad de servidor es una base coherente. La revisión detectó huecos de recuperación, temporización y autorización que podían producir implementaciones incompatibles. Se han corregido los contratos documentales; no se han implementado estas capacidades ni demostrado equidad de reacción o capacidad de 100.000 jugadores.

Se revisaron los perfiles multidispositivo, temporal, web/Flutter y virtual; localización y capacidad; y su coherencia con API, modelo, arquitectura, políticas, roadmap y handoff. La exploración visual permanece aplazada/no aprobada. Esta revisión complementa la del 5 de octubre, sin convertir sus correcciones de diseño en funciones ejecutables.

1. Estado y autoridad

Nivel	Qué consta
Decisiones del usuario	API y servidor/motor Go; frontend Svelte; juegos propios; protección transversal; IA opcional definida por juego con instrucciones; tres presentaciones; QR presencial sin invitaciones; TV personal tras invitación con paso a móvil completo; futura app Flutter.
Propuestas técnicas	Contratos v2 de proyección/renderer, HTTPS/WSS y tickets, mando activo con generación, relojes/rondas, controladores IA, presupuestos y límites. Deben concretarse en esquemas y pruebas antes de habilitarse.
Base ejecutable comprobada en código	Salud, bootstrap y catálogo Go; frontend Svelte con español/inglés. No hay motor, identidad, salas, PostgreSQL, tiempo real, IA ni Flutter ejecutables. Véase el handoff.
Evidencia existente	Verificador de contratos v1 y comprobaciones documentales. No validan las extensiones v2 descritas aquí.

Los perfiles especializados definen semántica; la API reúne rutas/recibos; políticas fija admisión y límites de producto. No se deduce soporte de un ejemplo JSON. Una decisión expresa posterior se incorpora a sus documentos canónicos y al handoff, sin dejar recomendaciones antiguas en conflicto.

2. Hallazgos y correcciones

P1 indica riesgo de autorización, duplicación, pérdida de acciones o resultado injustificado. P2 indica ambigüedad de contrato, planificación o evaluación. Todos los estados siguientes significan corregido en documentación; implementación pendiente.

ID	Nivel	Hallazgo	Corrección y verificación necesaria
R1	P1	Cambiar web/app sin los UUID del cliente anterior podía permitir que una acción incierta se aplicase después de actuar en el nuevo.	Mando activo y generación, adquisición explícita y barrera común con ingresos. Probar transferencia concurrente, envío antiguo tardío y recuperación de recibo confirmado sin mando.
R2	P1	Una segunda vista podía revelar la pregunta antes mientras se compensaba el retardo de otra TV.	Fuente de estímulo por ronda, restricción de suscripciones nuevas y revalidación de outbox. Probar pestañas, web/app simultáneas y reconexión; no prometer prueba física de visualización.
R3	P1	Pasar a recogida/cerrar podía invalidar respuestas puntuales todavía en cola o anunciar recepción como aplicación.	Ingreso duradero y barrera de cierre; mantener precondición hasta drenar, distinguir cola de commit. Probar retraso SQL, caída antes de persistencia y lease vencido.
R4	P1	Neutralizar por cualquier reporte de lag permitía repetir rondas hasta acertar o reutilizar preguntas reveladas.	Política de incidentes con criterios de servidor, cuotas acumuladas, estímulo nuevo y conservación de resultados resueltos. Probar desconexiones deliberadas y agotamiento.
R5	P1	Cookie/CSRF se describían como universales mientras la app necesitaba otra sesión; faltaba ligar origen observado y ticket WSS.	Adaptadores web/nativo y consumo vinculado a conexión/generación. Probar ausencia/falsificación de origen, ticket cruzado y coordinación entre nodos.
R6	P1	Reintentar un trabajo IA obsoleto podía renovar su presupuesto; bloquear el agente podía dejar un reloj adjudicando derrota.	Oportunidad duradera y fallo operativo, límites totales y fencing; política obligatoria de pausa/recuperación. Probar workers concurrentes, reinicio y plazo simultáneo.
R7	P2	round.* se usaba sin corresponder a las familias del transporte.	Estado en game.snapshot.context.timing, eventos en game.snapshot.events y acuses técnicos time.ready/time.readiness. Crear fixtures de TV pasiva, preparación y reconexión.
R8	P2	Marcas UTC y monotónicas podían confundirse o compararse tras cambiar de proceso.	Unidades y época explícitas, sufijo Ms, fechas operativas separadas y nueva época tras cambio de autoridad. Probar suspensión y failover.
R9	P2	Recibo pending que luego fuese applied contradecía recibos inmutables.	Operaciones de presentación/mando separan recibo de solicitud y estado consultable. Probar reintento durante espera y rechazo por precondición obsoleta.
R10	P2	El código de 10 símbolos del QR contradecía el requisito de 128 bits; caducidad y recuperación eran ambiguas.	Token QR y alias manual diferenciados, consumo conjunto, cuotas y vigencia sin renovación por reintento. Probar ambas entradas y revocación concurrente.
R11	P2	Idioma siempre inmediato contradecía estímulos congelados y juegos de palabras; se presuponía Intl en cualquier cliente.	Interfaz y contenido separados, variantes fijadas por ronda y formateadores web/Dart equivalentes. Probar que cambiar idioma no elige otra pregunta ni reinicia tiempo.
R12	P2	Go servidor figuraba pendiente y la producción original se confundía con games2; medias de carga parecían incluir todas las conexiones.	Arquitectura y modelo alineados con handoff; capacidad distingue entregas, suscripciones, bytes y ráfagas. Ninguna cifra es capacidad medida.
R13	P2	Redactar secretos podía interpretarse como ocultar también toda actividad.	Distribución multidispositivo explicita la observabilidad de revisiones globales; juegos que deban ocultar actividad requieren otro contrato probado.

3. Qué falta antes de implementar/publicar

1. Crear esquemas ejecutables v2, contrato nativo Go y fixtures comunes de mensajes, proyecciones y renderers. Mantener v1 separado y probar rechazo explícito de versiones/combinaciones no admitidas.
2. Construir el primer corte de persistencia, autorización, recibos, outbox y recuperación del roadmap. Las carreras descritas necesitan pruebas de integración transaccional, no solo validación JSON.
3. Materializar operaciones duraderas de mando/presentación, invalidación de suscripciones y sesión WSS; después, los recorridos QR y la futura sesión nativa. Los registros y fallos se documentan antes de ofrecer la app.
4. Empezar el quiz por acierto en ventana, con política de incidentes. Mantener reacción compensada experimental hasta medir estimador, incertidumbre, rutas de pantalla/control y abuso. No existe garantía de ordenar exactamente pulsaciones humanas bajo cualquier conexión.
5. Fijar presupuestos de IA, plazos operativos y mezcla de carga con evidencia. Probar privacidad con juegos de información oculta y ensayar capacidad en infraestructura real antes de anunciarla.

4. Verificación de esta revisión

Comprobaciones realizadas y satisfactorias:

• npm run contracts:check: 5 manifiestos, 14 mensajes, 37 casos de rechazo, 5 componentes, 52 huecos de arte, plan de presentación y 6 esquemas; comprobación TypeScript incluida.
• Revisión estructural de 13 documentos corregidos: 170 enlaces/anchors locales y 11 ejemplos JSON válidos; sin espacios al final de línea.
• Correspondencia del ejemplo multidispositivo: 6 renderers, 2 nativos, y tupla de negociación coherente con proyección/versiones. El comando web/nativo incluye la generación de mando propuesta.
• Ejemplos numéricos: los intervalos de reacción publicados producen empate y el supuesto de tráfico da aproximadamente 104 MiB/s. Son cálculos ilustrativos, no ensayos de red/capacidad.

Estas comprobaciones no validan los nuevos contratos v2 contra un esquema, porque todavía no existe. Se corrigió un enlace interno del propio registro antes de cerrar la revisión.

La revisión es documental; no cambia el runtime ni revalida con ella los ensayos históricos de frontend/Go del handoff. Las fuentes de industria permanecen enlazadas en sus perfiles, diferenciando documentación histórica de versiones actuales. La parte nueva de seguridad WSS se contrastó con OWASP y la recuperación de reloj con la documentación de Go.