Historial de versiones

El registro ahora pide un correo electrónico y lo verifica antes de que exista la cuenta, y el operador dispone de una lista de cuentas.

• El registro envía un código de 6 dígitos a la dirección y solo entonces crea la cuenta: hasta que se introduce el código no hay ninguna fila en la tabla de usuarios.
• Cambiar la dirección también requiere un código y exige antes la misma prueba de identidad que borrar la cuenta; después se avisa a la dirección antigua y se cierra la sesión en los demás dispositivos.
• Las cuentas creadas antes de esto no tienen dirección, siguen funcionando igual y no dependen de ello para nada.
• El inicio de sesión con terceros adopta la dirección que informa el proveedor, marcada como verificada solo si el proveedor dice haberla verificado.
• Límites de envío: como máximo 3 códigos por dirección al día, 3 direcciones distintas por navegador al día y 40 mensajes por hora en todo el sitio.
• Nueva lista de cuentas para el operador: direcciones enmascaradas por defecto, cada revelación registrada, y opciones de desactivar, forzar el cambio de contraseña y borrar. No muestra contraseñas: no hay ninguna contraseña en texto plano en la base de datos.
• Borrar una cuenta ahora elimina también los avatares, los ajustes de perfil, los mensajes de chat y las filas de verificación pendientes, que antes se quedaban.

Cinco tablones con sus propias publicaciones, filtros y chat por publicación, respaldados por la misma base de datos local que todo lo demás.

• Tablones de reclutamiento de equipo, amigos y club, más un tablón general y otro temático.
• Cada publicación lleva un hilo de chat; enviar un mensaje devuelve la publicación a lo alto de su tablón.
• Las publicaciones de reclutamiento admiten un modo, un mínimo de trofeos, un rango mínimo de Competitivo y un idioma; cada tablón puede filtrarse por modo, mínimo de trofeos, idioma y estado.
• El campo de rango mínimo del formulario se rellena con los nombres de rango de Competitivo que esta instancia ha observado realmente, así que nunca ofrece un rango que ya no existe.
• Publicar requiere una cuenta; el autor puede cerrar una publicación cuando termina o eliminarla directamente.
• Las publicaciones sobreviven a la eliminación de la cuenta con el nombre del autor registrado en la fila; ver la política de privacidad.

Resultó que la API oficial publica varios campos que el sitio estimaba. Esas estimaciones se eliminaron en lugar de conservarse como respaldo.

• El índice de rango de Competitivo, el nombre del rango, el elo y el id de temporada se guardan ahora por jugador, junto con los máximos de temporada e históricos.
• El nivel total de prestigio, la fama y el rango de fama se guardan y muestran como valores medidos.
• Se indexan el prestigio por brawler, la racha de victorias actual y máxima, y el aspecto equipado.
• La tabla de nombres de rango de Competitivo se aprende de los perfiles observados en vez de estar codificada, así que un cambio de nombre de Supercell no deja etiquetas obsoletas.
• Los aspectos equipados se registran por jugador y por brawler, que es lo que cuenta el ranking de uso de aspectos.
• Las columnas nuevas se aplican a instalaciones existentes mediante un paso ALTER explícito, así que actualizar no obliga a descartar la base de datos.
• El anuncio que decía que la puntuación de Competitivo era una estimación fue sustituido por «Competitivo, prestigio y fama ahora se leen de la API»; las instalaciones sembradas antes de esa corrección se actualizan en el sitio.

La lista de brawlers incluida dejó de mantenerse a mano. Un script de sincronización descarga el plantel en vivo y escribe un archivo generado que la aplicación importa.

• npm run sync obtiene el plantel de la API oficial y regenera el archivo de datos incluido.
• Cada brawler lleva sus habilidades estelares, gadgets, hipercargas y equipamientos reales, con ids y nombres reales.
• La rareza y la clase son los únicos campos que la API omite; se buscan por nombre en una tabla aparte y se dejan como desconocidos en lugar de adivinarse.
• Los brawlers más nuevos que esa tabla se muestran en gris neutro y quedan fuera de los totales por rareza, y un script de comprobación lista lo que falta por clasificar.
• El arte de brawlers, iconos de perfil, insignias de club y mapas se sirve desde la CDN abierta de Brawlify, con una ficha de iniciales cuando falta un recurso.

El sitio pasó de leer datos de demostración a sondear la API oficial continuamente y mantener su propio índice de lo que ha visto.

• Un único módulo de API envuelve los endpoints oficiales; las páginas solo hablan con una capa de servicio que informa de si un valor vino de la API, de la caché local o del generador de demostración.
• Los perfiles de jugador y club se guardan brevemente en SQLite y se sirven desde allí ante un fallo de la API, así que un límite de peticiones no deja una página en blanco.
• Una cola de actualización con prioridades sondea con frecuencia las cuentas marcadas y vistas recientemente y el resto despacio, con un token bucket compartido que mantiene todo el proceso dentro del límite de la API.
• Los registros de batalla se archivan en cada captura, porque la API solo devuelve las últimas 25 partidas, y se agregan en los acumulados diarios que leen las tier lists.
• En el primer arranque con token se recorren las clasificaciones oficiales de ocho países para que la búsqueda por nombre tenga corpus de inmediato.
• La sincronización en segundo plano corre dentro del proceso en un servidor persistente, o desde un planificador externo a través del endpoint cron en plataformas que no pueden mantener un intervalo.
• Actualización manual con enfriamiento por etiqueta, y un endpoint de salud que informa del tamaño del índice, la profundidad de la cola y el último error de la API, con una pista explícita para el fallo del token ligado a la IP.
• Los datos de demostración sembrados antes de configurar un token se purgan por completo en cuanto aparece un token real.

La forma del sitio: enrutado, traducciones, el vocabulario de componentes y la base de datos local.

• Páginas del App Router con prefijo de idioma en chino tradicional, chino simplificado, inglés y japonés, negociado en el middleware a partir de una cookie y luego de Accept-Language.
• Un pequeño conjunto de primitivas de UI compartidas y cinco tipos de gráficos SVG escritos a mano: sin biblioteca de componentes ni de gráficos.
• Temas oscuro y claro dirigidos por completo por variables CSS, con la elección recordada en el navegador y aplicada antes del primer renderizado.
• Páginas de jugador y club, búsqueda por etiqueta y nombre, tier lists, clasificaciones, las calculadoras y la rotación de mapas.
• SQLite mediante el binding integrado en Node, con cuentas, marcadores, historial de visitas y el directorio de jugadores y clubes.
• Cuentas sin dirección de correo: un nombre de usuario, una contraseña con hash scrypt y una cookie de sesión.
• Un modo de demostración determinista para poder explorar todo el sitio antes de que exista un token de la API.