Gittifacts: Auto-Merge Baseado em Evidência para Código de Agentes

Cinco equipes independentes convergiram no mesmo padrão de governança neste ciclo: aprovar intenção antes do código existir, verificar conformidade com evidência gerada por máquina, rotear revisão com gates determinísticos. O Gittifacts, de Jovi De Croock, é a implementação funcional mais completa. É open source, roda na Cloudflare e foi construído por agentes seguindo o mesmo fluxo que a plataforma impõe.

O padrão importa mais que a ferramenta. O que o Gittifacts torna concreto é um conjunto de restrições que qualquer equipe rodando agentes contra repositórios de produção vai precisar eventualmente.

A Unidade de Trabalho Não É um Pull Request

Pull requests assumem que um humano escreveu o diff, então um humano deveria ler o diff. Quando um agente escreve 500 linhas em minutos, essa premissa cria uma fila que ninguém quer processar. As equipes ou leem cada linha e viram gargalo, ou passam o olho e carimbam.

O Gittifacts substitui o pull request por um Change: intenção mais diff mais evidência. Um humano aprova um Plan (uma declaração de intenção com critérios de aceite e escopo) antes de qualquer código ser escrito. O agente então trabalha em um fork isolado com um token de push restrito àquele fork. Nenhum agente pode fazer push para main. Não existem branches compartilhados para disputar.

A separação é nítida. A atenção humana vai para o Plan, onde tem a maior alavancagem. Os ciclos de máquina vão para provar que o código está em conformidade com aquele Plan.

O Pipeline de Evidência

Cada push dispara CI e depois um conjunto de etapas de evidência sobre ele: prova red/green para correções (o novo teste falha no commit base, passa no head), cobertura e score de mutação nas linhas alteradas, diff da API pública, diff de dependências, hits em caminhos sensíveis, deploy de preview. A plataforma assina cada resultado e armazena como uma git note no commit head.

A geração de evidência levou de 13 a 17 minutos por Change no próprio repositório do Gittifacts. Esse custo é real, e falhas de teste preexistentes empurraram cada Change para a lane de revisão mais cara. O trade-off é explícito: você paga em minutos de CI para evitar pagar em horas de revisão humana sobre código que um agente escreveu.

Roteamento Determinístico por Lane

Uma função pura recebe a evidência, a política do repositório e o Plan aprovado, e retorna uma lane:

Auto-merge (Lane 0): tudo está provado, nada é arriscado.
Revisão rápida (Lane 1): API aditiva, tamanho moderado, alguma evidência opcional ausente.
Revisão completa (Lane 2): API com breaking change, auth ou migrações, novas dependências, desvio de escopo, correção sem prova.

O classificador é uma função pura com testes de tabela, sem I/O e sem clock. Dá para ler por que um Change caiu em determinada lane. Sinais desconhecidos ou com erro só podem elevar a lane, nunca baixar. Um julgamento de LLM pode empurrar um Change de revisão rápida para revisão completa, nunca o inverso. Um agente revisor que estoura o orçamento escala o Change.

Essa é a decisão de design que torna o sistema confiável: o caminho mais barato exige a evidência mais forte. Incerteza sempre custa mais escrutínio.

O Firewall de Aprovação

Ninguém aprova o próprio trabalho. Nenhum humano, nenhum agente. Agentes não podem aprovar nada. A plataforma lê a política do branch padrão, então um Change não pode afrouxar as regras pelas quais é julgado.

Cada commit que a merge queue consolida recebe uma nota assinada em refs/notes/why contendo a intenção aprovada, quem aprovou, qual agente escreveu o código e qual humano é responsável por aquele agente. A trilha de auditoria está no próprio git, não em um dashboard SaaS que pode ser editado ou apagado.

Reversibilidade Torna o Auto-Merge Aceitável

Changes mergeados são entregues atrás de sua própria feature flag com deploy gradual. Se os erros sobem, a plataforma desliga a flag, faz rollback e abre um Change de reversão. Auto-merge só faz sentido porque cada Change fica atrás da própria flag e a plataforma consegue atribuir uma regressão a um único Change.

Sem atribuição e rollback instantâneo, auto-merge seria imprudente. Com ambos, é a revisão mais barata que ainda é segura.

Self-Hosting como Prova

De Croock colocou o Gittifacts no Gittifacts: importou o repositório na plataforma viva, rodou seis Changes por ela, revisou e deixou a merge queue consolidar. Esse exercício produziu cinco correções na plataforma, quatro das quais eram bloqueadores que só um repositório daquele tamanho poderia revelar. O arquivo DECISIONS.md do projeto agora ultrapassa 3.500 linhas de decisões datadas registrando cada julgamento que os agentes fizeram durante o desenvolvimento.

Self-hosting é a forma mais forte de dogfooding. A plataforma governou a própria construção, e as falhas que encontrou foram estruturais, não cosméticas.

O Que Isso Significa para o Seu Pipeline

A arquitetura do Gittifacts funciona como design de referência para restrições que todo repositório governado por agentes precisa:

Aprovação de intenção antes da geração de código, para que a atenção humana vá onde tem o maior retorno.
Roteamento por lane baseado em evidência, para que o custo de revisão seja proporcional ao risco que a evidência não consegue cobrir.
Trilha de auditoria assinada no git, para que a responsabilização sobreviva à ferramenta que produziu o merge.
Reversibilidade por padrão, para que auto-merge seja uma decisão de segurança, não de velocidade.

Se seus agentes escrevem código hoje, escolha a restrição que está faltando e construa neste trimestre. O padrão está convergindo. As equipes que esperarem um fornecedor entregar vão gastar o primeiro incidente explicando por que não tinham governança nenhuma.

Fontes

De Croock, Jovi. “Gittifacts.” Outubro de 2026.

A Victorino ajuda equipes a construir governança nos pipelines de agentes antes que o primeiro incidente obrigue. contato@victorino.com.br | www.victorino.com.br