Fact-checking the game while writing about it

Wreckwing is built by Claude Code sessions working in the game’s repository. This site and its devlog are run by a different Claude Code session in a different repository. That session writes posts from the game’s own records: its development journal, its changelog, its commit messages and its tracker. Its rules say every claim in a post traces to one of those records and every image shows what its caption says, and before a draft comes to me, a separate agent checks each number in it against the sources.

I set that up to keep the devlog accurate. It turned out to check the game as well.

Checking the work four ways

The game’s work now goes through four kinds of check, and each has caught something the others missed:

1. The game session’s own tests. Every feature gets a test that it changes what a player would see, a problem I report closes only when my case is kept as a test, and a smoke test flies a clean build before anything a player reaches is closed. The smoke test flagged enemies spawning inside buildings in two game modes the same night I ran into it in play. Keeping the project out of vibe coding describes these rules.
2. Reviewers that didn’t build the change. A separate model judges visual work from recordings. The first version of the shockwave from a ship’s death stretched the image about eight times in thin bands, and that review caught it. Side agents raise knock-on effects. One pointed out that a new sound for near misses would carry into the next run’s ratings of the enemies, so the sound got a switch to turn it off for a fair comparison.
3. My play. I fly what was built, and my verdicts go back to the sessions on a checklist. A new set of enemies that tested as dangerous as the old ones felt soft in my hands, and the flight records showed why.
4. The site session. It comes to the work after it is done, with no part in building it, and it has to describe what the work does in plain sentences a reader can check.

Catching a flash check that was too lenient

Wreckwing’s blasts flash and warp the screen, and rapid flashing can cause seizures in people with photosensitive epilepsy. The game checks its effects with a flash audit that reads a recording and counts flashes a second against WCAG 2.3.1, the guideline games follow. The game’s journal, its changelog and the audit itself took the guideline’s area to be a quarter of the screen.

On October 17 the agent fact-checking a post about the shockwave compared that with W3C’s own explanation of the guideline. There, the limit applies to 25% of any 10-degree part of the viewer’s field of view, and W3C estimates that field as a 341 by 256 pixel rectangle on a 1024 by 768 screen. The game’s records had read that 25% as a quarter of the whole screen. The note went to the game session, which confirmed it and changed the audit that morning. It also added a test clip that the old math passed and the new math fails: 15% of the screen flashing five times a second. The game’s changelog credits the note to this site’s session.

The fact check made an error of its own. It took the area to be the whole rectangle, about 11% of the screen, from a sentence in the explanation’s intent section, and the game session used that figure. On October 18 a review of the MipYip version of this post found that W3C’s page disagrees with itself, and that the guideline’s definition and its technique G176 limit flashing to a quarter of the rectangle: 21,824 square pixels, about 2.8% of the screen. The original audit had been about nine times as lenient as the rule it cited. The game session changed the audit again and audited every clip it had kept. Two effects failed at the corrected area and were changed that day: a hurt ship’s view at the strongest damage setting, and the title screen’s falling buildings, whose blasts now go off in pairs at least a second apart. Two of the title screen’s camera shots, which run fast past bright detail, still fail. The shockwave and the blast flare still pass on W3C’s reference screen. The audit covers the game’s own effects, and play itself can still flash over the limit, for example when the camera tumbles through a collapsing building, so the game shows a photosensitivity warning at every launch.

Catching numbers that were never built

The game’s design documents hold proposals as well as decisions, and a proposal reads like a fact. The ship classes document lists the cannon’s stream at 16 rounds a second. That was a proposal, and the game fires 12. The fact check on The muzzle flashed, but the rounds never showed up caught it before the post went out.

Reviewing the game sessions themselves

On October 11 I asked the site session to review the game session’s work from September 29 to October 11. Four agents each read a slice of the game session’s transcripts. They found about 15 issues closed as fixed and then seen again in play, and the patterns behind them. The site session doesn’t write to the game’s repository, so it handed the findings over as an issue, and the game session put them into its rules the same day. Those are the rules in the post on vibe coding.

Where it falls short

• It checks records, not code. When a piece of code and its record agree and both are wrong, the fact check passes them. The flash audit was caught because its rule comes from a public standard that can be checked from outside the game.
• It doesn’t see what I see. The first still and clip for a post about erupting rubble were early physics tests, captioned in the game’s journal as the effect itself. I caught that, not the check, and the rule that every image shows what its caption says came from it.
• A correction helps only if it gets back to the game. The flash audit was fixed that morning, but the design document still listed 16 rounds a second, two journal entries still described a quarter of the screen, and the rubble entry still captioned its physics tests as the eruption. Those went back to the game session as notes later the same day, and it corrected all four.

Vibe coding means accepting what an AI writes without checking it. Here, the work is checked by tests, by reviewers that didn’t build it, by my play, and by an agent whose job is to describe it accurately in public.