15 publicações com a etiqueta "performance"

Perfil único de resolução para a arte de jogo​

• Janela desta entrada — cobre 03/08 a 09/08 (25 commits em main-7k). É a entrada mais recente do changelog; 10/08 ainda estava em curso quando ela foi escrita, e os dois commits daquele dia que fecham a poda de environments estão anotados no fim, em ## Infra / CI/CD.
• O Cloudflare Images codifica o transform no PATH, então cada combinação de largura, altura e recorte é um RECURSO distinto (PR #1876) — 1b6b8e904 parte dessa constatação: cache-key de browser própria, entrada de cache CF própria e download próprio pra cada variação. O app tinha 12 superfícies pintando game.image com 4 recortes e 10 ladders diferentes, nenhuma compartilhando nada. Medido no 7k mobile (iPhone 14 Pro Max, DPR 3, 3G): o card do carrossel pedia width=240,height=300 (10,0 KB) e a página de jogo pedia width=320,height=400 (13,5 KB) — 23,5 KB pra mostrar a MESMA arte duas vezes, com o segundo request entrando frio no 3G do usuário e a arte piscando ao abrir o jogo.
• Pior: os degraus grandes eram upscale. O master da arte de jogo no CF é 300x350 (amostrado sobre 12 assets reais da biblioteca), então 320, 447 e 480 inventavam pixel — width=480,height=600 devolvia 21,5 KB de nada, o dobro do degrau que a listagem já tinha em cache. O teto útil é ~300px de largura.
• O que passa a valer — ~/utils/game-artwork centraliza ladder e fallback num perfil único e cada superfície declara só o seu sizes, que é o slot de layout real. Não há mais recorte no servidor: o enquadramento vai pro CSS (object-cover numa caixa de aspect fixa), então card 4/5, poster 59/79 e thumb de proporção natural passam a compartilhar o MESMO arquivo. O ladder default vai de [144,216,288] pra [128,192,288] — o degrau do meio serve DPR 1 e precisa ficar logo acima do maior slot (186px, a thumb do preview da página de jogo) sem nenhum degrau entre ele e o menor slot de card de desktop (140px); com 216 o card pegava um degrau e o hero era empurrado pro seguinte, baixando a mesma arte duas vezes no desktop. As 5 brands size: "compact" passam a [128,192,240], cortando ~25% dos bytes e da memória de bitmap decodado. Fundos borrados e reflexos reusam as props EXATAS da thumb em vez de baixar uma segunda variante recortada só pra ficar sob um blur().
• Guarda-chuva contra regressão — 11 testes de perfil mais uma auditoria de TODAS as brands (56 casos) que falha se alguém reintroduzir um degrau entre o card e o hero, inclusive em brand nova. THUMB_ASPECT_VALUE foi removido porque existia só pra alimentar o recorte no servidor e mantê-lo era convite pra refragmentar.
• A convergência que faltava (PR #1877) — a97d91545: o perfil único convergia em DPR maior ou igual a 2 (todo celular real) e em DPR 1 no desktop, mas não em DPR 1 com viewport estreito, onde os slots divergem de verdade (o card declara 115px e a thumb do preview ~152px, com o degrau 128 exatamente no meio). O fix faz as superfícies da página de jogo declararem o slot do CARD no mobile: GAME_PREVIEW_ARTWORK_SIZES passa a espelhar os breakpoints do card e o GamePageHero da donald vai de 131px pra 128px. É uma sub-declaração deliberada de ~19% — em DPR 1 estreito a arte vem 128px numa caixa de ~152px, imperceptível.

BREAKING: cassino-bet-br e vera-bet-br saem do front-web-base​

• Janela desta entrada — cobre 27/07 a 02/08 (60 commits em main-7k). Duas mudanças breaking e duas features apagadas por completo: é a semana mais consequente do trimestre pra quem consome o template.
• As duas brands foram removidas do base e vivem hoje no fork front-web-external (PR #1835) — 84057c160 (refactor(brands)!) apaga overrides/cassino-bet-br e overrides/vera-bet-br inteiros. O diretório de overrides do base vai de 15 para 13 brands rastreadas: 7k-bet-br, betpontobet-bet-br, casateste-com, cl-bet7k-com, donald-bet-br, fi-7k-bet, ng-7k-bet, pb-bet, ph-state77-com, pt-state77-com, rj-bet, state77-com, x2b-bet. O commit toca 439 arquivos e remove ~28,4 mil linhas.
• Para onde elas foram — ops bd6d1ee cria config/brands/web-external/brand.yml apontando pro repositório cactus-agents/front-web-external e MOVE 5 environments de web-base pra web-external: cassino-bet-br, vera-bet-br (com default_branch de main-external pra main), stage-cassino, stage-vera e sports-vera. O placeholder config/brands/vera-bet-br é removido — um fork atende as duas. Ops e01a693 já havia apontado os envs pra main-external em 18/07, e ops 3b555c3 ajusta o required_team de deploy protection dos dois. No base, 2d47d394d limpa o dropdown de workflow_dispatch.
• O que morreu junto, por não ter mais consumidor — o commit é a melhor documentação do próprio efeito colateral: saem ~40 variantes órfãs de layout e widget (header-split-bar, header-vera, sidebar-sectioned-titled, sidebar-wide, header-secondary-flat, as bottom-navs illustrated-tabs/grid-tiles/betano/fab-center, TopGameCardLegacyGrid/CompactWatermark/Outline, SectionTitleNeon/Vera/Panel, CtaButtonVera, BiggestWinsListWidget com HomeWinsRightColumn, RecommendedGamesCarousel, ProfileCompactHero/CenteredSpotlight, FooterBadges) e features exclusivas das duas (ReferralIndicatorV2 com suas rotas de API, todo o Incognia, useAutoLogoutEndpoint com a rota /logout-auto, gamificationRelevanceSort, homeRightPane, usePaginatedGames, useRemarketingId). Mantidos de propósito por decisão de produto: ftd*, profiles, social auth, os módulos VIP, sports-rogue e RecommendedGamesBento (default do base).
• Consequência prática pra leitores do changelog — todas as entradas anteriores que tratam cassino-bet-br e vera-bet-br como brands do base descrevem um estado que não existe mais aqui. Mudanças nessas duas brands a partir de 28/07 acontecem no front-web-external, cujo histórico não é visível deste workspace.

Refino de UX da família 7k — ondas 4 a 7 e paridade cl/ng/fi​

• Janela desta entrada — cobre 13/07 a 19/07 (151 commits em main-7k, a branch de entrega viva do front-web-base; a main está parada desde 25/06 e não representa o que está em produção). Entradas semanais, não diárias.
• Ondas 4, 5 e 7 fecham a série de refino visual do 7k-bet-br — 2de6e2187 (onda 4: modais de depósito, PIX compacto, "já paguei", valores sugeridos), 927f6b2e6 (onda 5: sidebar/nav, gamificação, home cassino, busca mobile) e 352b5beeb (onda 7: corrige hydration mismatch dos links de share, que piscava no F5). As ondas 1 a 3 caíram na semana anterior.
• Paridade da família imediatamente depois — 32245acd0 replica as ondas 1 a 4 em cl-bet7k-com, ng-7k-bet e fi-7k-bet; fd3e7ad1c replica a onda 5 (sidebar/nav). O padrão do trimestre: o 7k-bet-br é a brand de referência e as três irmãs recebem o mesmo pacote em commit separado.
• Barra mobile redesenhada com FAB central da marca (PR #1597) — b5a8d4f99 cria a variante mobile-nav-fab-logo: o item "Menu" vira um FAB circular com a logo da brand e o menu mobile passa a subir como bottom sheet em vez de drawer lateral, degradando pra tiles planos quando o special fab-center está ausente. af7e9bd23 (PR #1594) reordena os tiles pra Menu · Cassino · Buscar · Torneios · Esportes, com a busca no centro pelo alcance do polegar.
• Tom global dos textos escurecido um ponto — e45e597c4 troca #e6e6e6 por #e0e0e0 nos theme/colors.ts das 4 brands da família, cobrindo texts, links, titles e todos os sub-tokens; 4fb6b3eb5 já havia escurecido o fundo dos títulos de seção.

Semana de 06/07 a 12/07, na branch main-7k do front-web-base. É a semana em que o programa de performance/streaming da plataforma sai do papel: 93 commits filtrados, a maioria concentrada num único eixo.

Semana 06–12/07 — streaming SSR e clientLoader em toda a aplicação​

• App-shell streaming SSR, começando pela home (90d1dcfb4): o entry.server passa a transmitir o stream no shell-ready via TransformStream — head processado no primeiro flush (tailwind inline, strip de modulepreload com keep-list derivada do manifest, strip de preloads de imagem não-LCP) e body em passthrough com tail-carry. Antes o stream era bufferizado até o fim pra rodar regex no HTML completo, ou seja, o primeiro byte esperava todo o conteúdo. Junto vem o piloto de deferred data na home: catalog, gameStatsCache, topWins e lastWins saem do caminho crítico e streamam via Suspense/<Await> no documento SSR e via turbo-stream nas navegações .data, com SectionSkeleton no lugar. Continuam awaited homeRows, brand, auth e a page description (meta/SEO/LCP). Cada perna deferida ganhou .catch(() => vazio), então rejeição degrada pra row vazia em vez de 500 na home inteira. streamTimeout de 10s com abort combinado.
• Estendido pra game page, hubs e navegação (85a108c2d): o loader da página de jogo cai de 3 gates sequenciais pra 2 awaits (game e brand, o mínimo pro meta/SEO), deferindo stats, winners, related, providers, voteState e as seções showcase. O getStatsRaw, um endpoint do BFF não cacheado que só alimentava o DevPanel, foi movido pro gate de dev — produção deixa de pagar por ele. Nos hubs de cassino e ao-vivo, gameStatsCache e os wins passam a deferidos no caminho de rows. E em _layout.shouldRevalidate, troca de pathname deixa de revalidar o layout, o que remove a chamada de auth por usuário — transatlântica — do caminho crítico de toda navegação SPA logada; login e logout seguem revalidando via revalidate() explícito. Skeletons CLS-zero novos: WinsCombinedSkeleton (o fallback anterior causava ~137px de shift no desktop), WinsMarqueeRowSkeleton, PaidTodaySkeleton, ListWinsSkeleton e GameRowSkeleton derivado do gameCardConfig, com widths corretos por breakpoint e por brand.
• clientLoader deixa a navegação game → game instantânea (1812d8b07): a navegação SPA pra /cassino/jogar/:provider/:game esperava o .data inicial, que aguarda o getDetail (round-trip de 0,5-1,5s em cache miss), travando a troca de rota inteira. O clientLoader devolve o loaderData na hora — serverLoader() disparado sem await, cada campo encadeado como promise — então a URL troca instantaneamente e o conteúdo preenche por streaming. game, frontDescription, seo e faqEntry foram combinados num único boundary de AwaitValue cujo fallback reserva a geometria exata do conteúdo real, e slug/showcase ficam síncronos porque são deriváveis de params/featuresConfig sem round-trip. 5c24a1354 acrescenta o skeleton pixel-perfect e o seed otimista do card clicado.
• Padrão propagado pro resto das rotas — b3e8c151d (hubs cassino e ao-vivo), bb0b2c012 (categorias e provedores), f241a9145 (home, incluindo seed otimista a partir do homeRows já cacheado na store e o bundle de favoritos/recentes virando um único favoritesBundle streamado), 761088aa6 (VIP e gamificação) e e6fe562f1 (conteúdo WP, legal e busca, com legalTerms deferido). cc237adfc centraliza o preview de dev-skeleton num módulo único e removível; 49ef0d808 e d8401122b corrigem imports .server que vazaram pro caminho client.
• Dois defeitos reais achados e corrigidos no próprio programa. 885f0e92c: o encoder de single-fetch do React Router corre toda promise deferida contra o streamTimeout, e perna pendente virava frame E:["Unexpected Server Error"] dentro de um body 200, por fora do .catch do loader; pior, errorElement={null} é falsy, então o <Await> re-lançava pro ErrorBoundary da rota em vez de suprimir (a tela renderizava e depois virava erro); e o worker cacheava o .data 200 com o frame de erro embutido por 60s, servindo o mesmo erro em HITs subsequentes. Fix: errorElement truthy (fragment vazio) em AwaitValue/AwaitWins e na home. afc20a73d, resultado de revisão adversarial: o buildSpaShell bufferizava o stream inteiro pro usuário logado (TTFB = render completo, ~11s no pior caso) e devolvia um shell morto; Set-Cookie de tracking bloqueava o cache compartilhado pra todo visitante anônimo frio; o cache autenticado não tinha guard contra payload envenenado ou documento truncado; e a home resuspendia pra skeleton genérico em todo login/logout. O buildSpaShell foi removido e o autenticado em rota pública passa a receber a mesma stream real do anônimo.
• Navegação e stats estáveis na página de jogo (dfad863b1): getStats e getVoteCount ganham timeout fail-fast de 1200ms, com a promise original registrada no waitUntil — assim o warming completa em background mesmo em cold-miss, o que o timeout sozinho mataria. As duas ondas sequenciais de Promise.all do loader foram fundidas, removendo um round-trip serial.

Semana de 29/06 a 05/07, na branch main-7k do front-web-base. Semana mais leve em volume (47 commits filtrados), mas com duas decisões estruturais de tracking.

Semana 29/06–05/07 — anaLayer: uma segunda camada de tagueamento GA4, paralela à existente​

• Fundação da camada (1fceb0672): implementa o tagueamento GA4 do guia Ana Gaming num container GTM secundário próprio, com dataLayer isolado chamado anaLayer, rodando em paralelo e independente da stack de analytics atual (dataLayer/registry + Meta, Kwai e os demais). A config é brand-gated com default null, então a invariante é que nenhuma brand dispara sem container declarado. Inclui registry tipado dos 32 eventos, helper pushAnaLayerEvent, campos padrão (user_id, user_id_hash como SHA-256 do CPF, platform, profile_type, event_timestamp), event_id determinístico, AnaLayerProvider/useAnaLayer e um AnaLayerInitializer espelhando o Consent Mode v2 do initGTM. 21 testes.
• Wiring de 22 eventos no mesmo commit — page_view, login, sign_up, modal_viewed, begin_checkout, add_payment_info, deposit_pix_generated/copied, purchase, deposit_pix_expired, withdrawal_started/requested, kyc_started/completed, form_error, view_item_list, select_item, view_promotion/select_promotion, select_content e search — disparados em paralelo aos eventos legados, lendo IDs reais das APIs. Bloqueados de propósito, com scaffold e TODO: game_opened e game_session_ended (aguardando game_session_id no StartGameResponse do core), além de refund, o ciclo de saque pós-requested, aprovação/rejeição de KYC e cashback, que são observados no backend e ficam registry-only. Nada é disparado com dado sintético.
• Alvo trocado de 7k pra vera e depois configurado por brand — fba166367 reaponta a camada pra vera em vez do 7k; b621f558e faz o useAnaLayer degradar pra no-op fora do provider; e 4bf4ebabd adiciona a flag enabled à AnaLayerConfig, criando o estado "configurado mas desabilitado": o gate passa a exigir enabled === true e containerId. Resultado no fim da semana: vera-bet-br é a única com enabled: true; 7k-bet-br e cassino-bet-br ficam com container declarado e enabled: false. Os IDs de container vivem só nos overrides de cada brand.

Semana de 22/06 a 28/06, na branch main-7k do front-web-base.

Semana 22–28/06 — Consent Mode v2: default invertido pra granted e consent cosmético como padrão​

• O baseline de boot do Google Consent Mode v2 foi invertido pra granted (16bf59fee). Isto reverte o comportamento descrito no changelog de 23/04/2026. A política antiga emitia gtag('consent','default', { ...tudo denied, wait_for_update: 500 }) e só depois, se houvesse cookie salvo, aplicava um update. A nova emite gtag('consent','default', { ...tudo granted }) sempre, sem wait_for_update. O único caminho que ainda rebaixa sinais é cookieConsentCosmeticOnly === false e cookie salvo indicando rejeição total, caso em que o initGTM dispara um update imediato pra denied. Matriz implementada: cosmético true → granted (qualquer cookie ignorado); cosmético false sem cookie ou com aceite → granted; cosmético false com rejeição total → default granted + update imediato pra denied. Arquivos: app/utils/metrics/consent.ts (injectConsentDefaults com opts.applyDenied) e app/utils/metrics/gtm.ts (decide applyDenied = !cosmetic && userRejectedAll), com 4 casos de teste. A justificativa registrada no commit é paridade com o app Nuxt legado, que nunca gateava tracking, e a eliminação da janela cega de 500ms do wait_for_update, apontada como causa suspeita da queda de performance em Google Ads e Meta Ads após a migração.
• cookieConsentCosmeticOnly passa a ter default true no base (be0518d91). Antes o default global era false, então brand que não declarasse a flag honrava a rejeição do usuário. As 7 brands que já declaravam true seguem idênticas; as 8 que herdavam false (casateste-com, donald-bet-br, pb-bet, ph-state77-com, pt-state77-com, rj-bet, state77-com, x2b-bet) passaram a declarar false explicitamente no próprio override — comportamento preservado bit a bit, com o ganho de que cada override é agora a fonte autoritativa da política de consent daquela brand, sem depender do default do base.
• Nota de revisão pendente: as duas mudanças acima descrevem o que o código faz hoje. A política resultante — consent concedido por padrão, tratamento cosmético como default e ausência de botão de rejeição total no banner — ainda depende de confirmação do responsável por LGPD antes de ser publicada como política oficial. Registrado aqui como fato técnico, não como posição de conformidade.
• Eco do gtag duplicando eventos do dataLayer corrigido em ea9b09a68.

Semana de 15/06 a 21/06. Daqui pra frente o changelog é semanal (arquivos YYYY-MM-DD-weekly.md, datados no último dia coberto). A fonte de verdade do front-web-base é a branch main-7k — a main está defasada e não reflete o que foi pra produção.

Semana 15–21/06 — cache overhaul: CACHE_GENERATION como token único de rotação​

• front-ops/config/cache/generation.yml vira a fonte operacional de verdade (ops f00c642): o arquivo carrega current: apcsrasj-v3, é lido no deploy e injetado como --var CACHE_GENERATION no wrangler deploy. Bumpar pelo workflow novo bump-cache-generation flipa de uma vez a namespace do Cache API do platform-cache, o cacheKeyPrefix do api-client e o GLOBAL_VERSION do front-service-api; sem o arquivo, o deploy cai no default in-source (fail-open). É separado do BUILD_ID, que já rotaciona a cada deploy — o CACHE_GENERATION é o "nuke from orbit" que o padrão legado de pasta-nova-por-deploy fornecia. cache-status.yml complementa como leitura read-only.
• Base conectado à máquina nova (b445a6b5a): binding declarado no worker-configuration.d.ts; app/services/platform-cache.server.ts mantém um storesByGeneration chaveado pelo token, então o cache de isolate rotaciona atomicamente; app/services/api.server.ts deriva cacheKeyPrefix como api-cache-<gen> e liga delegateCaching: true nas rotas já cacheadas na camada platform-cache, eliminando o drift de TTL duplo que causou o postmortem de /payment-providers em 05/2026. app/routes/api/cache/purge.ts passa a delegar ao createPurgeHandler do core (mesmo contrato de tag/glob/scope/dry_run, com extractApiError no lugar de [object Object]) e nasce app/routes/api/cache/inspect.ts, endpoint GET que lista recursos, tags e namespace corrente e, com ?include=state, sonda o Cache API.
• TTLs apertados e falhas de fallback visíveis (239651ff4): KV_SSR_TTL cai de 12h pra 1h (o valor antigo era resquício da premissa "rebuild a cada 12h"), entra MAX_API_CACHE_TTL = 3600 com clamp em getApiCacheRule, e erros de fallback de asset em KV e R2 passam a ser logados — antes eram engolidos em silêncio, deixando problema de permissão ou bucket invisível no Logpush. public/_headers reduz /icons/* de 1 ano pra 30 dias.
• Defaults e purge seletivo no front-ops (b36e445): brandConfig sai de 3600s e homeRows de 7200s, ambos pra 60s + SWR 300s, então mudança de backoffice reflete em menos de 60s; toda resource ganha tags pra o purge mirar fatias em vez de derrubar tudo; staleIfErrorSeconds capado em 6h. manual-cache-purge.yml sobe pra v3 com tags (CSV), glob, scope e dry_run. 8645ac2 cria config/cache/service-api-defaults.yml com 19 regras consumidas no deploy do service-api — base e service-api passam a compartilhar a mesma taxonomia de tags.
• skip_post_deploy_purge por environment (ops 2d83a4c, aplicado em 0d4437e e 64f130f): workers atrás de Cloudflare Access devolvem 404 no purge pós-deploy porque o curl segue o redirect de login sem service token. Até os service tokens entrarem no workflow, o environment pode sair do purge por segmento — a rotação do CACHE_GENERATION já torna as entradas anteriores inalcançáveis — e um step de notice registra o skip no run summary.
• front-service-api com política externalizada (f80791d): DEFAULT_GLOBAL_VERSION = apcsrasj-v3, getGlobalVersion(env) lendo CACHE_GENERATION → BUILD_KEY → default, política vinda de env.SERVICE_API_CACHE_POLICY_JSON (era hardcoded) e /v2/cache/purge com o mesmo contrato do base. scripts/build-cache-policy.mjs resolve o YAML por --file, FRONT_OPS_PATH ou irmão ../front-ops. 27 testes novos, com 8d9fe4f documentando o fluxo no README.

Semana 18–24/05 — Álbum v2 portado e endurecido​

• Substituição integral do módulo pela v2 — a079bcfab troca app/components/album/** pela versão v2 do drop-in: subdiretório share/ novo (15 arquivos) com pipeline de compartilhamento social por figurinha, URL canônica, card de OG safe pra Satori e helpers de UTM; três componentes novos (CheckinSuccessModal, MissionTypeChoiceModal, PackSummaryPhase); StickerCard e StickerRevealStack extraídos como reusáveis; check-in consolidado em CheckInState com dois tipos de claim (diário e de conclusão); e a novidade estrutural — trilhas duplas (casinoMissions / sportbookMissions mais missionType, um gate bloqueante de escolha no primeiro acesso). O hook público passa a ser useAlbumProgress; useProgressSync, CheckInTier e AlbumBootstrap.checkInDays saem do contrato.
• Handshake de auth próprio, server-side — 7644499ec. O BFF do álbum exige fluxo de auth distinto do JWT do cookie HttpOnly do host: POST {STICKER_API_URL}/auth/token com { encryptedUserId, brandId, campaign } devolvendo { accessToken, tokenType, expiresAtUtc }, e Authorization: Bearer em todas as demais chamadas. A versão anterior passava o JWT do cookie direto, o que não funcionava contra o BFF real. loadAlbumBootstrap agora faz o handshake antes do Promise.all de endpoints e retorna null quando ele falha — feature degradada em silêncio em vez de rota quebrada. 459b1b0d5 adiciona cache de token cross-request e fd8690a9b projeta o apiCampaign no servidor antes de mandar pro client.
• Auditoria de porte com 53 achados — 3a2a0eab6 compara a v2 portada contra o harness do sticker-book, o Swagger oficial do BFF e os contratos consumidos pelo módulo: 19 críticos, 31 médios, 3 baixos. Os commits seguintes endereçam os 19 críticos — entre eles ff17d4230 (sincronizar state.checkIn a partir de data.checkIn após refetch), d78a718a9 (blindar loadAlbumPageData contra throws inesperados), def9b3f41 (gatear o polling de 60s em document.visibilityState), 9066c2284 (alinhar os handlers de rota ao Swagger) e 819b5dd03 (adapters de mutação, retry de 401, tipos de API compartilhados).
• Kill-switch por marca e gating de acesso — 93b3d1312 cria albumConfig.enabled fail-closed: o código fica disponível pra todas as marcas mas só executa pra quem declara enabled: true explicitamente, com guard no loader de /vip/album que redireciona pra home antes de qualquer chamada ao BFF. Só o 7k liga. 72bf89007 adiciona modo preview, splash, gating de feature flag, entrada de sidebar e endurecimento de cache; b7157c1e6 esconde a entrada pra usuário deslogado; a13218eae faz o deslogado fechar pelo X e pelo backdrop em vez de abrir login.
• Missões vindas do Smartico e do BFF, mescladas por id — dc868194f passa a carregar "Suas Missões" da seção ALBUM_FIGURINHAS do Smartico, 07672c7ae cai em todas as missões quando a seção não existe, 0d0fed93e mescla Smartico e BFF por id e 8dca06afd remove /users/me/missions (deprecado — o Smartico é autoritativo).
• Renderização de flip-book e polimento visual — b64d23165 (capa centralizada, tag de faixa de páginas, backgroundImageUrl), 7b84ca712 (continuidade do flip: fatia da lombada, imagem de curl, lombada antecipando o BACK), 746803a4c (tap-to-flip nas bordas), bac022447 (thresholds assimétricos de commit FORWARD/BACK), 253ed4f2e (watermark central nos cards travados), b0a8d3c51 / bc9f28802 (dimensões, centralização e escalas proporcionais no mobile). d392f4072 fecha a semana com a LP de compartilhamento, download de composição e preview anônimo. Testes em c26c5af85, ad332e995 e 9340a8888 cobrem handshake, orquestração, os seis endpoints /api/album/* e os gates de degradação do loader.
• Chaves album.* de i18n foram adicionadas como overrides do host em vez de irem pro core (e251c0d09), e 8d78a79d7 troca nomes de placeholder por versões neutras na config base.

Analytics — Mixpanel Deposit + AppsFlyer S2S​

• Novo evento Mixpanel Deposit Requested (useAnalytics.trackDepositRequested) disparado quando /wallet/add-credit retorna 200 OK. Espelha o legado DefaultLayout.vue das brands 7k/cassino/vera (props Amount em unidades inteiras + DepositMethod). Continua complementar ao evento de funil já existente (pix_generated no GTM e PixGenerated no Facebook).
• Bugfix crítico nos eventos S2S do AppsFlyer (sendRegister, sendFTD, sendRebill). Os três estavam dentro do guard if (!shouldLoadTrackers) return do useAnalytics, mas o gate é o inverso do gate do AppsFlyer (shouldLoadTrackers = !isAppMode && !isBot, useAppsFlyer.ready = enabled && isAppMode) — resultado: nenhuma das chamadas server-to-server disparava nem na web (gate externo bloqueia) nem dentro do APK (early return do gate externo cortava o caminho). Agora as três chamadas são disparadas antes do guard e o S2S funciona em produção. Coberto por useAppsFlyer.test.ts (202 linhas) e useAppMode.test.ts (72 linhas).
• useAppMode agora reconhece ?is_twa=true além de ?app=true. Os APKs em produção da família 7k/cassino/vera (publicados antes do rename do query param) continuam injetando o legado em cada landing — sem isso isAppMode ficava false pra users do app e desativava todo o pipeline de tracking S2S silenciosamente.
• Valor do deposit GTM corrigido pra unidades inteiras (amountCents / 100) ao invés de cents puros — paridade com o legado e com a expectativa dos dashboards de BI.

Dia pesado: 25 PRs no front-web-base cobrindo um empurrão grande de performance (CSS, ícones, modal), refatoração do header secundário com gating de rota, novas features de cassino e pagamentos, e ajustes finos de SEO/mobile/auth. Plus 4 mudanças de CI/CD em front-ops pra suportar o novo modelo de cache por device/country/buildId.

Performance — empurrão grande​

• Drop important: true do Tailwind (tailwind.config.js). Removido globalmente — precedência CSS volta ao normal (inline style vence class). Resultado: CSS −23,5KB raw (−14,4%). Componentes que usavam o pattern condicional bgStyle ? "" : "bg-..." (omitir classe quando havia inline style) foram simplificados — agora basta sempre emitir a classe que o style inline sobrescreve quando presente. Atualizados: GameCardStacked, GameStats, GameWinners, MainLeaguesSquare, SidebarButtonsGradient, SidebarButtonsGrid.
• Migração react-modal-sheet → vaul (app/components/base/Modal.tsx). Modal chunk caiu de ~158KB pra ~65KB raw — −93KB (−59%). Mesma API externa, drop-in pelos consumers. (PR #405 fez ajustes finos depois pra resolver bugs de input-focus em mobile e espaço fantasma no footer.)
• Remoção do @tailwindcss/typography. Plugin não justificava o custo — uso restrito a 4 lugares (FaqSingleContent, WpPostContent, page.$slug, vip/levels) substituído por classes utilitárias inline. package.json enxuga uma dep + 22 linhas de pnpm-lock.yaml.
• Ícones direct-imports + lazy MainLeagues (app/widgets/home-leagues/). Drop do registry intermediário — agora cada componente faz import Icon from "~icons/<set>/<name>" direto. MainLeaguesSquare virou lazy chunk separado. 25 arquivos tocados, −564 linhas vs +454. Atualiza configs de home-leagues em 7 brands (7k-bet-br, cassino-bet-br, fi-7k-bet, ng-7k-bet, pb-bet, vera-bet-br, state77-com, x2b-bet).
• CI Lighthouse manual (.github/workflows/lighthouse.yml). Workflow caller dispatchável via workflow_dispatch pra rodar Lighthouse on-demand contra preview/prod sem precisar de schedule fixo. Útil pra validar PRs pesados de UI antes de mergear.