A check that finds nothing to check will tell you everything is fine

On 19 September 2026 I spent an afternoon tidying folders, and by the evening four separate things had broken without a single red light.

The job looked harmless. Every VALORAE site lived in one flat projects folder. I moved each one into a folder for its brand.

Nothing errored. That was the problem.

Here is the complication in one line. Every automated check I had built to protect those sites kept passing, because every one of them was now checking an empty room.

Failure 1: the build that shipped nothing

The blog engine that builds all six VALORAE blogs reads a config file per site. Each config says where to write the finished pages.

Those paths still pointed at the old folder.

So the build ran, reported success and wrote a complete, fresh copy of every blog into a location that no longer belonged to any site. The real site folders never changed. Nothing I published that afternoon would have gone live.

A build that succeeds into the wrong place looks exactly like a build that succeeds.

Failure 2: the gate that checked zero files

Before any deploy, a script checks every page against a size budget. It exists because a page that is too heavy can be cut off by a crawler.

Its list of folders was also stale.

It searched the old paths, matched zero files, found zero pages over budget and printed that the byte budget was fine.

Read that again. The safety gate on every deploy passed by inspecting nothing.

This is the one that still bothers me. I wrote that check. I trusted it. It had never failed, and I had taken that as proof it worked.

Failure 3: the monitor that swept an empty floor

A scheduled job reads platform policy changes each day and searches the blog content for any post that quotes the affected rule.

Its search path pointed at the old content folder.

Every day it would have found no matching posts, and every day it would have reported that no pages were affected. A clean sweep of an empty floor. I found it on 20 September, the day after the move.

Three different tools, one shape. Each one was built to say "no problems found", and none of them was built to say "I found nothing to look at".

Failure 4: the move that deleted what it was moving

The fourth one was not a false pass. It was worse.

The disk those folders live on is case-insensitive. To the file system, a folder name in capitals and the same name in lower case are the same folder.

My script created a new brand folder whose name differed from an existing site folder only in its capital letters. Then it moved the site folder into it.

Python's documentation for shutil.move says that when a plain rename does not work, it falls back to copying the source to the destination and then removing the source.

On that disk, the destination pointed back at the source itself. The copy step did not produce a separate copy. The remove step deleted the working folder.

There was no backup configured on that machine that day. That folder was gone.

I am not going to dress that up. It was a preventable loss caused by a script I wrote to save ten minutes of dragging folders.

Why green is the dangerous colour

Green is not proof.

Every one of those tools had the same design. It looked for problems, and when it found none it said so. That is a sensible design right up until the thing it looks at goes missing.

A red check gets attention. Somebody opens the log, reads the error and fixes it. A green check gets ignored, which is the whole point of it, and which is exactly why a broken green check can sit there for weeks.

I had built three checks that could only ever fail in one direction. They could tell me a page was too heavy. They could not tell me there were no pages. And because they had never been red, I read their silence as quality.

The uncomfortable part is that nothing about this is specific to code. A weekly report that says "no complaints this week" has the same flaw if nobody checked the inbox.

Rule 1: a check must prove it looked

Green means nothing unless the check says how much it saw.

The rule I am applying to every gate: print a count of what it inspected, and fail if that count is zero. Where there is a known floor, such as the number of blog posts that exist, fail below the floor too.

A size check that inspected zero pages is not a pass. It is a broken check wearing a pass.

Rule 2: after a move, search for the old path first

Before running anything after a reorganisation, I now search every script, config file and scheduled task for the old folder name.

Every hit is a tool that will quietly run against nothing.

This takes a minute. It would have caught three of the four failures above before any of them ran.

Rule 3: compare names the way the disk does

On a case-insensitive disk, two names that differ only by capitals are one name.

So any script that moves or creates folders should compare names in lower case against what already exists, and refuse to run if two collide. A rename guarded by a check that the source and destination are not the same folder is safer than a move that can quietly fall back to copy-then-delete.

Rule 4: have a backup before you tidy

The cheapest fix is the one I skipped.

Tidying is the moment you are most likely to destroy something, because it feels like the moment you are least likely to. A backup costs less than the smallest thing I lost.

The group corrects its public pages in the open, and there is a whole policy for how a VALORAE page gets corrected. This post is the internal version of the same idea: say what broke, say why, and change the process so it cannot break the same way twice.

The short version

• Moving folders breaks every hardcoded path, silently.
• A check that inspects zero files will report success.
• Make every gate print what it counted, and fail on zero.
• After a move, search for the old path before running anything.
• On a case-insensitive disk, compare names in lower case before moving.
• Back up before you tidy, not after.

More operator notes like this live at tgsidd.com.