Development covered 11 Aug 2026 to 15 Aug 2026 (commit dates).
This stretch was almost entirely the tie in novel rather than the game. The series covers a book per realm, and volume one alone is long enough that nobody is holding it in their head. So the writing runs as a pipeline, unattended, for hours at a time.
A pipeline like that has two products, and I had only been watching one.
The output is not the state
The obvious product is chapters. The other one is everything the pipeline remembers between chapters: which threads are open, who knows what, which promises the book has made and not yet kept. That running record is what makes chapter 300 agree with chapter 40. It is not delivered to anyone. It exists so the next run is not starting from nothing.
I found out that my revision step rewrites that record every time it runs. Not corrupts, rewrites: it reconstructs the state from its own reading and puts that back. Measured on one book, the record of open threads came back missing about four fifths of its entries. A separate step could truncate it to nothing at all.
None of this showed up in the chapters. The prose was fine. It would have kept being fine for a while, and then, thirty chapters later, the book would have quietly stopped honouring a promise it made in the second volume, and I would have gone looking for that in the writing. The story it has to keep straight is the game's story too, down to single quests such as Settling Karma.
What made it findable
I only caught it because I started checking the state before and after a run instead of reading the output. That sounds like something you would obviously do. In practice it is not obvious at all, because the state is intermediate, it has no reader, and every instinct says the thing to inspect is the thing you are shipping.
The rule I now work by: if a long job carries state between steps, that state is a first class artifact. Snapshot it before a destructive step, compare after, restore when the comparison fails, and assert on it in its own right. Do not infer its health from the output, because output quality degrades far later and far more gradually than state does.
A related trap, in the checking layer
The same week produced a version of this in the repair path. I had a step that takes an identified problem, edits the text, and reports success. Reporting success is not evidence, so I added two assertions: the thing you were asked to remove must be gone, and everything you were not asked to touch must still be there.
The first assertion had a flaw that made it always pass. Its pattern was allowed to end on whitespace, which meant it could never match what it was looking for, which meant it never fired. An assertion that cannot fail is worse than no assertion, because it makes a report of success look checked.
The second assertion, the one about not touching anything else, turned out to be the more valuable half. A repair step will happily fix the sentence you named and rewrite the paragraph around it.
The parallel version of every bug
The last thing I did here was let several arcs be written at once. That surfaced five separate defects that simply do not exist in a single stream, the most instructive being two runs racing for the same write with no single instance check between them.
Concurrency did not create those bugs. It removed the accidental serialization that had been hiding them, which is roughly what it always does. The people whose knowledge that running record tracks include figures like Zhou Ming, who also appear in the game.
Everything here ships in Idle Cultivation RPG; read the story and play it free in the browser.
Top comments (0)