Traceroute devlog #6

This week I finally got to watch something run that had existed only as a paragraph in a planning document for months. An automated pipeline that generates a new puzzle on its own schedule, hands it to another AI acting strictly as a reviewer, and only after that review passes does it come to me for a final human approval before anything actually joins the game. The idea for this is one of the very first real decisions I made on this project, back before a single line of code existed. Watching it actually fire for the first time didn't feel like finishing a feature. It felt like closing a loop that had been open since day one.

　Getting there wasn't clean, and I don't want to pretend it was, because every failure on the way to it taught me something I wouldn't have thought to check otherwise. The first real run died because the reviewer's own explanation got cut off mid-sentence, since I'd capped how much it was allowed to write, and the code trying to read that half-finished answer as data just crashed the whole run instead of treating it as an ordinary rejection. I fixed that and ran it again, and this time nothing crashed, but nothing finished either. The loop responsible for trying again until it found a good enough puzzle had no outer limit on how long it was willing to keep trying at all, so it just kept going. I fixed that too, watched a full run actually complete in a few minutes, and hit a wall that had nothing to do with either AI in the chain. The automation had never actually been given permission to write anything to the repository, only to read it, so the step meant to open a pull request got flatly refused. Once that was granted, the very last failure wasn't code at all. It was an unrelated setting sitting in the repository itself that nobody had ever switched on.

　Four failures in a row, and by the end I wasn't really debugging an algorithm anymore, I was debugging a chain of permissions and limits that had nothing to do with puzzle generation. And then it just worked. A pull request opened on its own, with a short note attached explaining that one candidate had passed review and a few others hadn't, and I sat there for a second just looking at it load. That's the version of automation I wrote into this project's very first planning document, long before I understood how much plumbing actually sits underneath a sentence as short as "the pipeline reviews itself."

　The harder bug this week lived somewhere else entirely, in a place I couldn't blame on any single piece of code. A level that had never been cleared started showing up in the level list with a full score attached, as if someone had played it perfectly. The actual cause was a gap between three things that were each individually correct. The path-completion animation is deliberately slow, so the moment the game checks whether a board is solved happens a beat after the click, not during it. That gap was just long enough for a player to leave the level and load a different one before the check ever fired, and the check itself was asking about "whatever level happens to be loaded right now" instead of the specific level it was meant to judge. So a result meant for one level could land on whichever level happened to be sitting in memory once the delayed check finally ran. The save system made it worse to catch, quietly discarding any wrongly-attributed result that wasn't an improvement over what was already saved, so I had to manually clear a level's record just to make the bug visible again. Fixing it meant having every one of those delayed checks confirm, at the moment it actually runs, that it still belongs to the session it was created for.

　There's a smaller thing worth mentioning before I close this out. Partway through this week, I noticed I'd drifted back into editing files directly myself instead of writing the changes out as prompts the way the whole project had been run. It got pointed out, and things went back to how they were supposed to work. Not a clever fix, not really a bug at all.

　Looking back over everything since that first day buried in nothing but planning documents, unsure whether it even counted as progress since I hadn't written a single line of code yet, the through-line I keep landing on isn't any specific bug. It's how many times something that looked finished on paper needed a completely different kind of finished once a real player, or a real permission system, or a real API bill, actually touched it. Take the undo rule, which only worked once I tore it down and rebuilt the whole thing around itself. Or the two-way path feature, which passed every test I threw at it and still felt wrong the second an actual hand touched the mouse. The hint system took three separate redefinitions before it stopped being able to quietly wreck someone else's puzzle without me noticing. None of those were really failures. They were just the gap between what I meant and what I'd actually built, showing up one layer later than I expected, every time.

　I don't know yet whether I can actually sit in an interview and explain the solver the way I promised myself back in July that I would be able to. I think I probably can, at least the parts that matter: the pruning, the retry budget, why difficulty ended up measured off what the solver actually finds instead of what the generator happened to draw on its way there. What I'm more sure of is smaller than that. I built something end to end, broke it in ways I could trace, and fixed it in ways I could explain afterward without waving my hands. That's most of what I was actually trying to prove to myself back when I sat down with an empty document in July and didn't write a single line of code all day. This is the last entry. Not because the project itself is finished, there's still polish and documentation left to do, but because the thing this whole log was quietly tracking, whether I could carry something like this from a blank page to a thing that runs and mostly holds up, already happened somewhere back in these entries. I just didn't notice exactly which one.