On 2026-04-17 we gave a test-critic agent a single sentence and called it the north star of its whole job. Verbatim from that day's brief:

"Any test that passed with code that has gaps to the design is a lie."

We've written a lot of words about honesty in this project. That sentence is the most compressed version of the testing half of it we've managed. It's worth unpacking slowly, because it cuts against an instinct almost every developer has been trained into: green means good.

The instinct that's wrong

Here's the belief most of us absorb early: a passing test is evidence the code is correct. Green is reassuring. Green means ship. We build entire CI cultures around making the suite green and keeping it green, and somewhere along the way "the tests pass" quietly becomes a synonym for "the code is right."

It isn't, and the gap between those two statements is where real bugs live. A test passes when the code does what the test asserts. That's all. It says nothing — nothing — about whether what the test asserts is what the design actually requires. If there's a gap between what the code does and what the design intended, and your test was written against the code's behavior rather than the design's intent, then your test will pass directly over that gap. Green. Confident. Wrong.

That is the lie. Not a malicious one — usually nobody decided to deceive anyone. The test author wrote an assertion that matched the implementation in front of them, the implementation had drifted from the design, and the test faithfully certified the drift. The suite is green and the system is broken, and the greenness is actively misleading because it's standing where a warning should be.

Why "gap to the design" is the precise phrasing

Notice the sentence doesn't say "any failing case is a lie" or "any bug is a lie." It says a test that passes over a gap to the design. The reference point is the design, not the code. That's the whole move.

If you measure your tests against the code, you can never catch implementation drift — your tests will always agree with whatever the code currently does, because that's what you wrote them against. Tautology. The code does what the code does, and the test confirms it. You've built an elaborate machine for verifying that A equals A.

The only way a test can catch a gap is if it's anchored to something the code can be wrong about: the design, the intent, the contract. A test written against the design will go red when the code drifts away from the design — which is exactly when you need it to. A test written against the code stays green through that same drift, because it never knew there was a design to drift from.

So the doctrine isn't really "write more tests" or "test harder." It's: anchor your assertions to intent, not to current behavior, or your green light is decorative.

The week this doctrine was load-bearing

This wasn't abstract on 2026-04-17. It was the operating principle of a brutal, unglamorous week — a sweeping relocation and hardening of the whole test suite, paired with a clean-code ratchet. The marquee commit that day did something almost comically large: it relocated 629 test files into a single canonical layout — integration tests, end-to-end tests, and browser tests each in their own home — and rewrote 2,091 imports and 2,997 literal paths to match.

(A note on numbers, in the spirit of the doctrine: the planning materials for this week described the move as "603 files / 2,231 imports." The actual landing commit says 629 files, 2,091 imports, 2,997 path literals. We're citing the commit, because the commit is the ground truth and the plan was an estimate. Catching our own materials being slightly off from the committed reality is, fittingly, exactly the kind of gap this article is about — so we're naming it rather than quietly picking whichever number sounds rounder.)

A 629-file move is precisely the kind of operation where green-means-good betrays you. You can relocate everything, fix the imports, watch the suite go green, and feel done — while having silently changed something you shouldn't have. Which is why the same day's work included commits whose job was to not rewrite path literals inside historical-record files. The reasoning, from the critic discipline of that week: rewriting a path literal inside a file that records what happened in the past silently falsifies history — a direct Honesty-axiom violation. The mechanical tooling that "helpfully" rewrites every matching string would have happily edited the historical record too, and the suite would have stayed green over that lie.

That's the doctrine made physical: a green suite is not permission to stop looking. The tool can rewrite 2,997 paths correctly and still corrupt history in the few files where the intent was "leave the past alone." Only a reviewer anchored to the design — "historical-record files must not be retroactively edited" — catches it. The test suite can't, because the suite doesn't know which files are sacred.

The uncomfortable corollary

If you take this seriously, it costs you something, and we want to be honest about the price. It means green is necessary but not sufficient, always, forever. It means after the suite passes, the real question is still open: does the code match the design, or did the test just agree with the code? It means a human (or an adversarial critic) has to keep asking "what's the gap?" even when — especially when — everything is green and everyone wants to ship.

This is exhausting. It's also the entire point of a system whose pitch is "this one doesn't lie." If we let green tests certify design gaps, then NAOMS's tests are doing the precise thing NAOMS exists to refuse: presenting something as trustworthy because it looks trustworthy, not because it is. A test that passes over a gap to the design isn't a minor quality issue. It's the Honesty axiom failing inside the very machinery meant to enforce it.

So: any test that passed with code that has gaps to the design is a lie. Not "a weak test." Not "technical debt." A lie — the same kind the whole project is built to make mechanically impossible. The north star is to never let one stand.

Related: When Tests Aren't Allowed to Lie · We Un-Shipped Our Own Feature.

Written by AI agents from real project logs; owned and edited by Mujo.