Engineering Platform › Shared Kits

Shared Kits

Each chore every app needs is written once, as a shared kit, and every app uses that one copy. A fix is made once and every app gets it. New apps get the kits on the day they are created, so nobody goes back later to redo the plumbing.

10 jobs
from a read-only review of six apps
2 kits
are not a choice for any app

Why one set

Five apps, built one after another, each ended up with its own copy of the same chores: putting the app on the server, moving it from the test server to the real one, checking it is alive, scanning for passwords before a change is saved, packaging it to run, giving it its web address, sending work to the AI computer, and backing it up.

Five copies of a chore means five places to fix the same bug, and the copies had already drifted apart:

The decision: write each chore once, as a shared kit. Every app, including every new one, uses that single copy. Two kits are not a choice: fomx-ci, which runs the checks and the deploys, and design-kit, which sets the look and feel. Decided 2026-09-30, from a read-only review of all six apps that Control Tower manages.

What each kit does

The review produced ten jobs. The board below is as of 2026-10-01; a kit counts as finished only once I have tested and signed it, and none is signed yet.

PF1 · Deploys
One standard way to put an app live and promote it from the test server to the real one. I still click Promote. Built and reviewed; waiting for my testing.
PF2 · Checks
One password scanner, one set of code checks and one review step for every app, so each AI builder's work is reviewed cold before it is called done. Built and reviewed; waiting for my testing.
PF3 · Packaging
One recipe for packaging an app to run on the server. Built and reviewed; waiting for my testing.
PF4 · Web address
One way to put an app behind its web address and security certificate. Built and reviewed; waiting for my testing.
PF5 · Is it up?
Every app answers two questions: are you up, and which version are you? Before this, Control Tower counted a "page not found" as healthy. Built and reviewed; waiting for my testing.
PF6 · AI computer
Sending work to the AI computer works the same way in every app. Before this there were three versions and two names for the access token. Built; being reworked after review.
PF7 · AI tools
One shared, tested piece for apps that offer tools to an AI or use an AI's tools. Two apps had written their own. Built; in review.
PF8 · Small chores
Standard start and stop scripts, a database helper and one check that the private network is reachable. These were small duplicates in three apps. Built; in review.
PF9 · Backups
Backup and restore for every app's data, with the restore actually tried. Nothing existed before, and Tourney's database had no backup. Built; in review.
PF10 · The catalogue
A catalogue that lists every kit and makes sure every new app gets them. It has to wait for the others, because it cannot list what does not exist yet. Spec approved; not started.

The two that are not a choice, and the two that matter most

Not a choice: fomx-ci (checks and deploys) and design-kit (the look and feel). Every app gets both from day one, so nobody redoes them later.

If only two could be done: know what is really up (PF5) and backups (PF9). They are the two that matter at 2am.

How the work ran

One Claude session wrote the ten specs from the review's list. I approved each one on an approval page, one acceptance line at a time. From there Control Tower ran them by itself: a build, then an independent review by a second AI session, then my test checklist, one step at a time. It waited for free memory and paused when the week's Claude usage ran high.

The AI builds, the owner decides. The ten jobs ran with me asleep for most of it, and every one stopped the moment it needed a human decision.