Supernova: software that manages itself
Supernova is an agent-native platform for building and running software projects. Give it a product direction and it turns that intent into requirements, work, code, review, tests, deployment evidence, and follow-up—while keeping every step connected to the reason it exists.
The ambition is not simply to make agents write more code. It is to give an agent workforce the machinery a good engineering organization needs: a shared definition of success, durable work, clear authority, independent review, operational feedback, and institutional memory.
The elevator pitch: Supernova is a self-managing software organization in a box. Give it a specified goal state and it recursively decomposes, plans, acts, measures the remaining gap, and revises the plan until current evidence proves the goal is satisfied—or a budget, permission, or genuinely ambiguous decision requires explicit judgment.
The closed loop
Supernova is structured like a control system. The project’s vision and requirements are the setpoint. Automatic planning compares the vision with the requirement graph, identifies missing coverage, decomposes accepted outcomes into requirements, and plans the feature, specification, and implementation-wire work needed to satisfy them. Issues and workflows form the controller; agents, VCS, and operations are the actuators; review, tests, and monitoring are the sensors. The wiki, decision ledger, and event trail provide durable memory. When observed reality differs from the setpoint, Supernova turns the gap into bounded work, executes it under policy, and measures whether the result actually closed the gap. Ambiguous or constitutional choices still require capability-scoped judgment rather than being silently invented by the planner.
That feedback edge is the core behavior, not a reporting afterthought. Each result changes the next input: evidence closes part of the graph, failures preserve a smaller unresolved delta, and the controller replans from the new state. The loop recursively converges on the declared goal instead of running a one-shot plan and calling whatever happened “done.”
flowchart TD
intent["SETPOINT<br/>Vision + requirements<br/>what must be true"]
work["CONTROLLER<br/>Decompose + plan + schedule<br/>what to do next"]
fleet["ACTUATORS<br/>Agents + VCS + operations<br/>change the project"]
proof["SENSORS<br/>Review + test + field evidence<br/>is it actually true?"]
learn["FEEDBACK<br/>Findings + decisions<br/>repair and improve"]
intent --> work --> fleet --> proof --> learn --> intent
Most agent tools stop at the actuator: they produce a change. Supernova is built around the whole loop, including deciding what change matters, proving its effect, and feeding the result back into the project model for the next iteration.
What sets it apart
The wiki is an executable specification
Requirements form a graph from product outcomes down to individual files. Each one declares its
origin, dependencies, and the proof that would make it true; @R# spans bind code to file specs and
tests. Evidence percolates up the graph, so high-level completion is computed from what is really
implemented and proven—not maintained as a hopeful checkbox. For example, sun wiki validate can
reject a patch when a Rust line has no requirement, a cited test no longer exists, or the wrong test
covered the line. See the requirement and evidence model.
The whole platform shares one nervous system
Kafka is not another integration: every system speaks through the same typed event envelope and causal trail. Reactors turn events into a closed set of typed actions; Temporal workflows keep long-running, multi-step work alive through restarts and park it at zero compute while waiting for recovery, review, approval, or evidence. A monitor alert can wake the responsible agent, start a repair workflow, and later correlate the fix and its before/after metric through one causal chain. See the bus, reactors, and durable workflows.
One CLI exposes the whole organization
Humans, agents, workflows, and automation all use the same sun <system> command surface and typed
client libraries. sun issue frontier status shows actionable work and real blockers; sun agent goal pursues one evidence-bound target; sun monitor health --live reads operational truth; sun vcs ship performs gated promotion. Commands support structured output, so agents do not need a
second, privileged control plane. See how every system gets the same shape.
One instance can manage an entire project portfolio
Supernova’s tenants are projects. One instance can attach many existing repositories, giving
each its own namespace, agent swarm, issues, workflows, credentials, policy, and operational state.
sun project register payments --subject /repos/payments incorporates a repo without swallowing it:
vision, requirements, specs, tests, and code stay portable with the project, while live coordination
stays in the builder. If a human or outside tool changes that repo, reconciliation examines the exact
Git range, recomputes affected requirements and coverage, and blocks unsafe dispatch until conflicts
are resolved. See multi-project isolation and external-project incorporation.
Permission is architecture, not a prompt instruction
Authentication says who is acting; capabilities say what they may do; review says whether the result
is correct. A global approval system separately governs protected actions with a non-lowerable
risk floor and exact-scope, one-use elevation. Every external effect then passes through one egress
owner, while unknown inbound content enters a capability-stripped ingestion path. In practice, a
coder can edit its worktree but cannot commit, merge, approve itself, or send a message outside the
platform. sun approval request cmd ... may authorize one exact blocked command; it does not promote
the agent into a permanent administrator. Explore the full safety stack.
Provenance runs from intent to runtime proof
Supernova can trace a behavior from product claim to requirement, decision, file spec, code line, test, review, and field evidence—and walk the chain backward when something fails. Decisions use formal supersession rather than silent edits, so the platform can distinguish current law from historical rationale. Change reviewed code after it was stamped, for example, and the content hash invalidates that stamp; the old review stays in history but cannot authorize the new code. See provenance, evidence, and case-law decisions.
End-to-end means the whole journey
Coding agents cannot merge their own work. Trusted machinery folds isolated worktrees into a staging branch; independent review and requirement-owned evidence gate a batch; the E2E harness runs real workflows against an isolated Kafka, Temporal, and Postgres stack. Promotion is followed by passive soak and, for features, observation of the user outcome. A critical-user-journey check therefore means running the journey through the stack—not marking a registry row “tested.” Follow the delivery and E2E path.
Agents are managed as an accountable workforce
Agents have identities, scoped capabilities, sessions, memory, diagnostics, budgets, and warm-parent forks. The governance model also links demonstrated quality to routing capacity: reviewer outcomes include misses, round trips, escaped defects, false positives, and calibration—not comment count or raw speed. Scores begin in shadow mode, retain uncertainty and cohort context, and are themselves audited for gaming before they can influence what work an agent is trusted to take. A fast reviewer whose changes later produce escaped defects loses routing confidence; producing more comments does not improve the score. Meet the fleet and its incentive model.
Token economics shapes the runtime
Supernova optimizes useful outcomes per scarce model turn, not just the price printed beside a model. A new agent normally forks a warm parent already loaded with project and role context, reusing the provider’s cached prefix instead of paying to ingest it again. Repository changes append as deltas so the warm base stays reusable; large-context questions fork a preloaded oracle and discard the child; simple questions use structured lookup; waiting agents react to events at zero model cost. Goal loops carry turn, time, and token budgets, while monitor tracks provider/account usage, cache performance, spend rate, and value per token. The precursor’s field implementation reached roughly 99.7% cache reads on its warm-oracle path; Supernova makes that behavior a tested runtime contract rather than an operator trick. See the warm-session and token-economics design.
Monitor audits the system that does the work
Self-audit is a first-class monitor capability. Cheap mechanical checks continuously inspect
requirement coverage, bus wiring, provenance, feature adoption, staleness, audit follow-through,
cost, and metric gaming; a small number of agents then judge those artifacts instead of burning
tokens re-scanning the repository. The process can propose a missing requirement, implementation
wire, new check, better review rule, tighter prompt, improved context/tooling, or a validated sun agent def edit that reduces avoidable turns. It also audits its own schedules, false positives,
latency, bias, and realized benefit. Proposals still go through normal review and approval—the
monitor may improve the organization, but it cannot silently rewrite the agents or the policy used
to grade them. See the self-audit and learning loop.
“Done” can become unproven
Tests, coverage, reviews, field metrics, human approvals, and external attestations are typed, revision-bound evidence. If required evidence expires or turns red, requirement satisfaction can go down without erasing the historical delivery record. That gives the improvement loop a precise place to start: a decayed field metric can make an outcome unproven and generate a bounded repair candidate without reopening or rewriting the feature that originally shipped it. See how the system manages toward outcomes.
It can repair and improve without grading itself
Monitoring correlates an alert with the workflow, agent, decision, and requirement that produced it. Mechanical checks report facts; capability-scoped judgment decides what becomes work; before/after evidence proves whether the repair helped. A running version builds its successor in isolation, and the candidate cannot alter or approve its own admission policy. A recovery command is not “success” until the matching target metric improves and the action receipt is present on the bus. See the operational and self-hosting loop.
One coherent machine
These capabilities are not separate products joined by a dashboard. They share one command surface, one event grammar, one project model, and a common five-part system contract. The same nouns appear in the CLI, client libraries, configuration, code, and documentation. That regularity is what lets agents inspect and extend the platform without inventing a new architecture for every feature.
Where it stands
Supernova is actively using substantial parts of its own machinery to build itself. The repository contains a large Rust workspace, per-file specifications, extensive tests, owned-substrate integration exercises, and working slices of the delivery, evidence, agent, bus, workflow, safety, and monitoring paths.
It is not yet a released, production-soaked product. Several final provider integrations, long-window operational proofs, state cutovers, and end-to-end production command paths remain. This site distinguishes working implementation from in-repository proof and intended production behavior rather than presenting all three as the same thing.