Why build a second system

Supernova exists because its builder already works — and can’t be shared. automatt is Matt’s live, personal, self-modifying automation platform: it specs, builds, reviews, and ships software overnight with a workforce of agents. Those same properties make it useless as a product. Supernova is the clean-slate successor: the capabilities automatt has already proven, rebuilt as a coherent, shareable system — seeded by automatt, and now far enough along that it bootstraps itself.

You can’t fork a self-improving system

The origin is a sharing constraint, not a scaling one (idea009, the project’s founding design note, 2026-05-16). Matt wants to collaborate with other people, and automatt can’t do that: it is personal, unstable, and self-modifying. You can’t hand someone access to a system that rewrites itself around one person’s life, and you “can’t fork a self-improving system” — a fork of a thing whose value is its accumulated self-modifications diverges instantly and forever. Shoehorning external projects into automatt’s internals was the third bad option, after sharing access and forking.

There is a second, quieter motivation: coherence. Self-building projects accrete one-off pieces that don’t form a whole. automatt made two unifying moves — a single command surface and a wiki — and in the wiki’s own words they helped only “kind of.” Supernova’s answer is the five-part self-similar shape, where every system has the same anatomy and every piece of code has an obvious home.

Friction-on-friction

The obvious alternative — refactor automatt in place until it’s shareable — fails twice.

First, mechanically: “refactoring a live system from within itself is friction-on-friction, every agent doing the restructuring runs on the system being restructured (‘you break the thing you’re standing on’).”

Second, economically: restructuring a codebase you intend to migrate off is paying the same price for a worse outcome. The work is throwaway by construction.

So the bootstrap doc reframes the question. Not “reorganize automatt or build Supernova?” but “is automatt a good-enough builder as-is?” The evidence says yes — it pushes twenty-plus tasks overnight and self-organizes around incidents [live in automatt]. automatt therefore gets targeted stabilization only (recurring footguns like shared-checkout contamination and a hook blocking its own fix), never an architectural reorg.

The builder model

The relationship between the two systems was originally settled by a single ruling. Matt, 2026-06-10, verbatim:

“supernova is not intended to bootstrap itself, automatt will build it entirely and ship a mostly finished product. Automatt is the bootstrap and supernova will live as a subproject and get spun off.”

That ruling superseded two earlier designs, both still visible struck-through in the wiki with the ruling attached — supersession is formal in this project, and decisions are case-law. Gone at the time: the “self-hosting kernel” model, where a first slice of systems would run on Supernova and build the rest of it; and the migration clause where automatt moves onto Supernova mid-build.

Then practice overtook the ruling, and the same ledger discipline applies. As the issue, vcs, review, and wiki systems came up in the workspace, development moved onto them, and the standing word is now the reverse of the June plan: “Supernova is bootstrapping itself” (Matt, 2026-07-05). The agents building it claim work from its own issue tracker, operate in task-keyed worktrees its vcs system cuts, pass its review pipeline, and close work through its own validation gates. The self-hosting-kernel idea, struck down in June, is roughly what happened anyway — and the overruled ruling stays on the record, marked superseded, exactly the way the ledger says it should.

flowchart LR
    am["automatt: live, self-modifying, the seed"]
    sn["Supernova: bootstrapping itself"]
    ship["shipped mostly finished"]
    spin["spun off as its own project"]
    later["automatt migrates onto a Supernova instance"]
    am -- "seeded: specs, scaffolding, first systems" --> sn
    sn -- "its own issues, worktrees, reviews, gates" --> sn
    sn --> ship
    ship --> spin
    spin -. "post-spin-off decision, not a milestone" .-> later

Builder throughput IS the Supernova schedule (finding F15, 2026-06-10) survives the supersession with its meaning shifted: the builder is now increasingly Supernova itself, so the delivery date is a direct function of the platform’s own constraint chain — dispatch, review throughput, decomposition. Improving the platform is not competition with building it; it is the critical path. The schedule has no dates, only a bottleneck.

Owned infrastructure

One principle constrains every build-or-buy choice downstream. Matt, 2026-06-04, verbatim:

“everything has to run locally as part of project itself unless it absolutely can’t (models)”

with “local” later sharpened to something more precise than geography:

“‘local’ to me is more.. ‘I control software stack completely and functionally own machine and can configure it however I want and I won’t get billed per-run’ which GitHub runners do NOT fulfill nor does any hosted solution”

Local means ownership, control, and no metered billing. A Proxmox VM across the room qualifies; GitHub Actions, Confluent Cloud, Temporal Cloud, and every hosted CI do not. The consequences are concrete: self-hosted Kafka, Temporal, Prometheus, Grafana, and Postgres, all [supernova design] as an assembled stack (secrets use a lightweight encrypted-local store, not a Vault server), with model APIs as “the single metered remote dependency” — the one thing that absolutely can’t run on owned hardware. The footprint was checked before committing: single-broker Kafka runs in ~1–2 GB and Temporal in ~500 MB on a 64 GB box; the heavy cost is model calls, which are remote anyway.

The RSI story

A platform built by agents, for running agents, invites the recursive-self-improvement reading. For once the reading is roughly right — with the build-state care this site owes it.

The loop’s first home was automatt [live in automatt]: monitoring feeds alerts back into its own bus; a listener agent acts on them; recurring incidents mechanically propose new permanent checks. That loop is what made automatt an effective seed — and also exactly what makes automatt unshippable.

The loop’s second home is Supernova’s own construction. Every improvement its agents land — to the issue gates, the review pipeline, the traceability validator, the agent substrate itself — immediately sharpens the process that builds the next improvement [built in-repo]: the recursion runs on the workspace implementations and the sun CLI, not on a deployed Kafka/Temporal stack. automatt’s construction-site-and-crane problem — “you break the thing you’re standing on” — is mitigated rather than repeated here, because the thing being modified is not yet load-bearing under anyone’s life: breaking the scaffolding costs a rebuild, not an outage.

What stays deliberately out of the artifact is unattended self-modification of the shipped product. The platform bootstraps itself; what it ships is meant to hold still. Self-improvement of a running instance stays optional, on the far side of the spin-off, as a choice its operator can make rather than a property they inherit.

The second-system trap

Supernova is, unavoidably, a second system built with everything learned from the first — the classic setup for over-design, and the wiki names the risk itself (“beat the second-system trap”). Three mitigations are structural rather than aspirational. The build is incremental and system-by-system, each landing with end-to-end tests, not a big-bang rewrite. The substrate is bought, not built — Kafka, Temporal, Postgres, Prometheus — replacing bespoke components that had already failed on the record (the Python event bus was retired on same-night failure evidence — the bus page keeps the record). And the migration doctrine transfers problem classes, not features: each of automatt’s documented failure modes must be mapped to a named prevention mechanism or explicitly marked non-portable, with fresh state as the default. Scope is bounded by what already broke, not by what might be nice.

Whether that’s enough is a fair question — see the long view for what still has to prove out.

What this costs

• The two-systems window is real. automatt stays live through the build — it seeded Supernova and still backstops it — and self-bootstrapping adds its own tax: every process bug is now also a build bug. The bootstrap doc calls the dual-system cost mitigated, not eliminated.
• Nothing is production-live. Supernova today is a large design corpus plus a Rust workspace with test evidence. The project’s own readiness surface can report every local check green while production_ready:false — in-repo proof is deliberately distinct from live-substrate proof.
• The design corpus is enormous relative to running code. That ratio is the second-system trap’s natural habitat; the mitigations above are named, but the risk is inherent and the docs admit it.
• Owned infrastructure makes one person the ops team. Kafka, Temporal, Prometheus, Grafana, and Postgres on personal hardware, with no managed fallback on principle. The decisions record itself notes Kafka is heavy for one user; Matt chose it anyway.
• The loop is never fully self-contained. Model APIs remain the single metered remote dependency. An “owned” platform whose intelligence is rented is a tension the design acknowledges rather than resolves.