Verify passed code it never read

Verify is the part of Godmode+ that proves your code actually works before it lets the AI call a task done. It is the gap between I wrote the code and I watched the code run.

This week we pointed Godmode+ at its own source and told it to audit that very step. It found real bugs in its own verify phase, and the worst one let it pass code it never read.

🔎 What a verify step actually does

In plain terms, verify is a read-through plus a test-drive. It opens the files a task changed, gives them a quick read-through that catches broken code before you run it, and where it can, actually runs the thing to watch it behave.

That job has exactly two ways to fail. It must shout when something is genuinely broken, and it must never fake a pass when it simply could not check.

🪞 We aimed it at its own code

We audit code for a living, so we gave Godmode+ the same treatment we give client work: point it at itself and try to make it lie. Skipping the proving step is the AI's favourite shortcut, which we wrote about in why Claude Code skips the tests.

This was worse. Here the step ran and still lied. It found four real bugs in its own verify phase.

👻 The scary one: it passed a file it never opened

To decide what to check, verify asked git which files had changed. That question only returns files git already tracks, the ones you have committed or edited before.

A brand-new file you just created is invisible to that question. So verify would happily stamp PASS on a new file with a glaring syntax error, because it never opened it to look.

This is the headline bug, and it is the exact shape of a lie. Not a wrong answer, an answer given without looking.

🚨 It lied the other way, too

The same phase had the opposite bug. Its TypeScript check launched the checker in a way Windows refuses, so the checker crashed before it read a single line.

That silent crash got reported as “your code is broken.” Every TypeScript file threw a red X even when the code was perfect, a false alarm dressed up as a finding.

So one step could lie in both directions at once: a false pass on the file it skipped, and a false fail on the file it could not run.

⚖️ The one rule: never lie in either direction

Both bugs break the same rule. A verdict you can trust has to fail what is broken and pass what is clean, and when it genuinely cannot check, it has to say so out loud instead of guessing.

Version 2.7.2 makes that rule real. The TypeScript check now runs through your project's own installed compiler, the JavaScript check runs the code checker directly, and if a checker is not installed at all, verify skips that file with a stated reason instead of inventing a pass or a fail.

Here is that gate as a toy. Flip between the old and new verify, and click any file to break it or clean it. We have written before about forcing an honest verdict out of an AI in the verification run; this is the same fight, one layer down.

The old column lies in both directions. The new column fails what is broken, passes what is clean, and when it cannot check a file, it says skip and tells you why.

🐛 The two quieter bugs

The audit turned up two more that never made headlines but would ruin your afternoon. The first was two runs clobbering each other.

Godmode+ tracked “the current run” in one global spot, so running it in two projects at once let the second silently overwrite the first's progress. Now each project directory tracks its own run, and it keeps the 50 newest.

The second was old TODOs blocking forever. Its completeness scan flagged every leftover note already in your codebase, so a big existing project could never come back clean. Now the scan takes a snapshot at the start and only flags new notes you introduce during the task.

📦 What shipped in 2.7.2

A receipt, not a brag. Every bug was reproduced by hand, fixed, and re-tested before the version number moved.