Rationale
The engineering story
The short version of why this system looks the way it does.
Letting a system touch its own source is the hard part
Most software is written under the assumption that a human reviews every change before it runs. This system doesn't work that way — it can propose and install changes to its own source. That single capability is what everything else on this page exists to keep in check. Self-modification without a backstop isn't autonomy, it's just a faster way to break things.
Why a boot gate instead of just trusting the new version
A new version of the system is only a hypothesis about a better version of itself. The boot gate exists so that hypothesis has to prove itself before it gets to run unattended: the changed code starts on spare ports and has to give a real health response, while the previous, known-good version stays in charge until the new one clears the gate.
A fleet of its own
Day-to-day work — content, analysis, research — is handed off to background agents, each running in its own git worktree so several can work at once without stepping on each other. When an agent finishes, it opens a draft pull request. Nothing lands on main by itself, and nothing goes straight to deploy — a human still decides what merges.
AGENT FLEET & REVIEW
Why tool servers have to heal themselves
A system that depends on its own tool servers is only as reliable as the least reliable one. Rather than building everything to assume tool servers never fail, the system treats their failure as routine and builds recovery into how it uses them.
Grading with exit codes, not with vibes
It would be easy for a system like this to just report that a change "worked." Exit-code checks exist to remove that option — a real command either exits clean or it doesn't, and that's the signal the system grades itself against.