Covers July 17 - 19, 2026.

Five of my six active derived apps had the same live security hole. The generic database-admin editor guards row mutations with a mutability check, but their copies only consulted the append-only table set. They never looked at the mutation-denied set. api_keys, users, and the token blacklist were editable through the generic editor.

I paused The Dance (propagating template changes across the derived apps) while aidd and Spernakit went public. The fleet grew from six to thirteen because I kept adding applications to dogfood different parts of the process, mostly to give aidd more scenarios and a real workout. (That and when code is cheap, ideas are too!) That thirteen includes aidd, which doesn’t inherit the template. By this week all six active derived apps had fallen behind by six template releases. It took me one long day to catch them up.

I upgraded each app with a three-way comparison against its real 3.17.0 base, because a two-way diff can’t tell “the template moved forward” from “the app deliberately changed this.” I left files the template never touched alone. Along the way I found fifteen template fixes and sent them out as 3.24.0.

The current template checks both sets, so the upgrades closed the hole. I had a harder time with why it stayed open. Each app had frozen or disabled the gate that should have caught it. A .templateoverrides SKIP can freeze a file, but the interfaces around that file keep moving. The frozen copies drifted from the template and the matching assertion never ran.

I spent the rest of the day switching those gates back on.

Starting over

Six other apps had drifted far enough that a three-way merge was taking longer than describing the domain again against a current baseline. So on Saturday I re-created them from a fresh 3.24.1 scaffold with brand-new git history. The old repositories stay on disk as read-only evidence. One rebuilt app’s spec even names its .old sibling at a specific commit so there is no guessing about which behavior to reproduce.

Thirteen applications: six upgraded through a three-way merge, five of which had the same live security hole; six re-created from a fresh scaffold; and the orchestrator, which does not inherit the template SIX APPLICATIONS BECAME THIRTEEN upgraded (6) six template releases behind; five had the same live security hole re-created (6) drifted too far to merge; scaffolded fresh, no domain code n/a (1) the orchestrator no template security hole found and closed clean blueprint only
The five red squares are the ones where the generic database-admin editor could write to api_keys, users, and the token blacklist. Each of them had frozen or disabled the gate that would have caught it.

None of the six has its previous domain code yet. They have reviewed feature blueprints and that is where I stopped. I think separating the blueprint from implementation is the right call, although I admit that six empty applications look a little suspicious when you first open the folder.

One app opted out of Spernakit entirely because it’s a turn-based play-by-mail game. Workspaces and an RBAC admin shell would add a lot that the product doesn’t need, so its blueprint uses a stack-neutral scaffold and keeps the old turn engine as the behavior to port.

The next day I changed aidd’s application workflow to stop after the scaffold and reviewed blueprint unless implementation is requested. Spernakit creation also uses the template’s own initializer now. aidd had been reimplementing that initializer, and it was already lagging.

So far, I’ve used the old repositories to check behavior without needing to trace the commits. They’re still there if I need to.

Follow-up: Two Dances, Six Rebuilds.