Skip to content

Operations

Six repositories, one product

RepositoryWhat it isState
neutronThe platform itself — API, web UI, 61 numbered plans.version 0.6, active
neutron-authzThe permission engine, extracted so other apps can use it. Public, on npm.0.4.0, live
neutron-orbitThe Rust desktop companion: screenshot, input, accessibility perception, voice.core shipped
neutron-siteThe public marketing page, with a working waitlist and confirmation email.teaser, live
productNumbered product design documents, published as a site, each with a lifecycle stage.PD001–PD006
evidence · runtime-evaluationBenchmarks 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.

merge to mainchangelog requiredCI builds imagetagged as a builda human bumpsthe version filecontroller noticesand syncsinstance Ainstance B

there is no auto-bump — this step is manual on purposeVersioning: every merge produces a build of the next version. Tagging closes a version, and the counter resets.One version file covers both instances, so they move together.

The only manual link in the chain is the version bump — the same governed-autonomy instinct applied to the product's own release path.

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-b1

Nobody 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.