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.

View the system map.

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.

Read the current project state.

The self-managing loop

“Self-managing” is easy to say and usually means a scheduler plus a chatbot. In Supernova it means five concrete parts form a closed control system.

The operator supplies a goal state, not a fixed script. Supernova repeatedly compares current evidence with that state, decomposes the remaining delta, executes the next admissible work, and feeds the result back into planning. The recursion terminates when the declared evidence obligations are satisfied; exhausted budgets, denied authority, or unresolved judgment fail loud instead of being reinterpreted as success.

Start with what should be true

Every project carries a maintained vision. Accepted outcome claims decompose into a directed graph of requirements. Each requirement records why it exists, what depends on it, and what evidence would be proportionate to the claim.

That graph is the project’s setpoint. It gives the system something stronger than “keep the agents busy”: an inspectable definition of the destination and a mechanical way to find uncovered intent, missing implementation, and insufficient proof.

The planning loop continuously compares vision claims with that graph. It can propose missing requirements, decompose accepted outcomes into features, turn those features into specification tasks and implementation wires, and preserve the dependency and evidence relationships between them. Planning is therefore regenerated from current project truth instead of becoming a stale, separate roadmap.

Turn gaps into bounded work

The work generator and audits can surface several kinds of gap:

• a vision claim with no covering requirements;
• a requirement with missing children or proof;
• a failed test, degraded field metric, or expired attestation;
• an operational defect or recurring review miss;
• an adoption failure or coordination bottleneck.

Mechanical checks report facts. They do not silently redesign the project or file arbitrary work. A capability-scoped judgment step decides whether to dismiss the finding, amend the design, or create a reviewed issue. Once the outcome and requirement change are accepted, the ordinary decomposition path can plan the bounded delivery work automatically.

Act through durable, owned mechanisms

Admitted work enters the frontier. Workflows allocate it, agents act in isolated scopes, and VCS and operations perform trusted state changes. Every important action produces a typed event with causal identity, so later evidence can be connected to the decision and change that produced it.

Measure the result

Completion is derived from current evidence rather than an agent’s statement. A passing isolated test may satisfy a narrow code claim; a product-level requirement may also demand coverage, a clean review chain, a field metric, a user-journey exercise, or an independent human attestation.

Evidence can decay. When it does, the requirement’s satisfaction reading can go down without rewriting the historical issue that originally delivered it. That distinction lets Supernova say both “this worked then” and “it is not proven now.”

The new reading becomes the next loop input. A partial success narrows the remaining requirement delta; a failed proof selects repair work; a newly discovered dependency changes the plan. Supernova therefore iterates on observed state rather than blindly replaying the original plan.

Improve the manager too

The same loop can inspect its own behavior: reviewer misses, repeated boot-backs, inaccurate value scores, token waste, dispatch starvation, stale audits, or policy gaming. Proposed changes to the scoring rubric, role instructions, or gates follow the normal decision and approval path.

Predicted value is recorded before work begins and compared with realized outcomes later. That makes the work-selection system falsifiable instead of permanently self-congratulatory.

Know when quiet is legitimate

An empty queue is not automatically success. The frontier is legitimately quiet only when vision claims have covering requirements, required evidence is green and fresh, scheduled audits are current, and no actionable findings remain. Otherwise idle capacity is itself a generator or dispatch defect.

Self-management is bounded

The loop may identify and deliver improvements, but it cannot rewrite its constitutional limits. Protected policy changes require approval under the policy already in force. A stable Supernova version builds a candidate successor in isolation rather than changing the running floor beneath its own judgment.

Next: follow one change from intent to observation.

From intent to observed outcome

Supernova treats delivery as a chain of claims that earn stronger evidence as they move toward the real world. A feature request is not code, a merge is not delivery, and a passing unit test is not proof that a user outcome exists.

Three levels of work

• A feature describes a top-down outcome. Its decomposer may refine requirements and create implementation work, but it has no code-landing authority.
• A specification task turns an accepted requirement into file-level behavioral contracts.
• A wire is the smallest code-bearing delivery unit. Wires, bugs, and security fixes receive coder agents confined to dedicated worktrees.

This separation keeps intent, design, and implementation connected without asking one agent to be product manager, architect, coder, reviewer, and approver at once.

The path through the system

flowchart TD
    vision["Vision gap"] --> req["Requirement"]
    req --> feat["Feature"]
    feat --> spec["Spec task"]
    spec --> wires["Implementation wires"]
    wires --> review["Independent review"]
    review --> integration["Batched integration"]
    integration --> main["Promotion"]
    main --> soak["Soak"]
    soak --> observe["Outcome observation"]

Work begins in draft, then enters an explicit readiness review. Only admitted, actionable work reaches the ready frontier. The delivery workflow chooses work from that frontier, checks capacity and policy, forks the appropriate agent pod, and owns the transition into active work.

The pod may edit only its worktree. It does not commit or merge. A trusted step folds completed work onto the staging branch, where independent review and requirement-owned evidence gate the batch. Promotion to main is batched and end-to-end tested on an isolated real stack.

After promotion, passive metrics provide soak evidence. Features go one step further: they close only after observation of the top-down outcome. Bugs and security fixes can close after a green soak because their claim is narrower.

A frontier instead of sprints

Supernova continuously computes which work is admissible now. Dependencies, readiness, authority, capacity, project value, evidence decay, outages, and critical blockers all affect the frontier. There is no forced work stoppage at an arbitrary calendar boundary.

Among safe and actionable items, prioritization can consider expected product coverage, user impact, risk reduction, bottleneck relief, information gain, confidence, reversibility, and expected model cost. The score recorded at filing can later be compared with the realized result, allowing the selection process itself to be audited.

Failure moves backward with context

A deterministic integration failure boots the implicated work back to the responsible stage with evidence attached and wakes the context that owns it. A transient substrate failure parks the durable workflow until recovery. Neither path silently discards progress or starts a fresh agent with only an error string.

What is working now

The repository has working issue lifecycle, worktree, dispatch, review, workflow, VCS, evidence, and test slices, including local and owned-broker end-to-end paths. The full production delivery path is still being connected across every command and provider boundary. See project state for the distinction.

A fleet, not a chatbot

Supernova models agents as an operating workforce. An agent is not just a prompt attached to a model call: it has an identity, role, capability set, session history, diagnostic surface, project scope, and a place in a durable workflow.

Provider-neutral by design

The runtime uses one canonical representation for turns, tools, and results. Provider adapters normalize the transport details. Adding a model should mean adding an adapter—not rewriting the agent loop, permission system, or tools.

The intended production runtime is a thin, owned Rust loop rather than a wrapper around a vendor’s interactive coding application. Generic coding tools, Supernova’s typed domain tools, and MCP tools all enter through the same observed registry. Every tool call can therefore be attributed, checked, and emitted into the platform trail.

Token economics is a runtime concern

The limiting resource is not only dollars. Subscription allowance, uncached input, agent turns, context reloads, latency, and follow-on work all affect how much useful work the fleet can deliver. Supernova therefore treats token economics as architecture:

• warm-session forks are the default; cold boot requires an explicit fallback;
• stable prompt and project context stays at the front of the cached prefix;
• repository updates append as deltas and periodically roll into a new warm base instead of forcing a full context reload;
• easy questions use sun find or the memory graph before spawning research;
• large-context questions fork a preloaded, never-compacting oracle for one answer, then discard it;
• agents attach to events and sleep rather than spending turns polling;
• every goal has iteration, wall-clock, and token ceilings with a structured soft-stop;
• work selection records expected outcome, P50/P90 token cost, and realized value per token.

Monitor owns measurement: per-provider and per-account usage, spend rate, budget pressure, turn receipts, and cache field metrics. Agent owns avoidance: choosing the provider, account, warm parent, lookup path, or model appropriate to the job. This keeps cost dashboards from becoming a second scheduler.

Fork is the basic spawn primitive

A warm parent session can fork child agents with its prompt context already cached. Different jobs— implementation fan-out, reviewers, investigators, or specialist subagents—become policies around the same primitive.

flowchart TD
    parent["Warm parent<br/>project context + cached prompt"]
    parent --> coder["Coder fork<br/>one worktree"]
    parent --> reviewer["Reviewer fork<br/>independent authority"]
    parent --> investigator["Investigator fork<br/>failure context"]
    parent --> oracle["Oracle fork<br/>bounded question"]

This is both an efficiency feature and a coherence feature. Children begin with shared context while receiving different permissions, evidence obligations, and termination conditions. Field experience in the predecessor system demonstrated roughly 99.7% cache reads and about $0.008 per warm-oracle question. Supernova turns that useful hack into an explicit runtime contract; matching production field evidence for the final runtime remains an open admission requirement.

React, do not poll

Agents attach to typed event conditions and sleep at zero model cost. A matching bus event wakes the right session. The same parked-await idea serves agents and durable workflows, so waiting for review, recovery, approval, or new evidence does not require a polling prompt loop.

Goals terminate on evidence

A goal binds a target, an evidence obligation, and a budget. The loop is deliberately small:

act -> check existing evidence -> park -> wake -> repeat

The check reads the platform’s derived closure result; the agent cannot declare its own work done or manufacture a private definition of success. Iteration, wall-clock, and token ceilings make failure loud and return a structured result to the parent.

Each pass starts from the evidence produced by the previous one. The agent revises its next action against the remaining delta and recursively repeats until the specified goal state is demonstrably satisfied. Parking makes that recursion durable and cheap; it is not an unbounded prompt loop.

Diagnostics instead of watchdog kills

Each session exposes what it is doing, its recent activity, runtime placement, health, tool use, and budget state. The operating rule is diagnose first. A slow turn is not killed merely because a timer expired; termination is an explicit lifecycle action with a recorded reason.

Incentives are attached to responsibility

Agent roles are separated so that improving a personal score cannot mean weakening the bar. A reviewer does not implement or approve the work it reviews; an outcome steward cannot close work by narrowing the outcome; and an implementer cannot change the evidence obligation after readiness.

The planned reviewer scorecard is a visible vector of responsiveness, comprehensiveness, avoidable round trips, independently attributed escaped defects, false-positive burden, calibration, and process integrity. Raw speed, comment volume, and finding count carry no positive weight by themselves. Results are normalized against comparable work and always retain sample size, uncertainty, evidence, and policy version.

Activation moves from measurement-only shadow mode to advisory use and only then to constrained routing. Adequately supported outcomes may affect the classes of work an agent is trusted to review, but a scalar score can never grant a capability or bypass an eligibility floor. Monitor audits bias, metric gaming, risk avoidance, fragmentation, and attribution disputes; it may propose a policy change, but cannot apply one.

Memory with boundaries

Per-agent memory and derived knowledge indexes live in the agent system. Project truth does not. Agents can rebuild or discard their own convenience state without losing requirements, issues, evidence, or code. That separation prevents an agent’s private recollection from becoming a hidden source of authority.

What is working now

Supernova already runs project-scoped agent sessions, records lifecycle and tool evidence, supports goal and wakeup surfaces, and uses its agent machinery during its own construction. The final owned multi-provider runtime and some provider-network paths remain incomplete; current operation includes interim adapters. See project state.

Proof, memory, and decisions

An autonomous system becomes hard to trust when it cannot answer three questions: Why does this behavior exist? Where is it implemented? What proves it still works? Supernova makes those questions part of the project model.

A two-way trace

Each requirement carries two complementary fields:

• Origin points backward to the decision, defect, or product claim that created it.
• Evidence points forward to the proof required before the claim is satisfied.

Requirements form a directed acyclic graph that rolls from implementation details toward project outcomes. Source files have matching file-level specifications; Rust code uses active @R# annotation spans to bind implementation lines to those specifications. Tests and coverage artifacts bind back to the same requirements.

flowchart TD
    decision["Decision or product claim"] --> requirement["Requirement + evidence obligation"]
    requirement --> filespec["Per-file specification"]
    filespec --> code["Annotated implementation"]
    code --> evidence["Test, review, metric, or attestation"]
    evidence --> requirement

This enables queries in both directions: from a code line to its reason and proof, or from a changed requirement to the code, tests, and dependent outcomes it may affect.

Evidence is typed

Different claims need different proof. Supernova distinguishes unit and integration results, coverage, field metrics, critical-user-journey exercises, human approvals, external correspondence, documents, and independent agent attestations.

The kind, producer, subject, revision, freshness, and trust level matter. A passing local stub cannot satisfy an obligation for a provider-network result. A whole-suite coverage hit cannot prove that the specific declared test exercised a requirement’s lines.

Satisfaction is a derived rollup over the required evidence. It is not a status word someone may set by hand.

Proof can expire without erasing history

Isolated evidence can turn red after a code change. Field evidence can degrade with real usage. Attestations can expire or be revoked. When a required input decays, the satisfaction reading changes and the control loop rechecks affected parents.

The original feature or issue remains closed as a historical delivery record. New remediation work is filed at the most concrete useful level after scoped judgment. This avoids reopening the past while still refusing to call stale behavior healthy.

Decisions behave like case law

Architecture decisions live in a ledger with source authority, affected contracts, and formal supersession. A newer ruling cites and overrules the older one; the old record remains visible but no longer authoritative.

Routine analogous cases can apply precedent. Security, authority, system-boundary, founding-property, and genuinely ambiguous changes escalate. Accepted decisions name a propagation owner and a closure query so stale operational prose does not quietly survive beside the new rule.

Memory has owners

Supernova does not put every useful fact in one database:

• the wiki owns requirements and evidence obligations;
• monitor owns current evidence claims;
• issues own imperative work history;
• Kafka owns the correlated event trail;
• VCS owns code history;
• agents own disposable personal memory and derived indexes.

These stores can reference each other without competing for authority. Wiping an agent’s memory does not erase product truth; rebuilding a client library does not destroy state.

The validator is part of the build

The repository validator checks document contracts, requirement graph integrity, spec/source path mapping, annotations, evidence references, test symbols, and coverage joins. Broken traceability is a build failure, not a documentation task deferred until after shipping.

What is working now

The trace validator, requirement graph, per-file specifications, source annotations, decision ledger, and broad test mapping are active in the Supernova repository today. Production evidence collection and long-window freshness are less complete than in-repository trace proof. See project state.

Autonomy with constitutional limits

Supernova does not ask one safety mechanism to answer every question. It separates identity, capability, exceptional authority, correctness, and external execution so that each decision has a clear owner and an auditable boundary.

Five different questions

Passing one layer never implies passing another. A capable agent may still need approval. An approved change may still fail review. A correct result does not grant the implementer more authority.

Capabilities, not special names

Policy refers to capability groups such as review, approval, VCS, operations, or external-link authority—not to a favored agent name. Ephemeral agents begin with no capabilities and receive only the project-scoped grants their job requires.

The operating system and container boundary enforce the floor beneath the application-level checks. A denial is a real branch, not an invitation for the system to auto-request a bypass. The agent may adapt its plan or explicitly request a narrowly scoped elevation.

Approval is constitutional

Approval governs exceptions and protected changes. Routine, reversible judgment can be delegated to the configured capability holder or established precedent. Irreversible actions, safety-policy changes, founding architecture changes, and other protected cases route to the primary human principal.

Requests cannot lower the operation owner’s minimum risk classification. A one-shot elevation grants exactly the approved command and is consumed on use.

Roles cannot judge themselves

• Implementers do not review or approve their own work.
• Reviewers certify correctness but cannot authorize protected execution.
• Approvers authorize the exception; they do not replace review evidence.
• CUJ stewards maintain outcome definitions but do not implement or close the work they govern.
• A candidate Supernova version cannot change the policy used to admit that candidate.

This separation is more important than any model’s promise to be careful. The incentives and powers remain distinct even when every role happens to be filled by an agent.

One external door

All outbound actions—messages, email, provider mutations, infrastructure changes, and other third- party effects—flow through link. The link system verifies identity, capability, approval scope, credential materialization, and provider receipts before reporting success.

Inbound material follows the reverse trust boundary. Verified trusted events may enter normal chat or bus flows. Unknown external content goes through ingest, where capability-stripped readers classify it and two separate gates judge intent and output quality. Raw hostile text is never treated as an instruction merely because an agent can read it.

flowchart TD
    agent["Agent proposes action"] --> permission["Permission check"]
    permission --> approval["Approval when required"]
    approval --> link["Single egress owner"]
    auth["Auth + scoped credentials"] --> link
    link --> outside["External system"]
    outside --> ingest["Trust-tiered intake"]
    ingest --> bus["Internal event trail"]

What is working now

The repository contains working identity, permission, approval, external-action, encrypted-secret, and ingest slices with fail-closed tests and local provider exercises. Broader live provider-network coverage and some production materialization paths remain open. See project state.

The durable runtime

Supernova buys infrastructure for solved distributed-systems problems and builds the rules that make the platform itself distinctive.

The stack is self-hosted on owned infrastructure. “Local” means control of the machine and software stack without per-run billing; it does not require every service to run on the same physical box. Model providers are the deliberate remote, metered exception.

One event language

Every significant event uses a fixed four-part topic grammar and a mandatory envelope. The envelope separates a unique message identity from the causal correlation identity, records the initiating principal where one exists, and carries severity and time.

Delivery is at least once. Consumers are required to be idempotent rather than relying on an “exactly once” story that breaks at system boundaries.

State and events cannot silently diverge

For load-bearing database transitions, the state change and its event enter a transactional outbox together. A relay publishes the event to Kafka and retries safely after broker recovery. Advisory or reconstructible notifications may publish directly and reconcile from their owner.

The dividing question is practical: if this event disappears, can the system become permanently wrong? If yes, it belongs in the transaction.

The bus is also the trail

Actions, results, failures, approvals, evidence, and operational signals all ride the same correlated event substrate. Audit history is not reconstructed later from unrelated text logs. Monitoring reads the trail as a lens; it does not create a competing source of event truth.

Reactors connect facts to typed actions

The bus includes a small dispatch layer. A reactor binds fixed trigger topics and a side-effect-free predicate to a closed catalog of typed actions: start or signal a workflow, wake an agent, update an owned field, call a client library, or request an external link action.

Arbitrary callbacks are not accepted. Domain policy remains in the system that owns the action. The reactor only performs the declared handoff.

Park instead of blindly retrying

Temporal owns durable execution. Supernova classifies failures before deciding what “retry” means:

• Transient dependency failure: park at zero compute and resume on a recovery signal.
• Deterministic product failure: preserve the full context, surface a finding, and wait for investigation or changed inputs.
• Permission denial: take the designed denial branch; do not relabel it as an outage.
• Severe failure: roll back where policy allows and alert through an independent path.

This keeps retries from becoming an infinite loop that repeats a broken assumption.

The broker cannot report its own death

The platform permits one explicit exception to “everything rides the bus”: an out-of-band broker and monitor watchdog. When the normal event path is unavailable, the watchdog can still report failure. On recovery it emits the event that wakes parked work.

What is working now

The Rust bus, envelope, registry, outboxes, reactor, Kafka integration, Temporal SDK exercises, owned Compose stack, and multiple producer/consumer paths have real tests and working slices. Some local file-backed interim paths and mirrored control surfaces are still being replaced by their final Postgres, Kafka, Temporal, and provider-backed forms. See project state.

Detect, repair, learn

Supernova’s operational loop is where automation becomes self-management. It connects telemetry to the exact change and requirement involved, preserves enough context to repair the fault, and measures whether the repair actually improved the system.

Observe the whole causal chain

OpenTelemetry feeds Prometheus and Grafana while structured operational events enter the Kafka trail. Correlation identifiers connect an alert to the workflow, agent, tool call, approval, and change that preceded it.

The monitor system owns the current evidence ledger and the read models used to answer questions such as:

• Which requirements are no longer supported by fresh proof?
• Which project or workflow is blocked on a failing dependency?
• Did a recovery action improve the requested metric?
• Which reviewers or gates repeatedly miss defects?
• Is the fleet idle because there is no valuable work, or because generation failed?

The system audits itself

Monitor separates self-audit into two passes so intelligence is spent only where it helps.

1. Mechanical checks run cheaply and often. They produce structured artifacts for platform invariants, requirement-DAG coverage, bus wiring, provenance, feature adoption, external/CUJ delivery, store retention, staleness, recurring failures, cost, and audit health.
2. Agent-led audit reads those artifacts and applies judgment. It does not pay several agents to rediscover the same facts. The consumer decides whether a gap should become a specification, implementation wire, process change, or dismissal.

The audit catalog includes a meta-audit: did scheduled audits run, were their findings useful, did follow-up work close, how many false positives occurred, and are scoring or routing metrics being gamed? Repeated incidents can propose a new permanent mechanical check so the next occurrence costs zero model turns to detect.

Turn receipts, tool use, cache metrics, review round trips, escaped defects, and token/spend trends also feed the process audit. Sustained evidence can produce a focused, versioned proposal to improve a role’s prompt, maintained instructions, supplied context, checklist, or tools. When the right fix is an agent-definition change, sun agent def edit validates and atomically coordinates the role, model/provider, capabilities, isolation, and system prompt, then hot-reloads it. Monitor cannot apply that change itself: the proposal follows the ordinary review and approval path and keeps a rollback condition.

Facts first, judgment second

Mechanical checks may raise alerts, findings, and evidence changes. They do not automatically invent requirements or mutate issues. An authorized monitor agent investigates the context, applies existing precedent where appropriate, and decides whether to dismiss, escalate, amend the specification, or file bounded remediation work.

This prevents a noisy metric from turning directly into an unlimited autonomous backlog.

The repair loop

flowchart TD
    signal["Alert, failed proof, or audit finding"] --> context["Correlate trail + requirements"]
    context --> judge["Capability-scoped judgment"]
    judge --> work["File or amend bounded work"]
    work --> deliver["Agent + workflow delivery"]
    deliver --> verify["Before/after evidence"]
    verify -->|improved| close["Record outcome"]
    verify -->|not improved| context

A recovery action is not marked successful merely because a command ran. The proof contract requires matching before-and-after metrics and a broker-delivered receipt for the intended target and action.

Independent failure paths

Canaries exercise the alert-to-agent-to-workflow path. A separate watchdog checks the monitoring stack itself and can use an out-of-band provider when the normal bus or dashboard is unavailable. Long-lived field evidence and retention are treated as production obligations, not inferred from a short local test.

Learn from the process

The system records predicted value and later outcomes, review round trips, post-landing defects, reopened work, overrides, token use, and recurring failure classes. Audits can propose changes to work scoring, review criteria, role instructions, or system contracts.

Those proposals still pass through the same provenance, review, and approval mechanisms. The manager is improvable, but not exempt from management.

Build the successor, protect the current version

Supernova’s self-hosting boundary is intentionally conservative:

1. The stable running version treats its successor as an ordinary isolated project.
2. The candidate is built and tested without mutating the running floor.
3. State migration is rehearsed and checked under the current policy.
4. Cutover is bounded, observed, and approval-gated.
5. A tested rollback path remains available.

The candidate cannot approve itself or change the admission rules used to judge it.

What is working now

Alert lifecycle, evidence reconciliation, remediation issue creation, soak evaluation, canary and watchdog exercises, owned telemetry-stack tests, and selected recovery paths exist in the repository. Production long-window evidence, broader provider delivery, and concrete recovery adapters remain active work. See project state.

One platform, clear owners

Supernova is deliberately modular, but it is not a bag of microservices. Every domain has one owner, the same external shape, and typed seams to the rest of the platform.

The five-part system contract

Pick a system name such as issue, agent, or monitor. That name determines:

1. its implementation under systems/<name>/;
2. its stateless client library;
3. its sun <name> ... CLI namespace;
4. its requirements, invariants, interfaces, and file specifications;
5. its configuration schema.

Adding a system follows the same scaffold and validation path. There is no miscellaneous command drawer and no reason for a new feature to invent a second project model.

The client layer is a lens, never a store. It can be rebuilt or discarded without losing authoritative state.

One CLI for every system

The sun CLI is the platform’s shared operating surface, not a collection of unrelated scripts. Every top-level namespace belongs to a system and thinly wraps the same typed client library used by workflows and agents.

Examples show the range:

• sun wiki validate --details . checks requirements, file specs, source annotations, tests, and evidence links;
• sun issue frontier status --json reports actionable, in-flight, capacity-blocked, and genuinely quiescent work;
• sun agent goal ... runs an evidence-bound act/check/park/wake loop;
• sun approval request cmd ... requests a one-command elevation through normal policy;
• sun bus reactor ... manages typed event-to-action bindings;
• sun monitor health --live --json reads the current system and substrate health projection;
• sun vcs ship ... enters the approval-, review-, test-, and evidence-gated promotion path.

Structured JSON is a first-class output rather than a separate agent API. Humans can inspect the same action an agent will take, and policy applies at the owning client boundary regardless of who invoked it.

The system map

System count is descriptive, not constitutional. A domain may be added or folded when ownership is clear and the five-part contract remains satisfied.

Project namespaces are the tenancy model

A running Supernova instance can manage multiple projects. Each project receives a namespace for coordination state and an isolated agent swarm. Cross-project task dependencies are forbidden; explicit pointer tasks allow a root coordinator to express portfolio relationships without merging the projects’ truth.

An existing external repository can be incorporated rather than rebuilt inside Supernova:

sun project register payments --subject /repos/payments \
  --issue-namespace payments --workflow-namespace payments \
  --workflow-task-queue payments --vcs-base-branch dev

The typed binding tells issue, workflow, VCS, agents, permissions, and operations which project boundary they are acting inside. A reusable team template can then spawn a project-specific agent swarm, while a root coordinator uses explicit pointer tasks for portfolio-level sequencing.

Two kinds of state stay distinct:

• Product truth travels with the repository: vision, requirements, specifications, source, tests, and project policy.
• Builder truth stays with the running instance: active sessions, workflow runs, dispatch state, heartbeats, and other coordination records.

External changes are reconciled from exact VCS ranges. The project system classifies requirement, specification, coverage, and document-contract deltas and blocks unsafe dispatch while a namespace is conflicted.

This is project multi-tenancy, not a hosted account-isolation promise for mutually untrusted machine users. Supernova assumes an operator-controlled environment; its isolation boundary keeps projects, credentials, coordination, and agent work from bleeding into one another on that infrastructure.

Global state and project state

Supernova can operate on a machine that does not contain its own source checkout. Global identity, shared credentials, and installation state therefore live under the global Supernova home. Project- specific configuration, policy, and integration state live with the project. Authoritative service state belongs in Postgres, Kafka, or Temporal rather than ambiguous JSON files under either tier.

Rust is the default, not the product pitch

The platform is a Rust workspace because typed contracts, a compact deployment footprint, a single command surface, and source/spec annotation checks serve this architecture well. Off-the-shelf services remain off-the-shelf, and a language boundary is allowed when a mature integration makes it the sane choice.

The important property is not the language badge. It is that every system exposes the same shape and can be validated, operated, and traced through one platform.

Owned infrastructure

Kafka, Temporal, Postgres, the telemetry stack, test runners, and deployment targets are intended to run on machines the operator controls without per-run billing. Projects remain portable and model providers remain replaceable. The platform does not require hosted CI or a managed control plane to function.

Next: what exists today.

What exists today

Supernova is an active, self-hosting construction project—not a concept deck and not yet a finished product. The useful way to read its state is by evidence layer.

Working implementation

The repository contains a substantial Rust workspace spanning the current system set, with hundreds of source files, matching per-file specifications, and extensive unit and integration tests.

Working slices include:

• the sun CLI and typed client surfaces across all current systems;
• requirement parsing, source/spec traceability, evidence declarations, and validation;
• issues, worktrees, lifecycle gates, agent sessions, reviews, and VCS promotion controls;
• event envelopes, topic validation, outboxes, reactor dispatch, and Kafka exercises;
• Temporal SDK connections, durable workflow probes, signals, schedules, and delivery exercises;
• identity, permissions, approvals, encrypted credential stores, and external-action gates;
• monitoring alerts, evidence reconciliation, soak, canary, watchdog, and remediation paths;
• project registration, namespaces, critical-user-journey records, and VCS reconciliation slices.

Supernova uses parts of this machinery during its own development: work is tracked through its issue model, agents operate in isolated worktrees, review and evidence gates constrain closure, and the repository validator enforces traceability.

Proven in the repository

The project has local end-to-end exercises and opt-in tests against an owned stack containing Kafka, Temporal, Postgres, OpenTelemetry, Prometheus, and Grafana. Multiple real producer-to-broker-to- consumer paths are exercised with exact message identities. The wiki validator checks the current source/spec/test graph, and workspace self-checks aggregate trace, workflow, VCS, evidence, and test health.

This is stronger than scaffold-only code, but it is not the same as long-running production evidence.

Still being completed

The main remaining class of work is production closure:

• replacing interim local or mirrored state paths with final authoritative service paths;
• wiring the final provider-neutral agent runtime and broader live model transports;
• exercising external providers and credential materialization over real provider networks;
• carrying production semantics through every command, service, and workflow path;
• collecting long-window field metrics, retention, watchdog, and recovery evidence;
• deepening project reconciliation and state-migration/cutover rehearsal;
• removing residual documentation drift as newer architecture decisions propagate.

The normal standing project inventory still identifies itself as local-only. A production-health fixture can validate all current system rows when the required services and evidence are present, but that fixture is an admission test—not a claim that a released Supernova instance is operating in production.

How this site labels claims

To keep the distinction readable:

• Working means the behavior exists in the repository and is exercised directly.
• Proven in-repo means an automated test or owned-substrate exercise supports the claim.
• Production target means the behavior is part of the current architecture but still needs final live integration or sustained field evidence.

A feature may span more than one layer. For example, the Kafka reactor is working and exercised, while every production producer and recovery route is not yet fully wired.

The near-term test

The project succeeds when an operator can install a stable release, attach a real project, allow the fleet to deliver useful work under bounded authority, observe it over time, and upgrade Supernova through the isolated successor path without hidden manual machinery.

Until that full journey has current evidence, Supernova should be read as an unusually complete working system under construction—not as a production-ready release.