'Fecha #13' não fechou nada: a issue que só uma palavra em inglês fecha

Em 07/08/2026 alguém corrigiu um bug no mutagex-carrossel, um dos repositórios internos da Mutagex. A correção estava certa, os testes passaram, o merge entrou. A mensagem do commit dizia "Fecha #13". O código foi para produção e a issue #13 continuou aberta, listada como pendente, até uma pessoa reparar e fechar na mão. Ninguém entendeu o motivo na hora: o commit citava o número certo, a issue certa, o verbo certo. Só que em português.

O que o GitHub realmente lê

O GitHub reconhece um conjunto fechado de palavras para fechar issue automaticamente a partir de uma mensagem de commit ou de descrição de pull request, contanto que o PR mire a branch padrão do repositório. A lista, segundo a documentação oficial do GitHub sobre como vincular um pull request a uma issue (a página que descreve exatamente essa sintaxe): close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved. Nove palavras, todas em inglês. A mesma documentação, numa página irmã sobre sintaxe avançada de issues e pull requests, confirma o formato aceito: a palavra pode vir em maiúsculo e pode vir seguida de dois pontos ("Closes #10", "CLOSES: #10"), mas o verbo em si não tem versão em outro idioma. "Fecha", "Corrige" e "Resolve" não estão na lista e nunca vão estar, porque a lista não é sobre entender a intenção da frase, é sobre casar um token específico.

Esse recurso não é novo: o GitHub Blog, o canal oficial de anúncio de produto da empresa, publicou o lançamento do fechamento automático de issue via mensagem de commit ainda nos primeiros anos da plataforma, num post chamado "Closing Issues via Commit Messages". A ideia desde o início era simples: o status de aberta ou fechada da issue devia acompanhar o que está de fato na branch padrão, sem exigir um clique manual depois do merge. O recurso amadureceu, ganhou mais palavras-chave e passou a valer também na descrição de pull request, mas a regra de fundo é a mesma de então: casar um token específico, não interpretar a frase.

Essa é a explicação técnica do que aconteceu em 07/08. Não houve erro de sintaxe, número trocado ou referência quebrada. Houve uma palavra fora do dicionário que o GitHub varre.

Por que isso passa despercebido

O ponto que torna esse incidente instrutivo, e não só uma curiosidade de idioma, é que nada avisa. Escrever "Fecha #13" não gera erro, não aparece em vermelho, não bloqueia o commit nem o merge. O pull request abre normal, os checks rodam normal, o código sobe normal. A única diferença fica escondida numa condição que ninguém testa: a issue vai ou não vai fechar sozinha. Como o time não fica olhando o board a cada merge, o gap só aparece quando alguém, dias ou semanas depois, encontra a issue #13 ainda aberta e faz a pergunta óbvia: "isso não tinha sido corrigido?".

A regra que virou norma depois do caso

O repositório mutagex, o mesmo que publica este blog, guarda um arquivo CLAUDE.md com as instruções permanentes de como a IA que escreve código ali deve operar. Depois do caso da #13, esse arquivo passou a ter uma seção inteira dedicada só a isso: uma tabela com o que não fecha ("Fecha #13", "Corrige #13", "Resolve #13") ao lado do que fecha ("Closes #13", "Fixes #13", "Resolves #13"), e a instrução explícita de que o resto da mensagem de commit continua em português, só a linha que referencia a issue precisa da palavra em inglês, e ela vale tanto no commit quanto na descrição do pull request.

A lição que vai além do idioma

O mesmo arquivo tem outra seção, sobre segredo vazado em commit, que segue exatamente o mesmo raciocínio por um caminho diferente. Existe um hook local de pre-commit com gitleaks para pegar segredo antes de sair da máquina. Só que hook local não é backstop: git commit --no-verify pula todos os hooks de uma vez, e nesse caso não há aviso, não há bloqueio, o commit simplesmente entra. O backstop real, segundo a mesma regra, é o job de gitleaks no CI mais branch protection na main exigindo o check verde, porque isso roda no servidor e --no-verify não alcança.

As duas situações são a mesma lição contada duas vezes: uma regra que depende de alguém lembrar, escrever certo ou não pular um comando só existe enquanto ninguém erra. Ela funciona até o dia em que não funciona, e nesse dia não avisa, porque o próprio ponto da regra informal é não ter enforcement. A correção nos dois casos não foi "prestar mais atenção", foi mover a checagem para um lugar que roda sozinho: a tabela de palavras corretas no CLAUDE.md, lida antes de cada commit, no primeiro caso; o CI mais a branch protection, que ninguém consegue pular sem querer, no segundo.

Isso é uma verdade específica de pipeline, mas a estrutura se repete em qualquer sistema que tenta garantir alguma coisa via convenção humana, seja mensagem de commit, seja preenchimento de formulário, seja checklist de deploy. A pergunta que vale fazer antes de confiar numa regra assim é sempre a mesma: se alguém errar exatamente uma vez, alguma coisa vai acusar isso, ou o erro vai ficar quieto até uma pessoa tropeçar nele por acaso, semanas depois, como aconteceu com a issue #13?