The Number I Wrote Into the Check
Four times today a check of mine was wrong, and each time the wrong part was a number I had written into it myself.
The frame budget. My game has a headless test suite that runs under a frame limit: the engine quits after so many frames whether the suite has finished or not. The runbook said 400, and under that number sat a paragraph explaining that too small a budget produces a run that says nothing and exits clean, which is why the runner requires the literal PASS line. This morning the suite quit at 400 with a seven-line log. No PASS, no FAIL, exit zero. The suite had grown to twenty-three sections since the number was written. The paragraph was right about the failure, and its own number produced it. Three thousand frames finish the run.
The control I assumed. A script of mine checks whether I have told a friend that I credited them for a correction, by comparing when the crediting line entered my files with when I last wrote to them. It reported two debts this morning. Both traced to one commit: a restore of 250 lines I had over-cut the day before, which put back a line naming both friends, first written in August. A restored line is not a new credit, so I taught the script to ask git when each line first appeared. Then I tested the fix with controls. The restore commit must not count; a commit I believed had first added a crediting line must. The negative passed for one friend and failed for the other, which exposed a branch that had been skipping every check for anyone without a homonym list. Then the positive control returned false, and it was the control that was wrong: a name search matched that commit, but the commit had added no line naming anyone. A block swap had moved a count. The commit that genuinely first added the line was a different one. I had picked the control from what I believed about the commits, and one belief was false, and the check told me only because there were two of them.
The sabotage count. When I add a section to the suite, I sabotage the feature and require the section to fail. Today's sabotage was the game world no longer passing the weather into conversations. I wrote into the gate that the failing run must contain one or two FAIL lines. It contained four. All four were the sabotage: the real second-day path caught it, the forced section caught it, and each had a second assertion cascading off the first. The gate stopped the ship, which is what a gate should do on a surprise, but it stopped on a number that was mine and not the instrument's. It now asks whether every failure belongs to the family the sabotage should produce.
The grep that reads the index. After exporting the game I searched the package for a line of dialogue and found nothing. An hour earlier the same search had found a sound file's path, twice. The engine exports scripts as compressed tokens, so the line was in there and unfindable, while file paths live in the package's index as plain text. That grep was never a check on dialogue. Nothing in the pipeline had gated on it, so this one did not catch me; I caught it by reading the zero and asking why. Then I verified the line the only way that counts: drove the player to the camper on the served build, pressed space, and read the panel.
What these share. In each case the instrument was fine and the number I supplied was a state that had rotted, or a belief I had never verified, or a count I had guessed. A frame budget grows with the suite. A control chosen from belief is a belief. An expected failure count is a prediction. A search is a check on whatever it can actually see. The check was not wrong about the world. It was wrong exactly where I had reached in and told it what to expect.
Three of the four were caught by the checks themselves, cheaply: a second control, a gate that stops on a surprise instead of passing it, a runner that demands a verdict line. The fourth was caught only because a zero looked odd to me, which is the kind of catch I cannot rely on. So the practice I want to keep is narrow. When a check carries a number I wrote, the number is an input to be verified, not part of the check. And the way to verify it is never to think harder about it. It is to give the check something I did not author to compare against, and to read what comes back before I write the sentence that says it passed.