Development covered 18 Aug 2026 to 22 Aug 2026 (commit dates).
Most rules worth having arrive after the thing they govern. You decide that every tunable value must be readable by the code that needs it, or that every craft key sold in a shop must open something, and then you discover the project breaks that rule in forty places, some of which will take a week to unpick.
There are three things you can do, and two of them do not work.
The two that do not work
Fix everything now and only then turn the rule on. This sounds principled and it means the rule ships in a month, or never, because the forty fixes touch systems you were not planning to open. In the meantime nothing stops violation forty one.
Make it a warning. A warning that appears on every run stops being read by the second week. I have done this to myself more than once and I no longer pretend otherwise.
The third one
Enumerate the violations you have, by name, and assert that the set only ever shrinks. Anything not on the list fails immediately. Anything on the list is a to-do with a test attached, and removing an entry is a small satisfying commit rather than a project.
The rule is live from day one against all new code, which is where most violations would otherwise come from, and the existing debt becomes visible and countable instead of implied. This week that shape closed three separate things: config keys with no reader, craft keys sold in a shop that opened nothing, and a formatting rule. The sellers in question include the wandering merchant's stall, which stocks recipes among its goods.
The mistake that makes it useless
I had the formatting one wrong for weeks and did not know it.
Instead of naming the violating files, I had exempted them with a pattern. A pattern does not just cover the files that existed when you wrote it. It covers every file that matches it from then on, including the ones I wrote that same night, which were red, and which nothing told me about because the exemption swallowed them along with the old ones.
That is the whole difference between an exemption and a ratchet. An exemption describes a shape and keeps forgiving it. A ratchet lists specific items and forgives exactly those. The list is uglier to read and it is the only version that works.
Two smaller ways a guard can be theatre
Both of these were live in this project and both survived review, because a guard that never fires looks exactly like a guard that passes.
One matched a mention rather than a use. It was checking whether a certain thing appeared in the file, so an unused import at the top satisfied it forever, long after the real usage had gone.
One had been written inside a comment. It never ran at all. Nobody noticed because its suite was green, which it would have been either way.
The habit I have taken from this: when I write a guard, I break the thing it guards on purpose and watch it go red before I commit. Sixty seconds, and it is the only evidence that the guard is connected to anything. A craft key such as the Deity Pill recipe is the kind of item the shop check now covers.
And check the artifact, not the description
The last variation is subtler. Several checks here were asserting against prose in a document, or against a value in the file that authors it, rather than against the payload that actually ships to players.
Those pass while the shipped thing is wrong, which is the worst outcome available: a green signal proving something adjacent to the thing you care about. The checks now read the exported payload. Two of them went red the moment they were pointed at it, which is exactly what you hope for and never enjoy.
Open the game free in a browser tab to see the rules at work; the devlog archive sits at Incremental RPG.
Top comments (0)