Gittifacts: Evidence-Based Auto-Merge for Agent Code

Five independent teams converged on the same governance pattern this cycle: approve intent before code exists, verify conformance with machine-generated evidence, enforce routing with deterministic gates. Jovi De Croock’s Gittifacts is the most complete working implementation. It is open source, runs on Cloudflare, and was built by agents following the same workflow it enforces.

The pattern matters more than the tool. What Gittifacts makes concrete is a set of constraints that any team running agents against production repositories will eventually need.

The Unit of Work Is Not a Pull Request

Pull requests assume a human wrote the diff, so a human should read the diff. When an agent writes 500 lines in minutes, that assumption creates a queue nobody wants to process. Teams either read every line and become the bottleneck, or they skim and rubber-stamp.

Gittifacts replaces the pull request with a Change: intent plus diff plus evidence. A human approves a Plan (an intent statement with acceptance criteria and scope) before any code is written. The agent then works in an isolated fork with a push token scoped to that fork only. No agent can push to main. No shared branches exist to race on.

The separation is sharp. Human attention goes to the Plan, where it has the highest leverage. Machine cycles go to proving the code conforms to that Plan.

The Evidence Pipeline

Every push triggers CI and then a set of evidence steps on top of it: red/green proof for fixes (the new test fails on the base commit, passes on the head), coverage and mutation score on changed lines, a public API diff, a dependency diff, hits on sensitive paths, a preview deploy. The platform signs each result and stores it as a git note on the head commit.

Evidence generation took 13 to 17 minutes per Change on the Gittifacts repository itself. That cost is real, and pre-existing test failures pushed every Change into the most expensive review lane. The trade-off is explicit: you pay in CI minutes to avoid paying in human review hours on code an agent wrote.

Deterministic Lane Routing

A pure function takes the evidence, the repository policy, and the approved Plan, then returns a lane:

• Auto-merge (Lane 0): everything is proven, nothing is risky.
• Quick review (Lane 1): additive API, moderate size, some optional evidence missing.
• Full review (Lane 2): breaking API, auth or migrations, new dependencies, scope drift, a fix without proof.

The classifier is a pure function with table tests and no I/O or clock. You can read why a Change landed where it did. Unknown or errored signals can only raise the lane, never lower it. An LLM judgment is allowed to push a Change from Quick review to Full review, never the reverse. A reviewer agent that runs out of budget escalates the Change.

This is the design choice that makes the system trustworthy: the cheapest path requires the strongest evidence. Uncertainty always costs more scrutiny.

The Approval Firewall

Nobody approves their own work. No human, no agent. Agents cannot approve anything at all. The platform reads policy from the default branch, so a Change cannot loosen the rules it is judged by.

Every commit the merge queue lands gets a signed refs/notes/why note containing the approved intent, who approved it, which agent wrote the code, and which human is accountable for that agent. The audit trail is in git itself, not in a SaaS dashboard that can be edited or deleted.

Reversibility Makes Auto-Merge Acceptable

Merged Changes ship behind their own feature flag with a gradual deployment. If errors increase, the platform switches the flag off, rolls back, and opens a revert Change. Auto-merge only makes sense because every Change sits behind its own flag and the platform can attribute a regression to a single Change.

Without attribution and instant rollback, auto-merge would be reckless. With them, it is the cheapest review that is still safe.

Self-Hosting as Proof

De Croock put Gittifacts on Gittifacts: imported the repository into the live platform, ran six Changes through it, reviewed them, and let the merge queue land them. That exercise produced five platform fixes, four of which were blockers that only a repository of that size could surface. The project’s DECISIONS.md file now exceeds 3,500 lines of dated decisions recording every judgment call the agents made during development.

Self-hosting is the strongest form of dogfooding. The platform governed its own construction, and the failures it found were structural, not cosmetic.

What This Means for Your Pipeline

The Gittifacts architecture is not a product recommendation. It is a reference design for three constraints every agent-governed repository needs:

1. Intent approval before code generation, so human attention goes where it has the highest return.
2. Evidence-based lane routing, so the review cost is proportional to the risk the evidence cannot cover.
3. A signed audit trail in git, so accountability survives the tool that produced the merge.
4. Reversibility by default, so auto-merge is a safety decision, not a speed decision.

If your agents write code today, pick the constraint you are missing and build it this quarter. The pattern is converging. The teams that wait for a vendor to ship it will spend their first incident explaining why they had no governance at all.

---

This analysis synthesizes Gittifacts (Jovi De Croock, October 2026).

Victorino Group helps teams build governance into their agent pipelines before the first incident forces it. Let’s talk.