INCIDENTE: Auditoria encontra 91 arquivos alterados; nenhum deles havia sido alterado

A manhã começou com um git status e devolveu noventa e um arquivos modificados. Nenhum commit pendente, nenhuma edição do dia, nenhum arquivo aberto no editor. Segundo o relato registrado em ata, o primeiro reflexo foi verificar se alguém havia mexido em algo sem avisar. O segundo foi verificar se alguém havia mexido em algo avisando, o que na prática é pior.

O número noventa e um foi obtido com git status | wc -l, procedimento classificado internamente como "o único comando confiável daquela manhã". Com o número em mãos, a área responsável convocou reunião com quatro pessoas e convidou outras duas por precaução. A pauta tinha um item: alterações não autorizadas.

A reunião durou uma hora e começou pelo método errado. Dos participantes, cinco revisaram a lista de arquivos — todos nomes de arquivo perfeitamente plausíveis, o que, segundo o relatório posterior, "deu à lista uma credibilidade que ela não merecia". O sexto participante abriu o diff. A primeira linha do diff dizia, em inglês, que o modo do arquivo havia passado de 100644 para 100755. A segunda linha dizia a mesma coisa sobre outro arquivo. Havia outras oitenta e nove.

"Ninguém lê a primeira linha do diff", explicou um dos envolvidos, que pediu para não ser identificado e que, de fato, não será. "A primeira linha do diff nunca é importante. Só que quando as noventa e uma primeiras linhas estão dizendo a mesma coisa, alguma coisa está dizendo alguma coisa."

O diagnóstico técnico é banal e por isso mesmo constrangedor: o diretório de trabalho ficava num volume compartilhado que responde a mesma permissão para todo arquivo, inclusive para os que nunca precisaram ser executáveis. O sistema de arquivos não distingue o que é executável; quem distingue é a ferramenta de versionamento — e ela distingue errado quando decide confiar no volume em vez de no índice.

O momento de maior risco da manhã não foi o alarme, e sim a proposta apresentada às 10h40 de "reverter as alterações e ver no que dá". Se tivesse sido aceita, o comando teria reescrito noventa e um arquivos que nunca mudaram de conteúdo, para consertar um problema de permissão que existia apenas na cabeça do programa. A proposta foi retirada por falta de apoio e por excesso de bom senso, nessa ordem.

A correção que resolveu o caso tem uma linha, altera uma configuração local e não toca em nenhum arquivo do projeto. Ela foi colada no chat às 11h12 por alguém que, segundo testemunhas, não estava na reunião por estar ocupado trabalhando. Na página interna que documentava o problema desde 2019, a última edição resumia a situação com uma frase que a equipe decidiu manter como está: "isso vai acontecer de novo".

Ao fim do dia, os noventa e um arquivos seguiam intactos, a correção ocupava uma linha e a ata registrava uma decisão: revisar o processo de revisão. O comitê responsável por essa revisão foi criado no mesmo dia e já marcou a primeira reunião — que, segundo a pauta preliminar, vai começar pela lista de arquivos.

---

Esta é uma matéria de sátira. Personagens, empresas, números e a hora exata do chat são inventados. Se você já convocou uma reunião por causa de um git status que estava certo, o problema é do seu volume compartilhado.