You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

44 KiB

Políticas de producto y operación — Juegoland v2

Estado: base de diseño desarrollada el 5 de octubre de 2026 por encargo del usuario. No está implementada ni constituye una certificación jurídica. Las decisiones expresas del usuario son: juegos propios publicados exclusivamente por el equipo, motor propio, protección transversal del menor, chat desactivado para menores y SMS obligatorio para quienes puedan usar chat. Los demás valores de este documento son decisiones de diseño propuestas con justificación y criterios de revisión.

Complementa el modelo, la API, la protección del menor y la arquitectura de tres capas. Sustituye los valores abiertos P1–P8 del primer borrador por una base concreta. Proveedores, presupuesto autorizado, responsables y evidencia de funcionamiento se resuelven antes de activar las capacidades correspondientes.

1. Alcance del primer lanzamiento

  • Juegos propios, por turnos, casuales, con reglas y recursos revisados por el equipo. No hay publicación de usuarios, marketplace, plugins externos ni carga de código desde cuentas de jugadores.
  • Catálogo, cuentas, juego individual, salas privadas y salas públicas para adultos acreditados; partidas privadas supervisadas para menores; historial privado, invitaciones, bloqueo, reportes y consola interna.
  • Chat exclusivamente en salas configuradas para adultos acreditados y para miembros con SMS vigente. Las salas protegidas, incluidas las mixtas con menores, tienen comunicación desactivada para todos sus participantes. Es una decisión adicional de diseño: simplifica la supervisión y evita canales paralelos invisibles para parte de la mesa.
  • Sin mensajes privados, voz, espectadores, búsqueda global de personas, amigos abiertos, torneos, ELO, apuestas, compras, publicidad o recompensas por tiempo de conexión. Añadirlos exige estudiar permisos y abuso antes de ampliar contratos.
  • Primera política territorial diseñada para España; no se presupone lanzamiento mundial por tener la web accesible. La configuración de países admitidos y condiciones debe fijarse antes del registro público. Un país no configurado no hereda automáticamente las condiciones españolas; la IP es una señal auxiliar, no prueba de residencia.

2. Qué tomamos de otras plataformas y qué cambiamos

Fuentes oficiales consultadas el 5 de octubre de 2026. La columna de riesgos es nuestro análisis del diseño publicado, no una afirmación de vulnerabilidades demostradas en esos servicios. Los valores numéricos de Juegoland son propios salvo indicación expresa.

Referencia Práctica publicada Riesgo o límite que evitamos en Juegoland
Lichess Kid Mode Permite jugar restringiendo comunicación; mantiene excepciones para la clase y su profesor. Las excepciones complican la autorización. No habilitamos chat infantil por tutor, clase o sala privada.
ChessKid: seguridad Restringe chat entre niños y conexiones adulto-menor a relaciones de tutela. Adoptamos un entorno de contactos autorizados, comprobando la relación por separado de la edad adulta.
ChessKid: vinculación Describe vinculación de cuentas mediante correspondencia del correo del responsable. Una coincidencia de correo o un enlace reenviado no serán evidencia suficiente para tomar control de una cuenta infantil existente.
Roblox: seguridad de chat Filtrado de comunicación y medidas contra datos personales y salida a otras plataformas. Filtrar palabras no basta: la restricción se aplica también a nombres, imágenes, recursos, invitaciones y contenido de juego. No prometemos que un filtro comprenda todos los abusos.
Board Game Arena: FAQ Relojes, reputación y penalizaciones por abandonar; consecuencias competitivas de expulsar a quien excede tiempo. En una plataforma casual no inferimos mala conducta ni derrota de una conexión caída. Separamos retirada, inactividad, fallo del servicio y sanción.
Chess.com: abandono Usa temporizadores de desconexión/actividad y explica que la cobertura Wi-Fi no demuestra conexión con el servidor. Mostramos confirmación del servidor y estado de reconexión. No presentamos como ejecutada una jugada pendiente ni aplicamos tiempos competitivos ocultos a partidas casuales.
Lichess: apelaciones Revisión humana por otro moderador y objetivo publicado de respuesta. Definimos responsables, plazo y recurso junto a la sanción; no basta con un botón de denuncia. La falta de personal no se presenta como revisión independiente.
Comisión Europea: protección del menor Privacidad por defecto, control del contacto y reducción de diseños que fomentan uso excesivo. Sin rachas, presión para volver, avisos comerciales ni publicación de actividad infantil. La aplicación de estas guías no acredita por sí sola cumplimiento.

3. Identidad, credenciales y recuperación — P6

Estados y acceso

Estados de cuenta: pending-email, active, restricted, deletion-pending, deleted. Invitado es un tipo de principal independiente, no un adulto provisional. Verificación de correo, edad, teléfono, supervisión y restricciones tienen estados propios; ninguna columna verified los mezcla.

Identidad Acceso de diseño
Sin cuenta Catálogo seguro, reglas y demostraciones locales sin perfil social.
Invitado Juego individual y alias/preset de sistema; sin multijugador, chat ni descubrimiento de personas. Identidad temporal recuperable solo desde su contexto de navegador.
Cuenta con correo pendiente o edad desconocida Cuenta y privacidad propias; modalidad segura individual. No basta declarar una fecha para elevar permisos.
Adulto acreditado Multijugador público/privado, condicionado por aceptación y restricciones; SMS solo para chat.
Menor con cuenta tutelada activa Individual y salas privadas protegidas con participantes autorizados; sin comunicación ni ficha pública.

Convertir invitado conserva userId, partidas y preferencias propias. Entrar en otra cuenta no fusiona cuentas ni ocupa automáticamente sus plazas. El invitado no obtiene privilegios de una sesión anterior del navegador.

Credenciales

La base es correo verificado y contraseña de 15 a 128 puntos de código, normalizada NFC, sin truncar, sin reglas arbitrarias de composición ni renovación periódica. Se comprueban contraseñas comunes/comprometidas sin enviar su texto a un tercero. Hash Argon2id con sal aleatoria y parámetros calibrados/versionados para el hardware, respetando como mínimo la configuración de OWASP; no se inventa un algoritmo propio. Las recomendaciones de longitud, gestores y cambio por compromiso se apoyan en NIST SP 800-63B; los plazos y límites operativos siguientes son nuestros.

Passkeys son una evolución compatible para jugadores; el acceso administrativo requiere MFA resistente a phishing antes de producción. El PIN de cuatro cifras deja de servir como credencial remota. Migrar cuentas antiguas exige establecer credencial nueva y verificar un canal de recuperación; el correo antiguo no verificado no recibe poder para apropiarse de la cuenta sin comprobar titularidad.

Una cuenta infantil no necesita teléfono ni correo personal: recuperación por el responsable validado y credencial propia o emparejamiento de dispositivo de un solo uso autorizado por ese responsable. Un código de emparejamiento es aleatorio, caduca en 5 minutos, admite 5 intentos y no es una contraseña permanente. Su contrato ejecutable debe preceder a habilitar cuentas infantiles.

Flujos y sesiones

  1. Alta: contexto anónimo emitido por servidor, aceptación versionada y creación pendiente. Correo de verificación con token aleatorio de 256 bits, hash en servidor, uso único y vigencia de 24 h. La dirección no se muestra a terceros; solicitud repetida devuelve una respuesta genérica.
  2. Login: valida credencial y restricciones; rota sesión y CSRF, no acepta un identificador de sesión elegido por el cliente. Reautenticación administrativa exige su segundo factor.
  3. Recuperación: respuesta externa indistinguible exista o no cuenta; token aleatorio de 256 bits, uso único y vigencia de 30 min; permite restablecer credencial y luego iniciar sesión. No devuelve una sesión con permisos elevados en el enlace de correo.
  4. Restablecer credencial revoca todas las sesiones y tokens de recuperación pendientes. Suspende comunicación y gestión de menores hasta revalidar sus pruebas pertinentes; poseer correo o un teléfono reciclado no restaura automáticamente esos permisos.
  5. Cambio de correo: reautenticación reciente y verificación del nuevo correo; aviso al anterior, sin enlace que por sí solo conceda control de cuenta. Soporte no cambia edad, tutela o credenciales basándose únicamente en datos de perfil.
Sesión / operación Plazo propuesto
Invitado 24 h absolutas, 2 h inactivo; no prolongar por latidos.
Cuenta, modo normal 12 h absolutas, 2 h inactivo.
«Recordarme», adulto y dispositivo personal 30 días absolutos, 7 días inactivo; elección explícita.
Cuenta infantil o equipo compartido Sin «recordarme» por defecto; 12 h absolutas y 1 h inactivo.
Administración 8 h absolutas, 15 min inactivo, sin «recordarme».
Reautenticación para credenciales, teléfono, tutela, exportación o borrado Últimos 5 min; se mantienen rutas de ayuda para quien no pueda autenticarse.

Actividad es una interacción autenticada del usuario, no ping, polling o publicación servidor. Las páginas de verificación/recuperación no cargan terceros; secretos en fragmento y POST, fuera de logs, historial y analítica, con no-store.

Login, emisión de sesión y consumo de token necesitan un registro de intento específico. Ventana de recuperación de respuesta cifrada: 5 min, ligada al contexto y prueba original; repetir no crea otra sesión ni alarga su vida. Una sesión revocada no se reemite. Finalizada la ventana se exige nuevo login o recuperación. No almacenar contraseñas, OTP ni sesión en recibos generales. Cuotas iniciales: 5 fallos de acceso/15 min por cuenta y 30/IP, con espera progresiva; 3 correos de recuperación/hora por cuenta y 20/IP. No bloqueo indefinido activable por un atacante; respuestas con tiempos y contenido uniformes, límites globales y soporte accesible.

4. Edad, supervisión y comunicación — P7

El perfil de lanzamiento propone cuentas tuteladas de 6 a 17 años, alta autónoma para adultos y demostración local sin cuenta por debajo de esa franja. Es una elección de producto inicial, no una edad mínima legal ni una obligación de tutela universal. La autonomía de adolescentes y la adecuación del límite inferior deben reevaluarse con pruebas de uso antes de ampliar el perfil.

En España, el artículo 7 de la LOPDGDD distingue el consentimiento para tratamiento de datos por debajo de catorce años y contempla excepciones. Esto no equivale a permiso general para chat, mayoría de edad, capacidad contractual o autorización de todo tratamiento. Cada finalidad debe tener base y alcance propios; no se usa «aceptar condiciones» como consentimiento universal.

  • Una declaración de minoría activa restricciones inmediatamente. Acreditar adulto exige prueba del umbral de 18 años, vinculada a cuenta, propósito y solicitud. Sin prueba, se puede seguir en modo seguro individual.
  • Se prefiere acreditación de umbral con mínima información, sin guardar DNI, selfie, fecha exacta de nacimiento ni biometría en Juegoland. La evaluación del proveedor incluye falsos positivos/negativos, accesibilidad, corrección, supresión y alternativa viable para adultos sin documentos compatibles. EDPB: comprobación de edad.
  • La validez interna de la prueba adulta se limita al menor de la caducidad del emisor y 12 meses. Caducidad, recuperación sensible o evidencia contradictoria suspenden privilegios afectados; cumplir años según un dato autodeclarado no los activa.
  • Teléfono: reverificar a los 180 días y después de cambio, recuperación sensible o señal de compromiso. Se avisa antes de vencer; al vencer se corta chat, no la partida. La verificación nunca habilita una cuenta menor.

Cuenta tutelada y contactos

El responsable necesita cuenta adulta acreditada, correo verificado y reautenticación reciente. Acreditar edad adulta no acredita potestad sobre un menor. El alta de la relación requiere evidencia adecuada de responsabilidad y consentimiento por finalidad: un servicio que soporte esa comprobación o un procedimiento humano definido y auditado. No basta conocer correo/nick, compartir teléfono o presentar una invitación. No se abre esta capacidad hasta disponer del procedimiento y su tratamiento de evidencias.

Estados: pending → active → suspended|revoked. Alta inicial por responsable crea la cuenta infantil; vincular una cuenta existente exige comprobación adicional del control previo y de la responsabilidad, nunca autoenlace por correo. Cambiar responsable exige revisión; mientras haya disputa se suspenden cambios de supervisión y nuevos encuentros, manteniendo ayuda y acceso a datos propios según corresponda.

El responsable aprueba relaciones dirigidas y revocables entre principales concretos; no crea un grupo social público. Si ambos participantes son menores, sus respectivos responsables deben autorizarlas. Una invitación a una sala solo funciona si las relaciones necesarias ya están activas. Un menor puede bloquear o rechazar a una persona autorizada; el responsable no anula ese bloqueo silenciosamente.

La sala protegida no aparece en listas públicas; todos sus participantes están autorizados para encontrarse entre sí. Proyecta alias/presets revisados también para adultos. No admite texto libre, fotos ni chat de ningún participante. Menores no pueden crear salas públicas ni transformar una privada en pública. Salas públicas/adultas no admiten menores aunque alguien comparta su token.

En este perfil inicial, el anfitrión responsable ocupa una plaza como jugador y debe estar autorizado para supervisar a los menores participantes. No se crea implícitamente un rol de espectador. Por tanto, una sala protegida de dos plazas admite responsable y menor; jugar exclusivamente entre dos menores requeriría ampliar el modelo de supervisión sin plaza y queda fuera de esta primera configuración. Si el anfitrión abandona expresamente una partida protegida activa se cancela por seguridad sin resultado competitivo; perder conexión solo inicia la recuperación normal y no equivale a abandonar.

Revocar supervisión o contacto impide nuevas entradas y nuevas acciones entre las personas afectadas. En una partida en curso se aplica una cancelación de seguridad coordinada con el núcleo, sin ganador artificial y con motivo público genérico; preserva lo necesario para revisión privada. Una emergencia no espera a que el jugador confirme una revisión obsoleta. La transacción interna revalida la revisión actual.

La vista del responsable muestra configuración, personas autorizadas, juegos y duración aproximada, no secretos de partidas ni conversaciones adultas. A los 18 años no hereda control de la cuenta: la emancipación requiere acreditar el nuevo umbral y establecer recuperación propia; se revoca acceso del responsable de forma atómica. No se recopila una fecha exacta solo para automatizar ese cambio.

5. Salas, invitaciones y continuidad — P1–P4

Política Base de diseño
Inicio P1 Automático al llenarse la capacidad configurada y marcarse todos listos; uno también es válido si el paquete lo permite. Cambios de participantes/configuración invalidan listo.
Anfitrión P2 Al salir en espera, transferir al miembro elegible más antiguo, desempate por membershipId; si no queda elegible, cancelar. Revocar invitaciones del anterior anfitrión. En protegidas, anfitrión adulto responsable autorizado.
Configuración Juego, versiones, tipo de admisión y comunicación se fijan al crear; capacidad y opciones admitidas solo cambian en espera. La UI presenta consecuencias antes de «listo».
Espera P3 Sala pública caduca a los 30 min; privada a las 24 h desde creación. Ningún ping/chat la prolonga. El anfitrión puede crear otra explícitamente.
Partida P3 Perfil casual inicial: cierre solicitado tras 10 min sin progreso, solo por quien no puede actuar mientras otro sí; cancelación automática tras 24 h sin progreso. Sin derrota por presencia perdida.
Variantes El registro de publicación aprueba un perfil de duración por versión de juego. Un juego que necesite correspondencia o plazos diferentes no hereda silenciosamente 24 h: requiere otro perfil documentado antes de publicarse.
Invitación P4 24 h por defecto; máximo 7 días y siempre antes del vencimiento de sala. Un uso por defecto; límite de usos nunca superior a plazas libres al emitir. Revalidar capacidad al consumir.
Cuotas P4 Máximo 5 salas en espera por adulto, 1 por responsable en nombre de cada menor, 10 invitaciones activas por sala y 20 emisiones/hora por anfitrión. Entrada idempotente no consume otro uso.
Revancha Otra sala, otra invitación y aceptación explícita; no arrastra chat, tutela revocada ni participantes sin consentimiento.

Cerrar pestaña, pasar a segundo plano o perder Wi-Fi no es retirada. Se permite reconectar desde otra sesión del mismo principal sin otro asiento. Una retirada explícita la resuelven las reglas del juego; la plataforma no adjudica automáticamente victoria al último conectado.

No hay sanciones de reputación por desconexión en v2 casual. Abuso repetido de creación/entrada puede limitarse por cuotas; sanciones por sabotaje requieren evidencia y recurso. Un bloqueo personal evita nuevos encuentros, pero por sí solo no concede una victoria ni permite expulsar a un rival durante una partida.

Fallos del servicio

lastProgressAt cambia con progreso confirmado del motor. Para evaluar inactividad se excluyen intervalos de indisponibilidad del servicio confirmados por operación; se registran con alcance y revisión, sin que un cliente pueda declararlos. Antes de reactivar el programador tras un incidente se reconcilian los plazos y se concede al menos 10 min de margen para cierres de plataforma que hayan vencido durante el corte. Una ausencia de métricas no demuestra abandono: se retienen esos cierres hasta revisar el incidente.

No se reescribe el reloj de un juego competitivo inexistente en v2; si se introduce, tendrá política propia de incidentes. Una cancelación ya confirmada se conserva y solo admite enmienda auditada, nunca reapertura silenciosa. Se comunica por separado fallo de red, mantenimiento, partida bloqueada y cancelación.

6. Chat, presencia, notificaciones y bienestar — P5

Chat solo en salas adultas, texto plano de hasta 500 puntos de código/2 KiB, sin adjuntos, enlaces activos ni previsualizaciones externas. El servidor rechaza patrones claros de spam/datos de contacto y aplica moderación; no reescribe silenciosamente lo que quiso decir el autor ni considera el filtrado garantía suficiente. Un rechazo muestra una explicación y permite corregir como intención nueva.

El intervalo legible empieza al entrar en la sala y termina al retirarse o finalizar, sujeto a restricciones actuales y redacciones. No se comparte historial anterior a la admisión. Al finalizar, chat de solo lectura hasta su purga; no existe conversación persistente a través de revanchas. La pérdida de SMS o elegibilidad bloquea también historial.

Presencia solo dentro de salas autorizadas, sin «última vez» global, localización ni lista pública de menores. TTL vencido significa desconocido. Notificaciones de sistema sin fragmentos de chat, con destino autorizado al abrir. Sin correo/push comercial ni recordatorios de retorno; avisos de seguridad y recuperación usan su finalidad específica.

Preferencia de sonido y movimiento reducido, sin autoplay de audio antes de interacción. Aviso discreto de descanso a los 45 min de actividad local; descartable, sin sanción ni pérdida de partida. El responsable puede configurar una pausa futura: avisa antes y evita iniciar otra partida; no expulsa de una activa por sorpresa. No se exige una racha ni compartir datos para seguir jugando.

7. Moderación, administración y juego limpio

Roles internos separados: soporte de cuenta, moderación, publicación y operación. Acceso mínimo por función, MFA, reautenticación sensible y auditoría de consultas a evidencia. Publicar juegos no concede lectura de teléfonos o casos infantiles. El personal no puede impersonar usuarios ni jugar con una vista privilegiada; diagnósticos usan datos sintéticos o proyecciones mínimas.

Se prohíben acoso, amenazas, discriminación, petición de contacto/datos personales, captación, contenido sexual, spam, suplantación y manipulación deliberada del juego. Las reglas de ayuda externa se explican por modalidad: en multijugador sin acuerdo explícito, no motores ni asistencia que decida jugadas; práctica individual puede ofrecer ayudas declaradas. No se sanciona automáticamente por precisión, IP compartida o una anomalía estadística aislada.

Prioridad Tratamiento y objetivo propio
Urgente: posible daño a menor, amenaza o cuenta comprometida Confirmación inmediata, posibilidad de bloqueo/cierre personal y alerta a guardia. Primera valoración humana objetivo ≤1 h durante capacidad social habilitada.
Acoso, contenido o sabotaje Primera valoración ≤24 h; comunicación de decisión o estado ≤72 h.
Apelación/corrección de edad o sanción Acuse inmediato; revisión humana por otra persona objetivo ≤7 días. No requiere chat ni SMS.

Son objetivos de operación que deben dotarse de personal, no promesas de servicio ya existente. Antes de habilitar chat y encuentros públicos se asignan guardia y sustituto, calendario y escalado. Si no existe cobertura, esas capacidades permanecen apagadas; se puede lanzar juego individual y privado protegido con ayuda asincrónica y horario visible. Los reportes se reciben siempre; no prometer respuesta urgente fuera de la cobertura real.

Un reporte no produce sanción automática al denunciado. Restricciones preventivas requieren regla de riesgo explicable y trazabilidad; se separan de una decisión definitiva. Medidas: retirar contenido, limitar comunicación, suspensión temporal y cierre en casos graves/repetidos, con motivo, alcance y vencimiento. Revisión de urgencia no exige seguir una escalera antes de proteger.

La apelación se vincula al caso, permite aportar información sin publicar evidencia y no depende de mantener abierta una sesión social. Se admite durante 6 meses desde notificación, sin excluir solicitudes legales posteriores. Si solo hay un operador, se declara la limitación y se busca revisión distinta antes de habilitar una operación que prometa independencia. Las comunicaciones a autoridades o terceros tienen procedimiento jurídico/humano propio; no se envían automáticamente por este diseño.

8. Publicación interna de juegos

El equipo es el único autor y publicador. No hay endpoint de publicación para jugadores, acceso de desarrolladores externos ni sandbox de código subido por usuarios. Las dependencias de software y recursos reutilizados siguen requiriendo licencias y revisión; «propio» no equivale a ausencia de dependencias.

Flujo interno: draft → validated → staged → published → retired|quarantined. Los primeros estados son de preparación; los tres últimos son disponibilidad pública ya definida en el modelo. Un artefacto publicado es inmutable por digest.

Para publicar: validación estructural/semántica, inventario de recursos y licencias, pruebas de reglas y privacidad por asiento, conservación de versiones, reconexión, retirada, determinismo/azar, teclado/táctil/movimiento reducido, revisión de texto/imágenes/audio y ensayo de carga. El registro fija perfil de edad/contenido, duración, compatibilidad del motor y build de servidor que incluye sus reglas. Staging usa cuentas sintéticas, nunca sesiones de producción.

Se activa primero para pruebas internas, después gradualmente para nuevas salas. Las existentes conservan su versión. Retirar impide crear y permite terminar; poner en cuarentena bloquea ejecución y abre incidente, con reparación compatible o cancelación auditada sin inventar resultado. Revertir despliegue requiere conservar todas las reglas aún activas. Los assets públicos tienen nombre por digest; jamás incluyen reglas privadas, credenciales o estado oculto.

9. Datos, conservación y borrado — P8

Plazos base de producto, sujetos a concretar bases jurídicas por finalidad antes de producción; no se atribuyen a las plataformas consultadas. Cada purga tiene propietario operativo, métrica, propagación y prueba de restauración. No se mantiene todo indefinidamente «por seguridad».

Categoría Retención propuesta y eliminación
OTP y tokens de acción Secreto/hash eliminados al consumirse, agotarse o vencer; metadatos mínimos de abuso 30 días. Respuesta cifrada de emisión de sesión máximo 5 min; invitación máximo 24 h.
Sesiones Token revocado deja de autenticar inmediatamente; registro mínimo hasta 30 días después de caducar/revocar. Nunca token en claro en auditoría.
Invitados / altas incompletas Invitados: purgar perfil a los 7 días de expirar y cerrar antes cualquier partida individual; alta no verificada: 7 días. No consumir una cuenta convertida con un job antiguo.
Teléfono / prueba de edad Mientras habiliten una finalidad; teléfono cifrado se elimina en ≤24 h al revocar, salvo finalidad documentada distinta. Índice antiabuso HMAC 30 días; evidencia mínima de edad hasta 30 días tras caducidad/revocación. Sin documentos/biometría propios.
Supervisión / consentimientos Vínculo activo mientras sea necesario; prueba mínima de consentimiento/actuación hasta 12 meses tras fin, con finalidad y revisión. No guardar documentos originales como registro permanente.
Chat 30 días desde cada mensaje; páginas y eventos vivos respetan purga y redacciones. Evidencia seleccionada de un caso va a un almacén restringido independiente.
Salas terminales, estado y eventos de juego 90 días tras terminar; después borrar estado privado, recibos asociados y relación detallada de participantes salvo caso justificado.
Resultados resumidos propios 24 meses desde finalización, sin chat ni secretos. Después agregados solo si son realmente anónimos; pseudonimizar un UUID no basta.
Notificaciones 90 días desde creación, leídas o no; las referencias purgadas muestran destino no disponible.
Reportes y apelaciones 12 meses tras cierre definitivo, ampliación motivada/revisada por obligación o incidente. Aislamiento, registro de cada acceso y eliminación al terminar finalidad.
Sanciones y bloqueos Restricción mientras esté activa; al vencer, metadatos mínimos hasta 12 meses. Bloqueos mientras exista la relación y cuenta; su baja no revela quién bloqueó.
Logs / auditoría Logs operativos 14 días, seguridad 90 días, acciones administrativas 12 meses; sin payloads, OTP o pruebas privadas.
Outbox / recibos generales Outbox confirmada 7 días; no confirmada genera alerta y reconciliación, no purga silenciosa. Recibos sala/juego 90 días tras terminal; chat 30 días; otros comandos 30 días. Sobres caducados no se reaplican tras purga.
Avatares Solo revisados; eliminar original tras transformación, máximo 24 h. Reemplazados/eliminados: retirar origen y cachés controladas en ≤24 h; copias de terceros no son revocables.
Copias de seguridad Ventana móvil máxima 35 días, cifrada y separada; sin volver a poner en servicio datos borrados al restaurar.

Los originales de evidencia excepcional de tutela, si un procedimiento aprobado los requiere, se manejan en un canal restringido y se eliminan en ≤7 días tras decisión; se conserva solo resultado mínimo. Su necesidad y acceso deben justificarse antes de recogerlos.

Exportación: reautenticación/titularidad proporcional, preparación objetivo ≤7 días, descarga privada de un uso que caduca en 24 h, archivo eliminado en 7 días. Incluye datos propios y explica restricciones/redacciones de terceros; no exige SMS ni abre chat a menores. Las solicitudes legales siguen sus plazos aplicables aunque no haya cuenta activa.

Borrado: confirmación explícita y reautenticación; suspensión de sesiones y nuevas acciones inmediata, resolución coordinada de partidas activas, purga de datos ordinarios en ≤30 días. Sin período de espera obligatorio ni recuperación por un simple login. Retenciones excepcionales se segregan, justifican y comunican cuando proceda. Las copias expiran en ≤35 días adicionales respecto de una purga del origen, sin acceso ordinario.

Un registro mínimo independiente de supresión/restricción se conserva hasta que hayan caducado todas las copias que podrían restaurar esos datos. Toda restauración permanece cerrada al tráfico hasta reaplicar ese registro y las revocaciones vigentes. El simulacro incluye una cuenta borrada y una restricción posterior al backup. Una retención de caso no mantiene habilitada una cuenta ni autoriza uso comercial de su información.

10. Experiencia y accesibilidad

Se especificarán pantallas completas sobre estos recorridos: descubrir → elegir → configurar → aceptar listo → jugar → resultado; invitación → comprobación de acceso → entrada; alta/verificación/recuperación; tutela/contactos; denunciar/bloquear/apelar; exportar/borrar. Cada paso contempla carga, vacío, validación, permisos caducados, desconexión y error recuperable.

El objetivo es WCAG 2.2 AA: teclado, foco visible, instrucciones textuales, contraste, autenticación accesible y alternativas a arrastre/color/sonido. Interfaz de plataforma usable a 320 CSS px y zoom 200–400 %; tablero bidimensional con navegación propia sin estrechar el resto de la página. Probar navegadores móviles reales, teclado virtual, orientación, texto ampliado y modo de escritorio además de emulación.

La UI distingue acción pendiente y estado confirmado; no reproduce sonidos de todo el historial al reconectar. El frontend nunca calcula un permiso definitivo ni decide resultado/azar. Controles desactivados explican el requisito al propietario sin divulgar edad o sanción ajena. Las animaciones no bloquean plazos ni confirmaciones del servidor.

11. Operación y costes — P8

Elemento Perfil inicial de aceptación, aún sin medir
Disponibilidad Objetivo mensual 99,9 %, medido desde fuera de la LAN/proxy; registrar mantenimiento e incidentes. No equivale a SLA contractual.
Latencia p95 en servidor <500 ms lectura y <1 s recibo; reconectar/sincronizar <5 s tras restablecer red después de 30 s de corte. SMS/edad se miden aparte.
Carga reproducible 500 conexiones autenticadas, 100 partidas activas, 50 comandos/s sostenidos durante 30 min; ráfaga de reconexión de 500 clientes en 60 s. Fixtures públicos/protegidos y varias vistas por juego; registrar hardware, memoria, errores y p99. Es umbral de ensayo, no capacidad acreditada.
RPO / RTO Pérdida recuperable objetivo ≤5 min / recuperación objetivo ≤60 min. Copia base diaria + archivo continuo WAL, cifrados y fuera del host; alerta por retraso >5 min. Simulacro mensual y tras cambios relevantes.
Despliegue Artefactos reproducibles, staging, migraciones expand/contract, arranque automático y drenaje; readiness valida DB, versión de esquema y todos los módulos activos. No arrancar dos propietarios de una partida.
Diagnóstico Sondas separadas de frontend, API, comandos, DB, proxy, DNS/TLS y recorrido externo. Cambiar Node por Go no demuestra ni arregla por sí mismo una avería de red.
Proveedores Email, SMS y prueba de edad con timeout, dedupe/conciliación, métricas, circuit breaker y estado visible. Fallar en modo restringido sin cancelar juegos por una caída de SMS.
SMS Destinos admitidos por política, cuotas de desafíos de protección y presupuesto finito configurado. Perfil candidato: 10 €/día y 50 €/mes, sin autorizar gasto ni contratar proveedor por documentarlo; límite efectivo cero hasta configurar precio y presupuesto autorizado.

Antes de cada envío se reserva atómicamente coste conservador conocido; el callback concilia coste real. Al agotarse presupuesto, no se envía ni se cambia de proveedor silenciosamente; se preserva el estado verificable anterior hasta su caducidad. Disputas/costes desconocidos quedan reservados hasta reconciliar para impedir duplicados facturados.

Asignar responsable de operación, protección, privacidad y publicación, con sustituto y contacto interno. No inventar nombres ni cobertura. La consola muestra retraso de outbox, fallos de purga, edad de backups, disponibilidad de moderación, cuotas y errores de proveedor sin exponer secretos.

12. Dependencias de activación y aceptación

Capacidad Qué debe existir antes de habilitarla
Cuenta recuperable Email contratado/configurado, credencial y sesiones implementadas, migración segura de PIN y pruebas de emisión/respuesta perdida.
Multijugador adulto Acreditación de edad evaluada, reglas de admisión y revisión de privacidad; para encuentros públicos, bloqueo/reportes y cobertura operativa.
Cuenta infantil / salas protegidas Procedimiento de tutela, contactos autorizados, mecanismo de acceso infantil, proyecciones seguras y cancelación por revocación.
Chat Adulto + SMS + sala adulta + moderación operativa + retención, probados en HTTP, tiempo real, v1, exportaciones y cachés.
Publicación de juego Flujo interno y comprobaciones de paquete, runtime y frontend; manifiesto/digest asociado a build instalable.
Producción v2 Contratos ejecutables, Postgres real, migración ensayada, restauración con supresiones, observabilidad y capacidad medida.

Pruebas mínimas adicionales: recuperar una cuenta no restaura chat/tutela automáticamente; tutor revocado no admite nuevos participantes; menor no entra con invitación adulta; chat previo a la admisión no se filtra; moderación y purga invalidan páginas retrasadas; un corte del servidor no provoca cierres retrospectivos injustificados; dos proveedores/callbacks no elevan permisos ni duplican gastos; v1 y v2 no eluden la misma política. Estas pruebas deben convertirse en contratos y pruebas de integración; este documento no afirma que hayan pasado.

Powered by TurnKey Linux.