Trimming the loop

The grader was in the very first prompt. Right after the 8.5 I wrote that Claude might use “the /create-loop architecture to build independent verification sub-agents, but you decide what’s appropriate.” Eleven days later I cut it down.

The rule has not changed since Sunday the 27th: whoever writes the work never grades it. Claude builds, and other Claude agents that start cold score the result against criteria written before the work began. Claude writes the criteria, I approve the plan, and a failed grade comes to me.

The first graders

In the quality rounds of the first three days, one fresh Sonnet reviewer scored each of 11 areas, for 12 rounds. They found real problems. From round 4 on the average moved within about 0.3 each round while the real gain was worth 0.1 to 0.3, so a better game and a different reviewer looked the same. Round 1’s economy reviewer missed the job board entirely and scored the area 3.5. Round 12’s battle reviewer said Rook’s body “does not shift one pixel” across four swing shots when a pixel diff showed it moves 15.

None of them played the game. They read screenshots a script had staged. On the 29th I asked, “Are we making effective progress? We’re not just going in circles?”, and the exit became my own playthrough.

Pass lines first

On Sunday the 4th, with the new engine’s plan on the table, I asked: “Make sure independent self-verification loops with reasonable rubrics are part of your implementation plan.” I approved the result on the 5th: three fresh verifiers per step, each with its own lens. A step passes only if every hard pass line holds, every criterion’s median is 7 or better and the average is 8 or better. After three failed rounds it stops and brings me the evidence.

The 640x360 move is the first big job under it. Claude committed the pass lines on the 6th, before any code, and one of them says every 480x270 picture must come out identical after the first refactor. The baseline had to be stable first. Two runs of the same build differed in 56 of 72 shots (rain and water move, and a seed came from the clock), so Claude built a capture on a paused clock. Three runs now match byte for byte.

The first step passed on the 7th with an average of 8.31. It still came back with a bare 2 in the battle renderer where a size constant belonged, and a pixel-diff tool that reported success when both folders were empty.

Where it stopped

WP3 is the field, the maps and the cutscenes. It ran three rounds of three verifiers today, two on Haiku and one on Sonnet, and every round failed. Round 1 averaged 7.85 against the gate of 8. Round 2 averaged 8.08, but performance had a median of 6. CI was red because a slow runner read 8.79 ms for the software field mean against a gate of 8 (the rerun passed at 5.82). Round 3 averaged 7.77, with performance and code clarity at 6.5. The builder had loosened that speed gate to 10 ms, which the verifiers showed would now catch a 5 ms slowdown by only 0.8 ms.

At the cap I accepted WP3 with named fixes, made in the first commit of the next package and checked there. No fourth round.

What I changed

After that I set the lean loop, and Claude wrote it into CLAUDE.md. Code gets two fresh verifiers, one that runs the touched tests and makes the pictures and one that reads the diff, and docs get one. A step passes when no Critical or Important finding is open, and the scores stay as evidence only. A minor finding waits for the next commit.

The repo’s note gives the reason: the last two packages of the 640x360 move took 5 builder runs and 15 verifier runs. Most of the failed rounds came from records or CI noise, not defects.

PR #39 with the rule is merged. The next two packages, both screen layout, will be the first to run under it, as one build and one round.