Operations
Six repositories, one product
| Repository | What it is | State |
|---|---|---|
| neutron | The platform itself — API, web UI, 61 numbered plans. | version 0.6, active |
| neutron-authz | The permission engine, extracted so other apps can use it. Public, on npm. | 0.4.0, live |
| neutron-orbit | The Rust desktop companion: screenshot, input, accessibility perception, voice. | core shipped |
| neutron-site | The public marketing page, with a working waitlist and confirmation email. | teaser, live |
| product | Numbered product design documents, published as a site, each with a lifecycle stage. | PD001–PD006 |
| evidence · runtime-evaluation | Benchmarks and proof artifacts kept beside the product. | supporting |
How a change reaches the live system
Two live instances run today. One is used internally for operations, the other is the developer-facing hub. Getting code to them is deliberately not fully automatic.
The versioning scheme
Merges make builds; tags close versions.
merge #1 → v0.6.4-b1 merge #2 → v0.6.4-b2 … tag v0.6.4 closes it
└→ next merge mints v0.6.5-b1Nobody edits version numbers day to day. CI computes the target from the latest clean tag on the line, and the running build number appears in the app itself. Closing a version is a deliberate act at a deploy milestone.
Every merge request that touches application code must add a changelog entry, and CI fails the merge if it does not. Genuinely non-user-facing changes opt out explicitly rather than silently.
Secrets
Three storage backends are supported behind one seam: a plain database table, an external secret manager, or the bundled encrypted vault in the assay-engine sidecar. The seam exists so a deployment with no external dependencies still works, while one that already runs a secret manager does not have to run a second.