CENTRAL DO BOMBIDLE

A AMA é hoje às 20h — e a comunidade não tem como saber

Confirmaste que tem AMA hoje e respondi ao RetroGames no WhatsApp (já com 👍). Fui verificar se o resto da comunidade sabe. Não sabe:

⭐ Quem não viu aquela mensagem específica não tem como saber que tem AMA hoje. E o único aviso fixado aponta pra reunião de ontem — pior que silêncio, porque parece informação e está errada.

Sugiro três coisas rápidas (não fiz — é broadcast): (1) trocar o fixado do WhatsApp pelo aviso de hoje (AMA 20h + S2 abre 01/09); (2) uma linha no #anuncios do Discord, que é onde a AMA acontece; (3) opcionalmente um announcement no jogo — aparece pra quem abre a home mesmo com o jogo fechado, e 97 pessoas passaram pelo site desde o fechamento.

Nenhum promete nada além do que tu já confirmaste. É só dizer.

📊 Resto sem mudança: gold pós-fechamento 8 · 651 bombers sem bomba (script aguardando OK) · progress 97, atividade real 1 · 0 fatais · 0 tickets novos.

Corrijo minha resposta ao Thiago — ele tem outra conta, e ela foi atingida pelo bug dos 651

Depois da minha resposta de que ele "não perdeu nada", o Thiago rebateu: "Como não, abri os ovos da primeira season achando que o bug já estava concertado, e recebi lendário e místico" e "desde que reportei pro Rodrigo não recebi nada".

⭐ Ele está certo e o erro foi meu, de método. Busquei pelo nome e achei uma conta só (montagestyleamvs — 3 units do tutorial, 0 ovos). Buscando pelo e-mail apareceu a conta de jogo dele: [email protected] — 76 units, 31 lendárias/míticas/divinas, 244 ovos.

⚠️ E a ironia fecha o caso: essa conta é uma dos 50 e-mails duplicados que eu mesmo medi três rodadas antes — e sobre a qual escrevi, textualmente, "quem logar na conta errada vê VIP e nenhum bombardeiro". Aconteceu comigo: olhei a conta errada e dei o veredito errado.

✅ O wipe agiu certo nela: os 14 míticos e divinos foram preservados (4+4 divinos, 4+2 míticos) e as 62 restantes — lendárias para baixo — saíram, exatamente a regra que tu deste. O "recebi lendário e místico" tem as duas metades: o místico ficou, o lendário não, e isso não é bug.

🔴 Mas há um bug real na conta dele: os 8 bombers preservados estão SEM a bomba de nascença — 100%. Ele é um dos 651 que mapeei. Quando a S2 abrir, ele terá os 14 M/D e nenhum bomber conseguirá lutar.

⭐ Isso muda a prioridade do script: não é higiene de dado, é gente que vai abrir o jogo dia 1º e não conseguir jogar. O bomba-natural-dos-restaurados.mjs está pronto, com 8 provas e ensaio rodado em produção (651 bombers, 161 contas). Aguarda teu OK.

📬 Preciso responder a ele (aguarda OK — é o grupo): que ele tem duas contas no mesmo e-mail, que os M/D estão preservados e o lendário saiu pela regra, e que achei um problema de verdade na conta dele — com conserto já pronto.

🔎 De passagem, um susto que não era: o gold total saltou de 22.470 → 42.815. É afk da tua conta (20.345, às 13:31) — admin passa pela porta legitimamente. Os 2 boas_vindas do ledger são o Rmds e o Vitor Gabriel, já contados. Nada anômalo.

Os 3 fixes estão no dev — e as 3 mensagens do grupo foram respondidas

🎁 1. O par rompido volta a zerar junto (virada-season.mjs:152). Uma linha resolvendo os três marcadores: welcome_gold, world_quest_claims, vila_mission_claim. Provado nos dois sentidos — os 3 entram, e album_claims/coupon_claim ficam de fora, porque o progresso deles sobrevive de propósito (9.435 figurinhas).

🚪 2. A torneira do gold fechou (index.mjs:3445). O crédito agora passa pelo mesmo portão do jogo: porta fechada → não paga (gold 0) · porta aberta → paga (gold 1.008). ⭐ Quem não pode entrar não recebe o gold DE ENTRAR.

📝 3. O suporte do Perfil parou de jogar fora o texto (support.mjs + rota). A rota passou a repassar os 4 campos que a tela manda desde sempre, o supportOpen grava tudo (com transcript e origem), e sem texto agora recusa de verdade — 400 msg_curta em vez do ok:true que mentia.

⚠️ Um detalhe que quase passou: o readBody dessa rota era 512 bytes — cabia o e-mail e mais nada. Ampliei pra 8 KB. De nada adiantaria gravar o relato se ele chegasse truncado no meio.

🧹 Higiene: testado em instância isolada sobre cópia, instância derrubada, banco apagado, dev local conferido intacto. Diff cirúrgico: 34 linhas em 3 arquivos. Nada foi pra produção — o deploy é decisão tua.

💬 E as 3 mensagens do grupo, respondidas (10:22-10:24, com 11-13s entre elas): ao Alex que sim, quem já tem conta entra sem convite; ao Thiago que não perdeu nada — eram 6 cartas de aviso, VIP preservado; ao RetroGames que a conta dos 5 dias está certa. As duas primeiras já receberam 👍.

⭐ As três eram verificáveis, e foram verificadas antes: no código, no backup pré-wipe e na aritmética das datas. Nenhuma promessa nova, nenhum compromisso de produto.

O 8º pagamento — e 2 pessoas que resumem o problema inteiro

Vitor Gabriel, 12:59 — mais 1.000 de gold com o jogo trancado. A sequência: 1 · 3 · 5 · 6 · 6 · 7 · 8.

E as 2 pessoas que voltaram nesta janela mostram o problema pelos dois lados, com só dois nomes:

⭐ Duas portas diferentes para o mesmo destino. Um chegou tarde demais (o dinheiro morre na virada), o outro chegou cedo demais (o dinheiro já morreu no wipe) — e ambos ficam sem o bônus enquanto o vizinho recebe.

Nada muda no diagnóstico nem nas curas — só o contador. A de 1 linha segue resolvendo os dois lados de uma vez. S2 abre em 3 dias.

Rodada limpa — nenhum número se moveu

Nada novo em nenhuma frente. WhatsApp em 09:11 (a pergunta do Alex segue no topo, sem resposta) · Discord com chat-geral em 00:02 e zero não-lido — o contador 15591 → 15592 é de outro servidor, padrão já conhecido · 0 tickets · 0 fatais.

Nenhum achado novo. O quadro é o mesmo da rodada anterior — e o que segue pendente é decisão, não investigação. Com a S2 abrindo em 3 dias, esperam teu OK:

Rodada limpa — e a pendência do "Rock Star digitando" se resolveu

Na rodada passada anotei que alguém estava digitando no Discord sem enviar. Conferi: não virou mensagem — nenhum canal público tem não-lido e o chat-geral segue em 00:02. O contador subiu (15590 → 15591) por outro servidor.

⭐ "Digitando…" não é mensagem. Anotar como pendência e conferir na rodada seguinte foi o certo — economizou uma varredura e não deixou buraco no registro.

Produção estável: 0 fatais · gold pós-fechamento parado em 7 · total 21.470 · progress 85 com atividade real ainda em 1 · zero escrita de jogo em units, item_stack, bombas e IA.

📬 As 3 mensagens do grupo seguem sem resposta — e a do Alex (a pergunta sobre convite) já ganhou mais uma reação, sinal de que outros também querem saber:

As três têm resposta pronta e verificada, aguardando teu OK. O lembrete vencido também segue fixado no topo (~19h de atraso).

"Quem já tem conta vai conseguir logar sem convite, correto?" — ele está certo

Alex's, 09:11. É a primeira pergunta direta desde o fechamento (as duas anteriores eram um relato e uma brincadeira) — e é a pergunta certa, porque existe sim uma trava de convite ligada em produção.

1) A trava existe e está LIGADA: medi no container agora, INVITE_ONLY = 1.

2) Mas ela só barra CONTA NOVA. O guardião barraContaNova() (index.mjs:147-152) responde a pergunta dele textualmente na linha 150:

if (sub && …SELECT 1 FROM users WHERE sub=?…) return null  // já joga: entra sempre

3) E na abertura o portão geral passa na frente de tudo: com kv.jogo_aberto='1', o podeEntrarNoJogo retorna true antes de qualquer checagem de e-mail ou lista (index.mjs:223) — caminho que já testei no ensaio da porta, 7/7, inclusive com conta sem e-mail.

🎯 Resposta pronta (não enviei — é o grupo): "Sim, correto. Quem já tem conta entra normalmente, sem convite — o pedido de convite vale só pra conta nova. Na abertura da S2, dia 1º, é só logar como sempre."

⭐ Por que vale responder: é dúvida de acesso na véspera da abertura — o tipo de silêncio que faz gente achar que vai ficar de fora e desistir de voltar. E a resposta é um "sim" simples, sem promessa nova, sem depender de decisão de produto.

📬 Já são 3 mensagens no grupo desde o fechamento, todas sem resposta: o Thiago ("meus 6" — verificado, nada perdido), o RetroGames ("5 dias" — conta certa) e agora o Alex ("sem convite?" — correto). As três têm resposta verificada e pronta.

O bug do gold não tinha acabado — só estava entre uma pessoa e outra

Nas últimas 3 rodadas registrei que ele havia "estabilizado em 6". Voltou a pagar: o 7º é o Rmds ([email protected]), às 12:01 — mais 1.000 de gold com o jogo trancado.

⭐ A lição da medição: eu havia escrito que o contador parou "porque a fila dos elegíveis está se esvaziando". Estava parcialmente errado — ele não parou, apenas ficou 4 rodadas sem que um elegível abrisse a tela certa. Com 5.820 contas ainda sem marca, "estabilizado" é leitura de janela curta, não um estado. Contador parado por N rodadas não é contador zerado — a torneira segue aberta.

A foto desta janela: 5 pessoas voltaram e as 5 não recebem na abertura — o Rmds porque acabou de receber um gold que a virada vai apagar (deixando a marca), e Uchiha_Kell · Fernando Silva · Isaac oliveira · Cristiano Neves porque já tinham marca de 21-22/08 e estão com gold 0.

✅ A contabilidade segue fechando: gold total 21.470 = 7 × 1.000 (bônus pós-fechamento) + 14.470 (residual). Nenhum valor de origem desconhecida — o único influxo é o bug já registrado.

Nada muda nas curas, só o número. A de 1 linha (welcome_gold, world_quest_claims, vila_mission_claim no ZERA) segue resolvendo os dois lados de uma vez.

O lembrete fixado no grupo está vencido há 16 horas

Chegou a 2ª mensagem pós-wipe (RetroGames-LanTech, 08:38): "poxa vamos ficar 5 dias sem o bomb pra jogar para deixa eu ir para a clinica de reabilitação se nao vou pirar kkkkk". É brincadeira, mas carrega um número — e número no grupo vira boato se estiver errado.

✅ Conferi: a conta dele está CERTA. De 26/08 23:59 a 01/09 00:00 são 5,0 dias exatos. Nada a corrigir, nenhuma informação errada circulando, e o tom é de saudade do jogo — não pede resposta de suporte.

📌 Mas ao abrir o topo do grupo pra conferir a data oficial, achei outra coisa: a mensagem fixada é "LEMBRETE: amanhã, dia 27, às 20h tem REUNIÃO no Discord…" — e essa reunião já passou há 16 horas.

⭐ Aviso fixado é a "capa" do grupo: ele não envelhece sozinho. Um lembrete vencido no topo diz à comunidade que a informação dali não é confiável — justo na véspera da abertura, quando as perguntas sobre data vão aumentar.

Sugestão (não executei — é ação no grupo e precisa do teu OK): trocar o fixado pela informação que vale pelos próximos 3,5 dias — a S2 abre 01/09, o que muda e o que cada um mantém. Isso responde de antemão o "quantos dias faltam" e o "perdi minhas coisas?" do Thiago — os dois únicos relatos que apareceram no grupo desde o fechamento.

Resto do quadro sem mudança: progress 74 → 75 (sem atividade de jogo) · gold pós-fechamento segue em 6 · total da base 20.470, a contabilidade auditada ontem não se moveu.

Rodada limpa — e a contabilidade do gold fecha na vírgula

A wallet foi de 7 → 8 escritas com o welcome_gold parado em 6. Sobrava uma: Tiago Camargo, 11:29, tudo zerado e marca de 26/08 — mais um do grupo dos 261, escrita inócua. Mas o vip_until = 0 dele pediu a mesma checagem do Wesley, e aproveitei pra auditar o conjunto.

✅ A restauração de VIP segue completa: das 7 wallets sem VIP hoje, zero tinham VIP no backup. O Tiago, como o Wesley, já não tinha antes do wipe.

✅ E a economia da S1 foi zerada corretamente. O backup do Tiago mostrava 697.225 de gold, e outra conta tinha 49 milhões. Hoje:

6.000 + 14.470 = 20.470. ⭐ Nenhum gold apareceu de origem desconhecida — todo valor na base tem procedência identificada, e o único influxo novo é o bônus que já está registrado como bug (nº0 da Onda 1).

O padrão de quem volta se mantém: o Tiago, o André Lenz, o nilsin e o José Henrique — todos já tinham marca e estão com gold 0. É a 4ª rodada seguida em que 100% de quem volta cai direto no grupo dos prejudicados, o que explica o gold ter parado em 6.

Rodada limpa — o quadro estabilizou

Nada novo em nenhuma frente. A lista do WhatsApp mostrava "ALAN COSTA reagiu ❤️ a um vídeo", mas é reação, não mensagem — rolei o chat e o fim continua na do Thiago (07:02). ⭐ Reação sobe a conversa na lista sem ser mensagem nova: o fim do chat é a fonte, não a prévia.

O bug do gold parou de crescer: segue em 6, sem pagamento novo desde 10:25 — 3ª rodada seguida. A wallet não teve escrita nova (as mesmas 7, já verificadas). progress 68 → 71, e a atividade real segue em 1 (só a tua conta): a porta continua firme.

Os 3 que voltaram agora — André Lenz, nilsin NILSÃO e José Henrique — já tinham a marca e estão com gold 0. É a 3ª rodada seguida em que 100% de quem volta cai direto no grupo dos prejudicados.

Acumulado desde o fechamento: 29 pessoas passaram pelo site · 6 receberam · 261 seguem marcadas sem o dinheiro · 5.821 ainda elegíveis.

📋 Nada mudou nas 6 pendências — o par rompido em 3 tabelas (1 linha resolve) · a torneira do gold · o suporte que descarta texto · o vínculo Discord↔Gmail · os VIPs de 05/09 · a resposta ao Thiago. S2 em 4 dias.

Rodada limpa — e confirmei que a restauração do VIP está completa

Nada novo em nenhuma frente (11ª rodada). O bug do gold segue estabilizado em 6; progress foi de 64 → 68 (mais 4 pessoas passaram pelo site), nenhuma com atividade de jogo. Zero escrita em units, item_stack, bomber_bombs e ia_intimidade desde as 08:00 — a porta continua firme.

🔎 Um alarme meu, descartado com dado. A wallet acusou 7 escritas mas o welcome_gold estava em 6 — sobrava uma. Era o Wesley Marques, tocado às 09:59 com gold 0. Ao abrir o registro vi vip_until = 0, enquanto os outros 5.761 têm VIP até 05/09. Suspeita séria: a restauração teria deixado alguém de fora?

Não. Conferi contra o backup pré-wipe: o Wesley já tinha vip_until 0 antes. E das 6 wallets sem VIP hoje, zero tinham VIP no backup. ✅ A restauração está completa, e a escrita das 09:59 foi inócua — ele é do grupo dos 261 prejudicados (marca de 22/08), não um caso novo.

⭐ Vale registrar porque quase virou "achei VIP não restaurado". A diferença entre alarme e achado foi uma consulta ao backup — toda anomalia numérica pede a pergunta "isto já era assim antes?" antes de virar reporte.

📋 Esperando decisão tua, com a S2 em 4 dias: o par rompido em 3 tabelas (261+56+91, 1 linha resolve) · a torneira aberta do gold · o suporte do Perfil que descarta texto (42 chamados mudos) · o vínculo Discord↔Gmail (50 duplicados) · os 5.593 VIPs que vencem em 05/09 · e responder o Thiago no grupo.

O par rompido não é só o gold — achei mais 2 marcadores na mesma situação

O bug do gold estabilizou (1 → 3 → 5 → 6 → 6, nenhum pagamento novo desde 10:25) — mas por um motivo ruim: os 2 que voltaram nesta janela (Pepón e BYOHArj) já tinham a marca de 20/08 e estão com gold 0. ⭐ O contador parou não porque o problema acabou, mas porque a fila dos que ainda podem receber está se esvaziando pelo lado errado.

Então fui procurar o mesmo padrão em outros marcadores "1x por conta". Levantei os 9 que existem com dados e cruzei com a lista ZERA da virada. Nenhum está lá — mas isso só é problema quando o prêmio zera e o marcador fica. Conferi um por um:

Os dois casos, medidos. Em world_quest_claims a coluna period_key separa o que importa: 167 linhas são once (permanentes, 56 pessoas — q_reach5, q_boss1, q_kill2000) e 498 são diárias (viram sozinhas). Já vila_mission_claim não tem period_key: toda linha é permanente — 91 marcações com os contadores em 0. Nos dois, a pessoa refaz a conquista e não recebe, porque o servidor acha que já pagou.

⭐ A regra que emergiu: marcador de "já recebeu" tem de zerar junto com o progresso que o gerou. O teste é uma pergunta por tabela: "o que este marcador impede de acontecer de novo — e esse algo foi zerado?"

⚠️ E o erro simétrico, que quase cometi: a tentação é jogar os 9 no ZERA de uma vez. Seria errado — apagaria o album_claims, cujo progresso (9.435 figurinhas) tu mandaste preservar. A lista se confere par a par, nunca por padrão de nome.

A cura ficou mais barata: é a mesma linha que eu já propunha pro gold, agora com 3 nomes — 'welcome_gold', 'world_quest_claims', 'vila_mission_claim' no ZERA. Total afetado: 261 + 56 + 91. Não toquei em nada — mexe em distribuição de prêmio, é tua decisão.

9 pessoas voltaram ao site. 3 receberam o gold, 5 não vão receber — e a diferença é acaso

O progress deu o maior salto até agora (53 → 62): 9 pessoas voltaram nesta janela. Olhar quem são elas mostra o problema inteiro numa tabela só:

⭐ Oito das nove não vão receber o bônus na abertura. Só o ez34 recebe — e o que o separa dos outros oito não é mérito, é o acaso de quando abriram uma tela. É a mesma injustiça que venho medindo há 4 rodadas, agora com nome e horário.

O ritmo desacelerou (1 → 3 → 5 → 6, só +1 nesta rodada) — mas por um motivo ruim: a maioria de quem volta agora já tem a marca (5 dos 9). O contador de pagamentos indevidos cai justamente porque o grupo dos prejudicados já está grande.

🔍 Refinamento do diagnóstico — são DUAS rotas, não uma. O ez34 entregou isso: abriu o site (ganhou linha em progress), passa na regra (fase 1) e não tem marca — mas não recebeu. A wallet dele tem updated da restauração, ou seja nada foi escrito hoje. Logo: /api/site/profile cria a linha (todos os 9 fizeram) e /api/account paga (só 3 fizeram). ⭐ Bom saber antes de mexer: fechar a torneira em index.mjs:3445 resolve o pagamento sem afetar quem só passa pelo perfil.

Nada muda nas curas. A de 1 linha — welcome_gold no ZERA do virada-season.mjs — segue sendo a que resolve os dois grupos de uma vez: zera a marca junto com o dinheiro, e todo mundo recebe igual na abertura.

Primeiro relato pós-wipe no grupo — e nada foi perdido

Thiago Willians, 07:02 (a primeira mensagem no grupo desde as 04:01, em 8 rodadas), respondendo ao teu post sobre companheiro mítico/divino: "Os meus 6 ainda não foram entregues dos ovos que abri".

Verifiquei no banco E no backup pré-wipe. A conta dele ([email protected]) tinha 3 unidades antes do wipe — 1 bomber common, 1 uncommon e 1 pet uncommon — e zero ovos de qualquer raridade. Ele nunca teve 6 unidades míticas ou divinas. Cruzei com quem de fato tinha 6 M/D no backup: nenhum é ele. A conta está exatamente como o wipe deveria deixá-la, com o VIP até 05/09 preservado.

🔍 Achei de onde vem o número 6: ele tinha 6 CARTAS no correio — e o correio foi limpo no wipe, por ordem tua. Conferi uma a uma: nenhuma tinha prêmio a coletar (cinco eram avisos com rewards vazio; a "Compensação do recomeço" já estava coletada antes do wipe). Não houve perda material.

Não é bug — mas é ruído que se espalha. O relato está público, sem resposta, na véspera da S2, e é do tipo que vira boato ("sumiram meus 6"). Ele não perdeu nada, mas também não tem como saber disso.

Não respondi (é o grupo, broadcast só com teu OK). O conteúdo está pronto: conta íntegra, VIP preservado, o que sumiu foram cartas de aviso, e os bombers voltam com o tutorial na abertura. Se autorizares, eu respondo.

O bug do gold segue correndo — 5 pagamentos e 5.822 contas ainda elegíveis

Continuo cronometrando: 01h50 → 1 · 02h40 → 3 · 03h40 → 5. Ritmo constante de ~2 por rodada. Os novos: 10:18 Otto Ivar e 10:21 Layrson Rocha. A tabela welcome_gold foi de 273 → 275 → 277.

Nada mudou no diagnóstico nem nas curas — só o número. Segue sendo o único achado que piora sozinho enquanto ninguém age, e a cura mais barata continua sendo 1 linha: pôr welcome_gold na lista ZERA do virada-season.mjs. Detalhes completos no card abaixo.

O bug do gold está acelerando — e o diagnóstico ficou pior do que eu escrevi ontem

Ontem registrei como "pequeno: 1 conta". Voltei a medir e mudou: 1 → 3 pagamentos, todos em ~11 minutos, conforme a galera volta ao site — 09:49 Carlos Jhoneiker · 09:58 marcio zarth · 10:00 Helenilton Campos.

⭐ Não é caso isolado, é torneira aberta: ainda há 5.824 contas sem a marca. Se a base voltar ao site antes da porta abrir, são até 5,8 milhões de gold criados com o jogo fechado. (O marcio zarth é, de novo, um dos 50 e-mails duplicados — o mesmo grupo aparece em toda medição desta noite.)

🔴 E o pior: fui conferir o que acontece com esse gold na virada e comparei as duas tabelas contra a lista ZERA (virada-season.mjs:121): wallet ESTÁ na lista (o gold será apagado) e welcome_gold NÃO ESTÁ (a marca sobrevive).

Quem recebe nesta janela perde as duas pontas: ganha 1.000 que não consegue usar, o dinheiro é zerado na virada, e a marca fica — então na abertura não recebe de novo, enquanto o vizinho recebe. Já são 264 nessa situação (261 do wipe + 3 de hoje), e cresce a cada hora.

⭐ Não é um segundo bug: é o mesmo par rompido de ontem, visto do outro lado. A virada trata o dinheiro como estado de temporada (certo) e deixa o marcador que autoriza o pagamento (errado).

Retiro o que eu disse ontem sobre "higiene pra depois da S2" — enquanto o site estiver no ar com o jogo fechado, o grupo cresce sozinho. Três caminhos, todos teus: (1) fechar a torneira em index.mjs:3445; (2) ⚠️ 1 linha — adicionar welcome_gold ao ZERA da virada, e o par volta a ser zerado junto (resolve pela raiz, sem tocar na rota); (3) limpar a marca dos 264 (distribui gold, não faço sem OK).

O gold de boas-vindas paga com o jogo trancado — e 261 contas não vão recebê-lo na S2

Como apareceu: a varredura desde as 08:00 UTC acusou 1 escrita em wallet, e desta vez não era minha — Carlos Jhoneiker ganhou 1.000 de gold às 09:49, com o jogo fechado. O gold_ledger registra reason: 'boas_vindas'.

A causa: o crédito é chamado dentro do GET /api/account (index.mjs:3445) sem checar a porta. E essa rota não devolve 403 de propósito — o perfil do site também a consome, então a porta ali só filtra a presença. O crédito ficou de fora da régua.

Reproduzido em instância isolada, com a porta fechada: POST /api/action → 403 BARRADO, GET /api/account → 200, e o gold vai de 0 → 1.008.

🔍 O tamanho é pequeno: 1 conta desde o fechamento. E nem chega a ser exploit — quem recebe não consegue usar, porque o jogo barra tudo. É antecipação, não vantagem.

🔴 Mas puxando o fio apareceu o problema de verdade, e ele é da S2: a tabela welcome_gold é idempotente por conta e sobreviveu ao wipe — o dinheiro que ela pagou, não. Resultado: 273 contas marcadas, das quais 181 estão hoje com gold 0 e 80 nem têm wallet. São 261 contas que perderam o dinheiro mas mantiveram a marca — no dia 01/09 os outros ~5.500 recebem os 1.000 e essas não, todos começando do zero lado a lado, por um motivo que o jogador não tem como saber.

⭐ É o mesmo padrão da wallet no wipe: zerou o DINHEIRO (certo) mas deixou o MARCADOR que autoriza o pagamento. Zerar um sem o outro rompe o par.

Duas curas, nenhuma aplicada: (1) higiene — mover o crédito pra dentro de podeEntrarNoJogo ou pro 1º /api/action autorizado; (2) decisão tua — limpar a marca das 261 pra que o bônus valha igual na abertura. É reversível, mas distribui 261.000 de gold, então não faço sem teu OK.

Quatro jogadores reais bateram na porta — e quem escreve em progress é o site, não o jogo

O progress saltou 44 → 48 com o jogo fechado. Desta vez não é resíduo antigo: são pessoas de verdade tentando entrar agora — Davis Sudatti · KRILL · Jean · Dùúh Hartmann, todas em fase 1 e sem nenhuma atividade.

⭐ O [email protected] (Dùúh) é um dos 50 e-mails duplicados que medi na rodada anterior — a pessoa está voltando, e tem duas contas esperando por ela.

Rastreei e reproduzi em instância isolada: com a porta FECHADA, GET /api/site/profile responde 200 e cria a linha, enquanto POST /api/action responde 403. A causa é o readProgress — uma leitura que cria a linha se não existir — alcançada pela rota do site via teamCpDisplay, só pra pintar o BomberPower no perfil.

Medi as 3 consequências antes de chamar de bug: (1) dá vantagem? Não — nasce em estado default e o jogo segue barrado; (2) fura a porta? Não; (3) queima o "import 1x" do save antigo? A linha nasce com progress_imported=1, mas saves está em 0 pós-wipe — não há nada a importar, logo não há perda.

Veredito: é ruído de dado, não bug. O custo real é que COUNT(*) FROM progress deixou de significar "quantos jogaram" e passou a significar "quantos abriram o site" — e é por isso que registro: quase virou alarme falso 3 rodadas seguidas. ⭐ Linha em tabela não é atividade; só o timestamp prova. Dos 48, 1 tem kernel_last_ts (tua conta). Cura de higiene pra depois da S2 → Onda 5.

O vínculo Discord↔Gmail: 50 e-mails duplicados, 100 contas, 40 com VIP em dobro

É o tema que mais volta em todas as frentes (tickets #30 e #36, chat-geral, planilha nº3) e estava na Onda 1 sem tamanho desde sempre. Achei o número puxando um fio lateral: notei jonathan couto aparecendo 2× numa lista de gold e fui ver.

O que está no banco: 50 e-mails duplicados = 100 contas, sempre no mesmo padrão — 1 conta Google + 1 discord_* com o MESMO e-mail. No total são 245 contas discord_* (242 com e-mail, 3 sem), 213 com VIP ativo e 64 com compra registrada — ou seja, gente real que gastou dinheiro, não fantasma.

🔴 Dos 50 pares, 40 têm VIP ativo nas DUAS contas. Mesma pessoa, mesmo e-mail, dois VIPs.

✅ Não é sequela do wipe — antes de reportar cruzei com o backup-ANTES-DO-WIPE: 50 duplicados, 245 discord_*, 213 com VIP. Idêntico. A restauração copiou fielmente o que já existia; a duplicata é anterior e estrutural.

Por que vira problema no dia 1º: a porta decide por e-mail (index.mjs:226), então as duas contas passam e o jogador entra em qualquer uma sem saber qual tem o patrimônio dele. E medi: nenhum par tem units nas duas — o acervo está concentrado numa só, mas o VIP está em ambas em 40 casos. Quem logar na "errada" vê VIP e zero bombers, e abre ticket dizendo que perdeu tudo. Na 1ª semana da S2, com 50 pessoas.

Não fundo conta — mexe em patrimônio (qual sobrevive, o que acontece com os 2 VIPs, como avisar as 50). Fica medido; o desenho é teu.

Rodada limpa — e um susto de 5.761 wallets que era obra minha

A varredura das últimas 3h acusou 5.761 wallets escritas com o jogo fechado. Parecia invasão em massa. Não era: as 5.760 têm timestamp idêntico (06:56:25.887) — é a minha própria restauração de VIP, e a janela de 3h simplesmente alcançou aquele instante.

Refazendo o corte a partir das 08:00 UTC (pós-restauração): units 0 · item_stack 0 · wallet 0 · tickets 0 · IA 0 · bombas 0 · guia_rate 0. Zero escrita de jogo. A porta segue firme.

⭐ Janela relativa ("últimas 3h") atravessa as manutenções que eu mesmo fiz. Ancorar o corte num MARCO separa o que é atividade do que é obra minha.

💰 A economia que a base encontra no dia 1º: BC total na base = 0 · Gold 14.470 em apenas 11 contas (a maior é a tua, 4.370). O wipe zerou a moeda como devia, sem resíduo de valor.

5.593 VIPs vencem no mesmo instante, em 05/09 — quatro dias depois da abertura

Radar quieto pela 4ª rodada, então medi o que acontece com o dinheiro real na abertura. O recorte por data mostrou uma concentração que ninguém tinha visto: zero vence até 01/09 (a virada), e 5.593 vencem em 05/09. O resto é pingado (≈20 até o fim de setembro, 144 depois de 01/10, mais os 4 vitalícios).

Os 5.593 têm o timestamp idêntico ao milissegundo (2026-09-05T15:21:39.321Z) — não é compra individual, é concessão em massa. Fazendo a conta: 30 dias exatos a partir de 06/08 15:21, a mesma data do "Beta comunitário 06/08" que travou os módulos. Foi a cortesia daquele dia.

✅ A restauração está certa — conferi o restaura-vip-pos-wipe.mjs: ele copia o vip_until exato do backup e não toca em prazo. A data já era essa antes do wipe. E está transparente pro jogador: o Perfil mostra "ativo até dd/mm".

Por que te trago isso: a S2 abre 01/09 e quatro dias depois 5.593 contas perdem o VIP de uma vez — sendo que só 296 têm compra registrada (as outras ~5.300 são cortesia). É um evento de retenção concentrado na 1ª semana. Três caminhos: deixar vencer (a cortesia cumpriu o prazo) · estender pra dar fôlego à abertura · usar como gancho de conversão pros 5.300 que nunca pagaram. Não mexo em prazo de direito comprado nem em número teu — fica o número exato pra tu decidires.

Rodada limpa — e conferi que ninguém entrou com o jogo fechado

Nada novo em nenhuma frente (4ª seguida). Mas o progress subiu de 42 → 43 desde a rodada anterior, e com o jogo fechado linha nova é sinal de que alguém entrou. Fui atrás.

Varri toda escrita de jogo depois das 07:00 UTC: units 0 · tickets 0 · conversas de IA 0 · bombas 0 · item_stack 1 · wallet 1. As 2 escritas são da tua conta (07:38:22, um mat_cosmic_shard_t1 e gold 4.370) — admin testando, que é exatamente quem a porta deixa passar.

⭐ E o detalhe que evitou um alarme falso: dos 43 com linha de progress, só 1 tem qualquer timestamp de atividade. Os outros 42 têm a linha e nunca rodaram o kernel. Linha em tabela não é atividade — só o timestamp prova. Contar linhas teria virado um "42 jogadores entraram com o jogo fechado" que não aconteceu.

O caminho do dia 1º está testado ponta a ponta: a porta abre e o tutorial entrega

Na rodada passada testei se as features voltam. Faltava a pergunta anterior: a porta abre? Hoje o jogo só deixa entrar se kv.jogo_aberto='1' — e em produção a chave nem existe, a porta fecha por ausência. No dia 1º alguém grava '1' e 6.099 contas entram de uma vez. Se o gesto falhar, a gente descobre ao vivo.

🚪 ENSAIO DA PORTA — 7/7. Fechada: admin entra (200), jogador comum barrado (403). Aberta: jogador comum entra (200). Fechada de novo: barra outra vez — é reversível.

⭐ Um caso valeu por si: 13 contas em produção não têm e-mail (entraram por Discord) e elas passam quando o portão geral abre. Se a abertura fosse feita pela lista jogo_liberado — que casa por e-mail — essas 13 ficariam de fora sem ninguém perceber.

🎓 ENSAIO DO DIA 1 — 10/10. Depois do wipe, tutorial_done está zerado pras 6.099 contas: a base inteira refaz o tutorial no mesmo dia, e ninguém tinha testado isso pós-wipe. O fluxo entrega 3 unidades (pet + 2 bombers), marca feito no banco, dá luckyShots:10, e reivindicar 2× responde already_claimed — sem kit em dobro.

⭐ E fecha um fio da noite: os 2 bombers do tutorial nascem com bomba. Isso prova que a porta normal do jogo funciona — os 651 sem bomba vieram só da minha restauração por SQL, não há defeito no caminho do jogador.

⚠️ A mesma armadilha, de novo, e de novo minha: a 1ª rodada deu tutorial_pendente e +0 unidades, parecendo bug grave no dia 1. Eu tinha chamado o claim direto — o fluxo real é inicio → fim → claim. ⭐ Supus o contrato em vez de ler o defineModule. Duas vezes na mesma noite é padrão, não azar: ler primeiro, testar depois.

🧹 Higiene: instância de ensaio derrubada por kill cirúrgico na porta, banco de ensaio apagado, e dev local conferido intacto depois (17 locks, jogo_aberto ausente, HTTP 200). Produção não foi tocada.

Ensaiei a abertura da S2: as features travadas há 21 dias voltam certo

Radar quieto pela 2ª rodada seguida, então fui atrás do risco que ninguém tinha testado: 15 módulos travados, 9 parados desde 06/08. ⭐ Um lock prova que a feature está FECHADA — não prova que ela ABRE. E entre travar e hoje passaram 21 dias, um wipe, uma virada de season e mudanças de esquema. Se alguma quebrasse, quebraria no dia, com a base olhando.

Como testei sem risco: instância isolada na porta 5471 sobre uma cópia do snapshot. Pra cada módulo: confere que travado recusa → destrava → chama a action que a tela chama → restaura o lock. Depois conferi: dev local intacto (mesmos 17 locks, HTTP 200), instância derrubada, banco de ensaio apagado.

Resultado: bestiary · dailypass · dungeons · pass · vault · yoshi → 6/6 responderam com dado real. E o lock barrou 6/6 enquanto fechado — nada de feature aberta achando-se fechada (o caso do pvp_arena às 08h40).

⚠️ Duas armadilhas que quase viraram alarme falso meu. A 1ª rodada deu 0/8 vivos e 5 "lock furado" — parecia catástrofe. As duas causas eram minhas: (1) inventei nomes de action (dailypass_view em vez de dailypass_status), e action inexistente responde bad_action sem consultar o lock — fabricando 5 furos que não existem; (2) esperei 1,2s e o cache do lock é 5s (modules.mjs:23). ⭐ Ler o defineModule custa 30s; inventar o nome fabrica um incidente. E medir mais rápido que o TTL mede o cache, não o alvo.

🟡 Achado de passagem, pra decidir antes do dia 1º: fishing e mural têm actions: {} vazio. Destravar a pesca não vai fazer a pesca aparecer — não há action registrada nem tela no dist/ (só o leaderboard da aba de ranking). A poda do L71 levou o fishing_view junto. Se a pesca entra na S2, é religar, não destravar. → Onda 3.

Rodada limpa — e o #38 encerrou bem

Nenhuma mensagem nova em nenhuma frente. WhatsApp parado desde 04:01 · chat-geral desde 00:02 · bugs-e-reports desde 26/08 12:17 (e é tutorial de marca, não bug) · feedback desde a tua resposta ao vandonft às 01:54 · 0 tickets in-game em 4h · 0 fatais em produção.

✅ Ticket #38 fechado no melhor tom: o KogimaPrince respondeu "tranquilo vamos ficar no aguardo 🙂" às 04:40, depois da correção de voz. A régua nova (1ª pessoa, sem "quem decide é o Giba") funcionou na prática.

⏳ Os 3 tickets abertos são os que já estão na Onda 1: #32 kevinaguiar (upar bomber), #30 leonardo (vínculo Discord↔Gmail) e #36 flavin (aguardando o jogador).

🔧 Nota de ferramenta: o Discord tinha ficado ilegível na rodada passada. Não era o site — era a ABA, presa em carregamento (4 tentativas, 2 rodadas, até um reload). Abrir uma aba nova resolveu na hora. ⭐ Régua: aba travada ≠ serviço fora — antes de declarar frente inacessível, tenta uma aba limpa.

O mural do Discovery mostra o nome antigo de quem trocou de apelido

Radar quieto, então fui atrás do item nº1 da lista do vandonft (11/08) — o único que descreve sintoma técnico: "corrigir pra uma única fonte de dados sobre nome, pois a pessoa muda num lugar e não altera no geral". Ele tem razão, e agora com caso concreto.

O nick oficial mora em profile.nick, mas o feed do Discovery (discovery.mjs:275) lê uma cópia congelada na própria linha. Resultado, no mural público do ranking:

BravoExplosivo2461 → hoje é muse · Pontes_IMP → Pontes · Sudatti_CC → Sudatti. O primeiro é apelido auto-gerado: a pessoa escolheu o nome depois, e o mural segue mostrando o de fábrica dela pra todo mundo.

⚠️ Quase reportei 5.720 divergências. bomber_log (792) e tesouro_log (4.737) batiam 100%, mas ali nome é do BOMBER, não do jogador — mesmo dono semântico duplicado da wallet. E são logs: guardar o nome da época é o certo. ⭐ Cruzar duas colunas com o mesmo nome não prova que falam da mesma coisa.

A cura é 1 linha (Lei do Unificar): LEFT JOIN profile + COALESCE, que preserva o histórico de quem não tem mais perfil. Não toquei em nada — aguarda teu OK. Bom candidato pra responder publicamente ao vandonft com um caso real.

O suporte do Perfil joga fora o que o jogador escreve — 42 chamados chegaram mudos

Como apareceu: o ticket novo das 19:15 (Marlon Rui) veio vazio. Fui ver se era isolado: 46 dos 57 tickets (81%) têm assunto "Atendimento iniciado", resumo vazio e transcript [] — e nenhum foi tocado depois de criado.

A inversão que entregou a causa: dos chamados mudos, 42 são de gente LOGADA e 4 de anônimos. Dos que funcionaram, 0 são de logado e 11 de anônimos. Inversão perfeita: quem está logado nunca consegue relatar. Isso descarta "a IA caiu" (os vazios se espalham por todas as horas) e aponta pro caminho que só o logado usa.

A causa, no código: o Perfil (proto-perfil.html:794) manda assunto, resumo, categoria e origem. A rota (index.mjs:2390) lê só o email. O supportOpen (support.mjs:217) nem tem parâmetro pra texto — grava assunto fixo e resumo vazio. Os 4 campos morrem no caminho.

Reproduzido no dev local: o jogador escreveu 66 caracteres · chegou 0. E o servidor responde ok:true com protocolo, enquanto a tela promete "Ticket aberto! Retorno pelo Correio. 💌" — o sintoma nº 2 da Lei do Unificar, textualmente: sucesso e recusa com a mesma resposta.

A prova comportamental: 11 pessoas tentaram mais de uma vez — Celio Junior 5×, mau 4×, Will/Max Serpa/Marlon 3× cada. ⭐ Ninguém insiste 5 vezes num formulário que funcionou. Escreveram, viram o protocolo, nada voltou, tentaram de novo. São 42 chamados de 23 pessoas.

⚠️ O agravante: o Max Serpa está aqui com 3 chamados mudos — é o mesmo do "pavio molhou". Ele tentou falar com a gente por dois caminhos diferentes e os dois o engoliram em silêncio.

✅ O resto está são: o chat da IA (/api/support/chat) responde certo anônimo e logado — quando funciona, a IA reescreve o assunto, então "Atendimento iniciado" é marcador confiável do caminho quebrado.

A cura (pequena, do lado certo): repassar os 4 campos em index.mjs:2390, gravá-los no supportOpen, e recusar de verdade quando faltar texto (a porta irmã da manutenção já faz: suporte-ia.mjs:159). Não toquei em nada — aguarda teu OK. Os 42 têm sub e email: dá pra avisar as 23 pessoas pelo Correio, mas isso é broadcast.

O wipe apagou o VIP pago de 432 contas — e os 4 co-fundadores vitalícios

Como apareceu: a checagem de rotina viu 53 tickets pendentes em produção. Fui olhar o mais antigo de prioridade alta — "VIP comprado não ativou", 29 dias — e o fio abriu isto.

O caso que puxou (com final feliz): o Jovani pagou 2 PIX em 27/07 (vip_r3 e passpremium_r3, R$ 3 cada) e o VIP foi ativado — no backup, vip_until = 05/10/2026. O ticket estava só desatualizado. Mas ao conferir a conta hoje: a wallet dele não existe mais.

O estrago, medido: wallet caiu de 6.104 para 39 linhas · VIPs ativos: 5.761 → 0 · co-fundadores: 4 → 0. Destes, 432 contas têm compra registrada e 395 têm PIX confirmado. Na base há R$ 26.066,37 em PIX pagos (R$ 830,93 só de VIP).

A causa — a intenção estava certa, o alcance não. O comentário do próprio script diz: "recursos e moeda de jogo (o BC/gold zera — a garantia lê purchases)". A wallet entrou como "moeda"… mas ela guarda vip_until e co_founder na mesma linha do gold. Direito comprado com dinheiro real, junto da moeda que devia zerar.

A lição: uma tabela pode ter dois donos semânticos. A wallet era "a carteira" (zera) e "o contrato" (nunca zera). Antes de pôr uma tabela num wipe, olhar coluna por coluna — não pelo nome dela.

✅ Dá pra restituir com precisão: purchases (1.825 linhas) e pix_orders sobreviveram — cada VIP pago tem sku_id e paid_at, e o backup tem o vip_until exato. Não executei nada — é dinheiro de jogador. 3 caminhos: devolver o saldo restante (recomendo — é o que foi comprado) · devolver o pacote cheio · ou só os 4 vitalícios. ⚠️ Antes de 01/09: se a S2 abrir sem VIP, 432 pessoas que pagaram descobrem juntas.

🎫 53 tickets pendentes — o mais antigo há 30 dias

46 abertos · 7 "prontos pra equipe" (a IA já triou e devolveu pro humano) · 3 aguardando jogador · 1 resolvido. Por categoria: 51 dúvidas, 1 pagamento, 1 bug.

Os 2 de prioridade alta, ambos parados há ~1 mês: BMB-2B3C0D9D (VIP não ativou — já estava resolvido, só não foi fechado) e BMB-BC4B598F ("Itens sumidos e ovo VIP" — ainda não verifiquei).

💡 A seção Suporte do CRM já mostra tudo isso com o pronto_para_equipe pulsando. É literalmente a fila que estava invisível.

🔴 Nenhum dos 32 produtos da loja avisa o que sobrevive à virada

StormTeam (26/08, 15:02) — e é um pedido de UX preciso: "na compra do ovo poderia estar assim: lenda não fica. Mesmo que já tenha em outra aba dizendo, no ovo deveria dizer que só mítico e divino permanecem — do jeito que tá, soa como se o lendas também permanecesse."

Ele comprou R$ 9,00 de ovos lendários achando que atravessariam. O Rodrigo confirmou o furo: "só no Bundles que não".

Verificado no catálogo (economy-core.mjs, 32 SKUs em 5 seções): zero mencionam a virada. As descrições dos ovos são só comerciais — "O pack de entrada", "10% de desconto", "DOBRA os slots da mochila".

⚠️ Ficou mais grave depois de ontem: a virada ACONTECEU, e os lendários que ele comprou sumiram de fato. Não é hipótese — é o que 220+ compradores viram hoje. A cura é uma linha nos 6 SKUs de ovo: "Lendário NÃO atravessa a season — só mítico e divino ficam na conta." Não implementei: mexe em produto que tu vendes, e o texto é decisão tua.

✅ "Os épicos não fundem" — não há bug, e circulou como confirmado

StormTeam: "porque esses epics nao fundi" + print. O Rodrigo respondeu "bug" e "Giba vai resolver" — ou seja, virou verdade na comunidade sem ser.

Medido no backup (fusion_events, 8.246 fusões da S1): épico = 6.001 fusões de 220 contas — é a raridade que mais fundiu. Legend 1.985 · divine 194 · mythic 66. Não existe bloqueio.

O que houve foi uma das 4 recusas legítimas. A mais provável pelo print (bonecos variados): fuse_same_kind — misturar bomber com pet, regra deliberada do LOTE5-P2. E o ALPHA_MAX_RARITY que travava legend→mythic está vazio desde o lançamento.

💡 O ponto de UX: a tela JÁ explica as 4 recusas em português claro — e mesmo assim ele leu como bug. Sugestão: desabilitar o botão enquanto a seleção for inválida, com o motivo ao lado. Recusa depois do clique é sempre lida como falha do jogo.

🔴 O PvP está aberto — dois locks apontam pra um módulo que não existe

Conferindo os 20 módulos travados, testei se o lock realmente pegava. Três responderam certo — vault_view, pass_status e bestiary_status devolvem module_locked. Mas o pvp_state respondeu {"ok":true,"elo":"bronze"…}.

A causa: o módulo se registra como pvp_arena (underscore), mas os locks no banco são pvp e pvp-arena (hífen). São strings diferentes — o lock nunca encontra o módulo. No banco: pvp=1, pvp-arena=1 (ambos órfãos) e pvp_arena=0, que é o real.

A lição: um lock com o nome errado passa em toda inspeção visual — a lista do CRM mostra "pvp: travado" e parece certo. Só a action diz a verdade. Mesmo padrão do companion/pet do L137: a régua procurando uma string que o sistema não usa.

Importa porque o PvP foi a 2ª feature mais usada da S1 (9.631 partidas). Se o jogo reabrir assim, ele entra no ar sem ninguém ter decidido. Não corrigi — é tua decisão: travar de verdade (criar pvp_arena=1) ou assumir aberto. ⚠️ Em qualquer caso os dois órfãos devem sair: lock que não corresponde a módulo só dá falsa sensação de segurança.

💡 12 features prontas estão fora do ar há 21 dias

O lock-lancamento de 06/08 travou 12 módulos com código substancial. O que a comunidade chegou a usar antes de travar: vault 18.149 registros de 1.462 contas · PvP 9.631 partidas · sets 6.508 marcas · pass 457 contas · mural 82 posts · bestiary/dungeons/dailypass residual · fishing zero (nunca saiu).

O vault e o PvP não são experimentos: são as duas features mais usadas da temporada. Vale decidir quais voltam na S2 — e isso encaixa direto na seção Jogo do CRM, onde os locks viram interruptores teus.

💡 "Abre a venda de 1 companheiro no shop… dia 1" — ideia do Valdinei

Depois que expliquei no grupo que o Espectral e o Celeste nunca poderiam cair jogando (é regra: "mítico/divino NUNCA no drop, só premiação de season"), o Valdinei sugeriu: "abre a venda de 1 companheiro no shop… dia 1". O Serpent confirmou o diagnóstico: "acho que ninguém msm KKKKKK, no máximo lendário".

Vale avaliar: os dois companheiros de topo existem no catálogo, têm arte pronta e nunca foram distribuídos. Como item de loja na abertura da S2, resolvem a frustração e dão um motivo de compra no dia 1º. Decisão tua.

🐦 "Ninguém pegou companheiro mítico ou divino, tava bugado o drop?" — não é bug

A resposta está escrita no código, em minigame-loot.mjs:155: "ANTI-INFLAÇÃO: bc com teto diário; equip teto LENDÁRIO; companheiro 1/dia; mítico/divino NUNCA no drop (só premiação de season)".

Só existem dois M/D no elenco dos 33: n=33 Espectral (mythic) e n=34 Celeste (divine). Foram desenhados pra ser prêmio de temporada — e a S1 fechou sem serem distribuídos.

O dado da produção confirma, e é elegante: de 33 matrículas do catálogo, só 10 foram distribuídas, e a mais rara que alguém possui é a n=32 — a distribuição para exatamente antes do 33. É a assinatura de um corte por regra: um drop quebrado deixaria buracos aleatórios, não um teto limpo.

Respondido no grupo (continuação da tua própria conversa, informação técnica que evita a suspeita virar folclore). Efeito colateral útil pro wipe: como ninguém tem M/D, a régua "míticos e divinos ficam" aplicada a companheiros resulta em sai tudo — que é o que o script já faz. Nada a mudar.

O nick do único creator é uma URL colada por engano

Investigando o item 1 do vandonft em #feedback-e-sugestões ("corrigir pra uma única fonte de dados sobre nome, pois a pessoa muda num lugar e não altera no geral" — a Lei do UNIFICAR dita por um jogador), medi as três colunas de nome: profile.nick 2.463 (a fonte de verdade) · users.name 6.099 (nome do Google, diverge em 2.378 e é o esperado) · creators.nick 1.

O achado: a única linha de creators tem nick = "https://bombidle.com/?ref=g_810535117950" onde deveria estar "Seroy". Não é bug de código — o adminUpsertCreator herda o nick do profile quando o campo vem vazio. Foi erro de digitação no CRM: colaram a URL inteira no campo do apelido.

Impacto: baixo. O link que o jogo mostra a ele vem de profile.ref_code (BOMB-JNX7XT), não desta coluna — e ele já trouxe 39 pessoas. O valor sujo é cosmético no CRM.

Cura (aguarda teu OK): um UPDATE pra "Seroy" — ou, melhor, parar de gravar o espelho e ler sempre de profile.nick. Um dado, um dono.

🥚 Os ovos da chocadeira somem na virada de season — 1.334 divinos em risco

Quem levantou: KogimaPrince (ticket #38, 01:29), com medo explícito: "to com 10 ovo divino na chocadeira q comprei hj a tarde… queria saber se o servidor vai voltar antes pra tirar os ovos tipo 1 dia antes de resetar?"

O medo é legítimo. Em virada-season.mjs:128 a lista ZERA inclui egg_hatch, egg_rarity e egg_used. A promessa da virada preserva units e items míticos/divinos — "nada de mítico ou divino se move" — mas o ovo ainda não é unit: é linha nessas tabelas, e elas zeram inteiras.

Medido na produção: 47.488 ovos de 491 contas, dos quais 47.321 já estão prontos (só falta clicar). Entre eles 1.334 divinos (86 contas) e 207 míticos (90 contas). No inventário, sem chocar: mais 59 divinos e 54 míticos.

✅ O que já confirmei e respondi a ele: o ready_at é timestamp fixo — o tempo corre no relógio, não depende do jogo aberto, e nada expira por ficar parado (procurei DELETE por prazo: não existe). Os ovos estão a salvo enquanto a virada não roda.

🎯 A decisão é tua: (1) abrir uma janela pra recolher antes da virada; (2) tirar mítico/divino do ZERA, estendendo ao ovo a promessa que já foi feita; ou (3) chocar tudo no servidor antes e entregar as units. Meu parecer: a 2 — 86 e 90 contas não entram todas numa janela, e é a leitura mais fiel do que já foi prometido.

🐉 O world boss rodou depois do comunicado — e o jogador veio contar

Caio Lucas Leão (00:38, no privado): "deu pra fazer o boss mesmo depois de sair o jogo do ar, testamos eu, matty e Lactoze… entramos na versão antiga (bombidle.com/v4)" — e ofereceu: "qualquer coisa só descontar os bcoin da premiação sem problema". Honestidade exemplar.

Confirmado no banco: evento wbe_2026-08-27_h00m30, boss wb_plan_guard_25, 03:30→03:37 UTC, HP 106.731.781 → 0, 4 jogadores tier ouro. Levaram 2.534 BombCoin + ~315k gold + materiais T8, 1 Equip Tier V e a Peça do SET do Boss.

✅ A notícia boa — não virou dinheiro. O world boss não credita BCD: reason LIKE '%boss%' no ledger inteiro volta vazio, em todos os dias. É moeda de jogo, fora do bolo dos R$ 3.000. Ninguém ultrapassou ninguém no ranking, e nada foi gasto (0 compras depois do payout).

🔍 Não foi glitch de evento: o h00m30 é agendado normal (a lista tem h03m30, h09, h12, h18, h21 no mesmo padrão). O que falhou foi o intervalo: o comunicado dizia "fechado em ~35 minutos" (≈00:05), mas a trava só subiu 00:45. Nesses ~40 min o jogo seguiu 100% funcional pra quem já estava dentro.

A lição pro próximo fechamento: anunciar e trancar são dois atos separados; entre um e outro o jogo continua valendo. Trancar primeiro, anunciar depois — ou anunciar o horário exato em que a trava sobe, e subir nela.

Meu parecer (decisão tua): não estornar. Boss agendado, nenhuma falha explorada, prêmio não é dinheiro, e quem avisou foi o próprio jogador. Estornar pune a honestidade que se quer na S2. ⚠️ E vale decidir: na janela 27-31, os bosses agendados continuam pagando se o jogo abrir.

Duas perguntas tuas no #chat-geral, sem resposta

1. Serpent (26/08, 21:54): "Amanhã tem AMA, hein? Anota ai" — o "amanhã" é hoje, e o jogo está fechado. Combinar o que fazer: adiar, ou fazer a AMA já explicando a janela de testes 27-31.

2. StormTeam (23:39): "próxima season só em setembro? ainda" e "começa os pg pelos mais baixo kkkk" — pedido sobre a ordem de pagamento dos BCDs. Vale decidir antes de começar a pagar: quem recebe primeiro vira precedente.

Clima geral positivo: às 00:02 o StormTeam postou "Parabéns a todos que jogaram esta season… ansioso pelas novidades". Zero reclamação da queda do servidor.

"Só consigo fusão do comum" — é a curva, não trava

O +55 21 98195-6669 (22:48): "só está conseguindo fazer fusão do comum?" · "dá bug nos lendários, depois de uns 30 minutos volta". Medi na produção, 48h: lendário é a raridade que MAIS fundiu (190×), acima de todas. Não está travada.

A causa da percepção: comum→raro é 35%, lendário→mítico é 0,1%. Fundir comum "funciona" 1 em 3; fundir lendário falha 999 em 1.000. O fuse_pity confirma o desenho operando: 163 contas acumulando (média 8,6 tentativas).

O "30 minutos e volta" não se sustenta: procurei trava temporal e não existe. O que muda a cada tentativa é o pity, que sobe a chance — ele tenta, desiste, volta depois e acerta.

É o 3º relato do mesmo mal-entendido em 2 dias. A cura já proposta continua a mesma: mostrar "4% de virar Lendário" antes do clique. O dado já viaja do servidor e a tela ignora.

"Onde ficam as marcas?" — de novo

Davis Sudatti (22:57). Antes: Neforo no Discord e o +55 15 no WhatsApp, ambos ontem. Três pessoas, dois canais, dois dias. Já registrado como UX (5 passos em 3 telas); a repetição confirma que não é distração de um jogador, é o fluxo.

Extrato de transações no Perfil — o dado já existe

Davis Sudatti: "essas cartas achei legal pq são os recibos" · "seria legal ficar na lista de transações em uma área do Perfil". Dois outros concordaram no grupo.

A parte cara já está pronta: o extratoPeriodo(sub, desde) existe e já é servido numa rota. Falta só a tela — o perfil não tem aba de extrato. É o mesmo remédio dos outros achados da semana: quando o jogador vê o registro, para de achar que sumiu dinheiro, e para de abrir ticket.

O alarme de 72,7% da premiação NÃO procede

Fui medir no banco vivo e o relatório estava errado: ele leu o snapshot de dev congelado em 18/08 — a mesma armadilha que quase me pegou na vigília do ovo.

O ranking real: 1.034 contas concorrendo, e a maior fatia é de 2,30% (Pedro Benetoli). O critério era "ninguém acima de 20%" — passa com folga de 8×.

A conta acusada é o Will Carvalho: tem 1,4%, não 72,7%. O raw dele era 120.876 e os tetos já cortaram para 57.031 — o sistema fez o trabalho. E tu já o bloqueaste: gac_freeze com blocked_by_admin:giba até 2029.

O relatório também errou ao dizer que as ferramentas nunca foram usadas: rank_exclusao tem 38 linhas e rank_revisao, 121.

As três portas abertas, fechadas antes de alguém entrar

Aluguel: dava pra anunciar bomber alheio e receber o BC — e a trava plantada só o atacante conseguia soltar. Curado com posse derivada do banco, fail-closed. Medido: 41 anúncios, todos com dono correto.

Guilda: body.guild era string livre — dava pra sobrescrever o relatório de qualquer guilda e queimar o drop de receita dela. Curado com guildOfSub(sub), o padrão que toda a família já usava. guild_raid tinha 0 linhas.

Equipar: mandar id de item alheio pulava a checagem inteira (fail-open). Curado na forma do irmão que já estava certo. Medido: 9.562 slots, 0 com dono divergente — e mantive exceção nomeada para os 4 de kind='magia', senão derrubaria jogadores legítimos por um buraco que não é deles.

O PDF da auditoria: 0 de 22 exploits funcionam

Não é relatório, são ~25 scripts prontos pra colar no console, sem uma linha de análise. Testados um a um: 12 não procedem · 4 já curados · 6 procedem parcialmente · 0 procedem.

A causa dos 12 falsos positivos é uma só: várias recusas do servidor respondem HTTP 200 + ok:true + reason. Os scripts contam sucesso com if (r.ok) e reportam 805/805 sucessos extraindo exatamente zero. A calibragem denuncia que foram escritos contra um alvo já endurecido: o delay de 4s fica logo acima do too_fast de 3,5s, e o loop de XP tem 805 iterações pra um teto de exatamente 800.

Mas 3 achados novos da varredura própria são reais: 11 de 20 tetos do anti-farm são letra morta (a chave que o emissor grava não é a que o contador procura, então o COUNT é sempre 0) · 4 primitivas de dinheiro sem atomicidade, com 79 chamadores · 4 IDORs, incluindo anunciar aluguel de bomber alheio e receber o BC.

Medi o dano: 0 carteiras negativas em 6.154, 0 ovos duplicados em 51.339, 3 anúncios de aluguel. São janelas abertas, não incêndio — o oposto do item da premiação, que já aconteceu.

"Tá dropando ovo normal?" — sim pra base, não pra ele

Murilo Tomadon perguntou e ninguém respondeu. Medi na produção real: a base está bem — 2.651 ovos ontem para 180 jogadores, e 10 bateram o teto do dia hoje.

Mas pra ele não cai há 5 dias. Está na fase 1800 (o fim do jogo), fez 297 clears ontem, e o último ovo foi em 22/08. O egg_pity dele está em 102 e subindo.

A causa: ele tem 1.234 ovos na chocadeira com 5 slots por tipo. Entupida, o ovo novo não entra em egg_rarity — vai pra carta de excedente. Ele está ganhando; o ovo só não aparece onde ele olha. Vale conferir se 1.234 parados é estado esperado ou represamento de outro bug.

De passagem: simulei a rolaOvo e o teto real é 4-5 ovos/dia, não 12 — 96,7% dos ovos sorteados são descartados quando a raridade já saiu no dia. É desenho, mas explica a percepção de "ovo sumiu".

"Como equipo a marca?" — 2 jogadores perdidos no mesmo dia

Neforo (26/08 12:17, bugs-e-reports, com print) e um jogador no WhatsApp às 21:42. O Rodrigo respondeu o Neforo com 4 prints montando um tutorial: comprou → vai pro correio → depois pra loja das marcas → aplicar → escolher quem → gravar.

Não é bug: são 5 passos em 3 telas. Quando dois jogadores se perdem no mesmo fluxo no mesmo dia e um moderador precisa ilustrar, é sinal de UX. Remédio barato: no correio, quando o item é marca, o botão dizer para onde ir.

O vínculo de conta existe no servidor e não tem botão

O Leonardo perguntou em 13/08 como vincular email à conta que só tem Discord. Foi respondido que "será consertado em breve". Mas não precisa de conserto: o resolveIdentity(..., linkToSub) já vincula, já protege o caso de a identidade ser de outra conta, e já funciona — 60 contas têm 2 identidades.

O que falta é o caminho até ele. Procurei "vincular"/"linkar" nas telas de perfil da v2, v4 e v5: nenhuma oferece o botão.

Por que importa mais que 1 ticket: 296 contas só têm Discord, e 83 delas têm progresso real — uma chegou à fase 1800, o fim do jogo. São jogadores com uma única porta de entrada.

"Fusão não funciona": duas causas, só uma é bug

Rodrigo/Smoker (18:12) "porque esses epics nao fundi" e StormTeam (15:21) "bug miseravel impediu eu pegar meu mitico". Separei:

(a) Não consegue tentar — a fusão cobra o mesmo frag_shadow. 100 de 360 contas com 2+ épicos (28%) não têm. Mesma raiz do ticket acima.

(b) Fundiu e não virou lenda — não é bug: épico→lendário é 4%, lendário→mítico é 0,1%. Está funcionando. Mas a tela não mostra a chance antes do clique (conferi), então frustração vira "bug" no chat. Mostrar "4% de virar Lendário" antes é barato e usa dado que o servidor já manda.

Jogador diz que lançaram um clone na Steam ("bomb farm")

O Cleomar (+55 27 99797-8612), que se apresentou como pouco ativo no grupo, escreveu: "lançaram um jogo na Steam, bomb farm, não sei se foi vcs mas pegaram a ideia por completo" e "o jogo é uma cópia total da ideia mas parece que foi feito com umas IAs brutas". O Serpent respondeu que viu o anúncio mas não o jogo. Ele te marcou diretamente.

O crafter T1 está fechado pra 2/3 da base — e 149 contas estão a UM ingrediente

Ampliei a investigação pro crafter inteiro (767 contas com material): 66% não conseguem craftar nenhuma arma, armadura ou joia T1 (503 contas). Poção e comida ficam em 47%.

Por que equipamento é pior: a receita de arma pede dois temas ao mesmo tempo (ember + frost) mais o core, que é o material menos distribuído do jogo (530 contas). A poção pede um tema só.

⭐ O dado acionável: das 503 sem nenhuma arma, 149 estão a UM único ingrediente de destravar.

E dá pra apontar o ingrediente exato: das 149, 63 travam no shard (74 na essence, 12 no core). Conferi as 120 receitas de arma T1 uma a uma: o shard é de tema cruzado em 100% delas — zero usam o shard do próprio tema. Uma Lâmina Brasa exige mat_frost_shard_t1. Quem farmou ember e quer forjar arma de ember é barrado por não ter frost. É isso que faz equipamento (66%) ser muito pior que poção (47%, tema único).

"Tô nível 7 de alquimista e nunca consegui um buff" (19:16), com erro "material ou consumível falhou". O craft não está quebrado — testei: com o material certo, a poção sai (craft_equip → ok:true). Existem 1.080 receitas de buff e 1.080 de comida.

O gargalo é o material. As poções pedem material temático (Essência Brasa, Pó Glacial…) e o que os jogadores têm é esmagadoramente crystal. Medido: das 767 contas com material, 364 (47%) não conseguem fazer nenhuma poção T1 — e subir de nível de alquimista não muda isso, porque o gargalo é o tema, não o nível.

E é TUDO OU NADA (medi depois): 364 contas fazem zero poções, nenhuma conta está na faixa de 1 a 3, e 403 fazem 4 ou mais. Não existe "falta pouco" — quem está travado, está travado de verdade. A causa: o crystal alcança 695 contas (quase o dobro do 2º tema), é o material que mais cai — e nenhuma receita de poção aceita crystal. O jogador acumula o que o jogo dá e não pode usar em nada de alquimia.

A linha de Quest do RPG sumiu da tela

"Não tem mais aquela linha de Quest pra seguir no RPG, fiquei meio período nesse" (WhatsApp 18:56, sem resposta de ninguém). O jogador passou metade da sessão perdido.

Confirmado, e é elo faltante clássico: o rpg_chapter_state devolve tudo que a tela precisaria — titulo, objetivo, counters, marcos — e o palco faz só SRV.chapter = c.chapter, guardando o número e jogando o resto fora. Esse número serve pra uma coisa só: saber se o guardião está trancado. O objetivo do capítulo não é desenhado em lugar nenhum.

A tela vende "esquiva" — e o jogo não tem esquiva

Saiu da pergunta do grcrosso (18:48): "a agilidade altera o que exatamente diferente de velocidade?". Fui conferir: a tela de Marcas descreve Agilidade como "esquiva e reação" — e isso está traduzido pra 4 idiomas. Mas no motor, agility e speed caem no mesmo canal: são +1% e +3% de velocidade por ponto. Não existe mecânica de esquiva no jogo.

Quem compra a Marca Ágil (550 BC) achando que ganha esquiva está levando velocidade mais fraca que a Célere — pelo mesmo preço. É o mesmo tipo de defeito do L55 (a marca de crítico que não fazia nada), só que aqui o número funciona: o que está errado é a promessa.

A fusão trava 84% de quem ainda não chegou no Mundo 5

Saiu do caso do StormTeam. Ao explicar por que os épicos dele não fundem (faltam 20 Fragmentos de Sombra), fui ver se aqueles 20 são alcançáveis pra quem está onde ele está. Não são — e não é caso isolado. O Fragmento só cai no Mundo 5 (fase 241+), mas a fusão cobra dele desde o rare.

Medido no banco (449 contas com trio fundível de rare/srare/épico): antes do Mundo 5 → 174 de 206 travadas (84%). Depois → 14 de 243 (6%). No total, 188 contas (42%) com a fusão parada.

E dói mais onde não devia: a rare é a pior (167 travadas, 40%) — e dessas, 107 estão na faixa de fase 1-60, gente começando. Pior: 154 das 167 têm ZERO fragmento, não "quase lá" — o item não existe no mundo delas. A rare é justamente a raridade da rotina que o tutorial ensina ("funde 3 iguais").

Os 32 bugs viraram 5 ondas

Onda 1 (bloqueia gente hoje): CRM · ticket #32 · Bombim · vínculo de conta · neurons desatualizados. 2: economia (ovos, Gold/Renome, BC na fusão, bombas, NaveBomber). 3: RPG em bloco (7 linhas). 4: UX. 5: segurança. Tudo em analise/2026-08-26-TRIAGEM-BUGS-ORDEM-ATAQUE.md — dev local primeiro, sobe num trem só.

Kika e Bombim ensinam número errado

As neurons do jogo estão desatualizadas em ~15 pontos vs. o código (lvlFactor morto desde 06/08, mítico/divino já fundem, lendário→mítico caiu de 1,5% pra 0,1%, crafter T3 abre na 181 e não na 15). A IA lê esses arquivos — hoje ela responde errado pro jogador. Apêndice D do GDD.

CRM da prod não abre

/index.html?crm=1 aborta: manifest aponta atlas.41ead07141.png e a prod responde 404 (o .json existe, a imagem não). É a única porta do admin — sem ela não vejo a fila real de tickets. Local também não tem essa imagem. Entra no próximo deploy.

Boss × minimizar — "fiquei em 28"

Serpent: "acho que se minimizar durante o boss… segunda vez hj". Valdinei: "aqui foi igual, fiquei em 28 tbm". 2 relatos independentes, mesma janela. Suspeita: aba minimizada corta o dano/placar do Boss Mundial.

StormTeam: "VIP 30 dias reseta?" — sem resposta

Pergunta aberta no chat-geral sobre o reset/season. Já tem reunião marcada (27/08 20h, pelo Rodrigo). Precisa da tua palavra sobre a política antes de responder.

Bombim sempre "pavio molhou" (Max Serpa)

Planilha marcou como Alta (25/08). Fallback identificado no código; causa na prod ainda em apuração — ver coluna ao lado.

kevinaguiar_: não consegue upar NENHUM bomber

Erro ao subir level em todas as unidades. [email protected]. Serpent respondeu 25/08 "correção em andamento". Candidato: erros no_frag/no_cap (a planilha relata o mesmo padrão: trava após 3 níveis).

Vínculo de conta é o tema que mais volta

#30 Leonardo (login Discord quer vincular Gmail), #36 Flavin (restrição por IP, orientado a IP fixo até a próxima season), Rock Star no chat-geral (login Discord pós-reset). Planilha também tem como Alta. Serpent/Rodrigo seguraram bem — pendência é a feature.

Thiago Willians comprou VIP Vitalício (30.000 BC)

E soltou: "como faz quando o filho do meu filho for jogar e acabar o vip?" (recibo mostra ×36.500 dias ≈ 100 anos). Deixa de recado divertido pro grupo — rascunho pronto na coluna RASCUNHO.

Murilo Tomadon: VIP vitalício + saldo zerado

Pelo tom ("tá bem obrigado…"), tu já respondeste — o vitalício custa 30.000 BC, o saldo zerar bate. Só registrando pra não duplicar. Ele também postou "forja deu bom" no Discord 01:11.

duuke: sumiu o Co-fundador depois da att

Rodrigo perguntou se ele comprou; conversa parou aí. Dá pra cravar no banco (purchases/grants) quando o CRM voltar — fica na fila de apuração.

32 bugs ativos · 29 aguardando · coluna Dev vazia

Blocos maiores: RPG (7 linhas: capítulos fora do ar, missões travadas, boss elite sem drop…), Craft de Bombas (3), Economia/Drops (3, incl. drop de ovos 500-1000 ignorando teto), cadeado ignorado no "Selecionar Tudo" (destrói item trancado). 3 já constam Corrigido. Mapa completo salvo em analise/.