One installation, with release evidence.
./lens setup creates a Compose installation. Its .novuslens.env records the release, access settings and private credentials.
Compose starts the customer-profile services and keeps their stores in Docker volumes.
The Operating section gives the steps for running, stopping and recovering that installation.
./lens doctor checks the running installation and names a repair for every failure.
Deployment runs the same checks before reporting sign-in details.
The checks include the tested sidecarSidecarA separate supporting process that runs beside the application. Here it runs Mycelium and exposes the gateway that NovusLens calls. and SDKSDKSoftware development kit: a package of code that helps another program use a service. NovusLens uses mycelium-py to talk to Mycelium. identity, customer secrets, network exposure and database migrationsMigrationAn ordered change to a database's tables or rules. Applied migration files are recorded so the same file is not run again..
./lens ops is contributor tooling. It builds dependencies and runs the twelve release checks, called gates.
The customer uses the Compose installation commands; contributors use the gates to collect evidence about a release.
How the pieces fit
The Compose installation includes PostgresPostgresThe database software that stores the tables read by the NovusLens screens, along with document bodies, access records and protected personnel records., persistent meshMeshA set of connected Mycelium services that exchange updates and keep the NovusLens log. volumes, an initialisation job and a containerised installer.
./lens backup archives its stores, recovery records and private configuration. Only the archive’s owner can read it.
The pinPinA recorded choice of one exact dependency version. It prevents an update from changing that dependency without a deliberate decision. in config/mycelium.pin names one MyceliumMyceliumThe application infrastructure underneath NovusLens. Its connected services exchange updates and keep the ordered structural log. release. Images carry the sidecar built from that pin and the vendored SDK wheelWheelA packaged Python library ready to install. A vendored wheel is stored in this repository so its exact bytes can be checked..
config/release-manifest.json records their hashesHashA fixed-length fingerprint calculated from content. Comparing fingerprints helps detect changes and match records.. Gate transcripts identify the source and build checked.
./lens doctor compares the running sidecars and SDK with the manifestRelease manifestThe file recording the exact software versions and fingerprints used for a NovusLens release candidate. Installation checks compare files against it. and reports a mismatch with its repair.
The shared common_py package supplies the customer-profile rules used by the services and installation checks.
The pin, binary, wheel, manifest and release checks lead to the installation identity checks.