Now live on orbitforge.dev

Evidence center

OrbitForge is designed around proof, so the public site should show that standard too.

This page explains the kinds of evidence OrbitForge expects before something is presented as finished, healthy, or ready to ship.

Proof bundles

Route coverage

Validate the public routes that shape first impression and buyer trust: home, docs, pricing, download, deploy, status, and evidence.

Build integrity

Confirm the repo builds from the same state that was deployed so screenshots are not hiding a broken pipeline.

Release parity

Keep docs, pricing, downloads, and public claims synchronized with the actual surfaces shipping today.

Verification inventory

Public routes

Home, features, docs, deploy, pricing, download, status, and evidence all render without private localhost dependencies.

A public product site should not collapse when it leaves the development laptop.

Health endpoint

The hosted app exposes `/api/health` for uptime checks and deployment validation.

Operations and trust need a machine-readable status signal, not only screenshots.

Release content parity

Pricing, downloads, docs, and the README describe the same shipped surfaces and deployment flow.

Public claims need to match reality across every surface a new user sees.

Cross-surface install story

The repo documents web hosting, CLI packaging, desktop targets, and VS Code packaging together.

A product feels unfinished when the installation story changes by surface.

Next action

Use the health endpoint, deploy guide, and status page as part of one proof story.