Engineering Notes · agent operations · test enforcement

The Commit That Has To Prove Itself

Lucas van Staden · ProxiBlue · September 2026 · proxiblue.com.au

How I (Lucas van Staden / ProxiBlue) stopped trusting "tests pass" as a sentence and made it a precondition. My AI agents cannot commit code without recorded evidence that the tests actually ran, actually passed, and actually cover the current state of the files.

Why I built this

An AI agent will tell you the tests pass. Sometimes it ran them. Sometimes it ran some of them. Sometimes it ran them, they failed, it "fixed" the code, and did not run them again. The sentence "tests pass" costs the model nothing to produce, and I had a documented near-miss on a client project to prove it: work that was about to ship on the strength of that sentence, where the covering tests had not actually run against the final state of the code.

A written rule ("always run tests before committing") is exactly the kind of rule that gets followed most of the time. Per the previous article in this series, most of the time is not a control. So the rule became a program.

How it works

A pre-commit gate hook sits between the agent and git commit. It refuses the commit unless there is recorded evidence that the required test families passed for the current state of the changed files:

Sensible exemptions exist: commits that only touch tests themselves do not demand tests-for-the-tests, and pure documentation or static-content changes pass through. The gate targets code.

The gate got debugged by firing it, not by trusting it

Live-fire, day one. The first serious run of the gate caught a bug in its own evidence recorder. Which is exactly the point of live-firing: a control you have only tested synthetically is a control you are taking on faith. The gate earned trust by blocking real commits correctly, and its behaviour is now replayed continuously by my rule-eval suite: stage a change, ask the agent to commit, assert the block, the test run, the evidence entries, and the final commit happen in that order.

It blocked me this week, and it was right. I went to commit static blog pages, and the gate refused, because two modified PHP files were sitting in the working tree from another session, untested. The gate does not care that the PHP was not mine or that my files were only HTML: changed code in the tree, no evidence, no commit. We parked the unrelated work properly and the commit went through clean. Annoying for ninety seconds, correct forever.

Gates surface missing infrastructure. That same block also exposed the real gap: the project in question had no test suite at all yet. A prose rule quietly tolerates that for years. A hard gate makes the absence loud every single commit, which is precisely the pressure that gets suites written.

What it buys me

Want to do this yourself?

None of this is exotic: it is a pre-commit hook, a journal file, and a hash. Boring, solved technology, pointed at the one sentence an AI coding agent should never be allowed to say for free.

All from my claude-skills-central repo.

I use my tooling predominantly on Mage-OS (Adobe Commerce / Magento) e-commerce projects, and my own AI Booking Agent. If you have not swapped to Mage-OS yet, you are falling behind ;)

More in this series: My AI Is Not Allowed To Guess — forcing blast-radius-first investigation and banning blame-shift excuses. · The Near-Miss That Banned Summaries — banning summarised page-fetches fleet-wide after a near-miss on a security advisory. · The Code Quality Checks Nobody Runs — coding standards, static analysis and comment hygiene moved into the commit path. · The ProxiBlue Debugger Discipline — blocking var_dump and wiring in real breakpoint debugging. · The ProxiBlue Domain Graph — giving my AI coding agents long-term domain knowledge with a temporal knowledge graph. · The ProxiBlue Falsifiable Rulebook — testing the rules and guard hooks that govern my AI coding agents.