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.