|
|
# 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](../platform-spec-v2.md), la [API](api-and-events.md), la [protección del menor](child-safety.md) y la [arquitectura de tres capas](architecture.md). 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 remotos con cuenta propia, búsqueda global de personas, amigos abiertos, torneos, ELO, apuestas, compras, publicidad o recompensas por tiempo de conexión. El [perfil multidispositivo](../game-engine/multi-device-profile.md) propone después una pantalla compartida pasiva, autorizada por sala y sin plaza de jugador; no abre acceso de espectadores. Añadir otras capacidades 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](https://lichess.org/page/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](https://www.chesskid.com/learn/articles/how-to-understand-chesskids-safety-features2) | 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](https://support.chesskid.com/en/articles/8863569-how-do-i-connect-to-my-kid-s-account-through-guardianship) | 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](https://en.help.roblox.com/hc/en-us/articles/203313120-Safety-Features-Chat-Privacy-Filtering) | 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](https://en.boardgamearena.com/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](https://support.chess.com/en/articles/8593801-how-does-game-abandonment-work) | 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](https://lichess.org/page/appeal) | 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](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-protection-minors) | 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](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html); no se inventa un algoritmo propio. Las recomendaciones de longitud, gestores y cambio por compromiso se apoyan en [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html); 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`.
|
|
|
|
|
|
El [perfil común web/Flutter](client-communication-profile.md) contempla una sesión nativa futura, revocable y ligada al mismo principal. Sus credenciales/almacenamiento y emisión se documentan antes de abrir la app, conservando los plazos y restricciones de P6; renovación y socket activo no alargan la vida absoluta. La app no concede otro permiso de juego/chat por evitar el navegador. QR y enlaces siguen finalidades de acceso/emparejamiento y no transportan sesiones permanentes.
|
|
|
|
|
|
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](https://www.boe.es/buscar/act.php?id=BOE-A-2018-16673#a7) 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](https://www.edpb.europa.eu/documents/statement/statement-12025-on-age-assurance_en).
|
|
|
- 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 o el acceso QR de mesa. 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 | Solo entrada `standard`: 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, nuevo acceso según su método (invitación o QR de mesa) 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.
|
|
|
|
|
|
El [perfil multidispositivo](../game-engine/multi-device-profile.md) propone mesas presenciales `TVBoard` con `screen-qr`, privadas, sin emitir invitaciones; el acceso mostrado por TV caduca/rota y siempre exige permisos actuales. Sus cuotas específicas siguen pendientes; se aplican también los límites de salas/plazas y no se abre acceso ilimitado por usar QR. En una sala convencional, el jugador invitado puede usar TV personal y mando móvil mediante QR de enlace, y debe poder elegir «Jugar solo en el móvil» manteniendo su membresía. Un cambio visual no transforma la política de la mesa ni consume otra invitación.
|
|
|
|
|
|
El [perfil de sincronización](../game-engine/synchronization-profile.md) propone preparación y recogida de respuestas con reloj de servidor. La llegada del primer paquete no es prueba de primera reacción; las carreras requieren compensación acotada, incertidumbre y empate. Una ronda con fallo temporal no se convierte en derrota por red. La base recomendada para quiz puntúa acierto, sin ventaja por velocidad de transporte; el perfil de reacción sigue experimental. Las reglas se fijan por versión antes de jugar y los cambios de presentación se aplican en un punto seguro, sin reiniciar el plazo.
|
|
|
|
|
|
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
|
|
|
|
|
|
Los [jugadores virtuales](../game-engine/virtual-player-profile.md) son una opción declarada por cada juego, con instrucciones incluidas en su paquete y perfiles publicados por el equipo. La sala identifica sus plazas IA y los humanos aceptan la configuración antes del inicio. Este soporte declarado no autoriza asistencia externa oculta para una plaza humana. Un agente usa solo la información de su asiento, carece de permisos sociales y no sustituye la tutela ni al anfitrión responsable; la práctica individual contra IA requiere un perfil de admisión explícito antes de activarse. La capacidad está pendiente de implementación.
|
|
|
|
|
|
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](https://www.w3.org/TR/WCAG22/): 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.
|
