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.