|
|
|
|
|
# Revisión de especificaciones de plataforma — 5 de octubre de 2026
|
|
|
|
|
|
|
|
|
|
|
|
Alcance: [modelo de plataforma](../platform-spec-v2.md), [API/eventos](api-and-events.md) y su encaje con el motor. Durante la revisión el usuario añadió protección transversal del menor, SMS obligatorio para chat y confirmó **chat desactivado para menores**. Esos requisitos se desarrollan en [protección del menor](child-safety.md), con comparación de políticas publicadas.
|
|
|
|
|
|
|
|
|
|
|
|
Esta revisión identifica defectos de **diseño documental**, no vulnerabilidades explotadas ni correcciones desplegadas. «Corregido» significa que la propuesta ya expresa la regla; aún faltan implementación, esquemas y pruebas de comportamiento.
|
|
|
|
|
|
|
|
|
|
|
|
## Hallazgos y resolución
|
|
|
|
|
|
|
|
|
|
|
|
P1: riesgo de privacidad, doble efecto o estado inconsistente. P2: ambigüedad o falta que impide implementar/comprobar correctamente.
|
|
|
|
|
|
|
|
|
|
|
|
| ID | Prioridad | Fallo del borrador anterior | Resolución incorporada y comprobación pendiente |
|
|
|
|
|
|
| --- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
|
|
|
|
| F01 | P1 | Retirada/cierre comprobaban solo revisión de sala; una jugada no necesariamente la cambia. No se fijaba frontera transaccional sala-motor. | Revisión adicional de partida, orden de bloqueo común y transacción compartida. Probar jugada frente a retirada/cierre y rollback de setup. |
|
|
|
|
|
|
| F02 | P1 | Se podía considerar corrupta una sala/partida por recibir sus eventos en orden inverso. | Barrera `minimumRevision`, estados independientes y recuperación del flujo atrasado. Probar ambas órdenes de entrega. |
|
|
|
|
|
|
| F03 | P1 | Moderar reemplazando un mensaje sin una secuencia nueva no actualizaba a clientes; páginas retrasadas podían reponer el texto. | Flujo de eventos de chat, redacción con nueva secuencia, `historyEpoch` y rechazo de páginas antiguas. Probar moderación concurrente con historial. |
|
|
|
|
|
|
| F04 | P1 | Idempotencia HTTP de 24 h sin límite de antigüedad permitía repetir una creación al purgar el recibo; faltaban colisión concurrente y propietario anónimo. | Fecha de emisión, ventana de admisión, restricción única, registro común por principal y contexto anónimo para altas. Probar repetición tardía y simultánea. |
|
|
|
|
|
|
| F05 | P1 | Invitación «token una vez/solo hash» era incompatible con recuperar una respuesta perdida. | Respuesta secreta cifrada temporal con alcance, caducidad y rotación explícita fuera de ventana. Probar pérdida de respuesta y cambio de anfitrión. |
|
|
|
|
|
|
| F06 | P1 | Exigir membresía para consultar cualquier operación impedía recuperar el recibo de una salida ya aplicada. | Recibo mínimo por principal emisor, sin devolver vista privada ni recuperar membresía. Probar salida y consulta desde otra sesión propia. |
|
|
|
|
|
|
| F07 | P1 | Autorización y revocación no contemplaban sesiones o publicaciones ya preparadas, ni protección infantil. | Política común, `safetyRevision`, cancelación de suscripciones y reautorización antes de entrega; menores/edad desconocida sin chat incluso en v1. Probar varias pestañas y outbox pendiente. |
|
|
|
|
|
|
| F08 | P2 | La matriz confundía invitado/cuenta con miembro/anfitrión y producía permisos contradictorios. | Ejes independientes y requisitos por operación; invitado puede ser anfitrión, pero no eludir edad/SMS. |
|
|
|
|
|
|
| F09 | P2 | Faltaban cancelar/configurar, revocar/rotar invitación, revocar condiciones/sesión y recuperar envíos de chat. | Operaciones y consulta común de recibos explícitas. Las credenciales/proveedor de edad permanecen señalados como pendientes, no simulados. |
|
|
|
|
|
|
| F10 | P2 | Solo podían jugar solos paquetes con `min=max=1`; inicio/fijación de versión aparecía en dos momentos. | Capacidad dentro del rango; pin exacto al crear, congelación de configuración al iniciar, invalidación de listo y setup atómico. |
|
|
|
|
|
|
| F11 | P2 | La política de inactividad no decía qué actividad contaba ni cómo evitar cierres obsoletos o reglas acopladas a `state.turn`. | Política versionada, progreso del motor, actores internos, generación y revalidación bajo bloqueo. No cuentan chat ni presencia. |
|
|
|
|
|
|
| F12 | P2 | Negociación dentro de `room.sync` no cubría clientes sin sala; faltaban recibos de baja, cursor de chat y límites de buffers. | Negociación de conexión, tipos correlacionados, sincronización acotada, cursores y backpressure. |
|
|
|
|
|
|
| F13 | P2 | La sincronización de chat retenía eventos mientras se paginaba un historial sin operación de continuación definida. | Snapshot de cola reciente con barrera; historial HTTP aparte, sin bloquear flujo vivo hasta leerlo entero. |
|
|
|
|
|
|
| F14 | P2 | Dedupe de avisos omitía destinatario; leerlos en una pestaña no tenía revisión. Un aviso de lobby podía revelar actividad privada. | Dedupe por destinatario/transición, revisión de bandeja al leer y señal solo por cambios públicos. |
|
|
|
|
|
|
| F15 | P2 | «Todos los IDs son UUID» contradecía `gameId`/asientos del motor. Campos de autoridad prohibidos también podían confundirse con destinatarios válidos. | Excepciones tipadas y distinción actor/objetivo. |
|
|
|
|
|
|
| F16 | P2 | 428 se reutilizaba para condiciones de uso; caché, errores, cursores y campos desconocidos eran ambiguos. | 403 para falta de aceptación, 409 para versión cambiada, revisiones de dominio y política separada de solicitud/respuesta. Referencia RFC 6585. |
|
|
|
|
|
|
| F17 | P1 | No se había especificado protección del menor ni diferencia entre teléfono, identidad, edad y consentimiento. | Requisito nuevo confirmado: no chat para menores; comprobación independiente de edad/SMS, restricciones en todo contenido/medio, reportes sin SMS y pruebas de evasión. |
|
|
|
|
|
|
| F18 | P2 | Recursos retirados parecían volverse privados; faltaban cuarentena, propiedad/validación de avatares y autoridad de publicación. | Política de distribución separada de contenido inmutable, publicación de confianza, medios propios validados y presets seguros. |
|
|
|
|
|
|
| F19 | P2 | Inmutabilidad de historial podía interpretarse como conservación personal indefinida; outbox y auditoría estaban mezcladas. | Finalidades/retenciones independientes, enmiendas auditables, anonimización y reaplicación de borrados tras restaurar. |
|
|
|
|
|
|
| F20 | P2 | SLO sin punto de medida/carga, migración sin autoridad única y recuperación/rollback no verificables. | Métricas servidor/exterior separadas, carga por definir, expansión/contracción, mapeo de IDs y cero doble escritura autónoma. RPO/RTO siguen pendientes. |
|
|
|
|
|
|
|
|
|
|
|
|
## Carencias que no resuelve editar Markdown
|
|
|
|
|
|
|
|
|
|
|
|
Actualización posterior por encargo del usuario: [políticas de producto](product-policies.md) desarrolla P1–P8 y compara fuentes oficiales; [arquitectura](architecture.md) separa las tres capas y evalúa Go. Publicación de juegos exclusivamente propios confirmada. Ya no faltan todos los valores de producto, pero sí evidencia de proveedores, capacidad operativa, contratos ejecutables e implementación.
|
|
|
|
|
|
|
|
|
|
|
|
| Pendiente | Entregable necesario |
|
|
|
|
|
|
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
|
|
|
|
|
| Credenciales y recuperación P6 | Correo/contraseña, estados y sesiones ya propuestos; faltan esquemas, proveedor, migración PIN y pruebas de emisión/recuperación. |
|
|
|
|
|
|
| Edad y acceso de menores P7 | Perfil España/tutela/salas protegidas definido; faltan evaluación territorial, proveedor de edad, procedimiento de evidencia de responsabilidad y validación real. |
|
|
|
|
|
|
| SMS | Plazos y límites definidos; faltan proveedor, precios/presupuesto autorizado, dedupe/conciliación y pruebas de webhooks. |
|
|
|
|
|
|
| Moderación | Roles, acciones y objetivos definidos; faltan consola, personal/cobertura, procedimiento de escalado y revisión independiente operativa. |
|
|
|
|
|
|
| Conservación/operación P8 | Matriz y objetivos RPO/RTO/carga definidos; faltan responsables, fundamento por finalidad, ejecución de purgas y ensayos medidos. |
|
|
|
|
|
|
| Contratos ejecutables | Fuente común de tipos, OpenAPI, esquemas de eventos, fixtures válidos/negativos y comprobación CI. |
|
|
|
|
|
|
| Integración del motor | Unidad de trabajo compartida, cancelación de núcleo, configuración de preparación/asientos y mapeo de versiones antiguas. |
|
|
|
|
|
|
| Dirección Go | API Go fijada; servidor Go recomendado. SDK nativo, binding de transporte, paquete versionado y equivalencia de reglas pendientes antes de portar producción. |
|
|
|
|
|
|
| Validación real | Concurrencia, privacidad, reconexión, abuso, SMS, pruebas móviles/accesibilidad y ensayos con PostgreSQL/proxy. |
|
|
|
|
|
|
|
|
|
|
|
|
Los requisitos confirmados de protección no dependen de aprobar una excepción de chat infantil: esa excepción no existe. Mientras falten pruebas de edad/mecanismos operativos, no se habilita comunicación por suposición.
|
|
|
|
|
|
|
|
|
|
|
|
## Hallazgos de la ampliación de políticas y arquitectura
|
|
|
|
|
|
|
|
|
|
|
|
| ID | Problema o riesgo de diseño | Resolución documental / aceptación pendiente |
|
|
|
|
|
|
| --- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
|
|
|
|
|
|
| F21 | «Publicador de confianza» podía interpretarse como apertura a autores externos. | Solo equipo y juegos propios; flujo interno, sin API pública de publicación. |
|
|
|
|
|
|
| F22 | Tres capas podían convertirse en dos escritores independientes de sala/partida. | API y servidor modular Go recomendado, unidad de trabajo común; puente Node con autoridad única si se necesita. |
|
|
|
|
|
|
| F23 | Confundir formato/protocolo JSON con compatibilidad ejecutable del SDK TS en Go. | Diferenciar datos, firmas y runtime; perfil de paquete versionado y fixtures de equivalencia antes de portar. |
|
|
|
|
|
|
| F24 | Sustituir Socket.IO por WebSocket sin adaptar handshake/cliente/recuperación. | Transporte actual preservado en su contrato; nuevo binding requiere especificación y pruebas, sin compatibilidad fingida. |
|
|
|
|
|
|
| F25 | SMS, correo, edad adulta o token podían interpretarse como evidencia de tutela o recuperación suficiente. | Evidencias y finalidades separadas, recuperación suspende capacidades sensibles, contactos autorizados y recurso. |
|
|
|
|
|
|
| F26 | Las políticas de desconexión podían sancionar fallos del servicio o ejecutar cierres vencidos durante una caída. | Sin penalización por presencia, ventanas de incidente y reconciliación de trabajos antes de reactivar cierres. |
|
|
|
|
|
|
| F27 | Historial de chat sin límite inferior y purga sin invalidación podían divulgar conversaciones previas o resucitar texto. | Intervalo por membresía, purga a 30 días y aumento de epoch/invalidación; pruebas de páginas retrasadas. |
|
|
|
|
|
|
| F28 | Objetivos de moderación/seguridad sin personas, presupuesto o backups medidos podían presentarse como capacidad existente. | Dependencias de activación, perfiles de ensayo y distinción entre objetivo y resultado observado. |
|
|
|
|
|
|
|
|
|
|
|
|
Las limitaciones observadas al comparar políticas de otras plataformas se distinguen de incidentes demostrados; no se ha auditado su implementación. Las fuentes y decisiones propias están junto a cada comparación en las políticas.
|
|
|
|
|
|
|
|
|
|
|
|
## Fuentes y criterio de revisión
|
|
|
|
|
|
|
|
|
|
|
|
- [Socket.IO: delivery guarantees](https://socket.io/docs/v4/delivery-guarantees/): sustenta la necesidad de recuperación a nivel de aplicación.
|
|
|
|
|
|
- [PostgreSQL: explicit locking](https://www.postgresql.org/docs/current/explicit-locking.html): orden consistente y transacciones acotadas.
|
|
|
|
|
|
- [RFC 6585, sección 3](https://www.rfc-editor.org/rfc/rfc6585.html#section-3): significado de 428.
|
|
|
|
|
|
- [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html) y [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785.html): errores HTTP y JSON canónico.
|
|
|
|
|
|
- [OWASP: session management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html): sesión y revocación servidor.
|
|
|
|
|
|
- Las fuentes de edad, SMS y la comparación con Lichess, ChessKid, Roblox y Discord figuran junto a las afirmaciones en [protección del menor](child-safety.md#8-cómo-lo-abordan-otras-plataformas).
|
|
|
|
|
|
|
|
|
|
|
|
La revisión toma estos textos como referencias técnicas y políticas publicadas, no como prueba de cumplimiento de Juegoland ni auditoría de terceros.
|
